Opened 3 years ago

Last modified 3 years ago

#19276 assigned defect

Scrolling is slow and CPU intensive

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-6.0-issues, tbb-usability, tbb-performance, GeorgKoppen201606, TorBrowserTeam201606
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (21)

comment:1 Changed 3 years ago by cypherpunks

FWIW about:config does not have the issue, so it seems to be related to rendered pages.

comment:2 Changed 3 years ago by cypherpunks

TB 6.0.1 still has the issue.

comment:3 Changed 3 years ago by gk

Keywords: tbb-6.0-issues tbb-usability added
Status: newneeds_information

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?

comment:4 in reply to:  3 ; Changed 3 years ago by cypherpunks

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.enabled to false. 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.

comment:6 Changed 3 years ago by bugzilla

Keywords: tbb-performance added

FWIW, this is a long-standing problem of Firefox on Windows, and it's just getting worse with updates. The reason is that Mozilla doesn't test its products on different systems, thinking that testing on their configs is enough.

comment:7 in reply to:  6 ; Changed 3 years ago by gk

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.

comment:8 in reply to:  4 Changed 3 years ago by yawning

Replying to cypherpunks:

Turns out issue is solved by setting gfx.xrender.enabled to false. 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).

comment:9 in reply to:  7 Changed 3 years ago by cypherpunks

Replying to gk:

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.

5.5.5 does work out-of-the-box and has gfx.xrender.enabled set to true so it seems something did regress.

comment:10 Changed 3 years ago by 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.

comment:11 Changed 3 years ago by yawning

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.

comment:12 in reply to:  10 ; Changed 3 years ago by gk

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-surfaces and setting it to true help?

comment:13 in reply to:  12 Changed 3 years ago by 49ax56xr36

Replying to gk:

Does adding layers.use-image-offscreen-surfaces and setting it to true help?

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.

comment:14 in reply to:  11 ; Changed 3 years ago by 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.

comment:15 in reply to:  14 ; Changed 3 years ago by yawning

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.enabled to false. 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.

comment:16 in reply to:  15 ; Changed 3 years ago by 49ax56xr36

Replying to yawning:

Try setting layers.offmainthreadcomposition.enabled to false. 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.

comment:17 in reply to:  16 Changed 3 years ago by yawning

Replying to 49ax56xr36:

Replying to yawning:

Try setting layers.offmainthreadcomposition.enabled to false. 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).

comment:18 Changed 3 years ago by gk

Keywords: GeorgKoppen201606 TorBrowserTeam201606R added
Status: needs_informationneeds_review

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.

comment:19 Changed 3 years ago by mcs

r=brade, r=mcs

comment:20 Changed 3 years ago by gk

Keywords: TorBrowserTeam201606 added; TorBrowserTeam201606R removed
Status: needs_reviewassigned

Applied to tor-browser-45.2.0esr-6.5-1 and tor-browser-45.2.0esr-6.0-1 (commits 7d0974ce3580b26f24f9363404e5d36cc584e254 and 979f170107821ca481870c01820d628e55d47913)

Note: See TracTickets for help on using tickets.