Comment 36 for bug 1500282

(In reply to Stefan Seidel from comment #31)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #28)
> > (In reply to :Gijs Kruitbosch from comment #23)
> > > I think these concerns were already addressed in comment #18.
> >
> > I disagree. "mostly been a non-issue" is very much one point of view.
> > The dependencies of bug 820679 track these.
>
> Why do you insist on making a special case for Linux here? I see your point
> in wanting stepped scaling factors for web content and I am happy to
> participate in a discussion about this. However, as has been pointed out
> already, this should be solved on a higher level and *not* be OS-specific.

Linux is special because there the dpi can default to arbitrary floating point
values, from EDID values without any steps. The values on other operating
systems have defaulted to pre-specified steps. The steps are different on Mac
and WINNT. On these platforms, the need for Gecko to round has not been
important because the system usually does this for us. I don't think we can
depend on that on Linux.

GTK3 solved this at a higher level by choosing to be consistent with Mac by
using integer scale factors for pixels, but we agree that this is a poor
solution for those with intermediate resolutions.

Even explicitly set, unstepped, arbitrary dpi values (as opposed to real EDID values) may be quite reasonable in some desktop environments and/or for some applications. For office programs displaying documents intended for paper not screen, for example, it doesn't matter what dpi is used.

The web, however, was designed for integer scale factors.
resolution media queries have since added support for unspecified fixed resolution
values. Following the values that authors expect will give the best results.

For example, the icon in the top-left of https://en.wikipedia.org/wiki/Main_Page renders best at 2.0, OK at 1.0 and 1.5, but poorly at other resolutions.

It uses these rules:

.mw-wiki-logo {
 background-image:url(/static/images/project-logos/enwiki.png)
}
@media (-webkit-min-device-pixel-ratio:1.5),(min--moz-device-pixel-ratio:1.5),(min-resolution:1.5dppx),(min-resolution:144dpi) {
 .mw-wiki-logo {
  background-image:url(/static/images/project-logos/enwiki-1.5x.png);
  background-size:135px auto
 }
}
@media (-webkit-min-device-pixel-ratio:2),(min--moz-device-pixel-ratio:2),(min-resolution:2dppx),(min-resolution:192dpi) {
 .mw-wiki-logo {
  background-image:url(/static/images/project-logos/enwiki-2x.png);
  background-size:135px auto
 }
}

If the author had cared about other scales, they would have inverted this and
used max-resolution to scale down larger images, but that would still not have
worked as well as rendering the images at native resolution, which the web
does not support AFAIK.

> I do not think that the majority of users prefer such a inconsistent
> behaviour as current. Check the screenshorts again. The font size of the
> tabs and the address bar change but the content size does not. Something
> similar can be seen in about:config, where the perceived "content" (namely,
> the list of properties) is scaled correctly. Web content is not. In one of
> the references bugs I found this post:
> https://bbs.archlinux.org/viewtopic.php?pid=1625930 and it explains the
> problem perfectly:
> 1) User set scaling factor to their liking
> 2) User perceives all apps follow the scaling factor
> 3) User perceives that only Firefox does not follow the scaling factor

I get "The link you followed is incorrect or outdated." for that link.

>
> I don't know, maybe I have to buy and send you a 140dpi and a 150dpi device
> so you can experience what the problem is. At <144dpi we're straining users
> with a web rendering that is far too small to be usable and at >144dpi

FWIW I used a 147 dpi display for years. My experience was that things were
better slightly smaller and sharp than larger and fuzzy. When necessary, I
used page zoom, even before this was remembered for each site. Even with
larger default scale factors, there will still be websites where page zoom is
required.

However, I know there will be plenty of people whose experience is different.

(In reply to Stefan Seidel from comment #32)
> continuing: [...] and at >144dpi we're just wasting space. Yes, adding a 1.5
> step mnakes things a bit better, adding stepless scaling would make things
> infinitely better.

I can see advantages in a continuum of values, but there is a point where the
advantages of more steps does not outweigh the disadvantages.

The fact that chrome/UI and the web use the same scale factors is not helping,
but, as long as that is the case, I need to weigh all the pros and cons that
are tied together.