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
> - 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
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
5. Support automatic compositing of images with opacity information
against a checkerboard --- this should just use the user preference for
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
Gimp-developer mailing list