Lazy image converters

Lazy image converters

[Evgeny Zajcev]

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

It is a nice feature in Emacs 27 - 'image-convert' type for the images.
To convert unsupported images to format Emacs can understand.

Normally image creation (with 'create-image') is a very lightweight
process, Emacs don't read the files or do any heavy things.  All heavy
things are done in redisplay, so you could create and insert 1000 images in
the buffer with a couple of them visible and this will be fast.

However, with 'image-convert' images, this won't work, because heavy things
are done in the 'create-image', not in redisplay.  So Emacs will convert
1000 images at once.

What if we have a lazy image, so its FILE-OR-DATA is calculated at
redisplay time.  'image-convert' could utilize this.  One of the approaches
to lazy images is to allow FILE-OR-DATA to be a function returning actual
file or data.  Redisplay could call this func and substitute the value of
FILE-OR-DATA in image spec with the results, kind of caching the results.

What do you think?

Thanks

-- 
lg

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

Re: Lazy image converters

[Lars Ingebrigtsen]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> What if we have a lazy image, so its FILE-OR-DATA is calculated at
> redisplay time.  'image-convert' could utilize this.  One of the
> approaches to lazy images is to allow FILE-OR-DATA to be a function
> returning actual file or data.  Redisplay could call this func and
> substitute the value of FILE-OR-DATA in image spec with the results,
> kind of caching the results.

Hm...  It does sound nice, but I worry about calling this complicated
(and slow) code from redisplay.

And in my experience, most of the time when you put images in a buffer,
you're going to display them, so it's not clear that this would often be
a win, UX wise.

I can see it being so when preparing huge directory-like buffers (with
images; I do that for my music playing interface) -- then the user will
normally only display a small subsection of the images, and then
delaying the processing of the images is a win.

And the same is the case for web pages, I guess, but there the download
time dwarfs anything Emacs does, so it wouldn't make much difference
there, I think?

So...  I'm not convinced of the utility here, especially compared to the
potential problems arising from running complicated Lisp code from
redisplay.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Lazy image converters

[Stefan Monnier]

> What if we have a lazy image, so its FILE-OR-DATA is calculated at
> redisplay time.  'image-convert' could utilize this.  One of the approaches
> to lazy images is to allow FILE-OR-DATA to be a function returning actual
> file or data.  Redisplay could call this func and substitute the value of
> FILE-OR-DATA in image spec with the results, kind of caching the results.

It's definitely worth a try.
Maybe we can do that using the existing jit-lock hook?


        Stefan

Re: Lazy image converters

[Evgeny Zajcev]

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

вс, 16 февр. 2020 г. в 16:07, Lars Ingebrigtsen <larsi@gnus.org>:

> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
> > What if we have a lazy image, so its FILE-OR-DATA is calculated at
> > redisplay time.  'image-convert' could utilize this.  One of the
> > approaches to lazy images is to allow FILE-OR-DATA to be a function
> > returning actual file or data.  Redisplay could call this func and
> > substitute the value of FILE-OR-DATA in image spec with the results,
> > kind of caching the results.
>
> Hm...  It does sound nice, but I worry about calling this complicated
> (and slow) code from redisplay.
>
>
Converting to supported format is not that slow. It is aproximately two
times slower than reading and decoding already done in redisplay.  Also
such converter functions are not that complicated to avoid calling them in
redisplay

But benefits are significant.  We will have unified interface to images.
You won't distinguish normal images from converted.  Can insert any number
of images of any kind without locks

And in my experience, most of the time when you put images in a buffer,
> you're going to display them, so it's not clear that this would often be
> a win, UX wise.
>
>
No quite.  Sometimes you just need to see some part of the buffer to decide
what you going to do.  Consider cycling through list of the directories,
searching for some image.  You select some dir and help buffer pops up
showing images in this dir, but actually few of them only visible, but this
is enough for the user to decide that this directory is not suitable and he
need to go to the next one.

I can see it being so when preparing huge directory-like buffers (with
> images; I do that for my music playing interface) -- then the user will
> normally only display a small subsection of the images, and then
> delaying the processing of the images is a win.
>
> And the same is the case for web pages, I guess, but there the download
> time dwarfs anything Emacs does, so it wouldn't make much difference
> there, I think?
>
>
Thin strategy to create and append buffer contents as user scrolls the
buffer, complicates things a lot.  You need many things to think about,
such as:
1) If window with buffer is visible, you insert only content that is visible
2) If buffer is invisible you generate nothing and install some hook to
take action, when buffers get visibility to add content
3) You need to control scrolling to take care of what is visible in
buffer's window and add/remove invisible parts of the buffer
4) If something changes in the buffer (image updated, or new image is
added) you also can't just insert it, you need to check is that part of the
buffer is actually visible and delay the update/addon action

More logic might be required and it is very very similar to what redisplay
is actually does

Fourth is especially significant for online image manipulations, when
images are downloaded from the network and might be updated at any time by
the server.

So...  I'm not convinced of the utility here, especially compared to the
> potential problems arising from running complicated Lisp code from
> redisplay.
>
>
-- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>


-- 
lg

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

Re: Lazy image converters

[Evgeny Zajcev]

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

вс, 16 февр. 2020 г. в 18:20, Stefan Monnier <monnier@iro.umontreal.ca>:

> > What if we have a lazy image, so its FILE-OR-DATA is calculated at
> > redisplay time.  'image-convert' could utilize this.  One of the
> approaches
> > to lazy images is to allow FILE-OR-DATA to be a function returning actual
> > file or data.  Redisplay could call this func and substitute the value of
> > FILE-OR-DATA in image spec with the results, kind of caching the results.
>
> It's definitely worth a try.
>

I just realized another benefit of such an approach.  There is a
long-standing bug in Emacs - when an image file is silently removed, there
is no way to hook on this, so empty square displays in place of the image.
In case of the function as FILE-OR-DATA, redisplay may call it once again
if corresponding image file has been removed.

Maybe we can do that using the existing jit-lock hook?
>

I'll look at it, thanks

-- 
lg

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

Re: Lazy image converters

[Lars Ingebrigtsen]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> Converting to supported format is not that slow. It is aproximately
> two times slower than reading and decoding already done in redisplay.
> Also such converter functions are not that complicated to avoid
> calling them in redisplay

It means calling external programs, which is more brittle than just
calling a library.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no