Closed Bug 835058 Opened 11 years ago Closed 11 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: 11 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: