On Saturday 22 May 2004 14:54, Sven Neumann wrote:
> geert jordaens <[EMAIL PROTECTED]> writes:
> > Signals :
> > 1. preview_draw       :   draw preview area from current preview buffer.
> > 2. preview_update    :   Call-back for rendering function  followed by
> > preview_draw or call preview_draw from callback.
> >                                       (if possible send signal
> > preview_draw from within callback to display rendering progress).
> > 3. preview_changed :   Call-back to determine which part of the
> > drawable that must be rendered for preview.
> >                                      (after scrollbar position changed)
> I don't think any of this should be part of the GimpPreview widget.
> IMO it's the plug-in's job to push the pixel data to the preview, not
> the preview's job to request it. 
But the position of the previewed area and the current magnification
are inherently properties of the preview itself. It seems pretty
logical to make scroll and zoom buttons part of the preview widget
and in that case it is the preview widget that will detect
if the position or scale has been changed. So the most logical
design is to let the preview call the plug-in algorithm and not
the other way round. I can see nothing wrong with using signals
in this case, because they are more flexible than the other standard
solution of having call-back functions.

Do you really propose that the plug-in itself handles all the GUI interactions
for scrolling, zooming and resizing and that it also is responsible for
recording the current position and scale and size of the preview?
This seems very unelegant, to say the least. Also how do you
handle plug-ins that have multiple previews?

> Such a framework can be added later
> as I outlined in the proposal I just sent to the list. The preview
> widget itself doesn't need to know about the drawable it previews, nor
> what part of it is previewed. It just displays a buffer the size of
> the preview and that's it. Perhaps we optionally need an API that
> allows to keep the buffer outside the preview widget. That would allow
> the plug-in to render a larger version and implement scrolling by
> changing the offset into the buffer.

How are you going to decide the correct size for this area?
When you make it substantially larger than the previewed area
the response to user actions will become slower. It will happen
frequently that this buffer will become invalid, e.g. when
some parameters of the algorithm have been changed, when the
user zooms out, when the image is scrolled over a larger
distance. The only case where such a larger buffer might
be useful is when the user only scrolls by very small amounts
and in my experience that does not occur often. So having
a larger buffer makes the design of the plug-in more complicated
(how should it determine the "right" size for this buffer),
it will cause a performance hit on many normal preview operations.

Ernst Lippe

Gimp-developer mailing list

Reply via email to