HighDPI (aka high pixels-per-inch) displays are becoming increasingly common. Perhaps most well-known are Apple's "Retina" displays, at ~220dpi (vs. ~96dpi for normal displays). HiDPI displays are becoming increasingly common on PC tablet, notebooks, and even external monitors. This leads to three interrelated issues: 1) How should we specify/control HiDPI in the Firefox theme? 2) What sizes/types of icons are needed? 3) What should the asset workflow (UX designer --> in tree --> packaging --> user's system) look like? Our implementation of the OS X HiDPI theme (deps under meta bug 785330) largely relies on using CSS media queries to set style/images for Retina displays. A typical example looks like: #someButton { list-style-image: url(chrome://browser/skin/someButton.png); } @media (min-resolution: 2dppx) { #someButton { list-style-image: url(chrome://browser/skin/someButton@2x.png); } } This works, but isn't really ideal. * It's verbose and repetitive. * It's prone to mistakes. Especially when the 1x/2x rules are separated (too easy to forget to update one) or -moz-image-region is involved. We've had a number of bugs where hidpi was implemented incorrectly as a result, from simply neglecting to provide a hidpi image to having giant/tiny misshapen UI. The HTML srcset feature (bug 870021, http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/) addresses these problems -- but only on <img> elements, which we rarely use in Firefox UI. The biggest problem, however, is that this solution doesn't really scale (teehee) to what's needed on Windows. The situation with Apple's Retina hardware is simple -- things are either sized 100% (normal) or 200% (Retina). But Windows supports many additional scaling factors. Windows 7 supports scaling factors of 100%, 125%, and 150% (as well as an easily accessible "custom" setting for anything between 100% and 500%). Windows 8 adds an explicit 200% option. The guidelines for Windows Store apps (Metro/RT) recommend 100%, 140%, and 180%. (And then there are the with text-only scaling, which isn't relevant here.) It's not really practical to extend the current OSX/Retina scheme to use bitmaps for so many different scaling factors. So it seems likely that we'll need to use a vector format (SVG) for image assets, so that the user isn't seeing a bitmap upscaled/downscaled for their particular DPI setting (which will often look blurry). We _could_ make a tradeoff decision to only support a couple of DPI settings and scale for things in between, but that seems like just kicking the can down the road. Note that even with SVG we will still need to (sometimes) provide multiple image assets! When an image is displayed on screen with a small number of physical pixels (16x16 favicons being the canonical example), hand-tweaked bitmaps are usually required to look acceptable. Finally, there's the asset workflow. Currently, all stages are the same -- for a particular icon, an UX designer provides the necessary sizes and flavors and those all go into the tree and are are all shipped in the respective platform builds. Depending on how we solve the other problems here, this may or may not need to change. For example, we could switch to pure SVG and basically do the same thing. Or we could have UX provide SVG assets, and convert them to bitmaps at some point (for checkin, for packaging, or at run-time on the user's system).

A separate comment about the asset workflow, since it's somewhat related... It would be nice (but isn't a direct requirement for this bug), to derive multiple flavors of an icon from a single source file. This would address two problems: 1) Per-platform variations of an icon are often nearly the same, other than a minor difference in color. Currently UX generates and provides separate assets for each of these flavors. It would save time and effort if a single asset could just be programmatically modified. (Again, this could happen anywhere between UX and the user's system at runtime). 2) We often have issues where static colors in images are insufficient for the variety of contexts in which they may be displayed on a user's system. For example, we have inverted (white) versions of the normal (black/gray) toolbar icons, which get used when we detect the user has a dark Lightweight Theme applied. And Linux is often a headache, because there is no defacto default OS theme (so contrast can be a problem, and we can't choose colors that specifically complement the user's OS theme). Being able to adjust the color or contrast of an icon at runtime would help address this. [And would also enable some interesting possibilities for how addons could restyle things.]

We can simply downscale 2x graphics for 125% to 200%. It's what we do for the Australis tabs. For the devtools, the work is even easier since 2x assets are included on all platforms (since they are all in the themes/shared/ directory). So basically, for devtools, you just need to replace (min-resolution: 2dppx) with (min-resolution: 1.25dppx).

Also, SVG is a good solution, but requires all current assets to be converted. DevTools already uses some SVG files, for the toolbox tabs, the dropdown icons, and the side menu widget arrows. Other devtools hdpi assets use the normal media query method.

Yes, one option is to just do 100% and 200% assets. But for some things that still going to result in blurry icons and/or misaligned stuff where bitmaps and vectors combine (ala bug 995733 for Australis tabs), and it works poorly for extreme scaling factors like 500%. So, as I wrote, that's really just "kicking the can down the road." Let's figure out if there's a better solution. One additional (mostly unrelated) note: For things like favicons that normally display at small pixel sizes (eg 16x16 physical pixels at 100%), a single 16x16 PNG + SVG for everything else may be insufficient... EG, at 125% that would become 20x20, which may still merit a hand-tuned icon. But we're not going to hand-tweak every possible oddball resolution (eg, at 110% it becomes 18x18 or 17x17, depending on rounding), and scaling isn't going to look good... Steven and I had discussed the possibility of looking into having SVG+CSS self-tweak, ala http://www.responsiveicons.co.uk/ (or how font hinting works). That could be a route to having a single asset that works well at multiple small sizes. Whatever we end up doing will be significant effort, which is why we want to do it right, once.

I think we can close this now as we chose an approach in bug 1147702 and can probably push that approach to the other bugs (that is, using 200% icons and downscaling). (In reply to Justin Dolske [:Dolske] from comment #5) > Yes, one option is to just do 100% and 200% assets. But for some things that > still going to result in blurry icons and/or misaligned stuff where bitmaps > and vectors combine (ala bug 995733 for Australis tabs), and it works poorly > for extreme scaling factors like 500%. So, as I wrote, that's really just > "kicking the can down the road." Let's figure out if there's a better > solution. I think we can file new bugs when resolutions of 500% become more common. For the time being, we're not seeing anything negligible above 200%.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6) > I think we can close this now as we chose an approach in bug 1147702 and can > probably push that approach to the other bugs (that is, using 200% icons and > downscaling). See bug 1147702 comment 5 from shorlander. I agree with that, and the context of that bug was to ship something ASAP in lieu of a better solution (which is what this bug is about).