On Thu, Oct 22, 2009 at 9:50 PM, <jcupitt@xxxxxxxxx> wrote:
> - 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)
VIPS has received significant work on performance and refactoring
after it started working (doing what it is meant to do). GEGL has not
gone much beyond reaching the stage of doing what it says on the tin.
Display caches between renderings is essentially what GEGL does as
well, but it also permits doing this at check-point stages, (like for
instance a full layer subgroup, meaning that that subgroup never would
need to be recomposited if it doesnt change, GEGL also tracks all
minor changes.)
The GEGL code is structured in such a manner that the public
application API (the one using nodes) can be kept while replacing all
the internals as well as the plug-in API either as a fork (or later if
such a fork proves itself as an alternative backend). Feel free to
spearhead such an effort, personally I prefer continuing my efforts at
completing the existing GEGL plans.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
