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

[Gwang-Yoon Hwang]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130415/552e82f1/attachment.html>