1297809 - OpenGL acceleration causes horrible performance on Linux

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect, P3)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I noticed my browser has been really sluggish for the last few days. I finally figured out a consistent way to reproduce it.

STR:
1. Open the Vidyo Desktop client and enter a call (going to your own room is fine).
2. Use Firefox.

ER:
It might be a little sluggish but not too bad.

AR:
Firefox is totally unusable. I see multi-second delays when typing and clicking on things.

When I change layers.acceleration.disabled to true, the problem goes away and I get the expected behavior. I also tried setting layout.frame_rate to 60 and it had no effect.

I'm running Ubuntu 15.10 with the Gnome 3 window manager. Here's the graphics section of about:support:

Features
Compositing	OpenGL
Asynchronous Pan/Zoom	wheel input enabled; touch input enabled
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile
WebGL2 Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile
Hardware H264 Decoding	No
Audio Backend	pulse
GPU #1
Active	Yes
Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile
Vendor ID	Intel Open Source Technology Center
Device ID	Mesa DRI Intel(R) Haswell Mobile
Driver Version	3.0 Mesa 11.0.2
Diagnostics
AzureCanvasAccelerated	0
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0

Comment 1

[Boaz Dodin]

A duplicate of bug 1296911 ?

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

No, I tested with layout.frame_rate set to 60 and saw no improvement. Also, I'm testing with the latest nightly, which has the fix for that bug.

Comment 3

[Clemens Eisserer]

just to be curious, does the step "Open the Vidyo Desktop client" imply you are using firefox through some kind of remote-desktop tool?

Comment 4

[Ryan VanderMeulen [:RyanVM]]

(In reply to Boaz Dodin from comment #1)
> A duplicate of bug 1296911 ?

BTW, that question would have been better-directed at acomminos rather than myself since he wrote the patch from the bug you referenced.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to Clemens Eisserer from comment #3)
> just to be curious, does the step "Open the Vidyo Desktop client" imply you
> are using firefox through some kind of remote-desktop tool?

No. Vidyo is a video conferencing client. I'm just logged into X normally from my laptop.

Comment 6

[Boaz Dodin]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)
> (In reply to Boaz Dodin from comment #1)
> > A duplicate of bug 1296911 ?
> 
> BTW, that question would have been better-directed at acomminos rather than
> myself since he wrote the patch from the bug you referenced.

NI

Comment 7

[Andrew Comminos [:acomminos]]

No, this looks like a different issue.

I wonder if vidyo is overloading the DRM device here- I've never used their Linux version, so I don't know how much GL they use. Do other GL applications exhibit slowness with vidyo running? Does firefox exhibit slowness with GL programs other than vidyo running?

Comment 8

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm not really sure what to test. I think mutter uses OpenGL. I haven't noticed any such issues with it. Chrome uses GPU acceleration for compositing. It also works fine with Vidyo.

The slowness in Firefox happens even when Vidyo is not running. It's just a lot more pronounced with Vidyo. I first noticed it a few days ago and assumed I was using a slow add-on or something. The only applications I regularly run are emacs, a terminal, and Firefox. The window manager is always running, of course, so I guess that could be involved.

Comment 9

[Andrew Comminos [:acomminos]]

Thanks for the info. Would it be possible to get a capture using the gecko profiler? That would be immensely helpful in figuring out where we're bottlenecking.

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm not sure you'll get much out of this.
https://cleopatra.io/#report=65e3ac4b228ccb09234ef75563e9e9ed31725c38&selection=0,2780,2781,124,2782,123,124,125,126,127,427,428,2201,2846,2847,2848,2849,2850,2851,2852,129,130,131,132,133,134,135,136,137,138,139,277,930,931,932,933,934,935,936,937,938,3267

During this time, Firefox was extremely laggy. However, the profile mostly just shows it waiting for events. The compositor doesn't seem to be doing much of anything at all.

Comment 11

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Another thing I've noticed is that, perhaps not surprisingly, popups like the awesomebar work fine. I guess because they're not using the same compositor.

Comment 12

[Andrew Comminos [:acomminos]]

VSync timing seems fine, and composites are quick. Texture uploads take up some extra cycles, but that's a given.

61836ms to 62298ms looks like a spike you may have experienced- some JS in chrome appears to be taking up a lot of time there. I'm not sure what's going on elsewhere, though.

Does this reproduce on a fresh profile?

Comment 13

[Andrew Comminos [:acomminos]]

(In reply to Bill McCloskey (:billm) from comment #11)
> Another thing I've noticed is that, perhaps not surprisingly, popups like
> the awesomebar work fine. I guess because they're not using the same
> compositor.

This is also pretty unusual. We actually *do* use the GL compositor for panel popups like awesomebar suggestions.

Comment 14

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Yes, it reproduces in a fresh profile.

Comment 15

[Clemens Eisserer]

Mesa 11 is quite out-dated - I have been using Firefox on compareable hardware + opengl for several months and it worked fine.

Could you give Firefox + opengl-layers a try with e.g. a LiveCD of some current Linux-Distribution?

Comment 16

[mirh]

Aside of the outdated mesa, couldn't this be a dupe of bug 801286?