On Wed, 18 Feb 2004 10:18:58 +0100
Dave Neary <[EMAIL PROTECTED]> wrote:

> Hi,
> Ernst Lippe wrote:
> > Sven Neumann <[EMAIL PROTECTED]> 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

Gimp-developer mailing list

Reply via email to