Ugly scaling on mobile

[1j01]

On mobile, it looks like this for me currently:

Yuck. Pixels aren't square; some are tall, some are wide. Look at the icon for the rectangle tool, it's not even straight on the top and bottom!

I could do:

document.body.style.zoom = 1 / window.devicePixelRatio;

but I'm not sure what the implications of this might be; it might make buttons really small. It might confuse some code using getBoundingClientRect(), etc.

Also for screens that have a higher scale than 1.5, like 2 or more, it should almost certainly round down to the nearest integer.

[1j01]

Also this should apply to 98, and I'm not sure how it might apply to jspaint when it's in an iframe; it might compound, which wouldn't be good.

[1j01]

var updateZoomScale = function(){
    var desiredDPR = Math.floor(devicePixelRatio);
    document.body.style.zoom = desiredDPR / devicePixelRatio;
};
updateZoomScale();
var lastDPR = devicePixelRatio;
addEventListener("resize", function(){
    updateZoomScale();
    if(lastDPR !== devicePixelRatio){
        console.log("ur zoomin'");
        // TODO: show a message to users here to let them know the zoom is being counteracted to make it even numbers of pixels to avoid jaggedness, but only within.. buckets? slices? intervals? and they can zoom in or out further for it to change
    }
    lastDPR = devicePixelRatio;
});

This isn't enough. zoom breaks things.

On 98 it breaks at least:

• desktop marquee coordinates are wrong (doesn't line up with your mouse)
• desktop icon layout (thinks the page's height is smaller than it is)
• start menu max-height (should do this differently anyways)
• winamp window bounds (thinks the page's height is smaller than it is)
• other window bounds (currently only triggered if you resize) (thinks the page's height is smaller than it is)
• iframe scaling (all iframe programs would need this sort of thing applied individually as well - not just as an enhancement, but the window sizes are currently determined by the size of the content or assuming the size of the content so the scales must be the same or it'll need to be updated to use the content size in conjunction with the relative scaling factor/ratio)

On jspaint it breaks at least:

• the viewport media query that hides the palette (which should maybe not be a thing; in Windows MS Paint it hides the palette and tools based on the size of the window but maybe that's not so helpful for this web app)
• window bounds (currently only triggered if you resize) (thinks the page's height is smaller than it is)

[1j01]

I've implemented a compromise approach, where it chooses between disabling antialiasing or not based on whether it's an integer scaling size (or large enough that it doesn't matter that the pixels are uneven in size). (https://github.com/1j01/jspaint/commit/2a5206a2c5e9555ddaa55ed773850270f62115c7, https://github.com/1j01/jspaint/commit/ad4e5c7cadd5408a304b513659ae5dba862fd592, https://github.com/1j01/jspaint/commit/6ac691e9bdcc08bf4ffdc15cd03204c95ae706f5, and maybe a few other commits around that time frame)

It's not that good of a compromise because Chrome at least has this bug where it'll do horrible flickering between antialiased and aliased.

It's worth looking into making the canvas (and selections) scale w/ the magnification code I already have (apply an additional scalar anywhere magnification is used for scaling, to correct for non-integer devicePixelRatios), even tho the UI would still be blurry - the canvas is way more important than the blurriness of the UI. And then maybe scaling individual parts of the UI that I know won't break from code that calculates stuff based on the mouse position or the positions of elements.