Hi, Federico Mena Quintero <federico@xxxxxxxxxx> writes: > > - 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. Did you look at the implementation details and the API? I don't think we should use this preview widget because it has a cumbersome API and some design flaws that we can hardly work around later. It certainly makes sense to study it and to use what's good about it but it should IMHO not be put into the gimp source tree without a major redesign. > 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. IMO it makes a lot more sense to first design a preview widget that provides enough functionality to replace GtkPreview now. This includes point (4) and (5) but not (1), (2) and (3). Later a more sophisticated framework can be added on top of this. The reason to do it this way is that we already tried it the other way around and it didn't work out. If we go for the simple preview widget as I proposed, there's a good chance we can get all the API issues sorted out during the next week or two. This means that we can get a sane API into gimp-2.2. If we try to create the super-preview-widget again we will probably not get aything done before the feature freeze. Federico, the real reason why I put you into Cc: was to get a word about you on the Unsharp Mask patch that you said you wanted to work on. If you don't expect to find time for it soon, then please say so. People are waiting to have their patches committed and I'd really like get the outstanding preview patches in as soon as possible. Sven
