Re: webkit integration in the xwidget branch

[joakim]

Julien Danjou <address@hidden> writes:

> On Tue, Jun 28 2011, address@hidden wrote:
>
>> I did a proof of concept webkit xwidget in the xwidget branch.
>
> I'm glad to read that.
>
>> pros:
>> - shows tighter webkit integration is indeed possible and that the
>> xwidget branch is a pretty cool playground
>
> :-)
>
>> cons:
>> - well, webkit doesnt have an out of the box mvc model. I find it
>> perplexing that state of the art web engines in 2011 cant even do a 1990s
>> type split pane view. I did some brief research around this mysterious
>> ommission and found odd references in wikipedia that this might be
>> covered by a patent or something. I hope I'm just having a bad dream.
>
> What does that means when using it, concretely? I don't know what model
> WebKit uses if it's not MVC, so what's wrong conretely?
> (maybe I should take a look at the WebKit API :-)

I made an alternate xwidget called webkit-osr.

It creates a separate offscreen window and renders the webkit component
there. the onscreen views are separate gtk drawing areas and the
offscreen webkit gets copied onscreen through a cairo pixmap blitting
operation.

its just a proof of concept, there are worse drawing glitches than
usual. To make it usable the following is needed:

- handle damage events from the offscreen window so the onscreen window
  is redrawn
- optimize clipping area
- propagate onscreen mouse events to the offscreen webkit

This technique should be visualy correct and have acceptable performance
most of the time, if one gets the clipping right. its also a textbook
type solution so it shouldnt bitrot too fast either.



>
>> Links like these:
>> http://www.chromeplugins.org/plugins/google-chrome-dual-view/> makes me 
>> think time stands still. Which is good news for us Emacsers I
>> suppose.
>
> In such a context, I tend to argue that this kind of the work of the
> window manager to organize windows.

-- 
Joakim Verona