On Wed, 18 Feb 2004 10:18:58 +0100 Dave Neary <dneary@xxxxxxx> wrote: > Hi, > > Ernst Lippe wrote: > > Sven Neumann <sven@xxxxxxxx> wrote: > >>http://refocus.sourceforge.net/preview/gimppreview.html > > > > The major points in the discussion were that some people did not like > > the way that the preliminary version of the preview tried to prevent > > recursive updates and that the names did not start with GIMP. > > > > As far as I can tell these points have been fixed in > > the first official release. > > 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? Something like this was present in the old preview, I deliberately removed it because it was an unnecessary overhead for some plug-ins. The first question that you face when you want to add this, should the drawable be scaled or not? 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. 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. If you want to send a scaled drawable, for several algorithms this is simply useless overhead because they can't use it. There are many plug-in algorithms that are not scale-invariant in the sense that the scaled version of their output is different from the output when they use a scaled input. Also several algorithms have an output area that is different from their input area. Yet another class of algorithms are those that simply generate a new image that is independent from the input image. For all these classes of algorithms a scaled drawable is simply useless overhead. So when you really want to let the preview generate a scaled drawable, it should definitely be optional. In that case there would be yet another parameter for the preview, and the internal code would have to be more complicated (at the moment it only draws directly to the underlying GtkImage and that should be modified to write to the drawable as well). Also, I am not convinced that there would be a real performance advantage, for most plug-ins that I have seen, the plug-in algorithm itself will be the main bottle-neck. For those algorithms that really want a scaled drawable there is another utitility function (gimp_preview_get_scaled_drawable). Ernst Lippe
