Hi, Ernst Lippe <ernstl@xxxxxxxxx> writes: > 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. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. > > 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. I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result. > 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. Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows. If our preview widget encourages the plug-in author to work on a row-by-row basis, then we will never get plug-ins that operate on the pixels in the most efficient way. Sven
