On Oct 12, 2006, at 2:03 AM, Øyvind Kolås wrote:
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.
In this particular case it will not be possible to inline. Since the
relevant GObject function must be virtual it won't be able to be
inlined. You can actually manage to inline it anyway in a more
managable language, since you can declare a class final and then
specify the final class as the concrete type.
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.
Yeah, the IP libraries I've worked with all do something similar,
unfortunately.
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.
I'm not going to be pushy about this. Just declare my experience.
--
Daniel
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
