On Fri, 2004-05-21 at 21:57 +0200, Sven Neumann wrote: [Thanks for CCing me on this, Sven; I don't follow gimp-developer as closely as I would like these days] > There seem to be a couple of options. Let me try to summarize the ones > that I see: > > - Use GtkPreview. > > GtkPreview is declared deprecated by the GTK+ team and we will > want to get rid of it at some point. On the other hand there isn't > really a good reason not to use it. The API does it's job w/o and > I never understood why it as deprecated in the first place. The GIMP should get rid of GtkPreview as soon as possible. It is a deprecated API, and it is a horrible API regardless of its deprecation status. From the viewpoint of the GIMP and likely elsewhere, this is why it is horrible: - It only supports a draw_row() API. This is very cumbersome for filters, which must generate a temporary buffer and then copy it row by row to the GtkPreview. - It doesn't handle opacity information. Plug-ins must composite their images against a checkerboard or some other sort of background by hand. - It doesn't handle scrolling, zooming, etc., which are very useful for previews in an image editor. > - Use a GdkPixbuf as the pixel buffer and use a GtkImage to display it. > > The disadvantage is that the GdkPixbuf and GtkImage API are not > too well suited for our needs. GdkPixbuf doesn't handle greyscale > buffers and GtkImage can only display the full pixbuf. If we > wanted to show only a region of the buffer we could work around > this using gdk_pixbuf_new_subpixbuf() but IMHO this is becoming > too hackish to consider it. GtkImage is just a way to easily slap an image into a window, for example, to put an icon in a dialog box. It's not designed to display non-static images or those that need scrolling/zooming/etc. GdkPixbuf is not meant to be *THE* one representation for images that all programs should use; it is just the representation that GTK+ understands. It also happens to be a convenient representation for simple programs as well; this is obviously not the case for the GIMP. I'm not sure if the GIMP can use some of the interesting functions in GdkPixbuf such as the composite-on-checkerboard stuff --- you already have code in the GIMP to composite against checkerboards for image windows. But if you find any use in that code in GTK+, by all means use it. > - Come up with a full-featured preview widget. > > We could use the widget that Ernst Lippe wrote but since there > hasn't been any effort so far to discuss it's API again and to get > it into CVS I am not sure if it makes sense to wait for this to > happen. This is the right way to go. I'd say the list of requirements for a preview widget for the GIMP are at least the following: 1. Have a way for the filter to specify whether the preview can zoom or not; this is for filters which are not scale-invariant. Still, special cases like blurring need to be able to zoom in and out, but cheat when computing the preview: - scale the original image by 1/N - blur with a radius of 1/N pixels - draw that as the zoomed-out preview That is, it won't show exactly the same result as if you did - blur the original image with a radius of N pixels - scale the result by 1/N - draw that as the zoomed out preview but it will be pretty useful anyway. 2. Be able to request rendering of only the previewed area, and only scrolled-in areas after that. Say the preview is (with, height) pixels large and it starts at offset (xofs, yofs). When the plug-in's GUI starts up, the preview emits a notification saying, "render the area at (xofs, yofs, width, height)". If the user then scrolls the preview by 10 pixels to the left, the preview should emit a notification saying, "render the area at (xofs - 10, yofs, 10, height)". That is, rendering of the preview should be incremental based on scrolling. 3. Normally the preview doesn't need to hand image data to the filter --- the latter already knows how to get it using pixel regions. Still, it would be useful to provide some sort of of gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...) This is for filters which can display a zoomed preview and which don't need to process the original image data, like color mapping plug-ins. 4. Support resizing the preview. Previews with a fixed size of 128 pixels are not useful when you are a graphic designer with a wide-screen monitor. 5. Support automatic compositing of images with opacity information against a checkerboard --- this should just use the user preference for image windows. I hope this is a useful starting point for designing an API. From what I saw, Ernst Lippe's code seems to handle a lot of this stuff already. It would be a lot easier to just resurrect that code and bring it up to date rather than to write something from scracth. I don't think an API for super-slow filters is even worth considering. People should just learn to write faster code :) Federico, who is to be blamed for the pathologically slow Diffraction filter
