Closed Bug 1241832 Opened 4 years ago Closed 4 years ago

Investigate disabling xrender on the compositor.

Categories

(Core :: Graphics: Layers, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
firefox47 - wontfix
firefox48 --- ?
firefox49 --- ?

People

(Reporter: nical, Assigned: lsalzman)

References

(Depends on 6 open bugs, Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

We just disabled xrender by default for painting on nightly, but we still use it for compositing. I am somewhat less worried about xrender on the compositor, but I don't know if it's the best thing we have for compositing.
Reducing our dependence on X is generally good, if only to help with moving toward proper wayland support, and reduce the amount of backends we need to care about.

The pref is "gfx.xrender.enabled"
Whiteboard: [gfx-noted]
Blocks: 1241161
Blocks: 1191775
Depends on: 1245550
Try run looks green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=039ea200107e

This doesn't look like it will leave us any worse up than enable Cairo image surfaces did, as far as tests go.
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #8717492 - Flags: review?(jmuizelaar)
Comment on attachment 8717492 [details] [diff] [review]
change gfx.xrender.enabled pref so that xrender compositing is no longer used by default

Review of attachment 8717492 [details] [diff] [review]:
-----------------------------------------------------------------

\o/
Attachment #8717492 - Flags: review?(jmuizelaar) → review+
Depends on: 1245241
A bunch of performance changes related to this coming in, some good, some bad:

https://treeherder.allizom.org/perf.html#/alerts?id=99

Should I file a regression bug here? Or should we just accept these?
Flags: needinfo?(lsalzman)
https://hg.mozilla.org/mozilla-central/rev/432ef38dab95
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
(In reply to William Lachance (:wlach) from comment #4)
> A bunch of performance changes related to this coming in, some good, some
> bad:
> 
> https://treeherder.allizom.org/perf.html#/alerts?id=99
> 
> Should I file a regression bug here? Or should we just accept these?

We decided among the graphics team that given that the regressions arising from this change are WONTFIX. We have had too many problems with xrender giving performance cliffs on certain features like 3D transforms as well as driver bugs, such that it is worth accepting a slight loss in performance in some places to avoid the other sadness.
Flags: needinfo?(lsalzman)
Seems like there is a duplicate which hasn't been closed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1001407
Duplicate of this bug: 1001407
Depends on: 1247935
Depends on: 1248582
The workaround of setting gfx.xrender.enabled to false also resolves the issue of Firefox going to 100% CPU when logging into Republic Wireless where it displays an interstitial page loading graphic

https://republicwireless.com/myaccount/account/orders
Depends on: 1253386
Depends on: 1254151
Depends on: 1255834
Depends on: 1258086
Just adding for the record that this has made scrolling and rendering in general massively slower when connecting using an X server (at least with my test setup).

With gfx.xrender.enabled=true I'm getting ~40-60 fps while scrolling with good and low cpu usage, and with it set to false I'm getting ~2-5 fps with higher cpu usage.

Test setup:
- Recent* Ubuntu live DVD.
- Virtualbox (5.0.16) on Windows host (without guest additions installed).
- X server** on Windows (I'm using http://sourceforge.net/projects/vcxsrv/ ).
- Boot the ISO in vbox, choose "Try Ubuntu".
- At the guest: `sudo apt Install ssh && sudo passwd ubuntu` (and set a password).
- Make sure a local port is forwarded to the guest:22 in virtualbox.
- Host***: DISPLAY=localhost:0 ssh -YC ubuntu@localhost -p <your forwarded port>
- run firefox

At this setup, the default Firefox 45.0.1 performs great via forwarded X, but nightly scrolls extremely badly. I used mozregression which got me to this bug, and indeed after enabling xrender in nightly it now too scrolls great (with or without e10s enabled).

e10s alone did not affect scroll performance.


* Tested with main desktop Ubuntu 16.4 beta2, and also a recent XUbuntu nightly.
** Launch it with standard multi window, next next etc.
*** The ssh at mozilla-build is good enough.
Could catch - I spun a separate bug 1263222 to track this issue.
(In reply to Avi Halachmi (:avih) from comment #10)
> Just adding for the record that this has made scrolling and rendering in
> general massively slower when connecting using an X server (at least with my
> test setup).
> 
> With gfx.xrender.enabled=true I'm getting ~40-60 fps while scrolling with
> good and low cpu usage, and with it set to false I'm getting ~2-5 fps with
> higher cpu usage.
> 
> Test setup:
> - Recent* Ubuntu live DVD.
> - Virtualbox (5.0.16) on Windows host (without guest additions installed).
> - X server** on Windows (I'm using http://sourceforge.net/projects/vcxsrv/ ).
> - Boot the ISO in vbox, choose "Try Ubuntu".
> - At the guest: `sudo apt Install ssh && sudo passwd ubuntu` (and set a
> password).
> - Make sure a local port is forwarded to the guest:22 in virtualbox.
> - Host***: DISPLAY=localhost:0 ssh -YC ubuntu@localhost -p <your forwarded
> port>
> - run firefox
> 
> At this setup, the default Firefox 45.0.1 performs great via forwarded X,
> but nightly scrolls extremely badly. I used mozregression which got me to
> this bug, and indeed after enabling xrender in nightly it now too scrolls
> great (with or without e10s enabled).
> 
> e10s alone did not affect scroll performance.
> 
> 
> * Tested with main desktop Ubuntu 16.4 beta2, and also a recent XUbuntu
> nightly.
> ** Launch it with standard multi window, next next etc.
> *** The ssh at mozilla-build is good enough.

Hoes does Chrome perform for you in a similar situation?
Flags: needinfo?(avihpit)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)
> Hoes does Chrome perform for you in a similar situation?

Badly. Firefox wins by a huge margin with xrender enabled.

Like I said, I can actually get 60fps scrolls most of the time in Firefox, and Chromium is quite worse. Probably similar to Firefox with xrender disabled.
Flags: needinfo?(avihpit)
(In reply to Avi Halachmi (:avih) from comment #13)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #12)
> > Hoes does Chrome perform for you in a similar situation?
> 
> Badly. Firefox wins by a huge margin with xrender enabled.
> 
> Like I said, I can actually get 60fps scrolls most of the time in Firefox,
> and Chromium is quite worse. Probably similar to Firefox with xrender
> disabled.

I'm interested in the comparison between Chromium and Firefox with xrender disabled.
Flags: needinfo?(avihpit)
Using the bookmarklet from bug XXX:

https://bug894128.bmoattachments.org/attachment.cgi?id=776049

Nightly with xrender enabled: ~60 fps:
-----------------------------

Page: https://www.mozilla.org/en-US/
Steps (after ignoring 1): 418
Step: 5 px
Duration: 7003 ms (target: 7000)

Window size: 1232 x 854
Average interval: 16.67 ms
STDDEV intervals: 1.08 ms

intervals histogram:
6.0 - 8.0 ms: 2
14.0 - 15.9 ms: 21
15.9 - 17.3 ms: 361
17.3 - 18.0 ms: 28
18.0 - 22.0 ms: 4
22.0 - 32.0 ms: 2



Nightly default (xrender disabled): ~7.7 fps
---------------

Page: https://www.mozilla.org/en-US/
Steps (after ignoring 1): 53
Step: 5 px
Duration: 7036 ms (target: 7000)

Window size: 1232 x 854
Average interval: 129.54 ms
STDDEV intervals: 48.06 ms

intervals histogram:
2.0 - 4.0 ms: 1
6.0 - 8.0 ms: 1
8.0 - 10.0 ms: 1
12.0 - 14.0 ms: 2
14.0 - 15.9 ms: 1
15.9 - 17.3 ms: 1
80.0 - 120.0 ms: 1
120.0 - 180.0 ms: 45



Chromium: ~6.3 fps

Page: https://www.mozilla.org/en-US/
Steps (after ignoring 1): 40
Step: 5 px
Duration: 7018 ms (target: 7000)

Window size: 1258 x 863
Average interval: 161.69 ms
STDDEV intervals: 75.07 ms

intervals histogram:
15.9 - 17.3 ms: 3
32.0 - 35.0 ms: 2
120.0 - 180.0 ms: 19
180.0 - 250.0 ms: 15
500.0 - 1000.0 ms: 1
Flags: needinfo?(avihpit)
(In reply to Avi Halachmi (:avih) from comment #15)
> Using the bookmarklet from bug XXX:

Bug 894128.
Depends on: 1279505
I start to see some reports about Linux users having graphics issues or slow keyboard/mouse with XRender disabled by default in 47: bug 1279505 and probably bug 1279632, bug 1279687.

Could we keep an eye on this bug for a potential chemspill build if necessary?
Flags: needinfo?(lhenry)
Depends on: 1279632
This is causing a font rendering regression if you use freetype-freeworld with rgb anti-aliasing: https://bugzilla.redhat.com/show_bug.cgi?id=1343947
If we can figure out a workaround (re-enabling the pref) and try to fix this for 48 that may be enough. Passing this to Ritu since she is driving 47.   

Are other channels also affected?
Flags: needinfo?(lhenry) → needinfo?(rkothari)
Depends on: 1279785
Depends on: 1280795
Hi Jeff, I am planning to do a dot release and while this might be a valid issue, it doesn't seem critical enough for inclusion in a dot release. Do you agree? I would prefer to wontfix this for 47.
Flags: needinfo?(rkothari) → needinfo?(jmuizelaar)
I think that's fine. We haven't fixed anything 48 so we wouldn't really be buying any time by disabling it, only postponing the problem.
Flags: needinfo?(jmuizelaar)
Thanks Jeff! This is now a wontfix for 47. Nom'ing for platform triage.
I think there's an inconsistency with the bug title and resolution.

This bug's title is "investigate disabling xrender". It's marked as "wontfix" for 47, but actually xrender ends up disabled in 47.

I think "wontfix" here actually means "wont-re-enable-xrender".
Depends on: 1281817
Blocks: 1281834
No longer blocks: 1263222
Depends on: 1263222
Depends on: 1284427
Depends on: 1271100
Depends on: 1319554
Depends on: 1375801
You need to log in before you can comment on or make changes to this bug.