Hi Martin,

2009/10/22 Martin Nordholts <ense...@gmail.com>:
> It doesn't seem feasible from a performance perspective to construct
> complex compositing graphs from scratch all the time. For example, can
> caches be reused between VIPS pipeline setups?

That's true, there is a cost there. I would argue:

- VIPS does almost no caching, so there's not actually much to throw away
- you spend much more time rendering pixels through a pipeline than
updating it, so it's the render part that needs to be quick
- a simple static pipeline is a big performance win: a year ago (when
I last timed GEGL) VIPS was always 10 and sometimes 100 times faster,
though perhaps I messed up the benchmarking
- with more than one CPU, large shared caches become a lot less useful
and can begin to limit scalability
- you can keep a display cache between pipelines to make panning and
zooming quick (the VIPS GUI does this)

> Another thing that makes VIPS less attractive is that it is not designed
> using an object oriented approach but is instead written in a
> functional/procedural manner. I have looked briefly at the code a while ago
> and my first impression was that VIPS will hard to extend and adapt to GIMP
> needs.

That's certainly true. VIPS is pretty old and it shows in the ugly API.

I'm trying to fix it up. The more recent chunks of API are built on
top of GObject and the long term plan is to break backwards
compatibility and move the whole thing over.

We had a stab at a "big bang" from scratch rewrite on top of GObject a
few years ago and it petered out (as any experienced programmer could
have predicted, heh), We're now trying to evolve the existing code
instead and reuse stuff from the big bang branch where we can.

Gimp-developer mailing list

Reply via email to