On Wed, 18 Feb 2004 16:19:06 +0100 Sven Neumann <sven@xxxxxxxx> wrote: > Hi, > > Ernst Lippe <ernstl@xxxxxxxxx> 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 preview. 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 helper functions. Ernst Lippe
