[webkit-dev] Current status of threaded compositor for WebKit Gtk
noam at webkit.org
Mon Apr 15 00:37:39 PDT 2013
Replying from right address this time...
On Mon, Apr 15, 2013 at 9:23 AM, Noam Rosenthal <noam at webkit.org> wrote:
> Thanks Gwang-Yoon
> Yes, I would like to get rid of TextureMapperImageBuffer, and we can do
> that once Qt-WebKit1 can move to the threaded compositor.
> I would like to use the threaded compositor as a replacement for the
> direct TextureMapper approach in general, so that we have less unmaintained
> code paths.
> What concerns me right now is that this implementation would fragment code
> paths that we should focus on removing, such as "non composited contents" (
> https://bugs.webkit.org/show_bug.cgi?id=110355). But otherwise let's move
> forward as far as I'm concerned...
> On Mon, Apr 15, 2013 at 2:53 AM, Gwang-Yoon Hwang <ryumiel at company100.net>wrote:
>> Thanks for respond.
>> On Mon, Apr 15, 2013 at 1:10 AM, Martin Robinson <mrobinson at webkit.org>wrote:
>>> On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang
>>> <ryumiel at company100.net> wrote:
>>> Nice work!
>>> > 1. There are 3 accelerated compositing methods in WebKit1 Gtk. Cairo,
>>> > Clutter, and GL. These patches will adds 1 more options, threaded
>>> > compositing. I think we need to simplify/unite rendering paths to
>>> > complexity.
>>> I think that No'am expressed interest in ditching the ImageBuffer
>>> compositor, so that would simplify things a bit.
>>> Good. Let's discuss about that with No'am.
>>> > 2. In these patches, I attached threaded compositor into webkit1 gtk
>>> > untidy codes. (ex ChromeClientGtk, FrameLoaderClientGtk.. ) I think if
>>> > need to maintain 4 compositing paths at a time, we need more cleaner
>>> > approach, with a single interface & factory.
>>> I'm surprised you didn't focus on WebKit2, since WebKit1 is in
>>> maintenance mode now.
>> It was easier to prototype, debug in WebKit1. So I did it first. Now I am
>> going to make it for WebKit2 Gtk.
>> And, there are another reason for that, If we choose threaded compositor
>> on WK2 only, we need to add another compositing path to
>> our maintenance list. I think it would be better if WK1 and WK2 uses same
>> unify compositing paths to reduce maintenance issues.
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev