On Monday 24 May 2004 19:11, Federico Mena Quintero wrote:
> 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.
As far as I can see my preview widget can satisfy all of your
> I don't think an API for super-slow filters is even worth considering.
> People should just learn to write faster code :)
That's not always possible. There are several classes of interesting
algorithms, e.g. most image enhancement techniques, that are inherently
slow. Also the fact is, that most current plug-ins are indeed not very
efficient. But especially with slow algorithms you desperately need
a preview. And even with a fast algorithm there will be cases
when the user is probably faster, e.g. while scrolling or
zooming a large preview image. So I certainly believe that
slow algorithms are an important use case for the design of
Gimp-developer mailing list