I've just posted a testcase[1] to demonstrate the issue that we would hypothetically be solving here. Essentially: `image-scaling:pixelated` looks considerably-worse than the default scaling algorithm when we downscale. With the image I'm using, it introduces breaks in the black diagonal "slash"; and in the second-to-last line, the diagonal "slash" disappears entirely. Having said that, I have a few observations which lead me to believe we can close this: (A) Chromium and WebKit have the same or similar downscaling artifacts on this testcase, so this isn't a case where we've fallen behind them, at least. (B) The CSSWG resolution that prompted me to file this bug never actually made it into the spec, unfortunately (as I mentioned in https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-785619937 ) (C) The spec has evolved a bit so that now pixelated will have an "optional better-than-Nearest-Neighbors behavior" for other fractional scale-factors as well (not just < 1), as noted in comment 20. All three of these factors lead me to believe we should just close this out. I'll file a new (not-high-priority) bug on optionally coming up with a better scaling behavior for fractional scaling factors, and I'll duplicate this bug forward to that new bug, as its spiritual successor. [1] Brief overview of the testcase: it shows the same image, with default `image-scaling` on the left and `image-scaling:pixelated` on the right, at a variety of sizes: - the default size - scaled *up* by 4x (to 128px in size), just to double-check that `pixelated` is doing something. - scaled *down* to a variety of widths
Bug 1072703 Comment 25 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I've just posted a testcase[1] to demonstrate the issue that we would hypothetically be solving here. Essentially: our `image-scaling:pixelated` implementation looks considerably-worse than the default scaling algorithm when we downscale. With the image I'm using, it introduces breaks in the black diagonal "slash"; and in the second-to-last line, the diagonal "slash" disappears entirely. Having said that, I have a few observations which lead me to believe we can close this: (A) Chromium and WebKit have the same or similar downscaling artifacts on this testcase, so this isn't a case where we've fallen behind them, at least. (B) The CSSWG resolution that prompted me to file this bug never actually made it into the spec, unfortunately (as I mentioned in https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-785619937 ) (C) The spec has evolved a bit so that now pixelated will have an "optional better-than-Nearest-Neighbors behavior" for other fractional scale-factors as well (not just < 1), as noted in comment 20. All three of these factors lead me to believe we should just close this out. I'll file a new (not-high-priority) bug on optionally coming up with a better scaling behavior for fractional scaling factors, and I'll duplicate this bug forward to that new bug, as its spiritual successor. [1] Brief overview of the testcase: it shows the same image, with default `image-scaling` on the left and `image-scaling:pixelated` on the right, at a variety of sizes: - the default size - scaled *up* by 4x (to 128px in size), just to double-check that `pixelated` is doing something. - scaled *down* to a variety of widths