[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: Fri, 19 Nov 2021 07:02:20 +0530

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

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

reply via email to

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