RE: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[arthur miller <arthur.miller@live.com>]

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

"> Tomas Hlavaty <tom@logand.com> writes:
>> It would be more convenient, if an image was represented as elisp data
>> instead of C data.
> :-) I don't think you have thought well about it;

Why would you say that?"

Because of the other things you wrote before that citate about drawing images in external process. You have expressed your sentiments about year 2020, efficiency and external processes a day or two ago, and I read similar reasoning here.

If all you wish is just to display an image, sure you can do that with external application, but if you would like to perform something interesting with images, or display something many images, the performance would drop quite fast.

Since you refer to drawing images and mention image data, I assumed you are talking about real image data, i.e. pixels, not handles to lisp objects. With other words I thought you would like to use Lisp to do something interesting as processing images in Emacs on pixel level. When people mention image data that is usually what they mean. But assumptions are always fault on the one that assumes, so I apologize for that.

Otherwise, you could surely easily integrate netpbm, image/openmagic or even libgd (via python or perl wrapper) into Emacs via pure lisp and processes. I don't see what's the problem if that is what you wish.

-------- Originalmeddelande --------
Från: Tomas Hlavaty <tom@logand.com>
Datum: 2020-12-01 17:49 (GMT+01:00)
Till: emacs-devel@gnu.org
Ämne: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

On Tue 01 Dec 2020 at 16:36, Arthur Miller <arthur.miller@live.com> wrote:
> Tomas Hlavaty <tom@logand.com> writes:
>> It would be more convenient, if an image was represented as elisp data
>> instead of C data.
> :-) I don't think you have thought well about it;

Why would you say that?

> but really nothing forbids you to try to reprsent images as lisp.

What do you mean exactly?

> You can take any de-compressed image and read in raw pixels in as a byte
> buffer and just shuffle around numbers and see how it
> works for you.Image is nothing but a bunch of numbers + some tiny
> metadata on top of it. Take some of netpbm formats and you have "textual
> image" you can manipulate on per-pixel level with lisp.

Image in emacs is represented in C as "struct image".

Image type in emacs is represented in C as "struct image_type".

The issue is that there doesn't seem to be a way to extend those (and/or
define new) in pure elisp.


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