Thanks martin. I think I should have been read your post before starting this discussion. :) http://blog.abandonedwig.info
On Jul 27, 2012, at 8:16 PM, Martin Robinson <[email protected]> wrote: > On Fri, Jul 27, 2012 at 12:32 PM, Gwang-Yoon Hwang > <[email protected]> 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. I totally agree with that. That's why I made a metabug before starting implementation. >> 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. > Yes, "same window from multiple processes" causes the problem. Your approach quite interesting, do you have a bug of your work on bugzilla? I think I need to read Xcomposite extension. >> 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 If we choose to make a thread or a process (I think it is more close to solution) for compositing, It will be seperated from other ports. And a implementation is quite huge job, that's why I trying to use already implemented UIProcesss compositing. I am not sure compositing job on UIProcess causes meaningful decrease in UI responsiveness. Based on my experience, compositing layers usually consumes less than 15ms in embedded platform. And processing and passing events to WebProcess do not needs so much cpu time. ( less than 1ms. ) So there were plenty of time to capture UI events at 60 fps. Thanks, Gwang Yoon Hwang
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-gtk
