On Sun, Jul 27, 2008 at 7:34 PM, Souichi TAKASHIGE <sigetch@xxxxxxxxx> wrote: > 2008/7/28 Liam R E Quin <liam@xxxxxxxxxxx>: >> On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote: >>> [...] >> >>> But it costs too much memory when we >>> make a lot of strokes -- and we *DO* make thousand of strokes when we >>> draw an image -- compared to the current implementation which has a >>> buffer per each layers. >> >> That's something that needs to be measured. > > I see. > It takes much memory when we draw brushmarks many times on the same > area, I think that is very usual situation. > Perhaps we should study the memory usage for this situation. > >> Don't forget that right now, the strokes are stored individually in >> the undo history anyway. > > Yes and no. GIMP copies previous tiles prior to its modification, but > that is part of previous layer image, not a stroke itself. GIMP can > forget the undo cache, and do forget the undo cache (on program > termination for example.) > On the other hand, GeglBuffers for each strokes should be kept > persistently. That is a big difference between undo cache and contents > of GeglBuffer. > But we can estimate the rough memory usage for the situation above > from the memory usage of the undo cache. 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). /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
