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
>     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

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

Gimp-developer mailing list

Reply via email to