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?
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.
(Oops, wrong Benoit :) .)
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.)
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.
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.
There is now some discussion on landing bug 837591 which solves this issue
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.