I tried adaptingtest_patches.py::test_patch_alpha_coloring to use the cairo backend, and the result reveals there are more issues withRendererCairo.draw_path_collection. With my fix for alpha above, this is the result:

So the alpha channel is correct, but the line style is wrong. The result looks correct if I removeRendererCairo.draw_path_collection() altogether to fall back onRendererBase.draw_path_collection().

The proposed fix looks reasonable.
Not sure what's happening with linestyles but I guess you can also exclude grouping in presence of them?

Had a look at the linestyles issue, and it seems to be unrelated to the grouped draw. It's incorrect also if I disable grouped draw, but correct if I removeRendererCairo.draw_path_collection() altogether.

No progress on the linestyle issue, maybe@anntzer can help?

Looks like

diff --git i/lib/matplotlib/backends/backend_cairo.py w/lib/matplotlib/backends/backend_cairo.pyindex ce68d198f..3afd5be32 100644--- i/lib/matplotlib/backends/backend_cairo.py+++ w/lib/matplotlib/backends/backend_cairo.py@@ -307,10 +307,13 @@ class RendererCairo(RendererBase):             for k, v in gc_vars.items():                 if k == "_linestyle":  # Deprecated, no effect.                     continue-                try:-                    getattr(gc, "set" + k)(v)-                except (AttributeError, TypeError) as e:-                    pass+                elif k == "_dashes":+                    gc.set_dashes(*v)  # Needs to be unpacked.+                else:+                    try:+                        getattr(gc, "set" + k)(v)+                    except (AttributeError, TypeError) as e:+                        pass             gc.ctx.new_path()             paths, transforms = zip(*grouped_draw)             grouped_draw.clear()@@ -326,7 +329,8 @@ class RendererCairo(RendererBase):             transform = (Affine2D(transform.get_matrix())                          .translate(xo, yo - self.height).scale(1, -1))             # rgb_fc could be a ndarray, for which equality is elementwise.-            new_key = vars(gc0), tuple(rgb_fc) if rgb_fc is not None else None+            new_key = (vars(gc0).copy(), tuple(rgb_fc) if rgb_fc is not None+                       else None)             if new_key == reuse_key:                 grouped_draw.append((path, transform))             else:

should fix the dashes issue. Can you confirm?

Great, can confirm that@anntzer's patch indeed fixes the issue.@anntzer will you commit your fix to master first, then I can rebase my alpha fix on top of it.

Can you just integrate it in your pr?

Sure, I can do that

Do you want me to add the test as well? Currently there seems to be no tests for the cairo backend...

There's also no machinery for that, but sure, if you can figure it out how to make it work, go for it!
I'd suggest using some adaptation of the check_figures_equal decorator (plotting the same thing two ways using the cairo backend, e.g. here drawing with a PathCollection or just two separate patches), to avoid adding more baseline images to the repo (as you likely won't be able to share the agg baselines due to differences in rasterization).

Sure, a drawback of using check_figures_equal is of course that we assume the reference figure is correct.

You could e.g. compare an ellipse collection with two single ellipses. While in theory both may be wrong. On the one hand, it's reasonable to check that the two code paths yield the same result. Also it's quite unlikely that a future code change with simultaneously change both. So the test would actually be quite good.

So I've added the test, which revealed yet another bug with the grouped draw (set_foreground() wasn't called for _rgb). After fixing this, the test passes, but only because it uses alpha blending and disables the grouped draw.

Now if I modify the test and sett fill color alpha to 1.0, thus enabling grouped drawing, the draw order is messed up somehow:

Looking at this again I'm not surprised by the failure: this is because the pathcollection drawer concatenates all paths and fills them in one go, then draw the edges in one go (so the entire blue edge is drawn after the entire red fill). I overlooked the overlapping-patch problem in#8787, sorry about that.
Unfortunately I don't think there's a really good fix other than deleting draw_path_collection and going back to the slow, one-at-a-time approach.
Remilestoning to 3.0.x as this fixes a regression.

Ah ok, should I change the patch then to remove draw_path_collection?

At least I can't think of anything better...

The style checker is unhappy:https://travis-ci.org/matplotlib/matplotlib/jobs/456934939#L2255.

The OSX test failure should be covered by#12835.

Thanks and congratulations to your first contribution to matplotlib! Hope to see you back some time.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.0.x$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 8272e7b7870d3c85824dbbbde499ff385d268790

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #12774: Cairo backend: Fix alpha render of collections'

4. Push to a named branch :

git push YOURFORK v3.0.x:auto-backport-of-pr-12774-on-v3.0.x

5. Create a PR against branch v3.0.x, I would have named this PR:

"Backport PR#12774 on branch v3.0.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free tosuggest an improvement.