> But that's not generally true.  Redisplay has its own criteria to
> decide which parts need to be redrawn, and those criteria are not
> necessarily trivial to guess from buffer contents alone, because
> redisplay has access to all kinds of information recorded specifically
> for that purpose, and not exposed to Lisp.
>
Display engine must continue to do what it does presently to not break any
functionality in the terminal and elsewhere.  I'm only asking to extend the
functionality to allow a developer more freedom to play with SVG should he
desire.

>   . 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?
> >
> >  "required information" in my sentence above refers to the parameters of
> (svg-render) API viz. svg x y width
> > height. display-svg-hook can be a no-arg function.
>
> What are X, Y, WIDTH and HEIGHT here?
>
- 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 .

And how will those hooks or svg-render know what to display an where
> on the screen?
>
Take some simple cases like a tooltip or an auto-completion popup.  They
usually display near the point with some offset. (posn-at-point) provides
that information. For complete window display control like my formula
editor, they can specify to display at (0,0) an image of size
(window-pixel-wdth) x (window-pixel-height).