Re: Rethinking the design of xwidgets

[Tomas Hlavaty]

some kind of canvas was discussed in
id:87zh9hrxfj.fsf@logand.c
and
id:83img4aegz.fsf@gnu.org

It was discussed in context of a WYSIWYG editor features, and console
based pdf viewer emacs-frabuffer and pure elisp pdf generator emacs-pdf.

Eli suggested:

   > If you want to do layout for PDF, I think one way forward would be
   > to implement a pdfterm.c "terminal" for Emacs, which produces PDF
   > like the existing *term.c backends do for supported display types.

that might be better than some kind of xwidget

> For example, consider svg support, which is my preferred image 
> format. As far is I can tell, currently Emacs rasterizes svgs 
> itself before ultimately drawing them on a cairo context. Since 
> librsvg supports drawing directly on a cairo context, it would be 
> much more efficient to do so, however adding support for svg could 
> be easily moved out of emacs into a dynamic module and drawn 
> directly onto it's own widget. This would allow users of the NS 
> toolkit to not have to rely on librsvg if they didn't want to as I 
> believe NS can render svgs itself.

It is not clear to me, why a dynamic module would be better.

For example, emacs-framebuffer can display svg images without any
dynamic module by using external program, because emacs-nox does not
have cairo or librsvg or NS toolkit.

Ideally, there would be a canvas (e.g. pdfterm) providing low-level
drawing primitives (something like html canvas API) and the rest built
on top of that in elisp.