[Webkit-unassigned] [Bug 78028] Not For Review: Decouple scrollbar painting from Scrollbar object

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 10 17:48:13 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=78028


Adrienne Walker <enne at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andersca at apple.com,
                   |                            |jamesr at chromium.org




--- Comment #5 from Adrienne Walker <enne at google.com>  2012-02-10 17:48:13 PST ---
(CCing andersca, as I'm not sure how this intersects with the ScrollTree work and also wonder if "drawing scrollbars from another thread" is a concern for Safari too.)

Peter, sorry for not giving you feedback on this sooner.

Separating out painting code at the ScrollbarThemeChromium level doesn't feel like the right place to put this abstraction.  It's right in the middle of a virtual inheritance hierarchy, so it's awkward to have some functions branch off into the *Painter class that takes ScrollbarData, but still have a whole bunch of virtual functions in base classes that take Scrollbar*.

Talking out loud, the goal here is to be able to draw scrollbars (with adjustable scroll positions) from a separate thread, sharing as much painting logic from ScrollbarTheme as possible.

Just holding a reference back to an existing ScrollBar isn't quite right, because we want to be able to have that other thread 
manipulate the scroll position independently and draw it, without messing with the actual Scrollbar.  Duplicating the Scrollbar itself seems like too much to reconstruct.  Scrollbar itself has-a ScrollableArea and is-a Widget which has-a ScrollView.  That'd be a lot to try to duplicate.

I wonder if a better approach would be to go a little bit deeper than you're going and get all ScrollbarTheme-derived classes to operate on some other abstraction than Scrollbar.  The theme classes are already functional classes, so they just need something that conforms to a Scrollbar-like interface rather than directly using Scrollbar.  In other words, create some interface that both Scrollbar and ScrollbarData could implement and have all the Scrollbar theme code operate on that instead.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list