* image scaling @ 2008-02-21 4:21 Stefan Monnier 2008-02-21 8:42 ` Mathias Dahl ` (4 more replies) 0 siblings, 5 replies; 30+ messages in thread From: Stefan Monnier @ 2008-02-21 4:21 UTC (permalink / raw) To: emacs-devel Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that we do not support image scaling. I'd like to add such a feature to image-mode.el, but am wondering how we should go about doing it. Would there be some advantage to provide it at the C level (e.g. if some of the image libs we use already provide the necessary functionality) or should we just bite the bullet and call some external tool like "convert -scale ..." (with the disadvantage that flushing the image cache will not automatically cause the image to be re-scaled). Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 4:21 image scaling Stefan Monnier @ 2008-02-21 8:42 ` Mathias Dahl 2008-02-21 9:10 ` Miles Bader 2008-02-21 15:59 ` Stefan Monnier 2008-02-21 10:01 ` David Kastrup ` (3 subsequent siblings) 4 siblings, 2 replies; 30+ messages in thread From: Mathias Dahl @ 2008-02-21 8:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that > we do not support image scaling. > > I'd like to add such a feature to image-mode.el, but am wondering how we > should go about doing it. Would there be some advantage to provide it > at the C level (e.g. if some of the image libs we use already provide > the necessary functionality) or should we just bite the bullet and call > some external tool like "convert -scale ..." (with the disadvantage that > flushing the image cache will not automatically cause the image to be > re-scaled). It would be really good to have such a feature as I think it would make browsing images in image-dired's thumbnail buffer (display some large images there and use SPC and DEL to go back and forth to see what I mean) much quicker. At least I guess it would be quicker to do this natively inside Emacs than using convert to scale the image as we do now. I assume the image libraries that Emacs use support scaling in some way. When on the subject of images, it would be really neat if we had built-in EXIF (et al) support as well, although I understand if people do not think it fits well in Emacs. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 8:42 ` Mathias Dahl @ 2008-02-21 9:10 ` Miles Bader 2008-02-21 15:59 ` Stefan Monnier 1 sibling, 0 replies; 30+ messages in thread From: Miles Bader @ 2008-02-21 9:10 UTC (permalink / raw) To: Mathias Dahl; +Cc: Stefan Monnier, emacs-devel "Mathias Dahl" <mathias.dahl@gmail.com> writes: >> I'd like to add such a feature to image-mode.el, but am wondering how we >> should go about doing it. Would there be some advantage to provide it >> at the C level (e.g. if some of the image libs we use already provide >> the necessary functionality) or should we just bite the bullet and call >> some external tool like "convert -scale ..." (with the disadvantage that >> flushing the image cache will not automatically cause the image to be >> re-scaled). > > It would be really good to have such a feature as I think it would > make browsing images in image-dired's thumbnail buffer (display some > large images there and use SPC and DEL to go back and forth to see > what I mean) much quicker. At least I guess it would be quicker to do > this natively inside Emacs than using convert to scale the image as we > do now. In addition, I think it's a bit dodgy to rely on specific programs -- "convert", for instance is part of imagemagick, which is a humongous/bloated package, so I don't have it installed on my home system (even though it's a GNU/Linux system, where you might otherwise expect to find it installed). I imagine it's simply not installed at all on many non-GNU systems, or hard to find even when it is installed. Scaling images isn't all that hard, even if you try to do a good job (using a filter to avoid aliasing etc), so I think it would be fine to do it in C code. [We could optionally try to use library calls to do it when those libraries will be linked into Emacs anyway, e.g., gtk-related libs.] -Miles -- The key to happiness is having dreams. [from a fortune cookie] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 8:42 ` Mathias Dahl 2008-02-21 9:10 ` Miles Bader @ 2008-02-21 15:59 ` Stefan Monnier 2008-02-21 20:41 ` Mathias Dahl 1 sibling, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2008-02-21 15:59 UTC (permalink / raw) To: Mathias Dahl; +Cc: emacs-devel > It would be really good to have such a feature as I think it would > make browsing images in image-dired's thumbnail buffer (display some > large images there and use SPC and DEL to go back and forth to see > what I mean) much quicker. Hmm... Seeing how other programs that deal with thumbnails also do "convert to a new file", it looks like that example isn't very compelling: it would require not just the ability to scale an image, but also to then save (i.e. re-encode, compressed in a format like png or jpeg) it. Running `convert' doesn't sound that bad of an idea in this case (especially you can run several `convert' processes at the same time, benefitting from multi-cores). > At least I guess it would be quicker to do this natively inside Emacs > than using convert to scale the image as we do now. Could be, but I'm not sure. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 15:59 ` Stefan Monnier @ 2008-02-21 20:41 ` Mathias Dahl 0 siblings, 0 replies; 30+ messages in thread From: Mathias Dahl @ 2008-02-21 20:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > > It would be really good to have such a feature as I think it would > > make browsing images in image-dired's thumbnail buffer (display some > > large images there and use SPC and DEL to go back and forth to see > > what I mean) much quicker. > > Hmm... Seeing how other programs that deal with thumbnails also do > "convert to a new file", it looks like that example isn't very > compelling: I think you misunderstand what I meant; I wasn't talking about making the thumbnails, I was talking about the scaled (to fit window) image used when browsing images in the thumbnail buffer. Here is a recipe: $ emacs -Q Then (output from view-lossage): M-x i m a g e SPC d i r e d <return> g f x <tab> p i c s <return> SPC SPC SPC ... Each time you do SPC or DEL in the thumbnail buffer a scaled version of the original image is created and displayed. Just so we talk about the same thing. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 4:21 image scaling Stefan Monnier 2008-02-21 8:42 ` Mathias Dahl @ 2008-02-21 10:01 ` David Kastrup 2008-02-21 10:06 ` joakim ` (2 subsequent siblings) 4 siblings, 0 replies; 30+ messages in thread From: David Kastrup @ 2008-02-21 10:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that > we do not support image scaling. > > I'd like to add such a feature to image-mode.el, but am wondering how we > should go about doing it. Would there be some advantage to provide it > at the C level (e.g. if some of the image libs we use already provide > the necessary functionality) or should we just bite the bullet and call > some external tool like "convert -scale ..." (with the disadvantage that > flushing the image cache will not automatically cause the image to be > re-scaled). I think we should refactor image support somewhat: most image libraries offer some way of loading/displaying/scaling/gamma-correcting whole images (and where they don't, things like gdk might come in). Yet our code can't make use of that. There is a reason we need an "image cache" even though the normal image library functions would be quite fast enough to cope with stuff on the fly. Without refactoring the API, adding hand-spun scaling support will further complicate future refactoring. -- David Kastrup ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 4:21 image scaling Stefan Monnier 2008-02-21 8:42 ` Mathias Dahl 2008-02-21 10:01 ` David Kastrup @ 2008-02-21 10:06 ` joakim 2008-02-21 12:43 ` David O'Toole 2008-02-21 18:43 ` Chong Yidong 2008-02-21 22:28 ` Richard Stallman 4 siblings, 1 reply; 30+ messages in thread From: joakim @ 2008-02-21 10:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that > we do not support image scaling. > I'd like to add such a feature to image-mode.el, but am wondering how we > should go about doing it. Would there be some advantage to provide it > at the C level (e.g. if some of the image libs we use already provide > the necessary functionality) or should we just bite the bullet and call > some external tool like "convert -scale ..." (with the disadvantage that > flushing the image cache will not automatically cause the image to be > re-scaled). I've looked at this briefly while preparing the SVG patch for inclusion. I think it would be apropriate to do this at the C level, but what would the Lisp level interface look like? > > > Stefan > -- Joakim Verona ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 10:06 ` joakim @ 2008-02-21 12:43 ` David O'Toole 0 siblings, 0 replies; 30+ messages in thread From: David O'Toole @ 2008-02-21 12:43 UTC (permalink / raw) To: joakim; +Cc: Stefan Monnier, emacs-devel I would like to suggest basic image-composition as well. I wrote a graphical roguelike engine in Emacs that uses the external "convert" program to resize and compose (i.e. overlay on top of one another) tiny graphical tiles that represent the player, monsters, walls, objects to be picked up, et cetera. This works fine with Imagemagick, but it would be wonderful to be able to compose these images directly within Emacs. Some screenshots here: http://dto.mamalala.org/notebook/rlx.el Currently won't compile due to refactoring, but the screenshots are real. On Thu, Feb 21, 2008 at 5:06 AM, <joakim@verona.se> wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > > > > Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that > > we do not support image scaling. > > > I'd like to add such a feature to image-mode.el, but am wondering how we > > should go about doing it. Would there be some advantage to provide it > > at the C level (e.g. if some of the image libs we use already provide > > the necessary functionality) or should we just bite the bullet and call > > some external tool like "convert -scale ..." (with the disadvantage that > > flushing the image cache will not automatically cause the image to be > > re-scaled). > > I've looked at this briefly while preparing the SVG patch for inclusion. > > I think it would be apropriate to do this at the C level, but what would > the Lisp level interface look like? > > > > > > > Stefan > > > -- > Joakim Verona > > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 4:21 image scaling Stefan Monnier ` (2 preceding siblings ...) 2008-02-21 10:06 ` joakim @ 2008-02-21 18:43 ` Chong Yidong 2008-02-21 21:49 ` David Kastrup 2008-02-21 22:28 ` Richard Stallman 4 siblings, 1 reply; 30+ messages in thread From: Chong Yidong @ 2008-02-21 18:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that > we do not support image scaling. > > I'd like to add such a feature to image-mode.el, but am wondering how we > should go about doing it. Would there be some advantage to provide it > at the C level (e.g. if some of the image libs we use already provide > the necessary functionality) or should we just bite the bullet and call > some external tool like "convert -scale ..." (with the disadvantage that > flushing the image cache will not automatically cause the image to be > re-scaled). I think the cleanest (but not necessarily easiest) approach is to add a C level function to rescale an image. This C function would act on the internal pixmap structures and implement its own image scaling algorithm. The trouble with using external library functions is that not all of them support rescaling. Then we could simply add an extra "scale" argument to create-image (and the underlying image descriptors), which, when non-nil, says to scale the image by that amount. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 18:43 ` Chong Yidong @ 2008-02-21 21:49 ` David Kastrup 2008-02-21 22:20 ` Miles Bader 2008-02-22 4:57 ` Chong Yidong 0 siblings, 2 replies; 30+ messages in thread From: David Kastrup @ 2008-02-21 21:49 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> Looking at the Elisp manual's "38.16.2 Image Descriptors", it seems that >> we do not support image scaling. >> >> I'd like to add such a feature to image-mode.el, but am wondering how we >> should go about doing it. Would there be some advantage to provide it >> at the C level (e.g. if some of the image libs we use already provide >> the necessary functionality) or should we just bite the bullet and call >> some external tool like "convert -scale ..." (with the disadvantage that >> flushing the image cache will not automatically cause the image to be >> re-scaled). > > I think the cleanest (but not necessarily easiest) approach is to add > a C level function to rescale an image. This C function would act on > the internal pixmap structures and implement its own image scaling > algorithm. The trouble with using external library functions is that > not all of them support rescaling. Since lot more people concerned about graphics work on those library functions than on Emacs' graphics, we should be factoring Emacs' image code in a manner that will allow us to make use of that functionality if it is given (and possibly be able to use gdk if it is available). Really: how pixels are passed one by one through Emacs before reaching the display is a mess. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 21:49 ` David Kastrup @ 2008-02-21 22:20 ` Miles Bader 2008-02-22 6:35 ` Jan Djärv 2008-02-22 4:57 ` Chong Yidong 1 sibling, 1 reply; 30+ messages in thread From: Miles Bader @ 2008-02-21 22:20 UTC (permalink / raw) To: David Kastrup; +Cc: Chong Yidong, Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: > Really: how pixels are passed one by one through Emacs before reaching > the display is a mess. Yup. It would be nice to see large swathes of the Emacs image support code hidden behind an abstract interface that lets us simply hand off 90% of it when linked against, say, GTK libs. -Miles -- "1971 pickup truck; will trade for guns" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 22:20 ` Miles Bader @ 2008-02-22 6:35 ` Jan Djärv 2008-02-22 6:49 ` Miles Bader 2008-02-22 22:57 ` Richard Stallman 0 siblings, 2 replies; 30+ messages in thread From: Jan Djärv @ 2008-02-22 6:35 UTC (permalink / raw) To: Miles Bader; +Cc: Chong Yidong, Stefan Monnier, emacs-devel Miles Bader skrev: > David Kastrup <dak@gnu.org> writes: >> Really: how pixels are passed one by one through Emacs before reaching >> the display is a mess. > > Yup. It would be nice to see large swathes of the Emacs image support > code hidden behind an abstract interface that lets us simply hand off > 90% of it when linked against, say, GTK libs. > I tried this and it works quite well. However, the image handling that uses bare X calls only caters for one display, so it is not usable for Emacs. Jan D. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 6:35 ` Jan Djärv @ 2008-02-22 6:49 ` Miles Bader 2008-02-22 7:26 ` Jan Djärv 2008-02-22 22:57 ` Richard Stallman 1 sibling, 1 reply; 30+ messages in thread From: Miles Bader @ 2008-02-22 6:49 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, Stefan Monnier, emacs-devel Jan Djärv <jan.h.d@swipnet.se> writes: > I tried this and it works quite well. However, the image handling that uses > bare X calls only caters for one display, so it is not usable for Emacs. Couldn't we just use cairo? That seems fairly well-designed to be be independent of the actual display... -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.' ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 6:49 ` Miles Bader @ 2008-02-22 7:26 ` Jan Djärv 0 siblings, 0 replies; 30+ messages in thread From: Jan Djärv @ 2008-02-22 7:26 UTC (permalink / raw) To: Miles Bader; +Cc: Chong Yidong, Stefan Monnier, emacs-devel Miles Bader skrev: > Jan Djärv <jan.h.d@swipnet.se> writes: >> I tried this and it works quite well. However, the image handling that uses >> bare X calls only caters for one display, so it is not usable for Emacs. > > Couldn't we just use cairo? That seems fairly well-designed to be be > independent of the actual display... > Sure, it would help printing also (we could use the Gtk+ print API). But it is a bigger effort. Jan D. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 6:35 ` Jan Djärv 2008-02-22 6:49 ` Miles Bader @ 2008-02-22 22:57 ` Richard Stallman 1 sibling, 0 replies; 30+ messages in thread From: Richard Stallman @ 2008-02-22 22:57 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, emacs-devel, monnier, miles I tried this and it works quite well. However, the image handling that uses bare X calls only caters for one display, so it is not usable for Emacs. We could perhaps write extensions to that GTK library and offer it for installation. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 21:49 ` David Kastrup 2008-02-21 22:20 ` Miles Bader @ 2008-02-22 4:57 ` Chong Yidong 2008-02-22 7:48 ` David Kastrup ` (2 more replies) 1 sibling, 3 replies; 30+ messages in thread From: Chong Yidong @ 2008-02-22 4:57 UTC (permalink / raw) To: David Kastrup; +Cc: Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: >> I think the cleanest (but not necessarily easiest) approach is to add >> a C level function to rescale an image. This C function would act on >> the internal pixmap structures and implement its own image scaling >> algorithm. The trouble with using external library functions is that >> not all of them support rescaling. > > Since lot more people concerned about graphics work on those library > functions than on Emacs' graphics, we should be factoring Emacs' image > code in a manner that will allow us to make use of that functionality if > it is given (and possibly be able to use gdk if it is available). > Really: how pixels are passed one by one through Emacs before reaching > the display is a mess. My main concern with outsourcing particular bits of the Emacs image functionality to external libraries (which may or may not be linked in) is how this will look at the Lisp level. This problem is already present to a small degree; for example, the `image-type-available-p' function checks if a particular image format can be displayed. But it would be a mess if we force users (Lisp coders) to perform a similar test before performing things like image rescaling---or, worse still, having such functionality quietly disappear, by functions not being defined or becoming no-ops. Of course, we could take the approach of writing our own "fallback" code for when the libraries aren't available, but that negates the point of using the libraries in the first place. As for refactoring the Emacs image code, I'm not sure if there's any urgency for such a project. The code isn't elegant, but it's simple enough to understand and work on; and I don't know of any performance problem in the way Emacs handles image pixmaps. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 4:57 ` Chong Yidong @ 2008-02-22 7:48 ` David Kastrup 2008-02-22 20:28 ` Chong Yidong 2008-02-22 10:23 ` Juanma Barranquero 2008-02-22 22:57 ` Richard Stallman 2 siblings, 1 reply; 30+ messages in thread From: David Kastrup @ 2008-02-22 7:48 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Of course, we could take the approach of writing our own "fallback" > code for when the libraries aren't available, but that negates the > point of using the libraries in the first place. Not if the fallback code sucks. Like pretty much all of Emacs' image-handling code does now. > As for refactoring the Emacs image code, I'm not sure if there's any > urgency for such a project. The code isn't elegant, The understatement of the year. Have you followed the code path for displaying the various pixels of an image? Please do so if you have not done so yet, and then repeat that statement with a straight face. > but it's simple enough to understand and work on; and I don't know of > any performance problem in the way Emacs handles image pixmaps. You must be kidding. We have an image cache exactly because Emacs can't handle images close to reasonably efficiently. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 7:48 ` David Kastrup @ 2008-02-22 20:28 ` Chong Yidong 2008-02-22 21:52 ` David Kastrup 0 siblings, 1 reply; 30+ messages in thread From: Chong Yidong @ 2008-02-22 20:28 UTC (permalink / raw) To: David Kastrup; +Cc: Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: >> but it's simple enough to understand and work on; and I don't know of >> any performance problem in the way Emacs handles image pixmaps. > > You must be kidding. We have an image cache exactly because Emacs can't > handle images close to reasonably efficiently. Don't other programs use caches for images? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 20:28 ` Chong Yidong @ 2008-02-22 21:52 ` David Kastrup 2008-02-22 22:41 ` Chong Yidong 0 siblings, 1 reply; 30+ messages in thread From: David Kastrup @ 2008-02-22 21:52 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > David Kastrup <dak@gnu.org> writes: > >>> but it's simple enough to understand and work on; and I don't know of >>> any performance problem in the way Emacs handles image pixmaps. >> >> You must be kidding. We have an image cache exactly because Emacs can't >> handle images close to reasonably efficiently. > > Don't other programs use caches for images? XEmacs, for example, does not have the equivalent, and works fine (actually quite faster than Emacs) when using preview-latex. The point is that when the image data is loaded into memory, Emacs still can't display it fast. It converts it with a painfully slow conversion chain called for every pixel into a pixmap and caches that. Considering that the binary data is pretty much identical a pixmap to start with (maybe modulo a gamma correction lookup table), this is somewhat ridiculous. The code paths are so muddled, however, that it is not easy to rip this out. Have you actually looked at the code? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 21:52 ` David Kastrup @ 2008-02-22 22:41 ` Chong Yidong 2008-02-22 22:51 ` David Kastrup 0 siblings, 1 reply; 30+ messages in thread From: Chong Yidong @ 2008-02-22 22:41 UTC (permalink / raw) To: David Kastrup; +Cc: Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: >>>> but it's simple enough to understand and work on; and I don't know of >>>> any performance problem in the way Emacs handles image pixmaps. >>> >>> You must be kidding. We have an image cache exactly because Emacs can't >>> handle images close to reasonably efficiently. >> >> Don't other programs use caches for images? > > XEmacs, for example, does not have the equivalent, and works fine > (actually quite faster than Emacs) when using preview-latex. > > The point is that when the image data is loaded into memory, Emacs still > can't display it fast. It converts it with a painfully slow conversion > chain called for every pixel into a pixmap and caches that. Considering > that the binary data is pretty much identical a pixmap to start with > (maybe modulo a gamma correction lookup table), this is somewhat > ridiculous. The code paths are so muddled, however, that it is not easy > to rip this out. > > Have you actually looked at the code? I'm fairly familiar with the code. If Emacs can't quickly display images that are already loaded into memory, it's not clear to me that the problem lies in the image.c code rather than redisplay. Could you elucidate? When you say the image is already "loaded into memory", do you mean that the image is supplied using a Lisp string representing binary data (i.e., passing a DATA-P argument to create-image), or are you simply referring to time Emacs takes to run the png_load function (i.e., from calling the libpng functions parsing the file until Emacs finishes populating and caching the pixmaps)? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 22:41 ` Chong Yidong @ 2008-02-22 22:51 ` David Kastrup 0 siblings, 0 replies; 30+ messages in thread From: David Kastrup @ 2008-02-22 22:51 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > David Kastrup <dak@gnu.org> writes: > >> The point is that when the image data is loaded into memory, Emacs >> still can't display it fast. It converts it with a painfully slow >> conversion chain called for every pixel into a pixmap and caches >> that. Considering that the binary data is pretty much identical a >> pixmap to start with (maybe modulo a gamma correction lookup table), >> this is somewhat ridiculous. The code paths are so muddled, however, >> that it is not easy to rip this out. >> >> Have you actually looked at the code? > > I'm fairly familiar with the code. It's been some time since I looked at it, and it was pretty inscrutable. I doubt it has improved much. > If Emacs can't quickly display images that are already loaded into > memory, it's not clear to me that the problem lies in the image.c code > rather than redisplay. Oh, I was not trying to assign blame to a particular piece of code. It is just what happens in totality is pretty ugly, almost to the point of being absurd. It may well be that each part, in isolation, does things as good as can be expected, given the designed APIs and pathways. > Could you elucidate? When you say the image is already "loaded into > memory", do you mean that the image is supplied using a Lisp string > representing binary data (i.e., passing a DATA-P argument to > create-image), For example. > or are you simply referring to time Emacs takes to run the png_load > function (i.e., from calling the libpng functions parsing the file > until Emacs finishes populating and caching the pixmaps)? It has been some time since I last looked at the code and finally gave up in disgust (twisty maze of passages...). So I can't be much more specific. The gist is that Emacs is orders of magnitude slower than programs which basically just tie libraries together without serious data manipulation of their own. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 4:57 ` Chong Yidong 2008-02-22 7:48 ` David Kastrup @ 2008-02-22 10:23 ` Juanma Barranquero 2008-02-22 10:55 ` Thien-Thi Nguyen 2008-02-22 22:57 ` Richard Stallman 2 siblings, 1 reply; 30+ messages in thread From: Juanma Barranquero @ 2008-02-22 10:23 UTC (permalink / raw) To: Chong Yidong; +Cc: Emacs Devel On Fri, Feb 22, 2008 at 5:57 AM, Chong Yidong <cyd@stupidchicken.com> wrote: > for example, the `image-type-available-p' > function checks if a particular image format can be displayed. But it > would be a mess if we force users (Lisp coders) to perform a similar > test before performing things like image rescaling Why would Emacs do rescaling of images that can not be displayed in the running instance of Emacs? Juanma ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 10:23 ` Juanma Barranquero @ 2008-02-22 10:55 ` Thien-Thi Nguyen 2008-02-22 11:06 ` Juanma Barranquero 0 siblings, 1 reply; 30+ messages in thread From: Thien-Thi Nguyen @ 2008-02-22 10:55 UTC (permalink / raw) To: emacs-devel () "Juanma Barranquero" <lekktu@gmail.com> () Fri, 22 Feb 2008 11:23:41 +0100 Why would Emacs do rescaling of images that can not be displayed in the running instance of Emacs? Maybe the scaling is part of a series of operations, the end of which would be displayable but not the middle. thi ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 10:55 ` Thien-Thi Nguyen @ 2008-02-22 11:06 ` Juanma Barranquero 2008-02-22 20:38 ` Chong Yidong 0 siblings, 1 reply; 30+ messages in thread From: Juanma Barranquero @ 2008-02-22 11:06 UTC (permalink / raw) To: Thien-Thi Nguyen; +Cc: emacs-devel On Fri, Feb 22, 2008 at 11:55 AM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote: > Maybe the scaling is part of a series of operations, > the end of which would be displayable but not the middle. I'm not sure I understand. A series of operations (presumably, image transformations of some sort) without the image library support? We do that today, manipulating for example PNG images without (statically or dynamically) linking libpng? Juanma ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 11:06 ` Juanma Barranquero @ 2008-02-22 20:38 ` Chong Yidong 2008-02-22 20:47 ` Juanma Barranquero ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Chong Yidong @ 2008-02-22 20:38 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Thien-Thi Nguyen, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: >> Maybe the scaling is part of a series of operations, >> the end of which would be displayable but not the middle. > > I'm not sure I understand. A series of operations (presumably, image > transformations of some sort) without the image library support? We do > that today, manipulating for example PNG images without (statically or > dynamically) linking libpng? Suppose, for example, we "outsource" image transformations to a specific external library. For the sake of argument, let's say this library is libpng. One way to do this is to have Emacs use libpng internally to store and manipulate (e.g. rescale) images, instead of the pixel buffer system we currently use. Alternatively, Emacs might keep the pixel buffer system, but perform image manipulations by converting the image into a png internally, calling the relevant libpng function to rescale it or whatever, and then converting it back. We would thus be using libpng to perform image manipulations, for arbitrary images and not just pngs. The trouble is that if libpng is not available, all this functionality would disappear (not just for pngs, but also for gifs or whatever other images *are* supported). In that case, how would we handle this at the Lisp interface level? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 20:38 ` Chong Yidong @ 2008-02-22 20:47 ` Juanma Barranquero 2008-02-22 22:21 ` Miles Bader 2008-02-23 19:28 ` Richard Stallman 2 siblings, 0 replies; 30+ messages in thread From: Juanma Barranquero @ 2008-02-22 20:47 UTC (permalink / raw) To: Chong Yidong; +Cc: Emacs Devel On Fri, Feb 22, 2008 at 9:38 PM, Chong Yidong <cyd@stupidchicken.com> wrote: > We would thus be using libpng to perform image manipulations, for > arbitrary images and not just pngs. The trouble is that if libpng is > not available, all this functionality would disappear (not just for > pngs, but also for gifs or whatever other images *are* supported). In > that case, how would we handle this at the Lisp interface level? Well, what would be the motivation to use the libraries? Because if it is speed, you can define a list of libraries, sorted by functionality (speed, or whatever), and if no library is available, you default to an Emacs-internal implementation... Juanma ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 20:38 ` Chong Yidong 2008-02-22 20:47 ` Juanma Barranquero @ 2008-02-22 22:21 ` Miles Bader 2008-02-23 19:28 ` Richard Stallman 2 siblings, 0 replies; 30+ messages in thread From: Miles Bader @ 2008-02-22 22:21 UTC (permalink / raw) To: Chong Yidong; +Cc: Juanma Barranquero, Thien-Thi Nguyen, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > We would thus be using libpng to perform image manipulations, for > arbitrary images and not just pngs. The trouble is that if libpng is > not available, all this functionality would disappear (not just for > pngs, but also for gifs or whatever other images *are* supported). In > that case, how would we handle this at the Lisp interface level? I dunno about other people, but my thought was simply to make the interface abstract enough that we could easily use a thin wrapper around an external library for image handling, and keep a "portable" version (mostly, the current code) for cases when such is not available. -Miles -- Quack, n. A murderer without a license. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 20:38 ` Chong Yidong 2008-02-22 20:47 ` Juanma Barranquero 2008-02-22 22:21 ` Miles Bader @ 2008-02-23 19:28 ` Richard Stallman 2 siblings, 0 replies; 30+ messages in thread From: Richard Stallman @ 2008-02-23 19:28 UTC (permalink / raw) To: Chong Yidong; +Cc: lekktu, ttn, emacs-devel We would thus be using libpng to perform image manipulations, for arbitrary images and not just pngs. The trouble is that if libpng is not available, all this functionality would disappear (not just for pngs, but also for gifs or whatever other images *are* supported). It is ok if libpng is required. We need not bend over backwards to support its absence. Anyone can install it, after all. Or we could make libpng required for image support. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-22 4:57 ` Chong Yidong 2008-02-22 7:48 ` David Kastrup 2008-02-22 10:23 ` Juanma Barranquero @ 2008-02-22 22:57 ` Richard Stallman 2 siblings, 0 replies; 30+ messages in thread From: Richard Stallman @ 2008-02-22 22:57 UTC (permalink / raw) To: Chong Yidong; +Cc: monnier, emacs-devel My main concern with outsourcing particular bits of the Emacs image functionality to external libraries (which may or may not be linked in) is how this will look at the Lisp level. The natural and convenient way is to put something in the text properties that specify scaling, etc. That makes it very easy for Lisp programs to specify scaling. But it would be a mess if we force users (Lisp coders) to perform a similar test before performing things like image rescaling---or, worse still, having such functionality quietly disappear, by functions not being defined or becoming no-ops. The tremendous advantage of using library facilities for this outweighs that disadvantage. We should not write our own "fallback" code, because that is duplication of effort. Let's use the libraries to save our time so we can make some other improvement. As for refactoring the Emacs image code, I'm not sure if there's any urgency for such a project. The code isn't elegant, but it's simple enough to understand and work on; and I don't know of any performance problem in the way Emacs handles image pixmaps. I agree it is not urgent, but it is quite desirable. We could release Emacs 23 without doing this, but we would very much like someone to do it after that. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: image scaling 2008-02-21 4:21 image scaling Stefan Monnier ` (3 preceding siblings ...) 2008-02-21 18:43 ` Chong Yidong @ 2008-02-21 22:28 ` Richard Stallman 4 siblings, 0 replies; 30+ messages in thread From: Richard Stallman @ 2008-02-21 22:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel I'd like to add such a feature to image-mode.el, but am wondering how we should go about doing it. Would there be some advantage to provide it at the C level (e.g. if some of the image libs we use already provide the necessary functionality) It would be far better for users to do it at the C level because that way changing the size would work instantly. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2008-02-23 19:28 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-02-21 4:21 image scaling Stefan Monnier 2008-02-21 8:42 ` Mathias Dahl 2008-02-21 9:10 ` Miles Bader 2008-02-21 15:59 ` Stefan Monnier 2008-02-21 20:41 ` Mathias Dahl 2008-02-21 10:01 ` David Kastrup 2008-02-21 10:06 ` joakim 2008-02-21 12:43 ` David O'Toole 2008-02-21 18:43 ` Chong Yidong 2008-02-21 21:49 ` David Kastrup 2008-02-21 22:20 ` Miles Bader 2008-02-22 6:35 ` Jan Djärv 2008-02-22 6:49 ` Miles Bader 2008-02-22 7:26 ` Jan Djärv 2008-02-22 22:57 ` Richard Stallman 2008-02-22 4:57 ` Chong Yidong 2008-02-22 7:48 ` David Kastrup 2008-02-22 20:28 ` Chong Yidong 2008-02-22 21:52 ` David Kastrup 2008-02-22 22:41 ` Chong Yidong 2008-02-22 22:51 ` David Kastrup 2008-02-22 10:23 ` Juanma Barranquero 2008-02-22 10:55 ` Thien-Thi Nguyen 2008-02-22 11:06 ` Juanma Barranquero 2008-02-22 20:38 ` Chong Yidong 2008-02-22 20:47 ` Juanma Barranquero 2008-02-22 22:21 ` Miles Bader 2008-02-23 19:28 ` Richard Stallman 2008-02-22 22:57 ` Richard Stallman 2008-02-21 22:28 ` Richard Stallman
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.