WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 56767
Differentiate scrollbar invalidations from page invalidations
https://bugs.webkit.org/show_bug.cgi?id=56767
Summary
Differentiate scrollbar invalidations from page invalidations
Adrienne Walker
Reported
2011-03-21 13:44:13 PDT
Scrollbar invalidations are currently not explicitly differentiated from normal page invalidations. FrameView::invalidateScrollbarRect calls FrameView::invalidateRect which then follows the normal invalidation path. Because scrollbar invalidates get conflated with other invalidations, the root layer page/tiles (at least in Chromium) get needlessly redrawn under the scrollbar on scroll. My general opinion is that scrollbars should be handled specially and should not be considered on the page. These invalidations can be differentiated implicitly by looking at the position of the scrollbar and seeing if the invalidation is wholly contained with the scrollbar. However, this approach hacky and short-sighted to me. I'd like not to have to guess whether an invalidation is intended for a scrollbar or not.
Attachments
Add attachment
proposed patch, testcase, etc.
James Robinson
Comment 1
2011-03-23 13:09:58 PDT
It seems like the best way to handle this would be to put scrollbars on their own composited layers and to route the invalidations there. Currently invalidations sent to a ScrollableArea are differentiated (invalidateScrollbarRect() vs invalidateRect()) but the FrameView sends both types of invalidations to the FrameView's backing (host window or owningRenderer). I'll try adding a new class to render the scrollbars that implements GraphicsLayerClient and can get inserted into the proper location in the composited layer tree, then teach the FrameView to route scrollbar invalidations to this object if it exists instead of the FrameView's backing. This should help both for the current Chromium tiling implementation as well for Lion-style scrollbars that overlay the visual content area since it avoids unnecessarily invalidating parts of the content that may be expensive to re-render. Does this approach seem sane?
Sam Weinig
Comment 2
2011-03-23 14:18:48 PDT
I believe Simon Fraser was going to work on this pretty soon.
James Robinson
Comment 3
2011-03-23 16:45:50 PDT
Awesome! I'll start looking at this since I want to understand this area of the code better, but I don't want to slow you down, Simon, so lemme know if you want get this done quickly and know how.
Simon Fraser (smfr)
Comment 4
2011-03-27 09:30:14 PDT
Go ahead and take this. Having ScrollableArea be a GraphicsLayerClient and making GraphicsLayers for scrollbars sounds like the right approach.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug