Re: [Gimp-developer] GEGL is no longer vapor. (was: improving image scale: reduction)

2007-06-15 Thread David Gowers
On 6/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås <[EMAIL PROTECTED]> 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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GEGL is no longer vapor. (was: improving image scale: reduction)

2007-06-15 Thread gg
On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås <[EMAIL PROTECTED]> 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.

thx.


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


Re: [Gimp-developer] GEGL is no longer vapor. (was: improving image scale: reduction)

2007-06-11 Thread g4
On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås <[EMAIL PROTECTED]> wrote:

> On 6/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> On Sun, 10 Jun 2007 13:12:02 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
>> > For GIMP 2.6, we will need high-quality and optimised scaling  
>> algorithms
>> > implemented as GEGL operators. Perhaps it would be a good idea to  
>> write
>> > such operators now so that we can start to use them when we port the
>> > core to GEGL.
>>
>> Doubtful. I can find a bit of time to tweek in the existing code but 2.6
>> seems a very long way off just now and I really dont have the time to  
>> get
>> deeply into geggling.
>
> GEGL supposedly has quite readable code that is running and works,
> 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 or depending on legacy behavior
> like having an indexed mode.
>
>> A bit nearer the time maybe.
>
> The time is now, and GIMP will soon enough start needing more and more
> adjustments/specialized operations to be implemented. More people
> looking at the code, and complain when things are difficult to
> understand, namings of APIs could be changed; will help getting the
> GEGL code base and APIs into sufficiently good shape for the 2.5
> development cycle of GIMP.
>
> /Øyvind K.

OK, maybe this is going to happen sooner than I thought. With 2.4 still  
not released after nearly 2 yrs , talking about 2.6 seems like planning  
for a replacement for the Kyoto Protocol ;)

I know my own little corner of the gimp code but getting familiar with a  
new API is an order of magnitude more time.

I'll start to look into GEGL when I have time but that's not now.

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