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
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
> eventuall
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
Mike (and others),
The standard rgba format in mpl has been a sequence of 4 doubles, but
these need to be converted to uint8 before they can be used by Agg, at
least. Therefore I added the ability for ScalarMappable.to_rgba to
generate uint8 initially, avoiding the extra translation. (This can