Scrolling is slow and CPU intensive
Scrolling in TB 6.0 is slow and increases CPU usage to near 100%. This occurs on all pages, even simple internal ones such as about:support.
The issue does not occur with Firefox ESR 45.1.1.
Activity
Replying to gk:
I guess this is on a Windows OS? Which version? Do you see error output or something on the browser console (Ctrl + Shift + J) while scrolling? Sorry for not mentioning the platform. The issue occurs on a Debian testing box. There was nothing in the browser console besides unrelated messages.
I've done some more testing to try and find why there was a difference between Firefox and TB. Unfortunately the previous comparison wasn't accurate as the Firefox instance i used was heavily modified. Using a clean profile made the issue appear with Firefox too so it's not TB specific.
Turns out issue is solved by setting
gfx.xrender.enabledtofalse. Because I'm unfamiliar with the Firefox code base, i don't know what the preference does, what its impact is, and whether it's worth setting in TB. Hopefully someone else can figure this out.
Replying to bugzilla:
FWIW, this is a long-standing problem of Firefox on Windows, and it's just getting worse with updates.
This is a Linux issue not a Windows one.
cypherpunks: Thanks for the workaround. Did 5.5.5 work for you out-of-the box? Might be interesting to dig a bit finding out what regressed if that's the case.
Replying to cypherpunks:
Turns out issue is solved by setting
gfx.xrender.enabledtofalse. Because I'm unfamiliar with the Firefox code base, i don't know what the preference does, what its impact is, and whether it's worth setting in TB. Hopefully someone else can figure this out.The behavior will end up being system/driver specific, since XRender performance depends on the driver. That said, upstream changed the pref(s) fairly recently, https://bugzilla.mozilla.org/show_bug.cgi?id=1180942 and https://hg.mozilla.org/mozilla-central/rev/432ef38dab95), and has written off performance related regressions on systems where XRender compositing outperforms Cairo (https://bugzilla.mozilla.org/show_bug.cgi?id=1241832#c6).
So in the mean time, the question is, do we care about systems that have drivers/hardware that supports XRender, but doesn't have hardware OpenGL? Or do we care about systems that do have hardware accelerated OpenGL more? The latter should be the majority...
As a side note, the windows upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=894128 (And it's totally orthogonal to the Linux rendering backend selection).
Everyone that actually has the issue is leaving out "what video card they have, and what drivers they are using if applicable".
It would probably be good to know why the pref is different between the ESR release as well, but unless digging there turns up something more actionable, switching the pref to false by default seems like the best course of action.
-
Replying to 49ax56xr36:
This severe regression continues to exhibit in the Advanced Certificate Manager dialog even with 'xrender' disabled. Likely in other dialogs as well. The disable setting may be ignored in these cases.
Does adding
layers.use-image-offscreen-surfacesand setting it totruehelp? 
Replying to gk:
Does adding
layers.use-image-offscreen-surfacesand setting it totruehelp?No perceptible difference. Did restart Tor Browser.
Created it as 'boolean' type, but when it was "reset" it reverted to an empty 'string' type before vanishing on the next restart.
Trac:
Username: 49ax56xr36-
Replying to yawning:
Everyone that actually has the issue is leaving out "what video card they have, and what drivers they are using if applicable".
nxagent -- virtual screen X-server, older version
Don't think an actual "drivers" are in the picture here, just the screen virtualizing X11 NX server.
Worked reasonably well with 5.5.5 and xrender=true. Epic disaster with 6.0.1. Six-oh-one with xrender=false seems a bit faster than 5.5.5 with xrender=true, but not different enough to cause complaint. Does seem a regression in the xrender code. Reading some of the above links it appears xrender is a mixed proposition. Works brilliantly on many targets, not-so-great on others. Could be a dumb bug that's imperceptible on fast hardware.
Trac:
Username: 49ax56xr36 Replying to 49ax56xr36:
Replying to yawning:
Everyone that actually has the issue is leaving out "what video card they have, and what drivers they are using if applicable".
nxagent -- virtual screen X-server, older version
Don't think an actual "drivers" are in the picture here, just the screen virtualizing X11 NX server.
Well, same sort of problem. I don't think that supports any of the relevant acceleration methods well enough (if at all), so you're probably stuck on some sort of software rendering regardless.
Worked reasonably well with 5.5.5 and xrender=true. Epic disaster with 6.0.1. Six-oh-one with xrender=false seems a bit faster than 5.5.5 with xrender=true, but not different enough to cause complaint. Does seem a regression in the xrender code. Reading some of the above links it appears xrender is a mixed proposition. Works brilliantly on many targets, not-so-great on others. Could be a dumb bug that's imperceptible on fast hardware.
One thing worth looking at for your specific case is disabling the off-main thread compositing (Enabled in FF40, so the 6.0.x series would be the first Tor Browser releases to support it. See https://bugzilla.mozilla.org/show_bug.cgi?id=994541).
Try setting
layers.offmainthreadcomposition.enabledtofalse. Behavior is noticeably different on my Poulsbo Atom box (using the open source 2D only drivers).Unfortunately, if I were a real Tor Browser person, I'd probably push against making the modified version of the pref the default even if it helps the 2d only configs since doing so will likely hurt more configs than it helps.
-
Replying to yawning:
Try setting
layers.offmainthreadcomposition.enabledtofalse. Behavior is noticeably different on my Poulsbo Atom box (using the open source 2D only drivers).The default for this setting in 6.0.1 is =false and that's what has been in effect. Set it to =true and it works better both with xrender=false and xrender=true. Seems a proper result as the event loop is presumably separated from rendering and can respond to mouse and keyboard events even while the browser is bogged down rendering.
I'm keeping 'offmainthreadcomposition' active and leaving 'xrender' disabled.
Disabling 'xrender' by default is potentially a diffcult choice--have no position on it. But considering that worst-case beahavior with xrender=true is terrible and worst-case with xrender=false is not-bad it might be a good idea.
Or maybe see if there's a "dumb bug" in there that can be fixed. Making the same calls multiple times or in a non-optimal order come to mind.
Trac:
Username: 49ax56xr36 Replying to 49ax56xr36:
Replying to yawning:
Try setting
layers.offmainthreadcomposition.enabledtofalse. Behavior is noticeably different on my Poulsbo Atom box (using the open source 2D only drivers).The default for this setting in 6.0.1 is =false and that's what has been in effect. Set it to =true and it works better both with xrender=false and xrender=true. Seems a proper result as the event loop is presumably separated from rendering and can respond to mouse and keyboard events even while the browser is bogged down rendering.
That's the idea behind it, yes, though it does sacrifice performance since there's extra overhead involved in making it multithreaded (The default, with a clean 6.0.1 installation is most certainly to enable it, not sure why it was disabled for you).
I'm keeping 'offmainthreadcomposition' active and leaving 'xrender' disabled.
Disabling 'xrender' by default is potentially a diffcult choice--have no position on it. But considering that worst-case beahavior with xrender=true is terrible and worst-case with xrender=false is not-bad it might be a good idea.
I don't personally think it's that hard of a call to make, since upstream has decided the path to take and the next ESR will change the behavior. Till then, I would be for disabling Xrender in the next point release and alpha series since it's probably going to help more than it hurts.
Or maybe see if there's a "dumb bug" in there that can be fixed. Making the same calls multiple times or in a non-optimal order come to mind.
My ~6 year old netbook being slow isn't enough motivation for me to debug an upstream graphics issue (perf on 45.1.1 ESR is equally horrible). Apparently the code is all getting changed again anyway (to use Skia instead of cairo).
-
Alright, bug_19276_v2 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_19276_v2) sets the Xrender pref to
false. We should still investigate whether we can find a solution to the problem in comment:10.Trac:
Keywords: N/A deleted, GeorgKoppen201606, TorBrowserTeam201606R added
Status: needs_information to needs_review mentioned in issue #19362 (moved)
mentioned in issue #21388 (moved)
