Hi Ernst,
Ernst Lippe wrote:
Dave Neary <dneary@xxxxxxx> wrote:>As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal?
The first question that you face when you want to add this, should the
drawable be scaled or not?
The kind of logic I would have thought might be reasonable is:
1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that.
2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio.
For example, say I'm doing a blur on a 400% zoomed copy of an image, and the viewport (256x256, say) is showing pixels (0,0) -> (64,64). In this case I take all the tiles that box covers (easy enough in this case, it's just 1 tile), make a new drawable with those tiles, apply my blur (on a 64x64image it should be quick), and zoom the result to 256x256.
If I'm blurring a 25% zoomed copy, the easiest way is to do the scale on the image first, blur that with a radius r * 0.25, and show the result.
In the former case (zoomed in), I'm not blurring 90% of the image data that won't ever be displayed in the viewport, and in the latter I'm doing a "good enough" zoom on scaled image data (with no interpolation). Also, as long as the zoom ratio doesn't change, I keep my reference zoomed drawable around so that I don't have to re-do the calculation/zoom every time I pan around in the viewfinder.
How does that sound?
There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview.
The performance advantage is surely in performing the preview calculation on a (possibly small) subset of the total image data, isn't it?
> Also, I have
added a utility function to the preview
(gimp_preview_get_temp_drawable) for doing this, so it is very easy
for the programmer to do this in the signal handler.
Yes, I'd noticed - that could be one way of doing this, I guess. It would be nice to avoid plug-in programmers having to repeat this logic, though.
Cheers, Dave. -- Dave Neary bolsh@xxxxxxxx
