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: `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
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

Back to Bug 1072703 Comment 25