WebGL glClear() frame rate is too low

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: diego, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
On my reference target I canvas animations to go over 12 FPS. I tried with a 2D context and webgl. Neither can go above this frame rate no matter how simple the animation.

For example, I tried a simple setInterval() animation that just fills the screen with fillRect(). It peaks at 12 FPS. That same animation reaches 60 FPS easily ~3 months ago.
(Reporter)

Comment 1

6 years ago
I traced it down to the fact that I was running the app from the web. When I install it as a packaged app I see the 60 fps back again. My guess is the 2d canvas of a non-packaged app can't be gralloc backed, causing an extra copy bottleneck
CrystalSkull and "flingtest" are packaged apps and I thought you were seeing this slomo there as well?
(Reporter)

Comment 3

6 years ago
The app I'm referring to in comment 1 is flingtest. Turns out it uses 2d canvas.

Looks like there's a different, possibly related issue for webgl apps. I wrote a webgl flingtest and I'm seeing it's peaks at 12 FPS. It's almost as if webgl canvas is creating a non-gralloc surface no matter what.
That's.. pretty awful.  Moving this over to Core-Layers, as I'm 99% guessing that's where the problems are going to lie (any surface backing for canvas etc. will involve there).
Component: General → Graphics: Layers
Product: Boot2Gecko → Core
We autofit "browser" content into a 980px wide viewport by default and then zoom out the content to fit the screen.  (I really hate that, but it's a de facto standard now.)

Putting <meta name="viewport" content="width=device-width"> into the <head> of your test page makes that go away.

Another possibility is event handling ... does the test page preventDefault() the touchstart event?
(Reporter)

Comment 6

6 years ago
Posted file glfingtest
(Reporter)

Comment 7

6 years ago
I attached the WebGL test I'm using. Notice how all it does it do a glClear() for each frame. I get 12 FPS :(
(Reporter)

Comment 8

6 years ago
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> We autofit "browser" content into a 980px wide viewport by default and then
> zoom out the content to fit the screen.  (I really hate that, but it's a de
> facto standard now.)
> 
> Putting <meta name="viewport" content="width=device-width"> into the <head>
> of your test page makes that go away.
> 
> Another possibility is event handling ... does the test page
> preventDefault() the touchstart event?

Thanks for the suggestions. I'll try that. This may explain the FPS when running the 2d canvas app in the browser.

Note that I get bad FPS on the webgl app shared above even as a packaged app.
The best framerate I've seen on a webgl demo is about ~45-50fps, so we need to manage our expectations a bit.  We didn't get our webgl pipeline to where we wanted it to be in v1.0.0, but the fixes are being landed as we speak.

But 12fps for a glClear() loop is ridiculous.  That's what CrystalSkull drives.  I suspect there's something going awry.
(Reporter)

Comment 11

6 years ago
FWIW CrystalSkull is 8FPS on the same target
Yeah, I confirm 9fps on the otoro.  I think this is a regression.
(Reporter)

Comment 13

6 years ago
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
>  I think this is a regression.

I certainly hope so :)
Vlad, can you guys check this out in Taipei this week?  If we can't glClear() faster than 12fps, we should just disable webgl.

I'm pretty sure this is a regression; maybe we stopped sharing the canvas buffer with gralloc?

(Note, this is totally separate from the double buffering and gralloc-render-target work.)
Flags: needinfo?(vladimir)
Yeah, we're working on it; no idea what happened here regression-wise or whatnot, but we're making good progress.  http://bit.ly/wsperf has a good clear-only testcase that we're using; with a simple patch from cjung in bug 837591 we hit 60fps on Unagi.  I may actually argue that we take that patch in 1.0(.1), with a few tweaks that he's doing to ensure that it only affects WebGL.  It's not the ideal solution since it depends on synchronous layer transactions; the async solution is being worked on, but is more invasive.
Flags: needinfo?(vladimir)
(Reporter)

Comment 16

6 years ago
The patch in bug 837591 really helps. We just need to figure out some issues with it
Depends on: 837591
(Reporter)

Updated

6 years ago
Summary: Full screen canvas frame rate is capped low → WebGL glClear() frame rate is too low
Bug 837591 is a potential fix, but it has a number of issues.  The full fix is working well in bug 716859, modulo some changes.  With that, we can hit 60fps for a glClear() testcsae in Unagi, and are starting to get much closer to fillrate with actual drawing content.
Depends on: 716859
No longer depends on: 837591
(Reporter)

Comment 18

6 years ago
There is now some discussion on landing bug 837591 which solves this issue
Depends on: 837591
No longer depends on: 716859
(Reporter)

Comment 19

6 years ago
Now that bug 843599 I get 60 fps with glflingtest. Thanks Vlad!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.