WPT failure in css/css-transforms/scale/svg-scale-013.html and -014.html
Categories
(Core :: SVG, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox116 | --- | fixed |
People
(Reporter: dholbert, Assigned: dholbert)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
We fail these two WPT tests:
https://wpt.fyi/results/css/css-transforms/scale/svg-scale-013.html
https://wpt.fyi/results/css/css-transforms/scale/svg-scale-014.html
Direct links to tests:
http://wpt.live/css/css-transforms/scale/svg-scale-013.html
http://wpt.live/css/css-transforms/scale/svg-scale-014.html
The failure looks like a rounding / antialiasing issue, arguably not really a bug. The test has a rect with fractional size and fractional position, which gets scaled down, and the test is expecting the math to work out precisely correctly for that rect to cover up a red area. We're off by a very small amount, whether due to pixel-snapping or rounding error.
We should fix the tests to avoid triggering this rounding error (i.e. avoid depending on precise pixel snapping implementation details), probably by adjusting the scales to not involve fractional pixels. (Or alternately: by making the rect slightly larger so that it's got a bit of wiggle room for rounding error.)
Assignee | ||
Comment 1•2 years ago
•
|
||
I filed https://github.com/web-platform-tests/interop/issues/359 to track the test-change upstream.
Assignee | ||
Comment 2•2 years ago
|
||
These tests were making unjustified subpixel-positioning assumptions about
rects with positions and sizes of 133.333px; and the tests were also not
accounting the fact that 1.5 * 133.333px is technically not-quite-200px.
This patch addresses these issues by using 1.25 * 160px instead -- testing the
same thing, but with a whole-number pixel value that doesn't require a
truncated decimal approximation.
This addresses https://github.com/web-platform-tests/interop/issues/359
Updated•2 years ago
|
Comment 5•2 years ago
|
||
bugherder |
Description
•