+++ This bug was initially created as a clone of Bug #716121 +++ Ashley Gullen of Scirra.com writes (via email): > We make a HTML5 game creator (see www.scirra.com for more). We've come up > with a performance test which seems to pretty reliably expose inefficient > HTML5 canvas implementations. We wrote more about it in this blog post: > http://www.scirra.com/blog/85/the-great-html5-mobile-gaming-performance-comparison > > The test is here: http://www.scirra.com/labs/sbperf/ > > We also have a WebGL renderer, and you can try the WebGL enabled version here: > http://www.scirra.com/labs/sbperfgl/ (The first one will use WebGL on a > desktop machine, but we disable it on mobile for the time being for reasons > mentioned below. The second one uses WebGL regardless of the device.) > > It's fully automated and reports a score of the average framerate. It's not > super scientific but it gives a ballpark figure of the kind of performance you > can expect from the browser. > > You'll see the Firefox Mobile I tested at the time of the post only got an > average framerate of 7. The latest version gets 11, so it has improved, but > it's about the same as the stock browser, and is still unplayable. Note the > Chrome for Android beta gets 24 on the same device, and a non-browser engine > designed specifically for performance (CocoonJS) scores 34. So it ought to be > possible to make Firefox about 4x faster than it is now. Is Firefox for > Mobile's 2D context hardware accelerated? If not I suppose that is the > problem. In case you aren't aware, software rendering rules out most games, > even on desktop machines, so consider missing GPU acceleration as a complete > blocker for HTML5 games. If you do have GPU acceleration, something's > seriously wrong! > > The WebGL version is broken in Firefox for Mobile. The screen is black, and > the performance is even worse. I'm not surprised it's slower - the WebGL > renderer is generally only faster on desktop machines because the javascript > engines and powerful CPUs can issue quads faster than the browser native code > can. However it definitely is broken in some way, and it might serve as a > useful benchmark if you want to try improve WebGL performance. Can we figure out what we could do to improve our performance on this canvas benchmark? (We should file a separate bug for the WebGL test if it's not covered by existing bugs.)

Can we get a profile here?

I filed bug 768982 about the webgl issue.

We're hitting a pixman slow path on this demo. I'll try to figure out why.

We're hitting slow paths here because of a couple of things: - Images without an alpha channel are optimized to r5g6b5 and we don't have very many fast paths for doing operations with r5g6b5 images on top of a8r8g8b8 canvases. - Drawn images are not snapped to pixel locations which means there edges need to be anti-aliased which can be more expensive. I expect the performance of this benchmark would improve if these two things were true.

Isn't the canvas GPU accelerated? If not is that planned? Things like mid-pixel positioning are very expensive for software renderers, but pretty cheap on a GPU.

(In reply to ashley from comment #5) > Isn't the canvas GPU accelerated? If not is that planned? Things like > mid-pixel positioning are very expensive for software renderers, but pretty > cheap on a GPU. No the canvas is not currently GPU accelerated. It is planned, but will probably not happen in the short term.

Is this a useful benchmark to test canvas? I don't believe we have much in talos to track this type of performance, so we need something.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4) > We're hitting slow paths here because of a couple of things: > - Images without an alpha channel are optimized to r5g6b5 and we don't have > very many fast paths for doing operations with r5g6b5 images on top of > a8r8g8b8 canvases. Is this something that we can realistically fix? Maybe if the image is written to a canvas, we deoptimize it back into 8880? > - Drawn images are not snapped to pixel locations which means there edges > need to be anti-aliased which can be more expensive. True, though this is a best-practice fix that needs to happen in the benchmark; we can't really affect this from our end.

filter on [mass-p5]