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 > 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. As far as I can see my preview widget can satisfy all of your requirements. > 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 a preview. Ernst Lippe
