* Lazy image converters @ 2020-02-12 14:11 Evgeny Zajcev 2020-02-16 13:06 ` Lars Ingebrigtsen 2020-02-16 15:20 ` Stefan Monnier 0 siblings, 2 replies; 6+ messages in thread From: Evgeny Zajcev @ 2020-02-12 14:11 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lazy image converters 2020-02-12 14:11 Lazy image converters Evgeny Zajcev @ 2020-02-16 13:06 ` Lars Ingebrigtsen 2020-02-16 17:45 ` Evgeny Zajcev 2020-02-16 15:20 ` Stefan Monnier 1 sibling, 1 reply; 6+ messages in thread From: Lars Ingebrigtsen @ 2020-02-16 13:06 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lazy image converters 2020-02-16 13:06 ` Lars Ingebrigtsen @ 2020-02-16 17:45 ` Evgeny Zajcev 2020-02-19 13:44 ` Lars Ingebrigtsen 0 siblings, 1 reply; 6+ messages in thread From: Evgeny Zajcev @ 2020-02-16 17:45 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lazy image converters 2020-02-16 17:45 ` Evgeny Zajcev @ 2020-02-19 13:44 ` Lars Ingebrigtsen 0 siblings, 0 replies; 6+ messages in thread From: Lars Ingebrigtsen @ 2020-02-19 13:44 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lazy image converters 2020-02-12 14:11 Lazy image converters Evgeny Zajcev 2020-02-16 13:06 ` Lars Ingebrigtsen @ 2020-02-16 15:20 ` Stefan Monnier 2020-02-17 11:02 ` Evgeny Zajcev 1 sibling, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2020-02-16 15:20 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Lazy image converters 2020-02-16 15:20 ` Stefan Monnier @ 2020-02-17 11:02 ` Evgeny Zajcev 0 siblings, 0 replies; 6+ messages in thread From: Evgeny Zajcev @ 2020-02-17 11:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-19 13:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-02-12 14:11 Lazy image converters Evgeny Zajcev 2020-02-16 13:06 ` Lars Ingebrigtsen 2020-02-16 17:45 ` Evgeny Zajcev 2020-02-19 13:44 ` Lars Ingebrigtsen 2020-02-16 15:20 ` Stefan Monnier 2020-02-17 11:02 ` Evgeny Zajcev
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.