Re: [webkit-dev] Current status of threaded compositor for WebKit Gtk
Replying from right address this time... On Mon, Apr 15, 2013 at 9:23 AM, Noam Rosenthal n...@webkit.org wrote: Thanks Gwang-Yoon Yes, I would like to get rid of TextureMapperImageBuffer, and we can do that once Qt-WebKit1 can move to the threaded compositor. I would like to use the threaded compositor as a replacement for the direct TextureMapper approach in general, so that we have less unmaintained code paths. What concerns me right now is that this implementation would fragment code paths that we should focus on removing, such as non composited contents ( https://bugs.webkit.org/show_bug.cgi?id=110355). But otherwise let's move forward as far as I'm concerned... On Mon, Apr 15, 2013 at 2:53 AM, Gwang-Yoon Hwang ryum...@company100.netwrote: Thanks for respond. On Mon, Apr 15, 2013 at 1:10 AM, Martin Robinson mrobin...@webkit.orgwrote: On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang ryum...@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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Current status of threaded compositor for WebKit Gtk
On Sunday 14 April 2013, Martin Robinson wrote: I'm surprised you didn't focus on WebKit2, since WebKit1 is in maintenance mode now. WebKit1 is easier to develop for. Especially now that we are not allowed to develop in WebKit2 anymore.. Second. Part of what this worl gives us is to unify the code-paths that QtWK1 and QtWK2 uses and thereby get rid of WK1 specific codepaths in WK2. I think it is a mistake to keep WK1 so undeveloped that it just ties up code in WebCore we can not remove or clean up. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Current status of threaded compositor for WebKit Gtk
Long time no see. I would like to share some of progresses about threaded compositor for WebKitGtk. First of all, I made a another prototype about it and I push it on github. https://github.com/ryumiel/webkit-experimental/commits/threaded-compositing *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 complexity. 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 pixel tests. *Remaining Problems* 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. Thanks. ( I sent this e-mail with a wrong address, sorry mrobinson and noamr for duplicated email.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Current status of threaded compositor for WebKit Gtk
On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang ryum...@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. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Current status of threaded compositor for WebKit Gtk
Thanks for respond. On Mon, Apr 15, 2013 at 1:10 AM, Martin Robinson mrobin...@webkit.orgwrote: On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang ryum...@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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
