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/
_______________________________________________
Gegl-developer mailing list
[email protected]
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
