Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
When drawing markers, don't set the GraphicsContext alpha.#11105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
15b8aa1 to1cd3f75Compare| ln_color_rgba = self._get_rgba_ln_color() | ||
| gc.set_foreground(ln_color_rgba, isRGBA=True) | ||
| gc.set_alpha(ln_color_rgba[3]) | ||
| lc_rgba = mcolors.to_rgba(self._color, self._alpha) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
OK, so_alpha overrides the alpha inself._color if its notNone. I'm confused if thats what happened before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yes. As a general rule, an explicit alpha will override one that comes "with the color" (we can always discuss whether that's a good strategy (I think it's a mess) but that's what we have for now). The exception is the one noted in the comment re: markeredgecolor.
(Before, that happened via get_rgba_ln_color, which I had forgotten to remove but now did.)
Setting the alpha value on the GraphicsContext forcefully applies it toboth the edgecolor and the facecolor, *except* that a facecolor of`None` ignores the alpha.Instead of requiring this behavior (which needlessly complicates theimplementation of new rendering backends), the alpha value (if any) candirectly be preapplied to the edgecolor and facecolor, the edgecolor canbe applied using gc.set_foreground, and the alpha value never set on theGraphicsContext.
1cd3f75 to7fbd4c2Compare| @@ -536,7 +536,10 @@ def draw_markers( | |||
| ps_cmd = ['/o {', 'gsave', 'newpath', 'translate'] # don't want the translate to be global | |||
| lw = gc.get_linewidth() | |||
| stroke = lw != 0.0 | |||
| alpha = (gc.get_alpha() | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This effectively treats alpha as a bool for ps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We do the same for text.
There seem to be a conflict, please backport manually |
…-alphaFIX: When drawing markers, don't set the GraphicsContext alpha.Conflicts:lib/matplotlib/lines.py - keep aliases (which are implemented automatically on master) explicitly in code
backported to v2.2.x as393c862 |
Uh oh!
There was an error while loading.Please reload this page.
Setting the alpha value on the GraphicsContext forcefully applies it to
both the edgecolor and the facecolor,except that a facecolor of
Noneignores the alpha.Instead of requiring this behavior (which needlessly complicates the
implementation of new rendering backends), the alpha value (if any) can
directly be preapplied to the edgecolor and facecolor, the edgecolor can
be applied using gc.set_foreground, and the alpha value never set on the
GraphicsContext.
The change to backend_ps is necessary because we no longer artificially set the linewidth to zero for transparent markers to prevent drawing on the ps backend.
Fixes#11104. Milestoned as 2.2.3 as "fixes a regression".
Also (unintentionally) fixes the SVG part of#10035 (not sure for the pdf part, which may involve a ghostscript bug anyways); updated test images accordingly.
Part of the longstanding effort (#7430) to not have two conflicting sources of alpha...
PR Summary
PR Checklist