Some Android devices extremely slow when rendering canvas elements

Question

Im developing an app for android devices, and found that samsung galaxy S4 specifically, has extremely poor performance when app/web page uses canvas. Odd thing is, that its not always the case.

I have tested 2 sample apps.

http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html

and

http://ie.microsoft.com/testdrive/Graphics/TouchEffects/Default.html

the first one works fine, and outperforms my Nokia (which is dual core) and is expected. However, the other demo, is almost completely unresponsive and framerate is close to 1, where as all other devices render it fine.

Since the first app runs well and the other one doesnt, it beggs the question, why ? First one has no event listeners, where as the other one has touch listeners. Could touchmove be the cause instead of canvas...or is that demo using some canvas features that the other one isnt, and thus has poor performance.

I have read lots of topics about this issue, and none seem to have answer. Most are many months old...so i thought ill make a new topic.

Is there any way to solve the canvas issue on Samsung S4 ... and potentially other android devices running 4.2.x. If any StackOverflow users here has S4, can you test both demos and confirm my observations?

Answer 1

I strongly suspect this is not a Canvas specific issue, but a requestAnimationFrame issue. The first animation does not attempt to use requestAnimationFrame, but the second does, in this file on line 206.

Android Browser on firmwares <= 4.2 does not support requestAnimationFrame, and instead uses setTimeout, dividing one second by specified frame rate in Hz, which executes renders in the normal event loop.

setTimeout does not execute at the exact time in milliseconds requested, but enqueues the event in the loop at the time specified. If the event loop is hung by other javascript on the page, or the single-core device decides something else is more important, the runtime is very vulnerable to de-prioritization without the requestAnimationFrame API, and the callbacks enqueued using setTimeout will stutter and bunch. More on setTimeout resolution and timing.

Unfortunately, you are at the mercy of the event queue if you are (1) going with this Canvas-based approach and (2) on a platform that does not support requestAnimationFrame. Here is the reference table for what browsers support the feature.

Cheers!