A few days ago, I was wondering about why my canvas is not working properly. I'm using szimek's library to create signatures and sometimes those pen strokes looked a bit crazy. I also tested on Edge (which ended in the same result as Chrome) and TOR (worked as it should).
Yesterday, I found the solution why this happens randomly. My strokes look crazy during the usage of the browsers developer console when it's open. If it's closed, they're looking normally (when drawing again).
Does anyone know why this happened or is it caused by it's core engines?
Here's an example of what I mean:
Thank you.
This happens because in Chromium (and in Gecko), as per specs recommendations, UI events like mousemove or pointermove are throttled to the frame refresh rate of the monitor.
However, in Chromium only and for whatever reason, when the dev tools are open, they emit the raw events...
So when dev tools are closed, even though the hardware pointer (e.g mouse) did emit more events, these have been coalesced into a single pointermove event, which may draw lines smoother to the eye since each point have been averaged, but you actually received less data.
You can retrieve the list of raw events from the pointermove event's getCoallescedEvents, as exposed in this other answer of mine, and from these you could also build up the coalescing logic yourself if needed (using requestAnimationFrame() as a throttler, that's exactly what Chromium does).
As to why Chromium does disable the coalescing when dev-tools are open... that's still a mystery for me, but I never got enough incentive to look this up.
Related
I've found some similar question on Stackoverflow but it does not really address my problem.
I'm playing multiple videos into a WebGL texture, one after another. It's based on user input, something like a web-based VJ tool.
Copying is done easily, and I have internal clock that is sync with same fps like the video I'm playing (eg. 30fps) and frames are updated correctly. Exactly like one of the answers offered in the above mentioned question. All that works well.
Texture is updated with:
gl.texSubImage2D(gl.TEXTURE_2D,0,0,0,this.gl.RGBA,this.gl.UNSIGNED_BYTE,video);
My problem is how to detect when the very first frame is available for composition. Video does not start playback immediately in the real environment (eg. average 4G, video on CDN), but sometimes takes 1s or more to start playback (to buffer sufficient data).
If I attempt to start updating texture prior the first frame is available, I get WebGL error thrown:
WebGL: INVALID_VALUE: texSubImage2D: no video
I'm aware of video.load(); method that can be called in advance (eg. on user interaction), however I have ~50 video files that I need to play (in unknown order as it depends on user input), and older phones (like iPhone 7) have major performance drop when I do that, to the point Safari sometimes crashes.
I'm looking for a reliable way to determine when video started actual playback. Events such as onplay don't seem to fire when first frame is available, but much earlier.
I have also tried ontimeupdate event, but that one does not seem to fire when first frame is available for composition, but earlier as well, just like onplay. I can see the event fired, and I start updating texture when it's fired for the first time, but at the beginning of updates it generates WebGL error (for about 0.5-1s, depending on network speed) until video actually shows the first frame. Once buffered, no errors are thrown.
This issue is more visible in 4G/mobile network. Also tested in Chrome with throttling speed. Un-throttled speed will get me 1-4 WebGL warnings prior showing first frame, while eg. 12mbps throttled will give me 100-200 warnings, prior video frame is presented.
I've seen requestVideoFrameCallback but it doesn't have coverage I need (iOS Safari not even planned anytime soon).
I'm trying to avoid updating texture if video frame is not ready for composition, but can't find a reliable way to determine when it is ready.
Any help is highly appreciated!
Alright, I have found a solution at listening on playing event.
I was listening on play and on timeupdate, didn't think of on playing being so different.
It does fire after the first frame is available for composition and now I don't have anymore those WebGL errors. Tested on an Android 10 device as well as on iOS 14.5 iPhone 7 device.
I'm having a issue which is hard to debug. I'm using a Javascript library (the JQuery Flexslider plugin) in a number of different places on my site. It's all working fine except for one particular phone where it doesn't work and slows down everything on the page.
So far, I've only seen it happen on this one device. Other devices of the same type do not have the issue. This person has an iOS that's a few versions out of date and not much memory, so I think it's a memory issue.
An old hack was to move the carousel element that has the issue on the page with Javascript, but I want to find and fix the root issue.
How can I start debugging this? I'm not sure how to test for a memory issue on a device.
If you're on a Mac, then you can plug in and use remote debugging via Safari, where you'll have access to the tools, including the profiler (not sure the state of Safari support in Windows). There are numerous resources for showing how to remotely debug a device, unless it is a really old version of iOS you should be fine, you’ll have to enable the develop menu via settings but after that its plain sailing if you know your debugging tools.
I'd agree that it doesnt really sound like a memory issue, although jQuery tends to be hungry in that respect, I dont know the plugin in question but the quality of plugins is hugely variable in jQuery-land. Old phones and old versions of jQuery certainly never played well together.
When you say one phone, you mean one type of phone + iOS version? The question isnt clear, its almost reads like you have 2 identical phones/os's where 1 works and 1 does not.
If you use Chrome you can use the Heap profiler
First open your developer tool and start recording.
Next start using your page and try to replicate your issue, stop recording and review the stats.
This is likely not a memory issue, but a cpu issue. The way jQuery does animation is processor constrained on older dvices. Factors that are easiest to handle include:
size of the page (html length and complexity)
animation steps, length, and complexity
You have a couple of options here, but the simple answer is you are asking too much of the older processor. Assuming you are using this plugin http://www.woothemes.com/flexslider/ you could try disabling or simplifying some of the transition effects. animation and animationSpeed would be the first I would suggest.
If you are interested in not changing the experience for most users you could consider tying into the start and end functions on the callback api and checking the time it took to perform the first transition, then reinitialize a simpler version of the slideshow for that device.
The hard thing here is there isn't really a right answer. If one of the above options doesn't fix it you're likely looking at choosing/building a different slideshow, degrading the experience for everyone, or determining the best way you feel comfortable with choosing who gets the degraded experience.
Can anyone explain why the provided canvas animation stutters? I've created a test stub which demonstrates the problem.
I see the stutter in FF, Chrome, IE on desktop and in FF and Chrome on Android.
Is the stutter due to garbage collection? It seems even raf generates a double on each call which eventually requires gc. If gc is the cause then html5 animation is pretty much doa. Sigh.
The same question was asked a year ago but because I'm a new member I'm not able to contact the author to find out his solution. HTML5 Canvas DrawImage Stutter / Choppiness . It is really too bad there is no way for a new user to get another user's attention, since the author of that other question may have the information I'm looking for, an simply hasn't posted it. I tried posting to his question in an effort to get his attention, but my post there was deleted as a rules violation(which is was). Guess I'm out of options. Chicken and egg problem with rep.
Ok, so after pulling my hair out for 1.5 days I think I have an answer. It appears browsers vsynch to a monitor, which I guess is the point of calling requestAnimationFrame. It appears the synch mechanism can get confused when running on a multi monitor system. I have three monitors. When I disconnect all but one monitor and restart the browser, the problem appears to go away. This kind of makes sense given that the problem manifests sporadically, ie I'm guessing when a given monitor gets out of synch with which ever monitor is providing vsynch to the browser.
Since I'm not certain about this I'm hoping others can confirm or shoot down my theory. I'll continue to (re)test with different monitor configurations, but it would be nice to get confirmation from another brain and set of eyes.
Edit 01: I'm not completely nuts. http://news.softpedia.com/news/Firefox-Nightly-Adds-Support-for-Vsync-for-Smooth-Animations-360245.shtml
Edit 02: Some chrome users/devs has discovered this or a related problem. Finally something might be done with this issue. See https://code.google.com/p/chromium/issues/detail?id=422000. BTW, IE11+ does not have this issue. Started using IE11 for baseline testing, since chrome is having QA issues lately.
Edit 03: Just ran across this q&a which is similar. Good info in the first answer. Chrome requestAnimationFrame issues
I'm facing a strange behavior on mobile Safari on iPhone4 and iPhone5 on iOS6.
What I want to do
Tracking the user's location in the browser with high accuracy, using
geolocation.watchPosition({ enableHighAccuracy: true, maximumAge: 0, callback })
Problem I'm facing
Normally, when the device is outside, under clear sky and moving, the accuracy und the update period of the GPS positions is very good.
The coords object passed to the callback has an accuracy of 5 meters, a correct heading value is given and when moving the callback gets fired at least every 500ms.
But: Sometimes the watched position never gets accurate, even though I test it under the same conditions (as far as possible).
Also, the update period is much longer, almost 30 seconds.
Basically, in this cases, the HTML geolocation is not useable for the accurate tracking of a position.
Observations
This seems to happen, when the GPS-Sensor is not on "Hot-Standby", I mean it was not used for some time (not sure how long) by another native app.
Reloading the page, re-allowing the GPS access and re-initializing the watchPosition does not change anything, still bad accuracy and slow updates.
Changing the options passed to watchPosition does not seem to do anything.
Manual fix 1:
Close Safari
Open another native app like Maps or GMaps
Determine the position in the native app
Open Safari
GPS position is immediately accurate, following position updates are fired again in 500ms periods and are very accurate as well (no reload needed).
Manual fix 2:
Close Safari
Open settings panel
Disable Wi-Fi
Open Safari
Again, problem fixed (without a reload)
Conclusion
When the problem occured, I looked into the coords object of the callback and detected the following:
Even though the passed location is far away from the real position of the device (> 1km), the accuracy passed is much smaller (very often at 165 meters). The heading is never given.
When WiFi on iPhone is disabled, there is a hint in the settings panel that says enabling WiFi will enhance the accuracy of determining your location (because of AGPS which is supported by a datase of geocoded WiFi networks). But as far as I can see this is not true if you want to use GPS in mobile safari. In fact, it does the opposite.
It seems to me that mobile safari does something like this to determine the location:
If GPS is already activated/in use on the device, it uses the GPS sensor (fast and accurate position updates)
If GPS wasn't active before and WiFi is enabled, the device only uses its WiFi database to get the location. (very slow updates, not accurate). It just updates from one WiFi location to another. You can see this very clearly e.g. if you drive on federal roads, as your location mostly get mapped to the next residential area.
Only if GPS wasn't active before and WiFi is disabled mobile safari will use the GPS to determine the location of the device (again, fast and accurate).
Question
Can anybody confirm my problem and my observations?
I worked with the geolocation in earlier iOS versions but never faced this problem before.
Is it a known bug for mobile safari, any chance that this will be fixed? Or am I just missing a better configuration of the watchPosition to get better results?
A lot of people have described similar problems including myself. I have described my problems on page 5 and onwards (as alstorp) in this discussion https://discussions.apple.com/thread/4313850?start=45&tstart=0
Read and see if it matches your problem.
The problem is that, as far as I know, Apple has not confirmed this. Are they working on fixing it? Is it really on their side? Is it really a bug? Therefore we do not know when/if it will be fixed...
Is there anyone out there that does NOT have problem with browser based geolocation in iOS 6? (even after multiple tests in different situations).
Have you tested your fixes extensively? My experience is that this type of fixes helps in some cases but not all the time (or for long periods). It would be really interesting if they work reliably for you...
(also check IOS6 geolocation watchPosition Callbacks fail
iOS 6 breaks GeoLocation in webapps (apple-mobile-web-app-capable) )
Can anybody confirm my problem and my observations? I worked with the geolocation in earlier iOS versions but never faced this problem before.
I tried watchPosition(onGeoSuccess,onGeoFail,{enableHighAccuracy:true}); in my web app using my iPhone (iOS 7.0.2).
With WiFi on accuracy was really bad, sometimes a mile off. With WiFi off accuracy was near perfect, with an occasional discrepancy of a couple hundred feet.
I have yet to test to see if helps to leave the GPS running between capture points, or if it's better to leave it off until you're at the next capture point and let the watchPosition() function settle.
I'm making a small game using the HTML5 canvas element. It works great, except that it has a scrolling background with obvious tearing happening in Firefox and Chromium browsers in Ubuntu. I'm pretty sure it's buffered because there isn't any of the flickering I'd expect; just tearing. Is there any way to work around this or time rendering to right after the last screen refresh?
Currently there is no way to control the actual repainting of a canvas element(which if there was, could actually help in increasing performance I guess). So one can only hope that the browser actually does something intelligent, rather than screwing up like in your case.
I myself have quite some experience with the canvas element and know of its quirks. I ran into some kind of "repaint lag" several times by now, where obviously the actual numbers behind the scenes are correct and "smooth", but the graphics still have a somewhat "jumpy" behavior, which in fact is really annoying.
Only thing I can imagine that could have an effect in your case, is activating VSync in the driver settings of your Graphics Card.
If you'd like to provide a link to your game that might be helpful too, since I'm also running Ubuntu here.