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"

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.

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/

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?

(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.

Seems like there is a duplicate which hasn't been closed: https://bugzilla.mozilla.org/show_bug.cgi?id=1001407

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

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?

(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.

(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.

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

(In reply to Avi Halachmi (:avih) from comment #15) > Using the bookmarklet from bug XXX: Bug 894128.

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?

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?

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.

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.

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".