Closed Bug 835058 Opened 12 years ago Closed 12 years ago

WebGL glClear() frame rate is too low

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: diego, Unassigned)

References

Details

Attachments

(1 file)

glfingtest
1.95 KB, application/x-gzip
Details
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.
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?
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?
Attached file glfingtest —
I attached the WebGL test I'm using. Notice how all it does it do a glClear() for each frame. I get 12 FPS :(
(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.
FWIW CrystalSkull is 8FPS on the same target
Yeah, I confirm 9fps on the otoro. I think this is a regression.
(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)
The patch in bug 837591 really helps. We just need to figure out some issues with it
Depends on: 837591
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
There is now some discussion on landing bug 837591 which solves this issue
Depends on: 837591
No longer depends on: 716859
Now that bug 843599 I get 60 fps with glflingtest. Thanks Vlad!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: