On 7/28/08, Souichi TAKASHIGE <[EMAIL PROTECTED]> 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 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.

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 Gibson
http://pippin.gimp.org/                            http://ffii.org/

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to