On 6/16/07, gg@xxxxxxxxxxx <gg@xxxxxxxxxxx> wrote:
> On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås <pippin@xxxxxxxx> wrote:
>
> > modifying that code base to deal with this properly will most probably
> > been seen as more lasting contributions than changing code that
> > eventually only will live on machines running legacy 2.4 series GIMP
> > due either to low performance hardware
>
> hmm, just reread this. Does that comment indicate that GEGL is a lot more
> resource hungry than gimp? I'd wondered if that might the case when I
> initially looked at the way it was structured.
I thought it was fairly clear that Øyvind mainly meant CPU power
('low performance' -- RAM would correspond to 'low capacity').
Currently, my impression from using GEGL is:
a) it wants more memory for an equivalent layer-arrangement
b) it wants to use less memory at a time
relative to GIMP. a) because of the way that layers are composited of
multiple GEGL ops, and b) because of caching -- if a graph node is not
dirty, then it doesn't need to be recalculated from it's child nodes*.
So it uses more memory during calculation, and less memory during
editing (depending on the dependencies of the node you're editing).
*the caching system is still under development, as far as I can tell;
final caching behaviour is not determined except in that it will be
something like i described.
Per the above, it seems to me clear that GEGL will be more usable on
systems with low memory and lots of swap space VS the GIMP's current
infrastructure, with efficiency while editing varying more (initially
with all ops written in C, individual op speed will be less but
caching will tend to speed up editing past GIMP speeds.)
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
