Re: SVG hack for display engine

[Eli Zaretskii]

> From: Anand Tamariya <atamariya@gmail.com>
> Date: Fri, 19 Nov 2021 07:02:20 +0530
> Cc: Alexander Adolf <alexander.adolf@condition-alpha.com>, Emacs Devel 
> <emacs-devel@gnu.org>
> 
>  So this is only for popping up some additional image on top of the
>  "normal" Emacs display?  Or is the intent to replace some parts of the
>  "normal" Emacs display, i.e. what we show in the windows of the
>  regular frames?
> 
>  And if this is just for popups, isn't there already some hook ypou
>  could use for that purpose?  If not, what is missing in the existing
>  hooks?
> 
> Two problems in current approach:
>  
>  I've used (read-event) and (lookup-key) to allow for key translations for 
> navigation commands.
>  Hopefully with a tighter integration, all of this will not be required.
> 
> - Do you remember I said I am running my own event loop? This means I'm 
> missing out on the key
> translations that Emacs would normally handle for me. So anything the 
> developer hasn't coded for will
> remain inaccessible while the mode is in effect.

Sorry, I don't follow: what do these issues have to do with what we
are discussing, and in general to the display engine?  What am I
missing?

>  > - svg-render (svg x y width height)
>  > svg is a Lisp DOM object as returned by (dom-node). This should use 
> librsvg to generate a bitmap
>  image of
>  > svg of size (width x height) and superimpose it at position (x, y) on the 
> current bitmap being displayed
>  by
>  > Emacs. The current image API takes either a filename or XML string for 
> SVG. This can be
>  avoided if svg is a
>  > Lisp DOM. Edit: (dom-node) is defined in dom.el .
> 
> Can you visualize the amount of string serialization, deserialization and SVG 
> parsing happening in a draw or
> move operation with live feedback? Do you see it performing well for even a 
> moderately sized SVG?
> 
> Without direct SVG support in the display engine ie. a way for a developer to 
> tell the display engine to use a
> particular SVG  in a DOM form during it's normal display cycle, any such 
> implementation will remain a hack -
> it works but it could be much better. 

I understand that you want Emacs to be able to support display of an
SVG specified via a DOM.  What I'm trying to understand, and so far
failing, is where would that DOM come from, assuming the SVG will
display text of some buffer or string.  Can you explain the connection
between the text to be displayed and the DOM?