Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Akira Kyle]

On Mon, Nov 23, 2020 at 02:39 AM, Lars Ingebrigtsen 
<larsi@gnus.org> wrote:

> This is great news -- the demo looks awesome.

Thanks!

> Just a couple of comments (without having actually tried it or 
> even
> looked at the code):
>
> One thing I hoped to do with the in-tree xwidget code was to use 
> it in
> eww to display media types Emacs doesn't support -- primarily 
> .mp4
> <video> elements (and youtube videos, for those who doesn't find 
> that
> abhorrent).  I poked at it for a bit, but the current code is 
> very much
> tied to the xwidgets mode owning the buffer, and I haven't yet 
> had the
> stamina to fix that.
>
> Is this easier with your package?  That is, the ability to plop 
> in an
> arbitrary number of widgets into any buffer?

Possibly, but I'm not sure it would be wise to try. I originally 
started with the current xwidget code, which does support such 
capabilities. However, I found what I think are fundamental 
conceptual incompatibilities with the way Emacs' redisplay and 
gtk's event loop want to handle drawing stuff to the screen. Thus 
I feel like the only sane way to mix the two is to allow gtk to 
just take over an Emacs window which is always rectangular. No 
need to worry about scrolling and all the redisplay optimizations 
that will try to interfere with gtk attempting to draw at some 
point in the buffer. Even then Emacs and gtk don't play very 
nicely when it comes to grabbing keyboard and mouse input. Not to 
mention the fundamental differences in UI paradigms between Emacs 
being primarily textual and gtk with it's eye candy interfaces. Is 
it really so wise to try to mix the two?

Thus the second half of my previous email where I speculated about 
ways to move the fundamental ways Emacs does rendering forward. I 
think if Emacs had an open gl surface it was drawing to, it could 
handle rendering more intense graphical sources such as from a 
video. It will take a lot of work to get there, but I can't 
imagine another way that wont feel at least somewhat hacky to 
render something as graphically intensive like a video in a 
buffer.

> The other thing I'm wondering about is the (pure) reliance of 
> Cairo (if
> I understood you correctly).  It seems like Cairo development is 
> slowing
> down as many projects have started using Skia instead.  Emacs 
> supports a
> number of graphics backends for a reason -- they pop up, last a 
> few
> years, and then they die off, and there's no reason to believe 
> that
> Cairo is going to be the One True Toolkit.  Toolkits come and 
> go; Emacs
> is forever.  :-)

I think the death of Cairo has been greatly exaggerated :) The 
recent hacker news post about it brought up some good points about 
this expectation that projects have daily commits for it to be 
considered "alive". I don't see Cairo going anywhere for awhile, 
at least so long as projects like gtk and gnome rely on it. Also I 
wouldn't characterize Cairo as a "toolkit" at least in the sense 
that gtk is a toolkit or motif is a toolkit. Cairo is more like a 
nice graphics api, and the thing I've come to realize about nice 
api's is they tend to stick around in one form or another (kind of 
like emacs has).