[webkit-gtk] Enable UI_SIDE_COMPOSITING for WebKit2 GTK

[Martin Robinson]

On Fri, Jul 27, 2012 at 12:32 PM, Gwang-Yoon Hwang
<ryumiel at company100.net> wrote:

Thanks for sending this to the list! I think it's quite important to
think carefully before introducing a lot of code that could seriously
affect the  maintenance burden of the port.

> The main reasons of this work listed below.
> 1.  We are facing on the problem "Xlib: unexpected async reply" on specific
> embedded system. Because WebProcess and UIProcess have "thread unsafe Xlib
> connection" at the same time, we need to maintain single Xlib connection.

Certainly, different processes can maintain their own connections to
the X server though? the UIProcess and the WebProcess are different
processes after all. Is this issue accessing the same window from
multiple processes? If that's the case, I'm writing a patch that uses
XComposite to avoid rendering to the UIProcess window directly. In any
case, this sounds like a bug either in our AC implementation or the X
server on the specific embedded system, not a reason for
re-architecture.

> 2. To maintain single Xlib connection on WebKit2 Gtk, we can reuse
> UI_SIDE_COMPOSITING feature that already implemented in WebKit2 QT port.
> 3. We can optimize UI_SIDE_COMPOSITING together with other ports (QT, EFL)

I agree that it's often beneficial to share more code with a port when
possible. Currently we share a lot of AC code with the Mac port now,
so I think this benefit is a bit of a wash.

> 3. In the embedded system, it is important to reduce workload of the main
> thread/process. :)

Moving expensive work to the UIProcess lessens one of the original
benefits of WebKit2 -- keeping the UI responsive at all times. I don't
think that using the UIProcess in this way is a nice work-around for
not having a threaded compositor. I know it's a complex task, but a
good solution, for this problem is simply writing a threaded
compositor.

--Martin