Last modified: 2012-10-01 18:49:38 UTC
For mobile, tablets and laptops with high-resolution displays we'll want double-resolution or SVG versions of the icons served. Attached screenshot taken in Firefox 16 nightly with acceleration disabled on MacBook Pro Retina. Looks about the same in Safari. The current icons appear to be PNG, with a PSD source file that's at low resolution. If the layers are vector shapes this should be easy to convert to high-resolution, but I don't have Photoshop on this machine to double-check.
Created attachment 10782 [details] Screenshot on Retina MacBook Pro
Mass-moving items into VisualEditor product
Moving to UI component
Fixed in https://gerrit.wikimedia.org/r/#/c/22113/
Looks awesome in Safari and Chrome on MacBook Pro with Retina display, thanks guys! :D (Proper rendering on Firefox will come in future... upstream issues there still but it'll come.)
Hmm. Actually there's a minor issue: if starting the editing on a low-resolution screen and then switching to high-resolution (by moving the window across screens or changing the screen resolution) we still are stuck with the low-resolution bitmap icons.
This sounds like a UserAgent problem. Isn't the UA meant to handle this?
What about when you have the browser spanning between a low and high DPI screen? We can only depend on devicePixelRatio. I think this is closed until there's a better way to detect this.
(In reply to comment #7) > This sounds like a UserAgent problem. Isn't the UA meant to handle this? Nope, no information available in the UA for this. (In reply to comment #8) > What about when you have the browser spanning between a low and high DPI > screen? We can only depend on devicePixelRatio. If you're spanning over low and high DPI screens on Mac OS X, the window gets assigned the density of whichever window it has the greatest area on. Eg, either you get 1.0 scale and it's pixelated on the high-res screen, or you get 2.0 scale and it's scaled down on the low-res screen. The trick is that window.devicePixelRatio may change over time -- it's a property, not a constant. I think you get a window.onresize event when switching ratios, but I'll have to double-check that. > I think this is closed until there's a better way to detect this. Yeah it's good enough for now, but I'll file a separate bug as a reminder for later if we find a cleaner way. The simplest full fix would be to always use SVG when SVG is supported in the browser -- this would also fix it for Internet Explorer 10, which doesn't support devicePixelRatio but has support for higher-resolution screens in Windows 8.
Broke out follow-up issue to bug 40140.
The problem with always using SVG is that at lower DPI the rendering quality is inferior. In most browsers the pixel boundaries are off a bit here and there, making the icons look fuzzy. I think using raster graphics for icons will some day be antiquated, but we aren't there yet.