466572 - Visible seams between two filled regions at curved path segments of the boundary

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Zack Weinberg (:zwol)]

Cairo's antialiasing logic produces visible seams between two filled regions whenever there's a curved path segment in the boundary.  For instance, in HTML if you have a box with rounded corners (-moz-border-radius) whose border and background are both solid colors, there will be a seam at the inner curves of the border where whatever's underneath the box shows through.  This is most obvious if the border and background are the same color.

See the test cases for bug 456219 -- as checked in they (will) have mask images that overwrite the problem pixels with the correct results.

Comment 2

[Zack Weinberg (:zwol)]

It's maybe worth mentioning that this doesn't just happen with -moz-background-clip:padding.  The background-painting code will clip to the padding box even if that isn't set, if it thinks the border is totally opaque; also, it's harder to see, but you can get artifacts at the *outer* edge of a curved border if the background's *not* being clipped to the padding box.

Comment 4

[Zack Weinberg (:zwol)]

Let's make this directly block the border-radius tracking bug, since it keeps getting rediscovered in that context.

Comment 5

[Jonathan Griffin (:jgriffin)]

Attachment: reftest

Adding a reftest which reproduces this issue, that can be checked in if/when this bug is fixed.

Comment 6

[Zack Weinberg (:zwol)]

There's a cluster of three box-shadow-related bugs that may or may not all be the same as each other and are very likely to be the same as this bug. I'm not sure enough to close them as duplicates, so I've instead made this bug block all three of 'em.

Comment 7

[Zack Weinberg (:zwol)]

Attachment: graphic investigating some options for fixing this bug

I wanted to find out if there are any drawing modes available in Cairo as it is now that could mitigate this bug (without having to wait for supersampling support).  It looks like we could do something for the interaction of curved border and background, at a possibly-acceptable performance cost.  I'm not sure about box-shadow, not being familiar with how that's painted.

The attached image has three columns and three rows.  Each cell is one possible rendering of a curved border corner with some combination of colors, clip boundaries, and Cairo options.  Taking the top row first, the leftmost cell shows the present rendering of a completely opaque border, with unwanted seam.  Top middle demonstrates that putting the background and border fills in a Cairo group doesn't help by itself, but top right shows that we *could* fix this case by putting the background and border fills in a group and using OPERATOR_ADD.  (OPERATOR_ADD by itself is hilariously wrong in all cases, and I didn't bother including it in this rendering.)

The middle row shows the same three options but for the present rendering of a partially transparent border.  (CSS requires that the background be drawn under the border in this case.)  Here there's an undesirable seam on the *outside* of the border curve, and group+ADD doesn't help -- in fact it makes the seam more visible, *and* messes up the color in the overlap area.  (The apparently black area in the bottom two rows is actually a very dark green; this is to make the effect of ADD on overlapping colors visible.)

I couldn't get rid of the outer seam with any Cairo compositing operator, but I was able to make it go away by cheating and shrinking the outer arc of the "background" fill by 0.5px.  (It's still slightly visible in the group+ADD case, but we don't want that anyway.)

Pushing a group and using OPERATOR_ADD is expensive relative to ungrouped OPERATOR_OVER, but we have to do this anyway when the two sides meeting at a corner have different colors, and it might be not as bad as supersampling.  The real trick here, though, is that background and border are presently drawn with entirely separate entry points to nsCSSRendering.cpp.  To do this, we're going to have to reorganize all the code so that, at least, corners get their background and border drawn at the same time, so we can do the grouped compositing.  I'll try to write up a plan for how it should all work.

Comment 8

[Zack Weinberg (:zwol)]

Attachment: program to generate attachment 427186

Here's the program I used to generate the demo image I just attached.  It needs the Cairo bindings for Python (available from http://www.cairographics.org/pycairo/ )

Comment 10

[RomD]

Any progress on this?
I'm experiencing the same problem with Firefox 3.6.3.

Comment 11

[Boris Zbarsky [:bzbarsky]]

One particular manifestation of this will be fixed in bug 704399 by painting the background under the border in the cases that bug hits...

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:bhood, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 13

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 14

[Gregory Pappas [:gregp]]

Attachment: testcase.html

Comment 15

[Gregory Pappas [:gregp]]

Unable to reproduce in recent versions.