I have a question about performance of Forge Viewer, and i think its big problem when the end users approach this technology. In Debug enviroment its so smoothly, i dont have any problems, model doesnt reload all the times. However, when i deploy application, its a different story. Take a look link below you can see how it lag, like the model reload all the times when ever i do something.
I use Firebase for my frontend and Azure for my backend. What is the problem or i must config something?
https://youtu.be/c4QbAknZNRY
Appreciate any comments.
Paxton.
Related
How do I debug GCF without deployment?
Is there a way to debug functions faster while having access to GC storage? Much appreciate!
Currently, Im working on trying to use GCF to access GC storage to retrieve ML model and process images. The function will retrieve the image from the same bucket, run the image through the Ml and paste ML model results to a text file with time and image name.
As a beginner coder on GCF, im constantly having to debug and therefore looking for a faster way to debug without waiting for deployment.
A function is simply a piece of code! Run it to test it.
If you want to do that easily and in a similar way as Cloud Functions run it, you can use the Function Framework, compliant in many languages.
Personally I prefer to wrap my code in a custom webserver, as I described in one of my first article here. And rapidly, I choose to abandon Cloud Functions to Cloud Run, again in a pretty recent article
You could have issues with authentication and stuff like that, let me know if it the case (and do not generate a service account key file ;) )
After switching over to SVF2 await aggregated.waitForLoadDone() sometimes blocks indefinitely. Unfortunately I can't reproduce the issue deterministically. It can happen right after starting my app, after loading/unloading models or not at all.
I did not observe this behavior previously, but I wasn't able to (ab)use the viewer like this until now (eg. rapidly switching between very large models, some half-broken). Kudos for SVF2, performance is mind-boggling.
My current workaround is to Promise.race the waitForLoadDone() and reject after 10 seconds. This is working ok and keeps my app in a consistent state.
I have a suspicion that the problem might be network related.
Edit: I narrowed it down to the property model.getData().loadDone which sometimes remains false forever.
Edit2: This is getting worse with every release. I'm now on 7.60 and the viewer constantly breaks. Some objects never load, websockets get stuck and don't transfer any data, users need to manually clean their browser cache. How can this possibly pass any QA?
I'm afraid that this could be - as you pointed out - a network issue. You may have noticed that the SVF2 format uses WebSockets to transfer the granular asset data to the browser, but if that persistent connection breaks, it's possible that the viewer wouldn't be able to recover.
Next time you see this happen, please check the console logs (and share them here if possible) and the network tab, to see if the WebSocket connection is still active. If it is, and the model still isn't loaded successfully, please submit a report to forge (dot) help (at) autodesk (dot) com with as much info as possible so that we can debug it on our side.
I am trying to figure out a way to do an internet connectivity check for an AIR for iOS app. Previously, I was using (against my better judgement) a URLMonitor that checked Google once every 30 seconds. I did not like putting that load onto Google and neither did they; this morning, our network got flagged as a possible DDoS attacker simply from testing the app. So I had to disable this type of check and move on.
I have thought about using the NetworkInfo ANE from Adobe, but that presents its own issues in determining internet connectivity. The only way I can think of doing it is to check for interfaces "en0" and "pdpxx" (which correspond to WiFi and Cellular interfaces, respectively) and check their IPs to ensure they are not in the 192.168.x.x, 10.10.x.x, or 127.0.x.x ranges. However, I am not entirely sure those are the only static router/localhost IPs out there and there is always the possibility that the network interface names will change in the future, which would render this monitor useless. There is also the issue of IPv6 possibly throwing a wrench into this method as well.
Is there another way to check if the user is connected to the internet? I've searched multiple times and it seems that these are the only two ways to check. If that is the case, what is the best way to check?
I'm surprised that you got flagged as a DDoS attacker, are you sure that's what happened?
In any case, if your not happy with putting the load onto someone else's server, then make your own server, just a basic setup that you use with the URLMonitor. You don't have to use google's url with the URLMonitor, you can pass it another URLRequest, which could point to your own server.
monitor = new URLMonitor(new URLRequest("http://www.you-own-server.com"));
This might also be useful if you decide that you want to pass more data between the app and the server. It's your server, so can do what you want with it.
I don't think there's any other way to check if the user is connected to the internet. To be honest, I don't see why there would be. Checking for the users interfaces/wan0 etc... probably would be possible, but you'd need another program, maybe a simple python or c++ program, that Air could use to check these things, but that sounds like the long way round.
so I load large amounts of data from services. I just updated our project to the latest 4.7 FB with Flex 4.9 SDK and AIR 3.4. Implemented workers. They seem to work great for one-off tasks EXCEPT when it comes to internet data loading. I haven't found the magic limit yet, but it seems as though if you load an internet request (Loader, URLLoader, HttpService... whatever) that is receiving a large replay, the worker just locks up and quits. The main thread can do this just fine in all cases (but with UI being unresponsive until the load is done). This is why I was so excited about workers is to offload the sometimes large data loads to the background workers.
Has anyone else run into this? I saw comments on the Worker class docs online where a few other people have seen similar problems and suggest putting data loading from the internet back on the main thread. Seems like "what's the point of a worker then"?
Can they only do local calculations? Math is cool... but HTTP Gets are not?
I tried giving the worker app privileges.. no help there. Is there a magic worker.canloadlargefiles = true? (rhetorical).
Any direction or help here would be greatly appreciated.
Well not a solution, but a workaround. Instead of digging internals of VM, use KISS (Keep It Simple and Stupid) principle, divide your data into managable chunks. You do not need to divide the files or data but can tell the server do it by a request format so it sends you manageable portions of data that will not timeout the VM. Retrieve and join the chunks on the client side to form the big file back.
Thats my two cents.
This is an odd freeze. When I switch from source view to design view for an HTML or ASPX file, the client area freezes, but I can still click on other tabs and menus.
What am I missing here? Really don't feel like reinstalling VS2008.
I had the same problem, and found one resolution.
In VS 2008, In a page that was using a master page, the either frequency while working in source view or switching to design view, IDE would freeze for 10-20 seconds.
In my master template, I had references to the Google hosted JQuery, Jquery UI, and one or two more scripts off site. These were placed directly in my master page's head section.
I downloaded the js and then by deleting any offsite references, my IDE would be smooth again in both design and source mode.
I also discovered I could put the scripts inside my ToolkitScriptManager (I'm using AjaxControlToolkit) and added the Mode="Release", and could place the http://www.google.com references for the scripts. The IDE is still working fine for me.
This is often due to the Design mode downloading external resources that are timing out. As #JonK mentioned, for him it was jQuery references. I have seen this when the ConnectionString was set to production databases that could not be accessed on my development machine, even though I wasn't debugging (running) the site only editing code, it would still try to connect and because it couldn't it would stall waiting for the timeout.
VS2008 is mostly single-threaded for UI operations like this, so if it is downloading a slow or non-existent network path it hangs like this.
VS2008 can make all kinds of network requests, so these two examples may not solve it for you. The best way I have found to diagnose the problem is to use the Microsoft tool Process Monitor, filter by the Process webdev.exe, and watch for I/O requests that are long running and/or throwing errors. In my case, I could find the place that was having a problem because there would be a 20 second gap in between the hundreds of I/O entries in Process Monitor. Then, just back-tracked from when that gap began and I eventually found the request that was causing the problem.
This may not be possible for you, but if you can, an upgrade to VS2010 would help; it does a much better job of running process on multiple threads in more places so you don't have to worry about this as much.
Have you tried restarting your computer and then reopening your project?