56767 2011-03-21 13:44:13 -0700 Differentiate scrollbar invalidations from page invalidations 2013-04-08 11:38:07 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 57202 1 enne enne bdakin enne jamesr nduca sam simon.fraser vangelis oldest_to_newest 370874 0 enne 2011-03-21 13:44:13 -0700 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. 372385 1 jamesr 2011-03-23 13:09:58 -0700 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? 372430 2 sam 2011-03-23 14:18:48 -0700 I believe Simon Fraser was going to work on this pretty soon. 372536 3 jamesr 2011-03-23 16:45:50 -0700 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. 374157 4 simon.fraser 2011-03-27 09:30:14 -0700 Go ahead and take this. Having ScrollableArea be a GraphicsLayerClient and making GraphicsLayers for scrollbars sounds like the right approach.