Closed
Bug 704399
Opened 13 years ago
Closed 13 years ago
Gap between background and border when using border-radius (due to antialiasing?)
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla11
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
(Depends on 1 open bug, )
Details
Attachments
(1 file, 2 obsolete files)
The testcase is at the url, but here's a pretty minimal version: <style> div { width: 100px; height: 100px; border: 10px solid black; background: black; border-radius: 60px; } </style> <div></div> There is a gray line separating the black ring from the black circle. I expect that this is due to the fact that we draw the background to the padding area, with antialiasing, then draw the border with antialiasing, so we get a strip of not-fully-painted-on pixels... In particular, if I change this code in nsCSSRendering: currentBackgroundClip = bg->BottomLayer().mClip; isSolidBorder = (aFlags & PAINTBG_WILL_PAINT_BORDER) && IsOpaqueBorder(aBorder); if (isSolidBorder && currentBackgroundClip == NS_STYLE_BG_CLIP_BORDER) currentBackgroundClip = NS_STYLE_BG_CLIP_PADDING; to also require !haveRoundedCorners to change currentBackgroundClip to PADDING, then the problem goes away... Should we just do that in general?
Assignee | ||
Updated•13 years ago
|
Summary: Gap between background and border-radius (due to antialiasing?) → Gap between background and border when using border-radius (due to antialiasing?)
Assignee | ||
Comment 2•13 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Attachment #576540 -
Flags: review?(roc)
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Version: 9 Branch → Trunk
Assignee | ||
Comment 3•13 years ago
|
||
Hrm. That patch causes some of the other border-radius tests to fail since we now paint the background out to the edge of the rounded area. Most of them are not that important (and I can explicitly set padding-box styling on them to fix them, in fact), but 456219-2.html shows that we're getting a few pixels of aqua ghosting at the very corners of the outermost part of the border. That's not unexpected, but seems undesirable... So I'm not quite sure how best to update that testcase or whether it indicates that we need a new approach to this bug (e.g. only expanding out by one pixel, not all the way out to the border edge. roc?
Expanding out by one pixel sounds good.
Comment 5•13 years ago
|
||
I tried expanding out by only one pixel in bug 466572. It is possible for that to not cover the entire seam, and it is also possible for that to *create* ugly fringes where there weren't any before, if the border is semitransparent.
Assignee | ||
Comment 6•13 years ago
|
||
> It is possible for that to not cover the entire seam In what situations? > it is also possible for that to *create* ugly fringes where there weren't any before, if > the border is semitransparent. I'm restricting this to the case of fully opaque borders. That is, it's a modification of our existing "optimize the background clip area to the padding area when it's the border area to start with and the border is opaque" code.
Comment 7•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #6) > > It is possible for that to not cover the entire seam > > In what situations? I don't remember exactly, but I think it involved large radii and/or high eccentricity. > I'm restricting this to the case of fully opaque borders. Ok.
Assignee | ||
Updated•13 years ago
|
Attachment #576540 -
Attachment is obsolete: true
Attachment #576540 -
Flags: review?(roc)
Comment on attachment 577746 [details] [diff] [review] When doing the 'restrict background painting to the padding area' optimization, actually restrict it to padding area plus 1px on each side to deal with seams caused by curved borders better. Review of attachment 577746 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/base/nsCSSRendering.cpp @@ +1580,5 @@ > + if (aBackgroundClip == NS_STYLE_BG_CLIP_MOZ_ALMOST_PADDING) { > + // Reduce |border| by 1px on all sides, if possible, so that we > + // don't get antialiasing seams between the background and > + // border. > + nscoord onePixel = nsPresContext::CSSPixelsToAppUnits(1); DevPixelsToAppUnits I think
Attachment #577746 -
Flags: review?(roc) → review+
Assignee | ||
Comment 10•13 years ago
|
||
Ah, high eccentricity could do it, yeah. I'm not going to worry about that case for now.
> DevPixelsToAppUnits I think
Makes sense. Will do that.
Assignee | ||
Comment 12•13 years ago
|
||
OK, I tried doing that. The test for this bug then fails on windows, because with only 1px of overlap we end up with some pixels that are rgb(1,1,1) insteadof rgb(0,0,0). I'm just going to mark the test as failing on Windows, I think... :(
Assignee | ||
Updated•13 years ago
|
Attachment #577746 -
Attachment is obsolete: true
Attachment #578451 -
Flags: review?(roc) → review+
Assignee | ||
Comment 14•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/85358854403f
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla11
Comment 15•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/85358854403f
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•