(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 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.
No. Please review the screenshots I have attached to this bug. *There is no rounding* in Windows. You are free to prove otherwise, but I have checked both the code and provided visual proof.
> (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.
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 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
> (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.
No, on Windows, *everything* is scaled as defined by the Windows font scale. In Linux, *only* a couple of things (namely,
(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 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.
No. Please review the screenshots I have attached to this bug. *There is no rounding* in Windows. You are free to prove otherwise, but I have checked both the code and provided visual proof.
> (In reply to :Gijs Kruitbosch from comment #24) css.devPixelsPe rPx and page
> > (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.
> zoom are available.
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 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
> (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.
No, on Windows, *everything* is scaled as defined by the Windows font scale. In Linux, *only* a couple of things (namely,