On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås wrote:

On 6/10/07, g4@catking.net wrote:

On Sun, 10 Jun 2007 13:12:02 +0200, Sven Neumann 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/

On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås 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.

On 6/16/07, gg@catking.net wrote:

On Sun, 10 Jun 2007 23:13:03 +0200, Øyvind Kolås 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.)