Re: [tor-bugs] #19276 [Applications/Tor Browser]: Scrolling is slow and CPU intensive

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#19276: Scrolling is slow and CPU intensive
-------------------------------------------------+-------------------------
 Reporter:  cypherpunks                          |          Owner:  tbb-
     Type:  defect                               |  team
 Priority:  Medium                               |         Status:
Component:  Applications/Tor Browser             |  needs_information
 Severity:  Normal                               |      Milestone:
 Keywords:  tbb-6.0-issues, tbb-usability, tbb-  |        Version:
  performance                                    |     Resolution:
Parent ID:                                       |  Actual Points:
 Reviewer:                                       |         Points:
                                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by yawning):

 Replying to [comment:16 49ax56xr36]:
 > Replying to [comment:15 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).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19276#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs