[Gegl-developer] Proposition : GeglInterpolator

Daniel Rogers daniel at phasevelocity.org
Thu Oct 12 07:32:36 PDT 2006


On Oct 12, 2006, at 2:03 AM, Øyvind Kolås wrote:


> On 10/12/06, Daniel Rogers <daniel at phasevelocity.org> 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





More information about the Gegl-developer mailing list