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

Gwang-Yoon Hwang ryumiel at company100.net
Sun Apr 14 17:53:10 PDT 2013

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>

More information about the webkit-dev mailing list