On 7/28/08, Souichi TAKASHIGE <sigetch@xxxxxxxxx> wrote:> Hi,>>> 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.>> From my understanding, if stroke information is stored in the node,> then the stroke can be regenerated, and that operation will be> non-destructive since the cache can be regenerated. I think David says> about "non-destructive" brush operation.> I saw source code of gegl-paint. It seems that gegl_vector stores the> information of the path, so I think it is also about non-destructive> brush tool. 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. > On the other hand, Øyvind says that we can implement "destructive"> brush. I think being "destructive" implies that there's no way to> regenerate the stroke since being able to regenerate the stroke means> that the cache is regeneratable, so the operation must not have any> path information. 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 canbe 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. I am not actively pursuing experimenting with this at the moment, but there is enough proof of concept code that it should be possible to start porting the current GIMP tools to such an infrastructure. This would also be the moment that the GIMP tools gain higher bitdepth retouching capabilities, initially it would make sense to port it in such a manner that it works, but is perhaps slow. Then to optimize as needed. How it makes sense to store this in a graph in GIMP probably should wait until the projection of the layer stack in GIMP has been ported, then it would be possible to add the strokes as a layer group or similar. /Øyvind K.-- «The future is already here. It's just not very evenly distributed» -- William Gibsonhttp://pippin.gimp.org/ http://ffii.org/ _______________________________________________Gegl-developer mailing listGegl-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
