[webkit-dev] Current status of threaded compositor for WebKit Gtk

[Noam Rosenthal]

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
>>> reduce
>>> > 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
>>> with
>>> > untidy codes. (ex ChromeClientGtk, FrameLoaderClientGtk.. ) I think if
>>> we
>>> > 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.
>>>
>>> --Martin
>>>
>>
>> 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
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130415/b6c9e27f/attachment.html>