Open
Bug 500804
Opened 15 years ago
Updated 2 years ago
minute rendering difference in table cell border-radius compared with same-size SVG rect
Categories
(Core :: Layout: Tables, defect)
Tracking
()
NEW
People
(Reporter: jgriffin, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(6 files, 1 obsolete file)
When -moz-border-radius is applied to <td> elements, the table cell borders are curved appropriately. However, reftest exposes minute differences in curvature compared with same-size SVG rectangles. Test files, and reftest analyzer screenshot attached. The CSS3 spec does not define how border-radius should be handled by internal table elements (except when border-collapse is set), and in any case the difference here is not visually apparent, so I'm not sure whether we care about this or not.
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Updated•15 years ago
|
Attachment #385486 -
Attachment mime type: text/html → application/xhtml+xml
Reporter | ||
Comment 2•15 years ago
|
||
Comment 3•15 years ago
|
||
Jonathan: please cc: me explicitly on future border-radius bugs. I would bet that these minute differences of curvature that you observe are down to the table cells not being precisely the size that the SVG test case expects: a difference of less than a pixel, which gets rounded away when deciding where the sides will actually be drawn, but still affects curve positioning. I'm egregiously unfamiliar with what can and cannot be done with table rendering -- is it possible for you to constrain the box size of the table cells themselves, rather than having the table layout code infer this from the size of the table and the requested inter-cell padding?
Reporter | ||
Comment 4•15 years ago
|
||
(In reply to comment #3) > is it possible for you to constrain the box size of the > table cells themselves, rather than having the table layout code infer this > from the size of the table and the requested inter-cell padding? Yes, but the same problem occurs. I'm updating the testcase (HTML) with the table cells defined the same size as the SVG rectangles; same reftest difference. (Parenthetically, I had to specify the table cells as 25x35 to get 35x35 cells for some reason I can't explain.)
Reporter | ||
Updated•15 years ago
|
Attachment #385497 -
Attachment mime type: text/plain → text/html
Comment 6•15 years ago
|
||
I'd like to see a cairo trace and/or the result of sticking a printf() of all arguments into gfxContext::RoundedRectangle(). That would also be interesting for bug 459945.
Reporter | ||
Comment 7•15 years ago
|
||
I'm attaching the reftest log for this single reftest, after adding printf's to dump all arguments to gfxContent::RoundedRectangle(). The code I added is: void gfxContext::RoundedRectangle(const gfxRect& rect, const gfxCornerSizes& corners, PRBool draw_clockwise) { printf("gfxContext::RoundedRectangle() called with args:\n"); printf(" rect.pos.x=%f\n", rect.pos.x); printf(" rect.pos.y=%f\n", rect.pos.y); printf(" rect.size.height=%f\n", rect.size.height); printf(" rect.size.width=%f\n", rect.size.width); printf(" corners[gfxCorner::TOP_LEFT]=%f,%f\n", corners[gfxCorner::TOP_LEFT].width, corners[gfxCorner::TOP_LEFT].height); printf(" corners[gfxCorner::TOP_RIGHT]=%f,%f\n", corners[gfxCorner::TOP_RIGHT].width, corners[gfxCorner::TOP_RIGHT].height); printf(" corners[gfxCorner::BOTTOM_LEFT]=%f,%f\n", corners[gfxCorner::BOTTOM_LEFT].width, corners[gfxCorner::BOTTOM_LEFT].height); printf(" corners[gfxCorner::BOTTOM_RIGHT]=%f,%f\n", corners[gfxCorner::BOTTOM_RIGHT].width, corners[gfxCorner::BOTTOM_RIGHT].height); ... Looking at the log, all numbers passed to this function are nice and round, no half-pixel numbers which might cause rounding differences.
Comment 9•15 years ago
|
||
I made some adjustments to both files to eliminate "noise" differences: - strip the HTML wrapper and 6-pixel horizontal+vertical offsets from the SVG reference - specify *{margin: 0; padding:0} in the HTML - remove all text content from the table (i.e. just have <td></td>) - don't position the table but the real change was to not specify any border at all on the TDs. border:none + -moz-border-radius:4px + background:black causes the background color to be drawn clipped to a rounded rectangle, which is functionally equivalent to what SVG does for a single <rect> element. Based on the traces, I think the problem was that the original HTML was *not* functionally equivalent to a single SVG <rect>; the black border and the black background were drawn as two separate entities, and I think that caused the corners to get drawn a different number of times in the HTML than in the SVG. Drawing the same curved fill over itself repeatedly in Cairo is not the same thing as drawing it once. So I'm inclined to say this is not a bug, but I'm not going to close it either.
Comment 10•15 years ago
|
||
At first it may seem that drawing two times the corners is wrong, but in fact I think that it's a case of the -moz-background-clip property set to clip at "outer" border edge, instead of "padding", ie "inner edge" of border. That way, the background is drawn once with the border *included*, and then the border is painted on top of that. You should verify what I say, but I think it is really not a bug.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•