Hi, 2008/7/29 <pippin@xxxxxxxx>: > 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
