User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20151003161951 Steps to reproduce: Set the scaling vlaue in unity-control-center to a float value, e.g. 1.5. Actual results: Firefox adapts its highdpi settings to the value in unity-control-center. However, it will round the scale to the next higher value, e.g. 2.0. This means everything is much bigger than it should be. If I set devPixelsPerPx to 1.5 manually everything looks fine. So there must be some bug in firefox that is reading this value as an integer. Expected results: Firefox should use the actual floating point value.

(If somebody tells me where to look I might be able to submit a patch...)

Here is the patch which fixes this. It basically removes the rounding applied when reading the current DPI from gdk_screen_get_resolution(). I have tested this and it works as expected: the Xft/DPI value is read from XSETTINGS, returned in gdk_screen_get_resolution() and then correctly applied to the content rendering as well. This is consistent with the UI rendering, which already gets scaled correctly at all Xft/DPI values > 96. I hope this can be included.

Further information: it seems that no-one ever questioned in the initial commit why "We want to set the default CSS to device pixel ratio as the closest _integer_ multiple, so round the ratio of actual dpi to CSS dpi (96)". This probably comes from the fact that GDK_SCALE and GDK_DPI_SCALE only accept integer values (and 0.5). There is no _technical_ requirement for this, though. https://developer.gnome.org/gtk3/unstable/GtkSettings.html#GtkSettings--gtk-xft-dpi accepts granularities of 1/1024th DPI. Also, the "component" of this bug should probably be changed to Gtk:Widget or seomthing else.

Yes, this scale (also editable by GDK_SCALE for debugging purposes) are intended to handle hi-res displays like retina. The DPI scale is just one part of it - the application is supposed to also provide hi-res graphics (pictures, icons, controls) for those modes. IIUC This is also a reason why it's integer scale - to easily scale bitmap images like icons or to provide hi-res icon set.

But from my (limited) understanding, the problem is that the GDK_SCALE is not the value which is rounded here. As I see it, the DPI (referred to as font scaling, gtk-xft-dpi or Xft/DPI setting) operates independently from the "global" GDK_SCALE setting. If I am reading bug #1131978 correctly, both are used to determine the overall "scale" within Firefox. That is, the font scaling read from gdk_screen_get_resolution is not affected by GDK_SCALE (but maybe by GDK_DPI_SCALE?). In any case, it is obvious that the *UI* (is it called chrome?) part of Firefox scales correctly (as seen for example in the font size in about:settings and the tab font size), but the *content* part doesn't. After applying this patch, both scale consistently.

AFAIK the GDK_SCALE is here for debugging purpose only (if you want to emulate hi-res mode on a regular display so if you want to override the fedault) and it's involved unless user set it explicitly by hand (by gnome-tweaking-tool for instance).

