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
good idea.

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

Reply via email to