Re: Rethinking the design of xwidgets

[Mingde (Matthew) Zeng]

Hi Akira,

> Another use case I had in mind for my proposed improved xwidgets is
> better pdf rendering. I use pdf-tools constantly and it's one of the
> best pdf viewers out there (not just because it's in emacs). I'll
> sometimes even use it to give presentations so I never have to leave
> Emacs. However it's design inherently limits its rendering performance
> as it must rasterize each pdf page in a separate process then pipe
> that data to emacs to display as an image. Granted this could be
> avoided by turning the epdfinfo server process into a dynamic module,
> however it will still be a bit roundabout as the pdf page would have
> to first be rendered into a cairo context then rasterized then Emacs
> will draw that rasterized image onto another cairo context to get it
> onscreen. Having direct access to an onscreen cairo context would
> eliminate this and make it easier to support crisp, performant
> rendering onto HiDPI displays. Maybe I could even throw slide
> animations into my presentations this way!

You might've already tried it (since you mentioned in the main thread), but I 
still want to point out that currently the Emacs Application Framework's 
PDF-viewer [1] is probably your go-to choice (for now) for best PDF rendering 
in emacs, as it uses muPDF in the shadow.

>From your main thread:
> Unfortunately EAF uses Qt to reparent a window
> into emacs and Python to do two way RPC with elisp. IMO it isn't a
> very emacsy way to enhance Emacs' display capabilites and is limited
> to just taking over a whole window rather than being embedded as part
> of a buffer (key to supporting dynamic content such as an interactive
> inline plot inside an org mode document). That leaves xwidgets which
> seems to be somewhat incomplete, unused, and neglected. I've been
> poking around the xwidgets code and I really like the concept, however
> the implementation seems to need some more thought and work.

As the maintainer of the EAF project, I have to point out that the original 
motivation for the existence of EAF was to enhance Emacs browser rendering, pdf 
rendering, and video rendering capabilites. The QGraphicsView was designed to 
span over the entire buffer to make it more emacsy, to fit the "one buffer, one 
major mode" idea. The choice was obvious when using EAF to view modern 
webpages, PDF, or videos. However EAF _doesn't have to_ stay this way, it is 
completely viable to embed the QGraphicsView inside a buffer.

I don't completely understand your opinion on why EAF is not very emacsy, I can 
see why it's not lispsy, but EAF is keyboard-oriented, highly extensible and 
customizable. It just didn't improve Emacs itself but decided to utilize other 
free software. The author of EAF, manateelazycat, thought that it would take 
quite a long time for Emacs to improve its graphical capabilites of rendering 
webpages or videos to the point of other modern software dedicated for these 
functionalities, and emacs-devel should prioritize on making Emacs a better 
text-based editing environment, then the EAF's job is simply extending Emacs to 
the world of modern graphics.

Nevertheless, I'm very interested to see how this xwidgets idea evolves.

Matthew

[1] Emacs Application Framework repo: 
https://github.com/manateelazycat/emacs-application-framework

--
Mingde (Matthew) Zeng