On Wed, 18 Feb 2004 16:19:06 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Ernst Lippe <[EMAIL PROTECTED]> writes:
> > No, the preview itself does not generate any temporary drawables.
> > However there is a utility function for the plug-in to generate
> > such temporary drawables, when it finds that more convenient,
> > but in that case it is the responsibility of the plug-in
> > and not of the preview. It can function perfectly without
> > any temporary drawables.
> Well, if the plug-in needs to allocate temporary drawables in order to
> conveniently display a preview, than this is a problem of the preview.
The decision if the plug-in "needs" the temporary drawable
is made by its designer and it is certainly not forced by
the preview. It is perfectly possible to draw a row of
pixels on the preview (indeed for a very long period that
has been the only way you could draw on the preview, support
for drawables is a recent addition). If a plug-in designer
writes a plug-in in such a way that it can only output to
a drawable, then it will always have to allocate a temporary
drawable (unless you want to mess around with the original
input drawable, which sound pretty horrible).
But when the internal datastructures for the algorithm
can be used to construct a single row for the preview
there is no reason to use a temporary drawable.
> One of the design requirements of the preview is to provide a
> convenient way for plug-ins to preview their results. Convenient means
> that it should be possible to reuse the existing pixel manipulations
> routines without or with small changes. Allocating temporary drawables
> in the core is in my opinion not a viable solution for this problem.
> It should however be possible to keep the temporary drawables
> completely on the plug-in side. To achieve this, the GimpDrawable
> wrapper would have to know whether it needs to get the tiles from the
> core (via shared memory or over the pipe) or allocate them in the
> plug-in process. I think this change would be rather straight-forward.
But unless I am mistaken, this temporary drawable has only
a limited functionality, because you cannot use any of
the "core" operations on it.
So I am not really certain if it would be worth the effort.
Furthermore, this functionality would only be needed
for those plug-in algorithms where it is difficult
to compute an entire row of pixels, and actually
I cannot remember that I have ever seen one.
So if you have some good examples, perhaps the problem
could also be solved by changing the interface of the
preview, e.g. adding support for drawing tiles on the
Anyhow, it does not have any real impact on the preview.
At most, I would have to change a few lines in two of the
Gimp-developer mailing list