emacs-devel
[Top][All Lists]
Advanced

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

Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was R


From: Akira Kyle
Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)
Date: Wed, 02 Dec 2020 17:37:58 -0700
User-agent: mu4e 1.4.13; emacs 28.0.50


On Tue, Dec 01, 2020 at 01:01 AM, Tomas Hlavaty <tom@logand.com> wrote:

On Sun 29 Nov 2020 at 20:54, Akira Kyle <akira@akirakyle.com> wrote:
However I think designing such a feature should keep eventual
integration with modules in mind. Especially since in general graphics is very performance sensitive and so doing some drawing in elisp just might not cut it and many interesting applications of such a feature
would require interfacing with an external c library.

Not necessarily.

There could also be a specialized program which could handle drawing. In fact there already is such a program: w3mimgdisplay and is part of the w3m web browser and pager. It is also used in the file manager
ranger.  It works both with or without X.  I am using it in
emacs-framebuffer too to display images and documents in Emacs.

The issues I am facing have nothing to do with modules or libraries.

For example:

It would be more convenient, if there was a way to specify elisp
function to draw an image. By default, it could just call the existing
C code but this would also allow me to specify a different elisp
function which would then for example call w3mimgdisplay.

It would be more convenient, if an image was represented as elisp data instead of C data. iirc there is no way to add new image types without
touching C.

Is there a way to turn off cursor for a buffer? (Blinking cursor
disrupts the drawn image.)

Is there a way run a function after emacs changes something on the
screen in a buffer?

I just briefly poked around w3m's codebase and it appears that the code paths for X and direct framebuffer are almost entirely independent. Its not totally clear what your ultimate goal is with respect to w3m's image display and emacs. Do you wish to never launch display server such as X or wayland but still have some of Emacs graphics support on the linux framebuffer? It seems like unless you're going to teach Emacs to entirely draw itself to the framebuffer, there will always be glitches like the cursor messing up images since TUI Emacs won't be aware of what pixels of the framebuffer have been drawn over independently of the linux VT displaying lines of Emacs' characters.



reply via email to

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