768959 - Poor canvas performance in Scirra benchmark on Android

Status: NEW

(Core :: Graphics: Canvas2D, defect, P5)

Description

[Matt Brubeck (:mbrubeck)]

+++ 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.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Can we get a profile here?

Comment 2

[Jeff Muizelaar [:jrmuizel]]

I filed bug 768982 about the webgl issue.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

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

Comment 4

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 5

[ashley]

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.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(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.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]