Hi Martin, 2009/10/22 Martin Nordholts <enselic@xxxxxxxxx>: > 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. John _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
