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.net>wrote: > >> Thanks for respond. >> >> >> On Mon, Apr 15, 2013 at 1:10 AM, Martin Robinson <mrobin...@webkit.org>wrote: >> >>> 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