Re: SVG hack for display engine

[Eli Zaretskii <eliz@gnu.org>]

> From: Anand Tamariya <atamariya@gmail.com>
> Date: Thu, 18 Nov 2021 05:17:47 +0530
> Cc: Alexander Adolf <alexander.adolf@condition-alpha.com>, Emacs Devel <emacs-devel@gnu.org>
> 
>  Please describe the intended use of these APIs and the hook to provide
>  the display feature(s) you have in mind, and how will that work in
>  concert with the display engine.  I don't think I have a clear picture
>  of that yet.
> 
>  Also, please describe what happens with use of these APIs when just a
>  small part of the Emacs display needs to be redrawn.
> 
> Maybe a demo ( https://youtu.be/1343m3LY4mo ) will help you visualize my suggestion. In the video, an
> event loop is started in the scratch buffer. All the edit operations update text and text property in a temporary
> buffer, say a.txt. Based on this information, in-memory SVG DOM is updated. Ultimately, the display engine
> updates the view with this SVG image. In cases like this, the mode can have full control over the display if so
> desired.
> 
> Since you have a problem accessing my repo, I've added the code of a function I call in my event loop at the
> end of this mail.
> 
> With a tighter integration, Emacs would define a new data structure {svg, x, y, w, h} and two new variables
> with this type - new_svg and prev_svg. Then the sequence of operations would be:
> - Display engine refreshes the view bitmap with current logic - full or partial refresh as the case may be.
> - If it's a graphical display
> - prev_svg = new_svg
> - Run display-svg-hook. The registered user function will call (svg-render) function passing required
> information. This API sets the value in new_svg.
> - If the bounding box of new_svg < the bounding box of prev_svg, display engine refreshes the area of
> prev_svg in the view bitmap.
> - Generate a bitmap for new_svg and superimpose it on the view bitmap.
> - Display the view bitmap to the user.

Thanks, but I'm not sure yet how to connect this to what the display
engine actually does.  Are you familiar with what happens in the
display code during a single redisplay cycle?  If so, could you
describe that and insert into that description what you say above?
That would go a long way towards making sure we are on the same page,
which I think is a necessary precondition for discussing your
proposal.

Failing that, I could try asking questions whose answers might help
reconstructing those missing links.  For example:

 . does this mean you expect the display engine to tell that
   display-svg-hook which parts of the display were redrawn?
 . what is the "required information" to be passed to
   display-svg-hook, and how will it be generated from the information
   that exists in the display engine?