Evgeny Zajcev <address@hidden> 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