[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SVG hack for display engine

From: Anand Tamariya
Subject: Re: SVG hack for display engine
Date: Thu, 18 Nov 2021 18:59:10 +0530

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]