On Tue, Aug 24, 2010 at 4:30 PM, Rupert Weber <g...@leguanease.org> wrote:
> On 08/24/2010 04:20 AM, David Gowers wrote:
>> I hope you're not associating the quite suboptimal way in which GIMP
>> currently uses GEGL, with BABL's speed or lack of speed.
> Just did a quick test:
> 1Mio random pixels passed to babl as one buffer (=one function call) vs.
> passing the same buffer pixel by pixel (=1Mio calls) to the integer
> babl still comes out 35x slower.
This is expected since there are no additional fast paths in babl for
the specific conversion you probably used. At the moment babl will
have to do quite a bit of internal work going via double precision
floats and manually permuting components.
The purpose of babl is to provide an API that provides correct color
conversions and allows accelerating these with extensions that are
conformance tested and performance ranked at runtime. Your integer
code could be added as such an extension and will be chosen
automatically if it is good enough (or if the environment variable
BABL_TOLERANCE is set to for instance 0.02 or higher, indicating that
babl shouldnt be as strict about which fast paths are permitted.)
Fast conversions added to babl do not only benefit the conversion of
the implemented source/target pixelformats since babl can also string
together such conversions in a chain).
Gimp-developer mailing list