Maybe, but I am not sure it is so simple as that. At the
> very least, it illustrates the fact that all the possible
> combinations of rgb with separate alpha, rgba, faces, edges
> etc. is confusing, and that because of the organic growth of
Yes, this is the result of code creep. Early versions of matplotlib
(GTK only backend) only supported rgb. Later we added an alpha
channel and put it in the graphics context and left the rgb tuples
alone. Later still IIRC we added support rgba colors, while leaving
the alpha in the gc. Thus we have a redundant and somewhat ill
defined alpha. The older drawing methods (draw_line, draw_poly) get
their color as rgb and their alpha from gc. The comparatively newer
ones (draw_poly_collection) always uses the rgba and ignore the
gc.alpha. Definitely confusing, suboptimal, and in need of
rationalization.
> mpl combined with its support for backends with differing
> capabilities, there is not a single clear pattern of
> behavior. Which means we have more cleanup work to do at the
> very least. To be more ambitious (as if there weren't
> already enough pending grand ideas), some reconsideration
> and possible modification of the drawing model would be
> nice.
Indeed, lots of grand ideas. I've been toying with the idea of trying
to organize an mpl sprint in some fabulous destination, and trying to
raise funds for several developers via donations. Sometime in the
early summer perhaps.
> For the backends, maybe it would be easier to let (-1,*,*,*)
> mean "don't draw"; if it has to be interpreted by C-code in
> some backends, always having a tuple and simply checking for
> a negative first element is much easier than having to check
> for None in place of a tuple.
If we are already passing in rgba, and are expecting the backends to
inspect it, wouldn't it make more sense for them to simply check for
rgba[-1]>0, as we do in backend_bases?
JDH