alpha value lost on marker edges

[mdehoon]

Using the tkagg backend:

import matplotlib
matplotlib.use("tkagg")
from pylab import *
plot(arange(10),'-o',color=(1,0,0,0.99),markeredgecolor=(0,0,0,0.1),markersize=100,markeredgewidth=10)

produces markers with edges with alpha=0.99 instead of 0.1.

[OceanWolf]

Ooh, another problem, I just tried setting color=(1,0,0,0,5) to see the problem more clearly, and I see more strangeness, the filled part of the marker overlaps part of the edge, so we get a double edge...

[efiring]

Yes, the alpha in markeredgecolor is ignored. in Line2D.draw():

                if rgbaFace is not None:
                    gc.set_alpha(rgbaFace[3])

                renderer.draw_markers(gc, marker_path, marker_trans,
                                      subsampled, affine.frozen(),
                                      rgbaFace)

This is all part of the mess associated with the original drawing model combined with the gradual increase in alpha support.

[efiring]

@OceanWolf, it sounds to me like you are describing the expected behavior: the marker edge is centered on the face edge, so when alpha is not 1, half of the marker thickness will be blended with the face, and the other half with the background.

[OceanWolf]

@efiring that sounds good, just double checking, too used to svg drawing ;).

Should I continue looking for a fix? I have just got to the part in the code where the kwargs get assigned to the Line, or leave it for perhaps 2.1, aware of the ticking clock until 1.5 I don't want to start another big project.

[efiring]

That's up to you, but I suspect it might be best not to try to do a quick patch. Instead, it might be good to agree on exactly how alpha should be handled, in the situation where colors can come in with or without alpha, there might or might not be an alpha kwarg, and a Line2D object can include up to 3 kinds of graphical element. And, we will want to try to maintain or improve consistency between Line2D and scatter, Patch, various collections...

[efiring]

0c20b5c
is the commit that appears to be the start of applying the alpha from rgbaFace to the edge. I think this is just part of the evolution; I don't think we ever had a situation where edge and face could have independently-specified alpha values.

[OceanWolf]

Thanks, though I had just gotten to that bit of code 😉.

I now have the test case working and I think I have a solution, will make the PR now :).

[OceanWolf]

Holey moley you did that fast @tacaswell , 2 seconds from me submitting the PR to you adding "needs_review"...

[WeatherGod]

He has some automated tagging through waffle.io, I think.
On Jul 4, 2015 10:43 PM, "OceanWolf" notifications@github.com wrote:

Holey moley you did that fast @tacaswell https://github.com/tacaswell ,
2 seconds from me submitting the PR to you adding "needs_review"...

—
Reply to this email directly or view it on GitHub
#4580 (comment)
.

[mdehoon]

I agree that the line identified by @efiring is problematic:

                if rgbaFace is not None:
                    gc.set_alpha(rgbaFace[3])

But I don't know why these lines are needed at all, since in line 752 we already have

        gc.set_foreground(rgbaFace, isRGBA=True)

[OceanWolf]

@mdehoon you mean me?

set_alpha at the moment sets the alpha for the entire thing (i.e. the entire marker) that we want to draw.

set_foreground sets the colour for the lines we want to draw which includes alpha.

The problem lies in that we have already set the alpha for foreground, but then set_alpha overrides it which I think we don't want, at least in this circumstance.

[efiring]

See #4586.