On Mon, Jul 28, 2008 at 9:39 AM, Souichi TAKASHIGE <[EMAIL PROTECTED]> wrote:
> Hi,
> 2008/7/28 Øyvind Kolås <[EMAIL PROTECTED]>:
>> 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
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.
> --
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Gimp-developer mailing list

Reply via email to