Things are not that bad. (See Shadow DOM for instance where people begged
for it to become a standard)
You should definitely write something up and have a working prototype that
demonstrates how your solution improves performance, cleaner
implementations, etc. You will also have to prove that this
Thanks for respond.
On Mon, Apr 15, 2013 at 1:10 AM, Martin Robinson wrote:
> On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang
> wrote:
>
> Nice work!
>
> > 1. There are 3 accelerated compositing methods in WebKit1 Gtk. Cairo,
> > Clutter, and GL. These patches will adds 1 more options, threa
On Apr 13, 2013, at 1:55 AM, Carlos Garcia Campos wrote:
>
> El vie, 12-04-2013 a las 18:15 -0700, Maciej Stachowiak escribió:
>> On Apr 12, 2013, at 4:09 PM, Karen Shaeffer wrote:
>>
>>>
>>> Of course, I understand that. But there is a huge opportunity cost to
>>> webkit.
>>> The c++11 sta
On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang
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
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
5 matches
Mail list logo
