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

[Eli Zaretskii]

> From: Akira Kyle <akira@akirakyle.com>
> Date: Tue, 24 Nov 2020 18:36:38 -0700
> Cc: emacs-devel@gnu.org
> 
> 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.

> 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.