Hi, On Mon, Jul 28, 2008 at 9:39 AM, Souichi TAKASHIGE <sigetch@xxxxxxxxx> wrote: > Hi, > > 2008/7/28 Øyvind Kolås <pippin@xxxxxxxx>: >> The situation would be the same for GEGL once the bug in >> http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since >> the part of the processing graph underneath the top most added stroke >> doesn't change, and it can be recomputed from the parameters of the >> nodes in the graph there is no need to always persist the actual >> pixels. This is a general optimization that also will help other parts >> of GEGL. Experimenting with the gegl-paint example in the GEGL sources >> will be a natural thing to do when fixing this bug. (The code in there >> should be easily modifiable to become full non-destructive again). > > Thank you for your comment. > I don't how to recompute the destructive brush stroke yet. Or I might > misunderstanding the meaning of "destructive." I thought destructive > means "destroy image itself and cannot undo it nor redo it" unless we > manage the undo cache. So it can't be non-destructive unless we save > that cache forever. No, it's only destructive if we have no way of regenerating the cache as needed. With GEGL, we can cache just at the newest node in the graph. Stroke information can be fully stored in the node. Ah! I think I might see what you mean! If a stroke is made, then you modify the brush used when drawing it, the stroke may then look different. This is a difficult problem really -- As I see it, we need to be able to keep brush data in the graph (or as an auxilary data managed by GEGL+GIMP), or maintain a history of each brush, for an indefinite length of time. The same would need to apply to palettes, gradients, patterns etc. HOWEVER.. If, once a resource was used in the graph, it was marked unchangeable, that could give a simple solution: then you just duplicate when you need to change it. Patterns would require a proper duplicate command, with this (they don't have one currently); otherwise it seems pretty easy to implement. (it would also require better memory/resource loading management, in consideration of large/animated brushes) > But maybe it's better to check the source code of gegl-paint first. > -- > Souichi TAKASHIGE > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
