(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.

> Linux should be consistent with Windows here.

Adding a 1.5 step and rounding down for smaller values would be as consistent
as practical for a change to this single function.

(In reply to :Gijs Kruitbosch from comment #24)
> (and, for that matter, with other apps.)

Firefox UI currently is mostly consistent with other apps.  i.e. for scale
factors in the range 1-2, text is scaled by the text-scaling factor and images
and other rendering are scaled by the pixel scaling factor.  The proposal in
attachment 8724197 is to differ from what other apps do.

CSS decided to use a single scale factor, and layout is usually using the
pixel scaling factor for content.  (System font sizes are still using the
text-scaling factor in content, I assume.)  It sounds like you are requesting
that layout use the text scaling factor for everything in content.  Having
content rendered using a different scale factor from the UI is an option I
guess.  I don't think it is a good one, but that would need a very different
patch.

My goal here is to get something that is consistent and suitable for the
majority.  Whatever we choose, there will be people who want something else.
For people that want something different, layout.css.devPixelsPerPx and page
zoom are available.

(In reply to Justin Dolske [:Dolske] from comment #18)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #11)
> 
> > > Comparing this
> > > to the Windows behaviour: the set scaling it read from the system as is,
> > > with no rounding applied.
> > 
> > Windows usually scales in steps, 1, 1.25, 1.5, 2 (and maybe higher).
> 
> The easily accessible UI only has a few choices (those sound about right),
> but there's other UI that lets the user set arbitrary scaling factors.

Ah.  When attempting to hand edit Win7's custom dpi value in the "Scale to
this percentage of normal size" editable field, it gets reset to one of the
available options in the select, but clearing the whole field defeats this
allowing any value to be set.

Win10's snap positions add 1.75, but I haven't worked out how to defeat
its snapping.

It is still true that Windows usually uses one of a few choices.

> > Adding a 1.5 step makes sense, I think, especially because this is supported
> > on Windows, and so has some chance of support from web authors.
> 
> I don't think _any_ of this should hinge on "support" from web authors. 

This issue is that web authors /can't/ support arbitrary sizes because Gecko
doesn't give them tools to do so.

> > I'm not so keen on adding 1.25 because the benefits of a different size don't
> > necessarily outweigh the disadvantage of likely interpolation.
> 
> 1.25 is the most popular scaling factor on Windows (other than 100%, of
> course).

And the Linux UI is already following the Windows behavior at dpi scale factors of 1.25.  Text is scaled and images are not, because that is the right thing to do at 1.25.  Firefox UI images may be scaled by 1.25 on WINNT but that would be a bug.