rgba formats

I think I'm a little confused by the question. From the Python perspective, everything in the Agg backend takes floats. Agg actually has color types for both floating point and 8-bit-per-plane colors, though obviously it's converted to 8-bit-per-plane eventually. But, of course, that is done on the fly without much memory copying, so I'm quite surprised that the speed up is significant... Where exactly is this conversion happening, and how are you now avoiding it? (Is this in code that is not checked in, perhaps?)

As for the other backends, it's a mixed bag. PDF, PS and Cairo want floats, SVG wants ints. Personally, I just *like* floats better, as it feels more future proof, even though most people aren't using the extra color resolution now. (Of course, if your plot relies on high-resolution color, you probably need to rethink your plot anyway... :wink:

Cheers,
Mike

Michael Droettboom wrote:

I think I'm a little confused by the question. From the Python
perspective, everything in the Agg backend takes floats. Agg
actually has color types for both floating point and 8-bit-per-plane
colors, though obviously it's converted to 8-bit-per-plane
eventually. But, of course, that is done on the fly without much
memory copying, so I'm quite surprised that the speed up is
significant... Where exactly is this conversion happening, and how
are you now avoiding it? (Is this in code that is not checked in,
perhaps?)

I was referring to _image.cpp and the quadmesh code in _backend_agg.cpp. Both work directly with agg::rgba8, and can benefit from doing a color table lookup directly in 8-bit space instead of using floats and then converting.

Eric

···

As for the other backends, it's a mixed bag. PDF, PS and Cairo want
floats, SVG wants ints. Personally, I just *like* floats better, as
it feels more future proof, even though most people aren't using the
extra color resolution now. (Of course, if your plot relies on
high-resolution color, you probably need to rethink your plot
anyway... :wink:

Cheers, Mike

I'm not sure that this consumes enough cycles to warrant the additional complexity of doing things differently on a per-backend basis (the choice to stick with 8-bit colors would have to be made higher than the backend to see any savings). The pcolor images are an exception, since that code is common to all backends -- we can do whatever works best.

To see what the "upper limit" on the performance increase would be, I modified draw_quad_mesh in the Agg backend so that it doesn't look up or multiply colors at all (it just uses a hard-coded 8-bit black always), and on the included pcolormesh benchmark, there was no significant difference (I ran each 3 times, since the difference is so small):

trunk:
  5.518 fps
  5.530 fps

trunk (hard-coded color):
  5.507 fps
  5.567 fps
  5.302 fps

I did notice, however, that draw_quad_mesh makes an unnecessary temporary buffer to convert the floating-point colors to 8-bit color. Since each color is only converted once, it is slightly faster to do the conversion on the fly and avoid the heap alloc/dealloc.

trunk (no alloc):
  5.630 fps
  5.618 fps
  5.617 fps

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

I think I'm a little confused by the question. From the Python
perspective, everything in the Agg backend takes floats. Agg
actually has color types for both floating point and 8-bit-per-plane
colors, though obviously it's converted to 8-bit-per-plane
eventually. But, of course, that is done on the fly without much
memory copying, so I'm quite surprised that the speed up is
significant... Where exactly is this conversion happening, and how
are you now avoiding it? (Is this in code that is not checked in,
perhaps?)

I was referring to _image.cpp and the quadmesh code in _backend_agg.cpp. Both work directly with agg::rgba8, and can benefit from doing a color table lookup directly in 8-bit space instead of using floats and then converting.

Eric

As for the other backends, it's a mixed bag. PDF, PS and Cairo want
floats, SVG wants ints. Personally, I just *like* floats better, as
it feels more future proof, even though most people aren't using the
extra color resolution now. (Of course, if your plot relies on
high-resolution color, you probably need to rethink your plot
anyway... :wink:

Cheers, Mike

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA