Re: SVG hack for display engine

[Anand Tamariya <atamariya@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

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



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

[-- Attachment #2: Type: text/html, Size: 2421 bytes --]