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

[Akira Kyle]

On Wed, Nov 25, 2020 at 08:11 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

> > Consider that any "rich" display element you might want 
> > displayed 
> > among others in a buffer needs to have some display property so 
> > that redisplay can be aware of it's position relative to other 
> > elements in the buffer. Thus there ultimately needs to be some 
> > entry in the glyph matrix for this "rich" display element. But 
> > the 
> > current way redisplay happens, with its various optimizations, 
> > you 
> > can't expect that every time the element is moved or partially 
> > clipped or even removed entirely, that Emacs will ask for your 
> > "rich" element to draw itself.
>
> It is a relatively simple matter to disable some optimizations 
> when a
> widget is displayed.  It is also relatively simple to tell the 
> widget
> to redraw itself when redisplay changed its position on the 
> screen.

Yes, but you had previously pointed to that fact that xwidgets 
needs to such disable such optimizations as part of the "kludge" 
that would need to be resolved for xwidgets to be considered 
viable for a path forward. Having looked at that, I'm not sure gtk 
will ever want to cooperate without doing things that would be 
considered hacks by gtk folks.

> > I see this second option as ultimately being pretty brittle as 
> > it 
> > needs to force redisplay to draw your glyph every time 
> > redisplay 
> > changes some properties of its display and pass what those are 
> > to 
> > your "rich" element and hope that it respects them.
>
> I don't see why you consider this such a significant problem. 
> The
> number of interfaces that such a "rich" display element needs to
> support is very small and well-defined.  The problem with 
> xwidgets in
> this regard is that its interaction with the display code was 
> left
> unfinished, it basically just copy/pastes the code which 
> supports
> display of images, which is not 100% correct, since xwidgets 
> don't
> display a static bitmap.

The "number interfaces" will likely be small no matter what 
solution is taken, its more about how easy you want to make it for 
a "rich" display element to really mess with Emacs' display and 
input handling. For example with xwidgets the onus is on the 
widget implementation to not totally steal keyboard focus from 
Emacs. I've found that gtk widgets really like stealing keyboard 
focus so its easy to end up in a state you can't escape out 
of. Similarly gtk widgets won't always easily draw themselves 
where you want at the size you want so its easy for widgets to 
render, say, across window boundaries. The xwidget approach 
requires non-insignificant work on the widget end to ensure the 
widgets will work within the confines of Emacs' redisplay. I'd 
think that such an interface to support "rich" display elements 
should be restrictive enough to not easily allow the "rich" 
display elements to misbehave. Especially if it becomes possible 
to define such elements from lisp. I see expanding the current 
image handling to give richer canvases that can be drawn on as the 
"safer" approach with respect to these concerns. But again much of 
this is highly speculative and doesn't mean much until some code 
is actually written. I'm just trying to voice some of the 
frustrations I had in working on the current xwidget code and how 
that might apply here.