[webkit-reviews] review granted: [Bug 57202] Allow setting composited backing stores for scrollbars and scroll corners : [Attachment 87677] fix compile breaks on win, avoid software painting composited scrollbars

[bugzilla-daemon at webkit.org]

Simon Fraser (smfr) <simon.fraser at apple.com> has granted James Robinson
<jamesr at chromium.org>'s request for review:
Bug 57202: Allow setting composited backing stores for scrollbars and scroll
corners
https://bugs.webkit.org/show_bug.cgi?id=57202

Attachment 87677: fix compile breaks on win, avoid software painting composited
scrollbars
https://bugs.webkit.org/attachment.cgi?id=87677&action=review

------- Additional Comments from Simon Fraser (smfr) <simon.fraser at apple.com>
View in context: https://bugs.webkit.org/attachment.cgi?id=87677&action=review

> Source/WebCore/ChangeLog:17
> +	   FrameView and RenderLayerComposited updated to provide layers for
frames that don't
> +	   use platform widgets for scrollbars.  The scrollbar/scroll corner
layers exist as siblings
> +	   of the frame's clip layer as children of a new synthetic
(non-rendering) scroll layer.  The
> +	   scrollbar/scroll corner layers always exist in the hierarchy, but if
there is no
> +	   scrollbar/corner then the layers do not render.

I'm concerned about adding new GraphicsLayers for scrollbars on SnowLeopard,
where we don't need them for Safari. I think you should add a switch somewhere
for platforms to opt in to composited scrollbars.

Otherwise this all looks good.

> Source/WebCore/rendering/RenderLayerCompositor.cpp:1445
> +	       m_horizontalScrollbarLayer = GraphicsLayer::create(view);

This is a little weird, that you create a GraphicsLayer whose client is another
object. It could lead to lifetime issues.