This article is incomplete, css image-rendering: pixelated will not do that the article claims

[greggman]

MDN URL

https://developer.mozilla.org/en-US/docs/Games/Techniques/Crisp_pixel_art_look

What specific section or headline is this issue about?

The entire thing

What information was incorrect, unhelpful, or incomplete?

The article ignores that devicePixelRatio might be a non-integer value making this solution look extremely poor.

What did you expect to see?

It should mention this issue so the effect you want your users to see is what they get.

Given a 100x100 pixel image

If the user's device has a non-integer DPR (mine is 1.25) it will look like this

Unless you have a device set up with with a non-integer DPR it's unlikely you'll see this issue. Note that you can change the DPR in windows by setting the "Scale". Another way to see the issue is to zoom in or out which changes the DPR to non-integer values on Firefox and Chrome

This is unlikely what users want but the article doesn't mention the issue

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

MDN metadata

Page report details

• Folder: en-us/games/techniques/crisp_pixel_art_look
• MDN URL: https://developer.mozilla.org/en-US/docs/Games/Techniques/Crisp_pixel_art_look
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/games/techniques/crisp_pixel_art_look/index.md
• Last commit: b0d4232
• Document last modified: 2024-07-23T11:48:42.000Z

[Josh-Cena]

Merging this into #23847

[greggman]

This is not a duplicate of the linked issue. This issue has nothing to do with ctx.scale. It has to do with non-integer devicePixelRatio settings. You can repo that issue by using zoom in firefox and chrome.

[Josh-Cena]

I know they are not perfect duplicates, which is why I said I'm "merging them". They have the same underlying cause, which is that the canvas pixels are not aligned to physical pixels. A fix to one issue would definitely fix the other.

[greggman]

No, they are not related and do not have the same underlying cause. ctx.scale affects what pixels are in the canvas. image-rendering: pixelated affects how the pixels in the canvas are rendered on the screen.

[Josh-Cena]

ctx.scale does not work with image-rendering: pixelated is what the linked issue is saying. devicePixelRatio does not work with image-rendering: pixelated is what you are saying. Both are because when you use an awkward CSS pixel size, the device cannot render the desired CSS pixel boundaries perfectly.

[greggman]

one more time, the two issues have nothing to do with each other.

Also, ctx.scale is not an issue what-so-ever with pixel boundries.

One, you have a canvas, say it's 4x4. You draw a line from 0,0 to 4,4

const canvas = document.createElement('canvas');
canvas.width = 4;
canvas.height = 4;
const ctx = canvas.getContext('2d');
ctx.moveTo(0,0);
ctx.lineTo(4,4);
ctx.stroke();

The spec does NOT require it to stroke single pixels

+---+---+---+---+
|###|   |   |   |
+---+---+---+---+
|   |###|   |   |
+---+---+---+---+
|   |   |###|   |
+---+---+---+---+
|   |   |   |###|
+---+---+---+---+

Instead, the implementation is allowed to do whatever it wants. Most will do something like this

+---+---+---+---+
|###|#  |   |   |
+---+---+---+---+
|  #|###|#  |   |
+---+---+---+---+
|   |  #|###|#  |
+---+---+---+---+
|   |   |  #|###|
+---+---+---+---+

Where ### would be stroke color and # is 33% of the stroke color blended with whatever is in the canvas. It's already not rendering to pixel boundries. There is nothing in the CanvasRenderContext2D spec that requires rendering to pixel boundries, period except "putImageData".

ctx.scale is entirely irrelevant to this. That it happens to be one way you can get non-pixel perfect rendering in a few cases is mis-understanding how the API works. The API itself does not promise pixel perfect rendering. There's been requests for it to have an option to do so, it's unlikely they'll ever be implemented.

---

2nd-ly, and underlated to the previous issue, whatever resolution the canvas is (in the case above it's 4x4 pixels), it gets composited on the page. That size is set with css. It could be

canvas.style.width = '100%';
canvas.style.height = '100%';

In which case the canvases 4x4 pixels will get rendered to fill the container of the canvas.

canvas.style.width = '100vw';
canvas.style.height = '100vh';

In which case it will be rendered the size of the viewport.

It could be a specific size like

canvas.style.width = '64px';
canvas.style.height = '128px';

In which case the 4x4 pixel canvas will get rendered 64x128 "css pixels" in size.

image-rendering: xxx specifies what algorithm to use when this stretch happens (the 4x4 pixel canvas gets drawn to a different size). It's irrelevant to it being a canvas. I could be an image or a video. All 3 have a resolution (the size of their data), and separately get draw on the page the size their CSS specifies. image-resolution: is related to this 2nd part. It's got nothing to do with the how the content inside the element is made (which is what the first issue is about).

The 2 are entirely unrelated to each other.

• ctx.scale is related to making the content
• image-rendering: is related to displaying the already made content

[Josh-Cena]

OK, I see what you mean. You are saying that the canvas first draws the image, and then the canvas element gets scaled with respect to the image-rendering property, and by the time the image-rendering property has an effect, the neighboring CSS pixels have already been partially colored, so they could never be rendered in a pixelated fashion, is that correct?

Do you think you could suggest improvements that would address both issues?