Hi, 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. [...snip...] > 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. -- Souichi TAKASHIGE _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
