On Tue, Aug 24, 2010 at 4:30 PM, Rupert Weber <gimp@xxxxxxxxxxxxxx> 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 > conversions. > 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). /Øyvind K. -- _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
