Closed Bug 594876 (ogl-linux-beta) Opened 14 years ago Closed 3 years ago

[Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware

Categories

(Core :: Graphics, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jrmuizel, Assigned: acomminos)

References

(Blocks 1 open bug)

Details

(Whiteboard: [k9o:p?:fx?] [games:p-])

Attachments

(5 files)

      No description provided.
Alias: ogl-linux-beta
Depends on: 586463
Depends on: 586462
Depends on: 595055
Is this taking ANY priority? Or is it that we'll get the OpenGL version after Firefox 6 gets released 3 years later...
Lots of Linux developers but much fewer Linux users. There are priorities here and plenty of betas left. Besides, this specific bug is bran new; give it at least a little time to have some activity. Please don't whine in tracking bugs.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
I'm just worried about when it will be implemented.

+ I've heard that they will be using Xrender also which I've heard only works well for ATI's fglrx...
Depends on: 580756
Should probably depend on bug 594308 and bug 580410, too?
Depends on: 594308
Depends on: 580410
(In reply to comment #4)
Yeah, added. I think they just got lost here when OSX and Linux were split into two different OpenGL tracking bugs.
Summary: [Tracking bug] Turn on OpenGL accelerated layers by default for at least some subset of hardware on linux → [Tracking bug] Turn on OpenGL accelerated layers by default for at least some subset of hardware on Linux
I have an ATI card with OSS driver. Please tell me which nightly build it is worth to start testing. I can't run any test suite but I can test normal browsing.
(In reply to comment #6)
> I can't run any test suite

Actually, yes you can, and easily using an extension:
http://jagriffin.wordpress.com/2010/08/30/introducting-grafx-bot/

Do so and you can send your results to be aggregated and investigated for better hardware support for everyone. :)
Yes, I can do this, thank you for your hint.
Requesting blocking betaN+ or beta7+ if we want feature parity with Mac for OpenGL (bug 580405). Joe Drew?
blocking2.0: --- → ?
I don't think we're going to be in a position to be able to turn OpenGL on by default. I will very happily take all the bugs that make it possible to do so, but I think we're going to end up needing to have an opt-in checkbox. (We might be able to whitelist certain drivers, like the NVIDIA proprietary driver and maybe the free ATI driver, but we've seen a lot of very bad bugs with the current driver situation on Linux, and I don't want to commit to turning OpenGL on by default for that reason.)
blocking2.0: ? → -
Thanks for the info Joe. That's pretty much what I expected, unfortunately.
Depends on: 593874
(In reply to comment #10)
> We might be able to whitelist certain drivers, like the NVIDIA
> proprietary driver and maybe the free ATI driver

Is there a separate bug for this, or do we need to file one? (or is that to be handled in this bug?)

Nice to know that the free ATI driver, which I am currently using, is a possibility... ;)
(rearranging bug title wording so the Linux and Mac tracking bugs don't look exactly the same in bugmail when truncated; don't bury the lead)
Hardware: x86 → All
Summary: [Tracking bug] Turn on OpenGL accelerated layers by default for at least some subset of hardware on Linux → [Tracking bug] [Linux] Turn on OpenGL accelerated layers by default for at least some subset of hardware
Version: unspecified → Trunk
Depends on: 597141
Depends on: 602190
No longer depends on: 580410
Depends on: 604047
I get this in my mail - 

          What    |Old Value                   |New Value
----------------------------------------------------------------------------
            Status|UNCONFIRMED                 |RESOLVED
        Resolution|                            |DUPLICATE
Depends on: 648604
We also need to make sure this gets disabled in the aurora branch next week, what do I need to do to track that?
Attachment #533146 - Flags: review?
Attachment #533146 - Flags: review? → review?(joe)
I did enabled hardware acceleration, but I got half the FPS to that in chromium.
Assignee: nobody → matt.woodrow+bugzilla
Comment on attachment 533146 [details] [diff] [review]
Turn OpenGL on by default for linux

When you land this, set tracking-firefox6 to ? so we're sure to back this out in Aurora for fx6.
Attachment #533146 - Flags: review?(joe) → review+
Depends on: 658921
Matt, was this orange on try?
Not when I last tried it, but it may have been when texture_from_pixmap was broken.
Depends on: 659560
Rebased and fixed the mochitest for this change.

Carrying forward r=joe
Attachment #549254 - Flags: review+
Depends on: 675474
Depends on: 671259
Depends on: 655017
Depends on: 675073
Depends on: 678372
Depends on: 659932
Looking good on tryserver, trying this again!

http://hg.mozilla.org/integration/mozilla-inbound/rev/0a920411e64c

Fingers (and toes) crossed.
Whiteboard: [inbound]
I believe one of the changesets in that push (bug 594876, bug 675474 or bug 675532) has caused an OSX 10.6 reftest perma-orange, so needs backing out:
http://tbpl.allizom.org/?tree=Mozilla-Inbound&usebuildbot=1&rev=0a920411e64c
Depends on: 680817
Note that Talos reported massive perf regressions on Linux for the push this was part.
... for the push this was part of.

I see that Matt filed bug 680817 on this.
Depends on: 678940
Depends on: 694258
Depends on: 630346
Depends on: 606649
Depends on: 630620
No longer depends on: 694258
Depends on: 693149
No longer depends on: 693149
Depends on: 687831
Blocks: 707722
No longer blocks: 707722
Depends on: 707722
Whiteboard: [k9o:p?:fx?] [games:p2]
Depends on: 722012
Depends on: 777170
Depends on: 778029
Depends on: 783043
Depends on: 787853
Depends on: linux-egl
I just pushed to try with the pref layers.acceleration.force-enabled = true to get an idea of the current situation on Linux:

https://tbpl.mozilla.org/?tree=Try&rev=673649ad7d36

I did not disable xrender. It may be worth trying also with gfx.xrender.enabled = false if this does not show good results.
(In reply to Nicolas Silva [:nical] from comment #27)
> I just pushed to try with the pref layers.acceleration.force-enabled = true
> to get an idea of the current situation on Linux:

You can see a recent try build here: https://bugzilla.mozilla.org/show_bug.cgi?id=787853#c10
Adapter DescriptionATI Technologies Inc. -- AMD Radeon HD 6900 Series 
Vendor IDATI Technologies Inc.
Device IDAMD Radeon HD 6900 Series 
Driver Version4.2.11762 Compatibility Profile ContextWebGL RendererATI Technologies Inc. -- AMD Radeon HD 6900 Series  -- 4.2.11762 Compatibility Profile Context
GPU Accelerated Windows1/1 OpenGL

with xrender set to false even the current aurora seems to work. Not quite sure how i tell if its working though - about:support seems to indicate it is. performance isnt much different. 

there are a few transient image artifacts but otherwise it seems ok.
(In reply to paulf from comment #29)
> with xrender set to false even the current aurora seems to work.

And what with xrender enabled?

> there are a few transient image artifacts but otherwise it seems ok.

If you can reproduce these artifacts on a particular page, please file a new bug blocking this one.
(On my radeon OSS driver with forced layers acceleration the rendering is steadily improving with each Firefox nightly for the last year. Where there was flickering and rendering artifacts all over the page, I can see no problems today. I just don't see any perf advantage, but it works. Even WebGL works. Good work guys!)
With xrender enabled there are the usual ati fglrx bugs. i have one open for that.

the artifacts are transient. 
1 - sometimes the color scheme is messed up in gmail. currently its perfect.
2 - sometimes the background flickers moving images in blogger when composing a post. 

as im not actually sure if the opengl layers are working at all i didnt want to be raising bugs against it.

i can do some retesting if need be - but i would like to know if layers are working as intended or at all or if there are still components missing from the gfx stack ?
(In reply to paulf from comment #29)
> GPU Accelerated Windows1/1 OpenGL

This means 1 out of 1 windows is using GL layers.  i.e. OpenGL is used to composite the layers, as intended.

Probably the most noticeable improvement in performance at this stage would be with high frame-rate WebGL such as
https://developer.mozilla.org/en-US/demos/detail/bananabread

Scaled webm/ogg video should also use less CPU.
http://videos.mozilla.org/serv/marketing/sfx_edutoolkit/asa_historymozilla.ogv

Also expect improvements scrolling LCD antialiased text over fixed backgrounds, but
bug 777170 means that is not yet working as intended.
Depends on: 797568
FYI, with Intel SandyBridge and quite recent kernels and X.org versions, GL layers have been working fine in Nightly for all cases I saw recently - I had the bounding boxes of doorhangers not being transparent for a while (with my custom theme, but without GL layers it was fine), but that has been fixed very recently as well.
As this machine is really fast overall, I can't speak for performance. On hardware and systems like this, I'd feel good with having this turned on by default in Nightly in the near future to get more feedback. Good work, guys! :)
Very stable on Sandybridge now. The previously observed slowdowns or graphical anomalies are gone.

Linux 3.6
Xorg 1.13.99
Mesa 9.1-devel
Intel DDX git
Nouveau DDX git
Depends on: 693149
Depends on: 807941
Depends on: 819846
Seems to work pretty well on ivybridge too:

ubuntu 12.10
kernel 3.5
mesa 9.0
intel 2.20.9

No more artifacts in the interface and scrolling like there used to be, seems to be quite usable. I'll have to give it more testing though.
ivy bridge has a small problem.

In the google search suggestions, sometimes it's going to show a blank list (with the lists's black border but no entries in it).

Also, what about benchmarking? It should be at par to other platforms.
I ran a few benchmarks on the ie10 testdrive site and some of them are still significantly slower than xrender. The most obvious example was psychedelic browsing. 7k+ with just xrender, and around 300 with layers enabled.
(In reply to Brandon Watkins from comment #39)
> I ran a few benchmarks on the ie10 testdrive site and some of them are still
> significantly slower than xrender. The most obvious example was psychedelic
> browsing. 7k+ with just xrender, and around 300 with layers enabled.

What hardware?
ivybridge i5-3210m 2.53ghz, 8gb ram on ubuntu 12.10
With xrender disabled, https://webglsamples.googlecode.com/hg/aquarium/aquarium.html is marginally faster; but it should be a lot faster.
Maybe that could be usefull in the future : GLX_MESA_query_renderer should soon be in Mesa thnaks to Ian Romanick [1]

"The glXQueryRendererIntegerMESA and glXQueryRendererStringMESA functions allow applications query a bunch of aspects about the driver and hardware before creating a context:

    Driver version
    Driver vendor
    Hardware vendor (may be different from driver vendor!)
    Hardware chipset (PCI ID)
    Available memory
    UMA vs. non-UMA
    Supported and prefered (by the driver) GL profiles"


[1] http://www.paranormal-entertainment.com/idr/blog/posts/2013-03-01T23:15:18Z-GLX_MESA_query_renderer_out_for_review/
Depends on: 825944
Depends on: 864628
Whiteboard: [k9o:p?:fx?] [games:p2] → [k9o:p?:fx?] [games:p-]
I am having this problem too. My notebook is good, but the WebGL graphics is very slow. I am using Ubuntu 13.04, 64 bits, Firefox updated with last version.
Coming from bug 1060406, this issue causes a huge CPU consumption when playing some videos on my hardware (Intel graphics cards on Linux : one Ivy bridge and one Atom).
Some VP8 or VP9 videos are playing fine on Totem but don't play at all on Firefox because of lack of CPU power.

I read the workarounds above of setting layers.acceleration.force-enabled=true and/or gfx.xrender.enabled=false but they did not work for me : the about:support page always says 0 accelerated windows and the CPU consumption remains the same.

Is there any way to manually enable accelerated windows on Intel graphics cards on Linux?
NB : using Firefox 33 (64 bits) from Ubuntu 14.04 standard repos. Same behavior with Firefox 31 downloaded from Mozilla
(In reply to Mossroy from comment #47)
> Coming from bug 1060406, this issue causes a huge CPU consumption when
> playing some videos on my hardware (Intel graphics cards on Linux : one Ivy
> bridge and one Atom).
> Some VP8 or VP9 videos are playing fine on Totem but don't play at all on
> Firefox because of lack of CPU power.
> 
> I read the workarounds above of setting
> layers.acceleration.force-enabled=true and/or gfx.xrender.enabled=false but
> they did not work for me : the about:support page always says 0 accelerated
> windows and the CPU consumption remains the same.
> 
> Is there any way to manually enable accelerated windows on Intel graphics
> cards on Linux?
> NB : using Firefox 33 (64 bits) from Ubuntu 14.04 standard repos. Same
> behavior with Firefox 31 downloaded from Mozilla

Video acceleration using GStreamer would be bug 894372.
Thanks Marco, but I don't think we're talking about the same thing.
If I understood correctly, the bug 894372 you mention is about activating hardware decoding through GStreamer+VAAPI.
The tests I made were with VP8 and VP9 video codecs, which are not decoded by Gstreamer as far as I know. And, in any case, my hardware does not support hardware VP8/VP9 decoding.

Based on the comments in bug 1060406, it seems that the CPU overhead I face would be due to Firefox window composition. It seems to depend on the hardware : some people with OpenGL accelerated windows do not have this overhead. I believe this is why it has been marked as duplicate of this issue.

I'd like to check these assumptions by manually enabling accelerated windows in Firefox (if it's possible)
(In reply to Mossroy from comment #49)
> Thanks Marco, but I don't think we're talking about the same thing.
> If I understood correctly, the bug 894372 you mention is about activating
> hardware decoding through GStreamer+VAAPI.
> The tests I made were with VP8 and VP9 video codecs, which are not decoded
> by Gstreamer as far as I know. And, in any case, my hardware does not
> support hardware VP8/VP9 decoding.
> 
> Based on the comments in bug 1060406, it seems that the CPU overhead I face
> would be due to Firefox window composition. It seems to depend on the
> hardware : some people with OpenGL accelerated windows do not have this
> overhead. I believe this is why it has been marked as duplicate of this
> issue.
> 
> I'd like to check these assumptions by manually enabling accelerated windows
> in Firefox (if it's possible)

layers.acceleration.force-enabled and a restart of the browser should be all that's required to trigger OpenGL+OMTC, though there may be blacklisted drivers now.

For basic (non-opengl) OMTC you can enable layers.offmainthreadcomposition.enabled with acceleration disabled
Thanks John.
I tested layers.offmainthreadcomposition.enabled (with acceleration disabled). It had no significant effect on my computers.
So I suppose the Intel open-source drivers I use on these computers are blacklisted?

How could I check that?
If someone could point me to where this blacklist is (in the source code, I suppose), I might try to remove it and recompile?
On linux, unless you are using firefox nightly, you also need to set either of these two environment variables:
export MOZ_USE_OMTC=1
export MOZ_OMTC_ENABLED=1
in addition to the prefs. There are historical reasons to that but in short, need to initialize X in thread-safe mode before the service that can read prefs is created (so at a point where we can only use environment variables). We didn't want to initialize X in thread-safe mode unless OMTC is activated because it adds a bit of overhead.
The plan is to enable OMTC on linux for everyone asap, but we are getting delayed by some fire fighting on windows at the moment, but soon-ish this should become easier.
Thanks Nicolas.
With these environment variables set and layers.acceleration.force-enabled=true, I manage to have an accelerated window in about:support : "1/1 OpenGL (OMTC)"

Unfortunately, it does not seem to make a visible difference when playing my test WebM videos : the CPU consumption is still ~ twice more than with Totem, and the video is still choppy on the netbook (while smooth in Totem)

Can I test anything else?
(In reply to Mossroy from comment #53)
> Thanks Nicolas.
> With these environment variables set and
> layers.acceleration.force-enabled=true, I manage to have an accelerated
> window in about:support : "1/1 OpenGL (OMTC)"
> 
> Unfortunately, it does not seem to make a visible difference when playing my
> test WebM videos : the CPU consumption is still ~ twice more than with
> Totem, and the video is still choppy on the netbook (while smooth in Totem)
> 
> Can I test anything else?

Maybe your local installation or the recent entanglement of layers.acceleration.force-enabled and OMTC is the problem.
You could try an older live system like Ubuntu 13.10 64-bit (including Firefox 24 without OMTC):

Download Ubuntu 13.10 64-bit from

http://releases.ubuntu.com/13.10/

burn it, boot it, select "Try Ubuntu" (not install), set layers.acceleration.force-enabled to true, restart Firefox and see if the CPU usage of your WebM video gets reduced.
Thanks a lot Cresto, you were right!

With Firefox 24 (from Ubuntu 13.10), setting layers.acceleration.force-enabled to true is enough to get hardware accelerated window in about:support : "1/1 OpenGL"
It's still OK with Firefox 26 (from Mozilla), but fails since Firefox 27 (from Mozilla : "0/1 Basic")
SO I suppose the regression has been introduced in Firefox 27.

The CPU usage is indeed reduced with OpenGL acceleration.
Here are the approximate CPU consumptions I have with a WebM video (VP8+Vorbis) played on an old netbook (Atom dual core N570 @1.66GHz with HT)
Firefox 26 : 90% + 16% compiz + 16% xorg + 8% pulseaudio (total = 130%)
Firefox 27 (or Firefox 26 without layers.acceleration.force-enabled to true) : 110% + 30% compiz + 13% xorg + 8% pulseaudio (total = 161%)
By comparison :
Totem : 65% + 13% compiz + 13% xorg + 5% pulseaudio (total = 96%)
Chromium 34 : 135% (3 processes : 90+25+20) + 18% compiz + 13% xorg + 18% pulseaudio (total = 184%)

To sum up, there is still an overhead when compared with Totem, but having OpenGL accelerated windows is really worth it, as it reduces this overhead in a noticeable way.

I hope the following versions of Firefox will fix these issues : at least allow to force-enable OpenGL, and at best enable it by default
NB : I tested with Firefox nightly (36.0a1) in the same conditions. The about:support says "1/1 OpenGL (OMTC)", and the CPU consumption is : 135% + 20% compiz + 20% xorg + 5% pulseaudio (total = 180%. Not sure this test is relevant because it seems that Firefox nightly eats ~35% CPU, even when idle)
Depends on: 1093060
Blocks: 1152974
Depends on: 1113647
Depends on: 1177091
Depends on: 1177079
Depends on: 801286
Depends on: 1135499
Depends on: 1181545
Depends on: 1184534
No longer depends on: 1181545
Depends on: 1187440
Assignee: matt.woodrow → acomminos
Depends on: 1189132
Depends on: 1181545
Depends on: 1193615
Depends on: 1194644
Is there any progress on this one?
At leats with the open-source drivers (radeon, intel), Firefox works well with opengl acceleration turned on.
(In reply to Clemens Eisserer from comment #56)
> Is there any progress on this one?
> At leats with the open-source drivers (radeon, intel), Firefox works well
> with opengl acceleration turned on.

At the moment it's best to wait for the transition gtk2->gtk3 to be done and stable before we ship another change that greatly impact the graphics pipeline on linux. We also need to figure out whether the servers we run tests on have have a reliable graphics stack and have them run tests with opengl compositing in addition to the software compositing configuration, and figure out the remaining issues (there are open bugs about gl compositing on linux, I don't think that it is free of regressions at the moments, even if it mostly works well). There are also other things to do on linux like moving away from cairo's xrender backend, that have an impact on the compositing backend so we have to figure out what the dependencies are there.
(In reply to Clemens Eisserer from comment #56)
> Is there any progress on this one?

My last post sounded perhaps a bit pessimistic, but to answer your question more directly, :acomminos has made some progress on this front, lately.
Depends on: 1193642
(In reply to Nicolas Silva [:nical] from comment #57)
> At the moment it's best to wait for the transition gtk2->gtk3 to be done and
> stable before we ship another change that greatly impact the graphics
> pipeline on linux.

But GTK+ 3 already is enabled by default now:

https://bugzilla.mozilla.org/show_bug.cgi?id=1186003

?

(In reply to Nicolas Silva [:nical] from comment #57)
> There are also other things to do on
> linux like moving away from cairo's xrender backend, that have an impact on
> the compositing backend so we have to figure out what the dependencies are
> there.

Do you have a link?

Regards
(In reply to nw9165-3201 from comment #59)
> But GTK+ 3 already is enabled by default now:

It hasn't made it to the release channel yet. Regressions from these kind of changes usually show up only when the new feature hits a large population of users, so waiting a bit between risky changes helps with being able to react quickly when bugs show up in the beta or release channels (and more importantly not having too many of these late bugs at the same time to deal with). Gtk3 isn't in a worrying state as far as I know so we should be good soon.

> (In reply to Nicolas Silva [:nical] from comment #57)
> Do you have a link?

Bug 1180942
Depends on: 1234058
Depends on: 1193855
Depends on: 1241874
Blocks: 1260559
Depends on: 1263678
Depends on: 1267137
Depends on: 1279335
It seems like a good time now to enable this on Nightly; these patches enable layers acceleration by default on GTK.

Let's triage, start making use of the downloadable blocklist, and improve glxtest as we start getting data in from nightly users.
Comment on attachment 8763264 [details]
Bug 594876 - Accelerate layers by default for nightlies on Linux.

https://reviewboard.mozilla.org/r/59526/#review56620
Attachment #8763264 - Flags: review?(nical.bugzilla) → review+
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review56622
Attachment #8763263 - Flags: review?(nical.bugzilla) → review+
Attachment #8763262 - Flags: review?(nical.bugzilla) → review+
Comment on attachment 8763262 [details]
Bug 594876 - Fuzz reftests with noise from enabling layers acceleration on Linux.

https://reviewboard.mozilla.org/r/59522/#review56624

\o/
Pushed by acomminos@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5bde2c12831c
Enable layers acceleration by default on Linux. r=nical
https://hg.mozilla.org/integration/mozilla-inbound/rev/d8b83ff870a3
Test that acceleration is used on Linux. r=nical
https://hg.mozilla.org/integration/mozilla-inbound/rev/cafa7213ef23
Fuzz reftests with noise from enabling layers acceleration on Linux. r=nical
Sorry, reftest fuzz order was incorrect for that test. Will fix and reland when I get back.
Flags: needinfo?(andrew)
Be aware that the push had many timeouts in various mochitests. Please push to Try if it isn't obvious that the changes fill fix these.
Depends on: 1280744
No longer depends on: 1277981
Depends on: 1285507
Depends on: 1292326
Depends on: 1294232
Depends on: 1296086
With larger AWS instances, the software GL infrastructure in bug 1296086 landing, and better Linux blocklisting, we have a better chance at making this stick. Let's make it exclusive to nightly builds for now, and see how things go.
Due to bug 1296086, test_acceleration.html has been flagged TODO (as we only accelerate on TaskCluster tests).

Thanks!
Attachment #8763263 - Flags: review+ → review?(nical.bugzilla)
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review70500
Attachment #8763263 - Flags: review?(andrew)
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review70502
Attachment #8763263 - Flags: review?(andrew)
Comment on attachment 8763263 [details]
Bug 594876 - Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration.

https://reviewboard.mozilla.org/r/59524/#review70618
Attachment #8763263 - Flags: review?(nical.bugzilla) → review+
Pushed by acomminos@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/314eb9761599
Fuzz reftests with noise from enabling layers acceleration on Linux. r=nical
https://hg.mozilla.org/integration/autoland/rev/f35636ae9fdb
Update test_acceleration.html to accomodate only taskcluster instances using layers acceleration. r=nical
https://hg.mozilla.org/integration/autoland/rev/32fd2e8a3be8
Accelerate layers by default for nightlies on Linux. r=nical
Depends on: 1296733
Thank you!
See Also: → 1296911
Depends on: 1297004
See Also: → skia-linux
Depends on: 1298333
I have before the layers accelerated, the only thing I have noticed is the noise on the browser, apart with my hd 4600 intel hd and arch linux all is going well
Depends on: 1298692
I think I was bitten by the fix for this ticket.  Details here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1299588
Just found a side effect of this fix on Ubuntu 12.04 x32 where the latest Nightlies (since the fix) fail to start on the machine. 
Using the following 2 prefs "layers.acceleration.force-enabled:false" and "layers.acceleration.disabled:true" makes the issue go away.

Ubuntu 14.04 x64 works as expected.
(In reply to Ciprian Muresan [:cmuresan] from comment #87)
> Just found a side effect of this fix on Ubuntu 12.04 x32 where the latest
> Nightlies (since the fix) fail to start on the machine. 
> Using the following 2 prefs "layers.acceleration.force-enabled:false" and
> "layers.acceleration.disabled:true" makes the issue go away.
> 
> Ubuntu 14.04 x64 works as expected.

This is probably the same issue that mirh pointed out in bug 1298333 comment 6.
(In reply to Marco Castelluccio [:marco] from comment #88)
> This is probably the same issue that mirh pointed out in bug 1298333 comment
> 6.

It seems so, thanks for pointing that out.
(In reply to Ciprian Muresan [:cmuresan] from comment #89)
> (In reply to Marco Castelluccio [:marco] from comment #88)
> > This is probably the same issue that mirh pointed out in bug 1298333 comment
> > 6.
> 
> It seems so, thanks for pointing that out.

Do you have the same gfx card and same driver version? If you don't, perhaps
you can add a comment in that bug saying what yours are.
Depends on: 1304347
Depends on: 1304195
Depends on: 1297212
Depends on: 1302850
Would it make sense to add bug 1306912 to the "depends on" list?
(In reply to Clemens Eisserer from comment #91)
> Would it make sense to add bug 1306912 to the "depends on" list?

Yes, done.
Depends on: 1306912
and another one please: 1306974
I only see this issue when OpenGL is enabled, and haven't experienced it with earlier versions (48/49(?)) - so either a firefox or mesa regression.
Depends on: 1306974
Depends on: 1305675
Depends on: 1320340
Lee, please reopen this once you fix bug 1323284, turning acceleration off by default.
Flags: needinfo?(lsalzman)
As part of bug 1323284, we disabled acceleration again until we have time/resources to better investigate this. Reopening...
Status: RESOLVED → REOPENED
Flags: needinfo?(lsalzman)
Resolution: FIXED → ---
See Also: → 1323991
blocking2.0: - → ---
Target Milestone: mozilla51 → ---
Depends on: 1261832
I'm experiencing heavy scrolling lag and jerky controls with FF 45.8 ESR on Linux Debian (i686/32bits). Disabling hardware acceleration had no effect.
(In reply to Etienne Robillard from comment #96)
> I'm experiencing heavy scrolling lag and jerky controls with FF 45.8 ESR on
> Linux Debian (i686/32bits). Disabling hardware acceleration had no effect.

You can try toggling the gfx.xrender.enabled pref and see if it helps either way.
(In reply to Lee Salzman [:lsalzman] from comment #97)
> You can try toggling the gfx.xrender.enabled pref and see if it helps either
> way.

I tried disabling gfx.xrender.enabled without any effects. Furthermore, I don't understand the logic
of disabling XRender for local X11 connections.
Not sure the meta bug is the right one to discuss that...
Also not sure why (in such a.. _complex and longstanding_ issue) reporting issues with a 1 year and half old codebase would really help anything when all the developments happens on builds with a 10 higher number.
Blocks: 1210727
Depends on: 1383116
Depends on: 1410084
What's the status/forward plan here? I see quite a few dependencies however it's a bit unclear how many of them are blocking enabling by default and which could be dealt with afterwards (or while riding the trains). 

Do you have a rough time estimate (in terms of trains) when you think this is worthwhile to pick up (i.e. enable by default)?
Flags: needinfo?(milan)
No current timeline or solid plans.
Flags: needinfo?(milan)
Blocks: 1420712
Is this meaning linux version won't get webrender? (as it need HW_COMPOSITING to work)
Depends on: 1463072
I think the importance of this issue should not be underestimated. It has a direct impact on "user-experience", and "user-experience" has a direct impact on market share. I know, because I was even considering switching over to Windows just so I could use the Microsoft Edge browser. Why? Because for years I've watched on in envy as my work colleagues smoothly scrolled around the heaviest of web pages on the Interwebs. It's like they were gliding on ice, while my scrolling made it look like skating on cobble stones.

On Kubuntu 18.04 (on 3 computers), I went in to about:config and set layers.acceleration.force-enabled to true. The difference is like night and day. Moving back to Windows is something I really didn't want to do, and thankfully, I don't have to now because I too am skating on ice.

I still get the odd "jank" ("micro-stutter" - whatever it's called), but it has become the exception rather than the rule. I know that "smoothness" can be very subjective, but here's the test I use:

1. Open Google's homepage.
2. Click on the "Images" link.
3. Do an image search for something (e.g. "cars").
4. Click on the middle-button to activate auto-scroll.
5. Move the mouse cursor about 1cm below the "auto-scroll circle.
6. Just observe the page as it scrolls downwards.

On a default installation of Kubuntu 18.04 on:

* My desktop (with an Nvidia 1070 with 6GB of RAM)
* My T470 laptop (with an Intel 520 iGPU)
* My T470p laptop (with an Nvidia 940mx with 2GB of RAM)

performing the above steps results in jittery and jerky scrolling - in other words, a terrible user-experience. Such an issue (and I do believe it's an important issue) is not easy for the average user to articulate. Their brains perceive something is wrong and not working "quite right", but they don't know how to explain it and they simply form a negative opinion.

Many years ago Intel commissioned a project whereby they reverse engineered the iOS user-experience (they wanted to find out why Apple was so successful, despite running on lower-end hardware and slower CPUs with less cores). The conclusion was definitive:

* The operating system managed to consistently maintain 60 frames per second.
* There was only 6 (or so) milliseconds of touch input lag (compared to Androids whopping 200ms in some cases).

That is the secret sauce - a successful implementation of the whole "touch paradigm". The same can be applied to the desktop experience, although with the desktop experience input lag isn't as important (most of the time).

Make the experience "smooth", and users "feel" good. Hardware acceleration is imperative to achieve this!!
(Just a community member)

(In reply to Scott Deagan from comment #104)
Hi, I think nobody will touch this old feature. I share your position and there's light at the end of the tunnel!

> managed to consistently maintain 60 frames per second.

That's exactly why you want to try out WebRender:
https://nightly.mozilla.org (Windows, Linux, Mac), gfx.webrender.all;true, restart.

It's developed in Rust (https://www.rust-lang.org), so it's more secure, it's also using OpenGL and there is a project porting it to Vulkan, DX12 and Metal based on an abstraction layer. Presumably, it will be enabled by default in Fx 64 for Nvidia on Win10. Other graphics cards, Linux, Mac and Android will follow afterwards.

You might want to follow:
* https://mozillagfx.wordpress.com/
* https://groups.google.com/forum/#!forum/mozilla.dev.tech.gfx
* https://github.com/servo/webrender/
Yeah, exotic, old and mobile configurations can't expect too much at the moment.
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #105)

Thanks! Good to know what's in the pipeline, but at the moment I have found a "solution" (?) that works for me right now. In the 10 years or so that I've been using Linux, this is the first time I have experienced "buttery smooth scrolling" - and while some may dismiss this as being "just scrolling", to me it makes all the difference. Again, it's subjective because it's "user-experience", but I'm sure others will be negatively impacted the same way I was.

Anyway, my point is I consider myself a fairly advanced user, and it took me 10 years to finally achieve something I've been wishing for since I started using Linux. It would be nice if "smooth" was the default, and not something users have to find very technical configuration tweaks to achieve (because most users won't).

I'll have a read about WebRender and will try it out. Again, thanks for pointing this out.
"Other graphics cards, Linux, Mac and Android will follow afterwards"

I sure hope so, but we've been told this before. The old opengl layers were supposed to be enabled on linux 'eventually' too, but it never happened, and in 2018 linux users are stuck without any hardware acceleration by default.
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #105)
> Hi, I think nobody will touch this old feature. I share your position and
> there's light at the end of the tunnel!
> 
> > managed to consistently maintain 60 frames per second.
> 
> That's exactly why you want to try out WebRender:
> https://nightly.mozilla.org (Windows, Linux, Mac), gfx.webrender.all;true,
> restart.
> 
> It's developed in Rust (https://www.rust-lang.org), so it's more secure,
> it's also using OpenGL and there is a project porting it to Vulkan, DX12 and
> Metal based on an abstraction layer. Presumably, it will be enabled by
> default in Fx 64 for Nvidia on Win10. Other graphics cards, Linux, Mac and
> Android will follow afterwards.

Since WebRender deepends on hardware compositing, isn't enabling WebRender by default on Linux blocked on this bug?
Depends on: 1514730
Depends on: 1516123
No longer blocks: 1210727
No longer blocks: 1210726
No longer blocks: slow-linux-webgl

ogl-linux-beta
Turn on OpenGL accelerated layers by default for at least some subset of hardware

This bug is basically a wontfix:

https://searchfox.org/mozilla-central/rev/0da35261b6789eec65476dbdd4913df6e235af6d/gfx/thebes/gfxPlatform.cpp#2947-2953

// Hardware compositing should be disabled by default if we aren't using
// WebRender.

https://hg.mozilla.org/mozilla-central/rev/74e4704a550e

If the GPU process becomes disabled due to crashes, then we should not
allow Linux to fallback from WebRender to OpenGL compositing in the
parent process. It should instead fallback to software just like
Windows. This is important because we don't support the OpenGL
compositor configuration.

Test WebRender

Beta and Stable might have bugs that are already fixed on Nightly.
Please download https://nightly.mozilla.org, open about:config, set gfx.webrender.all to true to force-enable WebRender, then restart Nightly.
If you see a problem, please file a new bug report. Open about:support, click on "Copy text to clipboard", paste it into a text file and attach it to the report. Thanks! Your graphics card must support at least OpenGL 3.1. Known Linux-only bugs are tracked here. On Nightly, WebRender is already enabled by default for modern Intel and AMD with Mesa 18.2 or newer with screens smaller than 4K.

I'm currently using layers.acceleration.force-enabled=true with Linux Mint 18.3 (Ubuntu 16.04) and it works flawlessly with my Intel Haswell iGPU. It worked fine in Linux Mint 17.3 (Ubuntu 14.04) as well.
Does comment #117 mean that I should revert it to false and rather set gfx.webrender.all=true now?

If you enable gfx.webrender.all, then layers.acceleration.force-enabled should have no effect. You can try to see which works better for you.

Is there a particular bug report dedicated to 4K screens?

(In reply to Mauro Molinari from comment #118)

Does comment #117 mean that I should revert it to false and rather set gfx.webrender.all=true now?

If you are using Nightly, then yes (but please update at least to Ubuntu 18.04 LTS!), otherwise rather not/at your own risk. Better force-enable WebRender only with Nightly for now. If you wanted to try it out with Beta, please check by yourself if bugs are already fixed on Nightly.

(In reply to Dmitry Gutov from comment #120)

Is there a particular bug report dedicated to 4K screens?

No, not one particular. Ctrl+F "4k": https://mozillagfx.wordpress.com/2019/04/30/webrender-newsletter-44/

No longer blocks: 1420712
No longer blocks: 1521004
No longer depends on: linux-egl

I think it depends on 1659143.

Taking the freedom to close this - accelerated layers are going away in favor of Webrender, which is tracked in bug 1491303.

Status: REOPENED → RESOLVED
Closed: 8 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.