[Webkit-unassigned] [Bug 78872] [chromium] ScrollbarLayerChromium/CCScrollbarLayerImpl for CC-side scrollbar painting

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Tien-Ren Chen <trchen at chromium.org>  2012-02-17 13:54:09 PST ---
(In reply to comment #7)
> (From update of attachment 127514 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=127514&action=review
> 
> >>> Source/WebCore/rendering/RenderLayerCompositor.cpp:1866
> >>> +                theme->attachToGraphicsLayer(scrollbar, m_scrollLayer.get(), m_layerForVerticalScrollbar.get());
> >> 
> >> Aren't we going to want to be able to draw any kind of scrollbar theme on the impl side? I'm not sure I follow what this class is trying to do.
> > 
> > The whole idea about ScrollbarThemeCCScroll is to provide an interface to create specialized PlatformLayer for scrollbars. (ScrollbarLayerChromium/CCScrollbarLayerImpl) The impl-side painting logic will be handled by the CCScrollbarLayerImpl implementation.
> > 
> > I don't think it is easy to allow drawing any kind of scrollbar theme on the impl side. It would put too much restriction on the ScrollbarTheme implementation. That means you have to make paint a static function, no access to the ScrollbarTheme during painting.
> > 
> > I think it is necessary to have different painting function for the impl side. Even creating GraphicsContext in the impl side could be a problem (correct me if I'm wrong).
> 
> If you're just creating a scrollbar layer, why do you need this factory-style interface to do it? Are you planning to have different types of scrollbar layers? I guess I just don't follow why the theme has to be replaced here just so we can create platform layers of the right type.

Yes, although currently I don't think any of the platform use more than one scrollbar theme, there is no reason why not to support that.

> Also, I don't think it is necessary to have a different painting function for the impl side.  My hope is that we can create a new ScrollbarTheme object of the same type and pass it over to the impl side with all of the scrollbar data, but not an actual scrollbar pointer.  It's not a static function, but it is an object with no member variables that just uses a vtable to decide what functions to use.  Then we can reuse Ganesh to wrap a GraphicsContext3D in a GraphicsContext and reuse the same paint routines to just draw directly into the backbuffer.  I think it's do-able and it'll be the easiest path to get all the other platforms to have impl-side scrollbars without rewriting paint routines for all of them.

I see. It actually sounds like a better plan. I'll try to reuse existing paint function then. This way we probably don't even have to do much modification with ScrollbarTheme.

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