2008/7/29 <[EMAIL PROTECTED]>:
> It is, right now that test program is destructive in that it forces a
> save/merge-down of the stroke as a temporary workaround until cache
> management in GEGL becomes better.
> The task of the painting operation is to provide the rendered result for a
> series of input events/coordinates, as well as a configuration for how it
> should be rendered. The code is written in a manner that makes it possible to
> append to the path and recompute a minimal region (semi working, but has some
> visual artifacts). All the things GIMP currently do can
> be expressed using this. It can also be easily extended to store line width
> and opacity varying along the stroke.
> When it comes to implementing more destructive like buffer access for
> performance reasons one could implement an operation that operates on a
> GeglBuffer in-place. It would still be possible to replay it from history,
> but there wouldn't be valid caches for each operation, and the replay would
> be much more expensive. We could add a smaller undo stack for the buffer
> though adding support for undo tiles for GeglBuffers has existed in the past
> and could be resurrected. Such a smaller undo stack might be useful, but that
> is probably something to keep in mind later after purging of caches, and copy
> on write works better.
Thank you for your explanation.
Now I understand what you mean "destructive", and your idea of brush
implementation. Basically brush operations are ready to be
non-destructive in that it has a path information. And we can choose
destructive operations instead of default cache updating algorithm for
better performance as needed. I think implementing undo cache is a
My main concern is about the performance of the brush processing both
for speed and memory usage.
I'm anxious about the performance a little yet, but I hope GEGL to
have enough performance in the future.
Gimp-developer mailing list