1108527 - Severe canvas performance regression compared to Firefox 29

Status: RESOLVED WORKSFORME

(Core :: Graphics: Canvas2D, defect)

Description

[Daniel Szabo]

Attachment: simple canvas performance test

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141201162954

Steps to reproduce:

Open the attached html page on an Android device running Firefox 30 or above.
Compare the results to Firefox version 29 or below.


Actual results:

Actual result on a Nexus 7 (running Android 4.4.4):
for Firefox 30-35: frame rate is 13..14 fps
for Firefox 26-29: frame rate is 60 fps


Expected results:

Frame rate should be 60 fps.
The sample is a really simple one: each frame, it just copies an opaque background image to the canvas.
Due to this bug, Firefox is not a valid platform for html5 games currently.

Bug 1072403 may be related to this issue.

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

I get 60fps on a few devices I tried here. I'm charging my Nexus 7 to try that.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Nexus 7 2012 or 2013? http://en.wikipedia.org/wiki/Google_Nexus#Nexus_7

Comment 3

[Aaron Train [:aaronmt]]

gfx.canvas.azure.accelerated and gfx.canvas.azure.backends preferences in about:config are not altered right?

Comment 4

[Daniel Szabo]

(In reply to Kevin Brosnan [:kbrosnan] from comment #2)
> Nexus 7 2012 or 2013? http://en.wikipedia.org/wiki/Google_Nexus#Nexus_7

It's the 2012 version, Antutu reports NVIDIA Tegra 3 GPU

This bug may be chipset related:

- on a low end tablet with Mali-400 GPU frame rate drops to 5 (FF34) from 15 (FF26)
- on an LG L90 phone with Adreno GPU frame rate is OK (60 fps)

Nexus 7 2013 has an Adreno GPU according to wikipedia.

Comment 5

[Daniel Szabo]

(In reply to Aaron Train [:aaronmt] from comment #3)
> gfx.canvas.azure.accelerated and gfx.canvas.azure.backends preferences in
> about:config are not altered right?

Didn't change anything, all tests were made after full uninstall/reinstall.

Comment 6

[Daniel Szabo]

Actually, changing "gfx.canvas.azure.accelerated" to "false" results in 36 fps (instead of 13)

Comment 7

[Daniel Szabo]

Additional tests:

quad-core phone with PowerVR SGX 544MP GPU: 9-10 fps
quad-core tablet with Mali-400 MP4 GPU: 6-11 fps

Comment 8

[Richard Newman [:rnewman]]

Nice test case from my dupe.

Comment 10

[Aaron Train [:aaronmt]]

Confirmed terrible on the Nexus 6.

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

Sadly, the fix for bug 1123084 is going to have made this even worse.

Comment 12

[Lee Salzman [:lsalzman]]

I tried on my Nexus 6 with recent Fennec nightly build, and I'm getting pretty close to 60 fps on this. Can you or anyone else check if it is still performing badly for you?

Comment 13

[Daniel Szabo]

Retested on Nexus 7 2012 / Android 5.1.1 using Firefox 38 beta available from Play Store:
- FPS is around 12-13
- disabling hw acceleration (gfx.canvas.azure.accelerated=false) results in 54-55 FPS
- Chrome produces steady 60 FPS

Low-end tablet (Mali-400 GPU, Android 4.2.2): 4 FPS vs 27-28 FPS when hw acceleration is disabled

(Note: Nexus 6 seems to be having an Adreno GPU. Do you have access to a non-Adreno based device by any chance?)

Comment 14

[James Willcox (:snorp) ([e-mail]) (he/him)]

With Nightly on a Nexus 10 (Mali), I get 54-59 fps.

Comment 15

[Daniel Szabo]

According to wikipedia Mali-T604 (found in Nexus 10) has a different microarchitecture than Mali-400/450 http://en.wikipedia.org/wiki/Mali_%28GPU%29

I've tried to do more performance test, but currently Firefox crashes on my Nexus 7 / Android 5.1 so that the device restarts (see bug 1168347) and earlier Firefox versions (pre 29) won't even start anymore (due to the update to Android 5).

However, using a slightly modified version of the testcase I think the problem is not the canvas backend itself. In the modified version (see new attachment) you can append a number after a hashmark to the url, and after reloading the page, drawImage will be called that many times.

For instance, when I appended #10 to the url (=10 drawImage calls within a single frame), frame rate dropped by only 10%. After switching hw acceleration off and doing the same test, frame rate dropped by 60%. So the hw accelerated canvas backend works just fine. There has to be something reducing performance when the canvas gets merged back (composed) into the html page and blitted to the screen. I tried to make the canvas fullscreen using the fullscreen api but frame rate stayed the same. Also tried to fiddle with vsync settings, none of which helped.

Also, on the low-end tablet, FPS is 50% higher on Firefox 28 without hw acceleration. So composing an hw accelerated canvas back into html took considerable amount of time in earlier versions of FF too, but starting from version 29, it just takes terribly much time on some devices.

Comment 16

[Daniel Szabo]

Attachment: simple canvas performance test

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Daniel, is this still reproducible for you on more-recent builds?

Comment 18

[Daniel Szabo]

Nexus 7, Android 5.1.1
Aurora 43.0a2 (2015-10-09): 13 fps
Chrome 45: 60 fps

when gfx.canvas.azure.accelerated=false, I get 60 fps

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Any ideas how to move forward on this, snorp?

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this a good place to use willReadFrequently on the canvas?  I'm not sure we enable this functionality on Android, so perhaps those two combined are the way to proceed?

Or, if this is GPU specific, we could do the accelerated canvas blocklisting approach?

Comment 21

[James Willcox (:snorp) ([e-mail]) (he/him)]

I get 60fps on this demo in Nightly, so I'm going to call this fixed.

Comment 22

[Daniel Szabo]

I've just tested it on Nightly 44.0a1 (2015-10-15) and the issue is definitely not resolved, fps is still 13-14 on the Nexus 7. I can reproduce the problem at least on 5 different devices.

Comment 23

[James Willcox (:snorp) ([e-mail]) (he/him)]

I profiled this on a tablet with a PowerVR GPU and we're spending most of our time in glCopyTexSubImage2D. This GPU doesn't have the framebuffer blit extension, so we're falling back to this slower path. Still, it shouldn't be *this* slow. It looks like it's copying with the CPU, ugh. I'm going to try a couple other paths.

Comment 24

[James Willcox (:snorp) ([e-mail]) (he/him)]

It's fine on Adreno devices and Nexus 10 (which is Mali). Nexus 9 is good too. My nexus 7 is charging, I'll try again there.

Comment 25

[James Willcox (:snorp) ([e-mail]) (he/him)]

CopyTexSubImage2D is definitely slow on the Nexus 7 (2012). Jeff, do you have ideas for a possible solution? We don't have frambuffer_blit here. I tried to hack it up to blit a quad, but that isn't going too well. The device has an interesting extension, GL_NV_copy_image, which might help (https://www.opengl.org/registry/specs/NV/copy_image.txt).

Comment 26

[Daniel Szabo]

As a workaround, couldn't you just disable hw acceleration if required features are missing? (gfx.canvas.azure.accelerated=false).
This bug affects webgl performance too (with mixed 2d/3d content).
Without hw acceleration the performance is ok, even if it's not near Chrome's performance.
For over a year now, we are recommending our users to switch to Chrome, due to this bug.

Comment 27

[Kelsey Gilbert [:jgilbert]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #25)
> CopyTexSubImage2D is definitely slow on the Nexus 7 (2012). Jeff, do you
> have ideas for a possible solution? We don't have frambuffer_blit here. I
> tried to hack it up to blit a quad, but that isn't going too well. The
> device has an interesting extension, GL_NV_copy_image, which might help
> (https://www.opengl.org/registry/specs/NV/copy_image.txt).

It's worth a try. It looks like it's just FramebufferBlit for textures. (Wish this was core!)