I try to synchronize VR scene using GunDB.
In order to experiment it, I put a few data in GunDB.
But I got this warning.
storage warning
I use IndexedDB, and I can keep going it with hitting 'allow'
But I'm wondering why it uses too much storage!!!!!
setInterval(putLocation, Math.ceil(1000 / 50));
// putLocation
obj.get('attributes').get('position').put(object.attributes.position);
It updates data every 200ms in the same node. (object.attributes.position)
please let me know how could I fix it.
Thank you.
#huhsame 1.2GB for VR scene data? That seems suspicious.
By chance is this in Safari?
Safari has a known bug (#go1dfish found this) where it creates run-away storage accumulation (with or without gunDB) that gets triggered if its file descriptor is left open too long.
Could you see if the same thing happens in Chrome? If it does, it is a GUN bug then.
If it is just Safari, we tried to add code that would reset/reopen Safari's IndexedDB instance every 15 seconds, and have had success so far with that approach.
However, clearly, either Safari has changed something, or that workaround is no longer viable, so we'll need to figure something new out.
I understand Safari is very important because of iOS, it is just unfortunate that Safari lags behind on several very serious and important fronts (WebRTC, IndexedDB, & WebM). There is only so much our team can do to work around these bugs until Safari is more standards compliant. But where we can workaround, we will.
#marknadal
thanks for your answer.
and sorry I am late.
I tested it on Chrome and Safari after clearing storage.
after 30 minutes, Chrome used about
1MB,
and on the Safari, I did not find the usage panel but there is no pop-up for warning like the previous one.
I guess it was total data since September when I had started this experiment.
but it's just my opinion.
And I am still wondering that users should delete data in WebStorage regularly?
please answer me.
Related
Is there a replacement for the RadioInfo that was removed as of OS11? (com.android.settings/.RadioInfo)
If not, where else can this information be found in UI? Or adb? (preferably without rooting the device)
Our team relies heavily on the use of the data in RadioInfo for QA testing, especially since it works on nearly all Android devices (rather than being OEM-dependent like engineering short codes).
It also offered ideal granularity in network selection, moreso than the basic Settings UI.
Also, why was it removed? I looked back about 11 months in logs and didn't see a single mention of it (though maybe I'm looking in the wrong place - if there's a comment on it somewhere, please do share the link).
Looks like it just got moved.
10 and earlier:
com.android.settings/.RadioInfo
as of 11:
com.android.phone/.settings.RadioInfo
We have been using the following library for months:
https://unpkg.com/react#15.3.0/dist/react.min.js
Yes - I know we can just reference 15.3 and get the URL rewrite to the latest, but they released a breaking change. That's another issue for another day. Don't get distracted.
Yesterday this simply stopped working. You'll notice that if you load the URL mentioned, that the file is TRUNCATED. Simply cuts off. This made everything we use react with break. Interestingly, if you go to the following URL (without the .js extension) - things work.
https://unpkg.com/react#15.3.0/dist/react.min
My question is - what the heck happened? Why did the URL we've been using for 8 months suddenly stop working, and who can we get to fix it. In the interim, we had a copy locally that we've started referencing (which we probably should have been doing to begin with, since we don't want the automatic upgrade). When things like this happen, who do you inform?
I'm not sure you'll find the answer as to why this file is no longer working here but based off of the website you could reached out to the creator on twitter: https://twitter.com/mjackson
On the website it says:
SUPPORT
unpkg is a free, best-effort service and cannot provide any uptime or
support guarantees.
i.e. you should probably only use this link if you are messing around with a small project and shouldn't be used for any website where you actually care about the uptime of the site.
I am using a Oculus DK2 (v0.8) and OSVR SDK. I'm having a problem getting the HMD to run/display anything.
The Oculus samples and the OSVR samples do work however, so the osvr_server seems to run fine.
My application itself renders a test scene just fine when not using a HMD.
I tried two approaches:
First, just creating a osvr context and creating a DisplayConfig object. This seems to work, but DisplayConfig::checkStartup() fails (I do this in a loop, calling update on the context when the checkStartup call is failing). I used the OpenGLSample.cpp as a guide for this
Second, I tried using a RenderManager, but the call to createRenderManager results in a crash within the RenderManager.dll. I get the same crash wether I create the graphics lib object myself or if I let the library create it.
I am quite stuck now, since the demos and examples do work, I have no idea where to look for the error on my side. Creating the context works, querying interfaces as well, but the crash with createRenderManager is beyond me.
Does anyone have any hints or ideas what the problem could possibly be?
Regards and thanks in advance
pettersson
RenderManager should not crash during open. There have been a couple of bug fixes recently to avoid that happening, and the latest RenderManager binaries, libraries and header files are available with the SDK download from http://osvr.github.io/using/ along with updated copies of the example programs.
When something goes wrong in RenderManager, it usually reports that to standard error. We're moving that to a logging interface, but for now it should show up on the console. Posting an output of that as an issue at https://github.com/sensics/OSVR-RenderManager/issues is a good way to let the developers know that there is a problem. Of course, providing the same sort of information you provided here will be helpful as well.
I have a FLEX 3 frontend that worked fine in FlashPlayer 9. But now that I've upgraded to FlashPlayer10, the ?_method=PUT/DELETE hack is not working anymore. All those requests show up as a POST on the backend now. I did some reading and it sounds like I need to use as3httpclientlib AND run a socket policy server to give access to port 80 (or any other port) in order to use as3httpclientlib. So my question is: are you freakin kidding me? How is it that, in earlier versions of Flex/flash player, all I had to do was add a simple string ("_method=") to the url. But now I have to do the hokey pokey AND turn my self around? Really? Please someone tell me that I've got this all wrong, and that _method= is, in fact, still supported. Otherwise, its BYE BYE FLEX/FLASH PLAYER - NEVER AGAIN!
I understand you very much, my friend, just had similar noise with authentication headers in new one Security Policy from Adobe. Anyway, if you'll share your code, maybe I could help you, because your goal is not clearly explained in your post, Buddy. So let me know please, cause java sandbox and silverlight are not the better way in this case. But maybe some javascript stuff could save our time.
I have a Webview that must load an image! When I upload this image I see every time the same image as before, and i must reboot my app to see the new image...
I think is a cache problem..How can I solve that??
One quick and easy method would be to append the current time stamp onto the url whenever you load it.
So instead of loading:
http://www.myhost.com/myimg.jpg
you'd load
http://www.myhost.com/myimg.jpg?12345689
Using a cache breaker like this is a very common method in web development to force reloading of content.
I did do some quick googling and it appears clearing out NSURL's cache won't do the trick. In 10.6 the api reloadFromOrigin: may do the trick, but I'm not aware if this has made it's way onto the iphone yet.
Edit:
I found this page in the docs. It looks like you can use the preferences system to say whether or not to use caching. Not tested, but that'd be something to look at.