Closed
Bug 466572
Opened 16 years ago
Closed 2 years ago
Visible seams between two filled regions at curved path segments of the boundary
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: zwol, Unassigned)
References
(Blocks 3 open bugs, )
Details
Attachments
(4 files)
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.
Flags: wanted1.9.2?
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
Reporter | ||
Updated•16 years ago
|
Component: GFX → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: general → thebes
Updated•16 years ago
|
Reporter | ||
Comment 2•16 years ago
|
||
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.
Reporter | ||
Comment 4•15 years ago
|
||
Let's make this directly block the border-radius tracking bug, since it keeps getting rediscovered in that context.
Blocks: border-radius
Comment 5•15 years ago
|
||
Adding a reftest which reproduces this issue, that can be checked in if/when this bug is fixed.
Reporter | ||
Updated•15 years ago
|
Flags: wanted1.9.2?
Reporter | ||
Comment 6•15 years ago
|
||
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.
Reporter | ||
Comment 7•15 years ago
|
||
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.
Reporter | ||
Comment 8•15 years ago
|
||
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•14 years ago
|
||
Any progress on this? I'm experiencing the same problem with Firefox 3.6.3.
![]() |
||
Comment 11•13 years ago
|
||
One particular manifestation of this will be fixed in bug 704399 by painting the background under the border in the cases that bug hits...
Updated•2 years ago
|
Severity: normal → S3
Comment 12•2 years ago
|
||
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.
Flags: needinfo?(bhood)
Comment 13•2 years ago
|
||
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.
Flags: needinfo?(bhood)
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
Unable to reproduce in recent versions.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•