[webkit-dev] Current status of threaded compositor for WebKit Gtk
ryumiel at company100.net
Sun Apr 14 00:52:16 PDT 2013
Long time no see.
I would like to share some of progresses about threaded compositor for
First of all, I made a another prototype about it and I push it on github.
*Needs discussion, and clean up. (For Gtk port)*
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
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.
3. pixel tests.. our team runs pixel tests internally, but we couldn't find
a way to run it using xvfb, yet. As soon as we find a way, we will enable
1. We need to solve this bug: https://bugs.webkit.org/show_bug.cgi?id=108899 ,
I will do this job from this week.
2. In WebKit Gtk, It uses XDamage extension to provide a callback mechanism
for repainting Gtk Widget in accelerated compositing case. But, what I
experienced is, whenever I placed a mouse pointer on top of webview that
has css3 animations, Xorg server uses almost 34% of cpu time. (My desktop
has quad-core, therefore, Xorg server eats a core alone.)
When I tried to render layers on on-screen window surface directly, this
problem didn't come up.
3. Scrolling with a mouse wheel does not update scrollbars in webview. I
think I miss some events about that. Minor problem.
4. Sometimes, changing viewport size of webview causes some tiles to be
broken. I don't have a idea about that yet, I need to look at codes.
*Remaining work items*
1. handle zoom.
2. handle viewport attribute.
( I sent this e-mail with a wrong address, sorry mrobinson and noamr for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev