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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 17 15:50:44 PST 2012


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





--- Comment #11 from Tien-Ren Chen <trchen at chromium.org>  2012-02-17 15:50:44 PST ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > 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.
> > 
> > Allow me to ask a dumb question. Does Ganesh wrap a GraphicsContext3D or OpenGL FBO/texture? There is subtle difference here because in Android port we use command buffer to delegate drawing to another process. That is, GraphicsContext3D calls are not backed by libGL.so. I'm afraid Ganesh won't work with it.
> 
> Ganesh uses the same command buffer code that other GraphicsContext3D calls, although it hooks in at a slightly lower level.  It works fine in the Android port.

Ok, let me write some code that actually make use of it. Not having to write separate paint function sounds a big big plus to me.

-- 
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