On 10/12/06, Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx> wrote:
sllooooooooooow. I've encountered this oh-so-wonderful abstraction
before (JAI uses it, among others). Making a method call in the inner
loop of your pixel calculation routine is a big-nono. The first
optimization you will make is to remove that. Typically, the common
case will not use the abstraction, and an operator will be provided that
can accept the general interpolation object, but the operator will be so
slow no one will use it. It is wonderful when developing your
foundations, to be sure, but it will eventually be ripped out as soon as
someone tries to speed it up.
Any such optimizations are premature optimizations at the moment. At the
current stage making the source code of the included operations general as well
as easy to read, understand and debug is more important than efficient code.
I guess the overhead of a function call is smaller in C than in Java, it might
also be possible to inline the actual interpolating sampling functions.
The operation that geert is currently working on is a displacement map, what
you are suggesting would lead to writing a separate displacement map operation
for each interpolation method. This would lead to very unwieldy code.
If you can provide versions that accept arrays as input, then the
general case can be used everywhere.
The proposed solution is the closest you will get to operate directly
on a linear buffer.
Actually that can be made a
general rule. Anything that manipulates pixels much accept arrays as
input (possibly masks as well) or they will be ripped out at the
earliest opportunity.
My guess is that the proposed solution is a good compromise, at a later stage
more optimized version can be added. And then I actually mean adding code, not
replacing the current code. The reference version of the base operation set
int floating point should remain readable code, and optimized version
of 8bit/16bit/floating point that are regression tested against the
reference version.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