(In reply to Martin Stránský from comment #6) > it's involved unless user set it explicitly by hand (by > gnome-tweaking-tool for instance). Erm, it's *not* involved.

So is there a reason to apply the rounding *in Firefox* where my patch would remove it? From a GTK3 point of view, probably, because the reason you mentioned that an application can provide hi-res bitmaps etc. From a Firefox point of view, I can say that there is no *technical* reason, i.e. setting devPixelsPerPx to a float value by hand (as Kai Mast has reported), produces the desired result - Firefox scales the content according to the preference. However, as Firefox is supposed to read the DPI value from the system when devPixelsPerPx is <=0, it currently doesn't, at least not in a meaningful way. It will work for the very limited use case of DPI=192 (font scaling=2) and other factors, but for anything in between, it does not. Comparing this to the Windows behaviour: the set scaling it read from the system as is, with no rounding applied.

Comment on attachment 8724197 [details] [diff] [review] patch to use actual gtk scaling I'm not a peer for this code (nor do I know anything about GTK3 in general).

This probably ought to live in the Widget::GTK component (and the suggested reviewers will be relevant then too).

(In reply to Stefan Seidel from comment #8) > So is there a reason to apply the rounding *in Firefox* where my patch would > remove it? From a GTK3 point of view, probably, because the reason you > mentioned that an application can provide hi-res bitmaps etc. From a Firefox > point of view, I can say that there is no *technical* reason, i.e. setting > devPixelsPerPx to a float value by hand (as Kai Mast has reported), produces > the desired result - Firefox scales the content according to the preference. There are similar reasons re images from web content. Firefox will scale, but will only render without interpolation if the web content supports the resolution. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1081142#c10 > 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). 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'm not so keen on adding 1.25 because the benefits of a different size don't necessarily outweigh the disadvantage of likely interpolation. At 1.25, Windows defaults (in some versions at least) to XP scaling, which scales font sizes but not pixels. Doing this in web content broke too many sites. The goal is to pick what will be best for most and layout.css.devPixelsPerPx is available for those where this doesn't work out.

I would like to adjust the patch to scale like the Windows code. I fail however to find any rounding there. I dug down to http://lxr.mozilla.org/mozilla-central/source/widget/windows/WinUtils.cpp#626 where GetDpiForMonitor is called and the value is return with no rounding applied. This is then passed through at http://lxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#1085 and used in http://lxr.mozilla.org/mozilla-central/source/widget/nsBaseWidget.cpp#565 . Are there any test cases where odd devPixelsPerCSSPixel values lead to actually broken website display? I would like to test it. As for GTK3 - I don't actually have a fully fledged GNOME system to test with, but can one set arbitrary values in the "normal user" control panel for the DPI/font scaling or does it have steps? In any case, are we not in the same situation as in Windows, where the system deliveres a DPI value (however rounded/stepped it may be from the OS's point of view) and Firefox just uses this value to determine the defaultScale?

Sorry, I only now read all the comments from https://bugzilla.mozilla.org/show_bug.cgi?id=1081142. Sigh. So this is actually an old discussion of correctness vs. blurriness (of bitmap images; fonts and vector graphics scale without problem in my experience). At the risk of overengineering this, would it be possible to set a special value (like -2.0) to apply the correct system scaling at the expense of blurriness? I can see from this and the other bug's comments that clearly there are users out there who prefer correct scaling over "beautiful" scaling. And certainly for DPI values around 1.5×96 DPI, which is _very_ common, the steps 1x and 2x are really too coarse, even 1.5x might not be enough. Also, I think the common use case is that GNOME sets the scaling correctly to an integer value, and only if the user is not satisfied with the look — or, for example, sight-impaired — the user will set the scaling to a different value. I think if a user sets an explicit value for the system font size (and all application will obey), Firefox should follow this setting too. I plan to prepare some screenshots to demonstrate this a bit better.

So I have taken some screenshots. Here are the GIFs of Firefox at these DPI values: 96, 105, 115, 125, 134, 143, 154, 168, 192, 216 (these correspond to the scaling factors 1.0, 1.1, 1.2, 1.3, 1.4, 1.49, 1.6, 1.75 (I got lazy), 2.0, 2.25) It can be observed that my reading of the Windows code is correct - Windows *does* scale exactly according to the system-reported DPI value. It seems obvious to me that the rounding currently applied when reading the system DPI leads in fact to a broken behaviour since parts of Firefox scale (best example: font size in tab label) but the content does not. The "proposed GTK3 scaling" screenshots are from a FF built with my patch applied.

To compare another application, here is LibreOffice, scaling the content just as the user ordered. The menu icons only double the resolution at 192 DPI and stay the same size for all other resolutions.

(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. And they've recommended supporting other oddball factors in the past (ISTR Metro guidelines had 133% and 180%, or something like that). > 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. > 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). At one point we were greatly concerned about this for the browser chrome (some discussion in bug 1147702), but it's mostly been a non-issue. Providing a 2x image and downscaling works quite well in most cases, and we're already well along in starting to shift to SVG. The only thing that doesn't "just work" very well is tiny bitmaps, like 16x16 favicons. Interpolated upscaling doesn't look very good, and even in cases where we force nearest-neighbor it can still look a bit off when scaling to 20x20 (1.25x). (We also talked about special-casing this in the UI, e.g. by forcing them to display as 16x16 physical pixels + padding, but it hasn't been a significant issue.) I think Linux should just follow what Windows is doing. If there's interest in pushing for snapping/rounding to certain levels, we should do that everywhere and be consistent.

Oh my god, this patch fixes the biggest (by far!) of my grievances with Firefox on Linux. The appearance on a high dpi display is now so much better that I feel as if my eyesight just got better! Please, pretty please, can we land this?

(In reply to Panos Astithas [:past] from comment #20) Not as is, but I'd be happy to take a patch for a 1.5 step, even though Mac and GTK do not, because, at that level, I expect the benefits start to out-weigh the flaws, and WINNT does this. Would that help your situation? What are your Gdk/WindowScalingFactor and DPI values? The DPI from GDK is a font scaling dpi. Users do not expect small changes to trigger blurry icons and UI, ugly tabs, etc. Also, Gecko does not provide a good way for authors to supply pixel-accurate bitmaps at arbitrary sizes.

(In reply to Karl Tomlinson (back 26 Apr, ni?:karlt) from comment #21) > (In reply to Panos Astithas [:past] from comment #20) > > Not as is, but I'd be happy to take a patch for a 1.5 step, even though Mac > > The DPI from GDK is a font scaling dpi. Users do not expect small changes to > trigger blurry icons and UI, ugly tabs, etc. Sorry, this is not about UI and tabs. Please review the screenshots. The Firefox UI already scales perfectly well without rounding. It's only the web content that doesn't scale. Please compare with other applications. Chrome scales as told, LibreOffice scales as told. Every other simple program I tested observes the font scaling and scales the _content_ accurately. Sometimes, as for LibreOffice, the UI only scales in steps, but again, the _content_ scales as requested.

(In reply to Karl Tomlinson (ni?:karlt) from comment #21) > (In reply to Panos Astithas [:past] from comment #20) > > Not as is, but I'd be happy to take a patch for a 1.5 step, even though Mac > and GTK do not, because, at that level, I expect the benefits start to > out-weigh the flaws, and WINNT does this. > > Would that help your situation? > What are your Gdk/WindowScalingFactor and DPI values? > > The DPI from GDK is a font scaling dpi. Users do not expect small changes to > trigger blurry icons and UI, ugly tabs, etc. > > Also, Gecko does not provide a good way for authors to supply pixel-accurate > bitmaps at arbitrary sizes. I think these concerns were already addressed in comment #18. Linux should be consistent with Windows here. As already pointed out, WINNT supports close-to-arbitrary sizes, so clamping to 1.5 doesn't do that. Please can you reconsider this decision?

(In reply to :Gijs Kruitbosch from comment #23) > Linux should be consistent with Windows here. (and, for that matter, with other apps.)

Correct, if there should be any rounding applied it should definitely not be OS-specific, but it should be applied at a higher level. Also, you write: > The DPI from GDK is a font scaling dpi. And exactly that is why it should be applied as is. Because right now, it is applied to the fonts in all applications except Firefox. Of course, applying the scaling _only_ to fonts does not make sense in the context of websites, so everything must be scaled.

Proper patch with amended comment

(In reply to Karl Tomlinson (ni?:karlt) from comment #21) > (In reply to Panos Astithas [:past] from comment #20) > > Not as is, but I'd be happy to take a patch for a 1.5 step, even though Mac > and GTK do not, because, at that level, I expect the benefits start to > out-weigh the flaws, and WINNT does this. > > Would that help your situation? > What are your Gdk/WindowScalingFactor and DPI values? $ dconf read /org/gnome/settings-daemon/plugins/xsettings/overrides $ dconf read /org/gnome/desktop/interface/scaling-factor uint32 1 $ dconf read /org/gnome/desktop/interface/text-scaling-factor 1.25 As you can see I'm using a step of 1.25 in my laptop screen, although I use 1.5 when I'm connected to an external hidpi monitor.

(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 [details] [diff] [review] 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.

(In reply to Stefan Seidel from comment #12) > As for GTK3 - I don't actually have a fully fledged GNOME system to test > with, but can one set arbitrary values in the "normal user" control panel > for the DPI/font scaling or does it have steps? Xft.dpi is equivalent to GNOME's text scaling factor, which accepts floating point values. Unit scaling is 96.0. The GDK_SCALE environment variable is equivalent to the pixel scaling factor, which affects everything (not just text). It is constrained to integer values. I don't know what exactly is presented in GNOME's UI. Other DE's may vary. > In any case, are we not in the same situation as in Windows, where the > system deliveres a DPI value (however rounded/stepped it may be from the > OS's point of view) and Firefox just uses this value to determine the > defaultScale? We are in a situation where we have one scaling factor that is similar to Mac (GDK_SCALE) and the other is similar to NT, but on nix has not been used to scale more than text in native apps. I hear some special apps (Libreoffice, Chrome, Firefox) have used the text scaling factor for more than text. (In reply to Stefan Seidel from comment #13) > At the risk of overengineering this, would it be possible to set a special > value (like -2.0) to apply the correct system scaling at the expense of > blurriness? I can see from this and the other bug's comments that clearly > there are users out there who prefer correct scaling over "beautiful" > scaling. And certainly for DPI values around 1.5×96 DPI, which is _very_ > common, the steps 1x and 2x are really too coarse, even 1.5x might not be > enough. Also, I think the common use case is that GNOME sets the scaling > correctly to an integer value, and only if the user is not satisfied with > the look — or, for example, sight-impaired — the user will set the scaling > to a different value. I can see that some might like to use the text scale factor for the pixel scaling factor. I'm happy for such an option to be added, but I don't think it should be the default. > I think if a user sets an explicit value for the system font size (and all > application will obey), Firefox should follow this setting too. Firefox should be using the system font sizes for system fonts. It is a bug if it is not. Author-specified sizes in web content are another issue and problematic because CSS requires that the same scale factor be used for text and pixels.

(In reply to Kai Mast from comment #0) > Steps to reproduce: > > Set the scaling vlaue in unity-control-center to a float value, e.g. 1.5. > > > Actual results: > > Firefox adapts its highdpi settings to the value in unity-control-center. > > However, it will round the scale to the next higher value, e.g. 2.0. > This means everything is much bigger than it should be. Thanks. That is a bug. The intention was that 1.5 would be rounded down to 1. Text is still scaled and UI auto-expands where necessary to accommodate the text, but icons are still rendered at system sizes. I also think that an additional step of 1.5 and rounding down for smaller values (at least) would be a sensible compromise. https://bugzilla.mozilla.org/show_bug.cgi?id=1081142#c10

(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 [details] [diff] [review] 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,

Oh, somehow this got submitted. 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. continuing: [...] *only* a couple of things (namely, tabs and address bar and preferences pages) are scaled. Again, if you think that stepless scaling in Firefox is a bug, this should be files separately and solved at an OS-independent level.

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

(In reply to Stefan Seidel from comment #31) > (In reply to Karl Tomlinson (ni?:karlt) from comment #28) > > 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. I checked this again and my statement was mostly not right, sorry. It depends. The XP scaling affects applications that are not DPI aware, and when it does apply, it is different. It is trying to avoid scaling making things less sharp, but Windows Explorer does scale icons at 1.25. Other apps do different things. On Win7, Chrome doesn't scale icons, URL bar, or content on Win7 at 1.25, but it does scale tab title text. On Win10, it scales all of these. It would be helpful to know the reasoning for this variation in decision. I've filed bug 1271893 for the 1.5 step. I'm willing to think about a 1.25 step for the subsequent release. My initial impressions were not good. Tabs are the worst (bug 995733). There's also the https/hamburger/bookmarks/etc icons, double-thick line between chrome and content, wrong size icons in menus. The impression is that the app was not designed for scaling (and it wasn't). Browsing the web immediately finds similar issues such as the fuzzy youtube icon, and wonky guardian hamburger, but most of the content on each page is good. Text of course is sharp, except where bitmap renderings are provided, and so one can get used to the problems. Some people will prefer this. I'd be more comfortable using 1.25 when we know the user has explicitly chosen to set that value, rather than using 1.25 based on EDID. In GTK versions with this change, I think we can be much more sure of where a non-96 dpi comes from: https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f That is in https://git.gnome.org/browse/gtk+/log/gdk/x11/gdkxftdefaults.c?h=gtk-3-18

Thanks a lot for your elaborate responses. So with that GTK change and that Xorg change that was referenced earlier, actually the only way to tell applications to scale will be the Xft.dpi/text-scaling-factor setting. Some more questions came to mind: - Android doesn't seem to have a blur problem, and I imagine there is no stepped scaling there? - Windows 10 introduced monitor-specific DPI scaling, I'm not sure if these are stepped or not, but it seems that it really reads the DPI from EDID. - Web developers who care about multi-device support know that they *will* be scaled to arbitrary factors (especially on mobile devices) and will use vector graphics to avoid blur. Obviously that only works for vectorizable graphics that they control, but I would guess that at least 90% of the rasterized non-vectorizable images on the web are photographs and thus not pixel-critical.

(In reply to Karl Tomlinson (ni?:karlt) from comment #34) > I'd be more comfortable using 1.25 when we know the user has explicitly chosen > to set that value, rather than using 1.25 based on EDID. It's uncommon to find DPI EDID-based on Linux. Xorg looks to EDID for preferred resolution, but for the past 9 or so years, it has been intentionally disregarding display dimensions, instead forcing whatever dimensions result in 96 DPI logical density. AFAICT, all using any other DPI on linux took at least some affirmative action, however minimal, to override server forcing to 96. (In reply to Stefan Seidel from comment #35) > So with that GTK change and that Xorg change that was referenced earlier, > actually the only way to tell applications to scale will be the > Xft.dpi/text-scaling-factor setting. To be clear, Xft.dpi is not the only means to scaling in Xorg. On my many Linux installations, few of which ever run at 96 DPI, and none of which include Gnome, Xft.dpi is always null. Here, DPI is always forced otherwise either via xrandr, or DisplaySize.

(In reply to Felix Miata from comment #36) > To be clear, Xft.dpi is not the only means to scaling in Xorg. On my many > Linux installations, few of which ever run at 96 DPI, and none of which > include Gnome, Xft.dpi is always null. Here, DPI is always forced otherwise > either via xrandr, or DisplaySize. I have yet to find an application that scales according to the xrandr/Xorg DPI value. Maybe it is my setup but I have tried for years and I've never seen an application using this DPI value.

(In reply to Stefan Seidel from comment #37) > I have yet to find an application that scales according to the xrandr/Xorg > DPI value. Maybe it is my setup but I have tried for years and I've never > seen an application using this DPI value. IME, most apps scale automatically at least to some extent if not perfectly. The bulk of the offenders are Java, Java-dependent (e.g. open/libre-office), or built with GTK. SeaMonkey's UI/Theming had been good up until it got built with GTK3.

(In reply to Stefan Seidel from comment #31) > 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 we're > just wasting space. Yes, adding a 1.5 step mnakes things a bit better, adding > stepless scaling would make things infinitely better. It's hard for us to overstate how horrible things are at the wrong scale. They have to see it to believe it! In my case Firefox rounded up to 3.0, making everything oversized and broke the layout on many sites. FWIW Chrome sets window.devicePixelRatio of 2.5, consistent with what I set in Ubuntu. Perhaps it's my untrained eyes, but I really can't tell that anything looks worse than they should be. I could only see a marked improvement when I set layout.css.devPixelsPerPx to 2.5 $ gsettings get com.ubuntu.user-interface scale-factor {'eDP1': 20} $ gsettings get org.gnome.desktop.interface scaling-factor uint32 2 $ gsettings get org.gnome.desktop.interface text-scaling-factor 1.25

Forgot to mention, here's a workaround which reads the DPI value from an environment variable called "DPI": === /usr/lib/firefox/mozilla.cfg // defaultPref('layout.css.devPixelsPerPx', ''+(Math.floor(parseFloat(getenv('DPI'))/9.6)/10)); === and === /usr/lib/firefox/defaults/pref/local-settings.js pref("general.config.obscure_value", 0); pref("general.config.filename", "mozilla.cfg"); === Works for Thunderbird too if put in the appropriate directories.

(In reply to Stefan Seidel from comment #37) > (In reply to Felix Miata from comment #36) > > To be clear, Xft.dpi is not the only means to scaling in Xorg. On my many > > Linux installations, few of which ever run at 96 DPI, and none of which > > include Gnome, Xft.dpi is always null. Here, DPI is always forced otherwise > > either via xrandr, or DisplaySize. > > I have yet to find an application that scales according to the xrandr/Xorg > DPI value. Maybe it is my setup but I have tried for years and I've never > seen an application using this DPI value. Wondering the same: Where exactly is Firefox reading the system value from so that it can automatically adjust layout.css.devPixelsPerPx when it is set to -1.0 (default value)? And would it be possible to alter layout.css.devPixelsPerPx and/or the system value via the terminal/via a command? Would be very much appreciated if someone could explain. Regards

Heads up, there are a few discussions about this that may stress this patch to be looked at before chrome extensions kills XUL: https://support.mozilla.org/en-US/questions/1167021 https://www.reddit.com/r/firefox/comments/6lxwj0/how_can_i_decrease_dropdown_menus_space_size/

These seems like a candidate for a photon priority bug?

Sorry, no, we will not be addressing this as part of Photon.

Is there any update on this? Now I'm still having to manually specify the scaling factor on Ubuntu 16.04 LTS. Caused me quite some frustration in the beginning. Seems that this bug is really hard to fix then. At least new users should be relatively well informed of this so that you know how to manually set the value.