DPI-derived font size (possibly DPI detection itself) seems to have gained a lower bound
Reported by
lightlyf...@gmail.com,
Sep 13 2016
|
|||||||||||||||||
Issue descriptionChrome Version: 53.0.2785.101 OS Version: Arch Linux Overview: For the past 6+ months (probably more) I've had `xrandr --dpi 81` in my .xinitrc to influence Chrome's UI (chrome) font size. I was doing this deliberately in order to be able to fit more tab caption text onto the screen - I like to have a *lot* of tabs open - and also because I highly favor smaller font sizes for system UI like menus etc. After upgrading from 51.0.2704.106 to the above, I found that the font being used for general UI (tabs, control/right-click menus, text search popdown, etc) was suddenly bigger than my enforced font size. Info about the attached screenshots can be found under "additional information" below. To make it easier to track down what caused this change, I spent some time sweeping up and down chromium-browser-snapshots to find the "before-and-after" regressing base position. I may also have found the offending patch that (if I'm right, unintentionally) caused this change, although I'm not sure (I don't know how to cross-reference commit ID hashes to base positions). Some extra notes can be found after the repro info. What steps will reproduce the problem? 0. If you do not want to taint your system X server DPI, install Xephyr (xserver-xephyr on Ubuntu), and do eg `Xephyr :1 -screen 1152x864' (if you don't specify a geometry you get 640x480), and remember `DISPLAY=:1`. Openbox is a good WM choice here (perhaps combined with tint2 or bmpanel2 if you need/want a task panel). 1. Download base positions 397169 and 397176: https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F397169%2Fchrome-linux.zip?generation=1464803604105000&alt=media https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F397176%2Fchrome-linux.zip?generation=1464805696297000&alt=media (Not sure why there are such huge gaps in the position IDs - these are indeed listed consecutively) 2. Unpack, +SUID and start both (see script below). **The tab font size should look identical.** 3. Close both browsers, run `xrandr --dpi 81`, then start them back up. **The font size should be noticeably smaller in 397169, but not 397176.** 4. Now try the other end of the spectrum, eg xrandr --dpi 100. **Both browsers should scale identically.** NOTE: I use the i3 windowmanager, without a desktop environment or X settings manager/daemon. It's quite possible/likely that a DE (and/or any associated settings daemon) may influence the DPI ultimately picked up by Chrome (see URL at end of ticket). Running Chrome on top of just X11+Openbox - or running within Xephyr, if you use a DE with your normal X session - is strongly recommended. You may have repro issues otherwise. NOTE 2: I was using this oneliner to rapidly sweep chromium-browser-snapshots - you may find it useful to download the aforementioned base positions. (Apologies for whatever broken wordwrap Monorail imposes...) read -ep 'Base? ' N; do wget "https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F${N}%2Fchrome-linux.zip?alt=media" -O $N.zip; unzip -d $N $N.zip; cd $N/chrome-linux; mv chrome_sandbox chrome-sandbox; sudo chown root:root chrome-sandbox; sudo chmod 4755 chrome-sandbox; ./chrome --user-data-dir=test123; cd ../..; done What is the expected result? There seems to be a new minimum font size limit. I'd really, really like for it to be made a bit smaller than it currently is. What happens instead of that? The font is capped to a minimum size that's very loud to my eyes :) Please provide any additional information below. Attach a screenshot if possible. Four screenshots are attached. The first two provide a comparison of how the aforementioned base positions react to 96dpi and 81dpi; this is being reproduced on a VPS, while I've experienced the same on my own system for several months. If you cannot reproduce what you see *please* let me know. The second two screenshots demonstrate the advantage of having a smaller font size when using 1366x768. (I don't have a laptop with this resolution myself; I picked it because it's a known widely-used size with certain laptop models.) (NB. The DPI settings do not affect the font size used for webpages (in this case the Settings page) - I assume this is intended.) Regarding the patch info, I don't follow Chrome too closely and I'm not a C++ expert, but I hunted through the changelog for 51.0.2704.106..53.0.2785.101 (I can't seem to find 53.0.2755.0, the value reported by chrome://version for the two base positions above, so I used the versions I upgraded from and to), and I found this: https://chromium.googlesource.com/chromium/src/+/52c96f45954fb726585acd0bac295d801728b22e%5E%21/#F0 > Keep using the same DPI scale > * Dynamic DSF change is not supported/tested on linux. Jus make > sure that it uses the same scale unless restarted. The patch itself is related to keeping the DPI locked, and I don't have any issue with that - but among the last lines in the patch I found this *newly-added* (!) tidbit... dpi = std::max(kDefaultDPI, dpi); ...which looks very interesting, as it suggests that Chrome will not consider DPI values of <96. If I understand this code correctly, the `static's will mean that the first time GetDPI() is run it will initialize the DPI values to -1, so the code in `if (dpi < 0) { ....... }' will run, and that'll then run the line mentioned above. My current compilation resources would require approx 24h to do a full build, so I'm passing on testing this theory for now; I might experiment if this bug sits around for a while. At the very least I found the different base positions. Further notes/rationale: I agree that it's important to consider potential usability issues with something like this. I argue that while I *am* actually short-sighted, the screen I use for Chrome is 1280x1024 (so, not particularly high pixel density), and it sits 2.2ft (70cm) away (I measured it!), so I don't find it a strain to use a smaller font without glasses at all. Furthermore, there are still quite a few laptops out there that use ridiculously low resolutions like 1024x768 and 1366x768. With a laptop you're generally 1.5-1.8ft (45-54cm) away from the screen - even less than the LCD on my desk. So, in short, being able to set the text size smaller than has recently become possible is, IMHO, not actually a bad thing for accessibility/usability. Also, as a mildly related aside, I set my local DPI to 1 (yes, 1) as a last-resort test, and while Chrome is enforcing its 96dpi lower bound, I've have been having a really hilarious time dealing with Chrome's open and save dialogs (the cursor is a 1px square dot, no text is visible, lol). KDE displays text at what looks like 0.01px (menu labels and button captions are ~2px-wide smudges). So, both GTK and Qt have no lower bound for DPI->font size mapping. In other words there's no real OS-level consistency to speak of, and so allowing smaller font sizes isn't exactly going to break any established toolkit-level policy. Finally, I'll admit that using xrandr is probably not the greatest way to go about configuring my DPI, but it worked and did not cause any issues elsewhere (the only other area affected by this is system-level open/save dialogs, and I appreciate the smaller font size there!). This info may be interesting for anybody wrestling with DPI on X11: https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/ UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36
,
Oct 4 2016
wai https://cs.chromium.org/chromium/src/chrome/browser/ui/libgtk2ui/gtk2_ui.cc?rcl=1475579939&l=385 I feel bad closing such a nicely detailed bug report so I'll let oshima@ do it instead :)
,
Oct 8 2016
One thing we can do is to allow lower scale only for fonts.
,
Oct 21 2016
,
Oct 21 2016
A few notes: By default, ignores display's DPI and reports 96 (unless you manually modify it using xrandr or resource). Most linux desktop uses gtk's fonts scale property, and that's what chrome is using now. That's one of reasons why "xrandr -dpi" no longer works. My plan is to add an option to use X's DPI instead of gtk, then allow Native UI to use fonts scale lower than 1.0f. The web page will use the 1.0 in this case, but you can always zoom out the content.
,
Oct 25 2016
,
Oct 25 2016
Aw, nice, this got fixed! https://codereview.chromium.org/2441043002/ oshima: I'm very curious why you're fixing this via DSF instead of DPI. As noted in the article linked at the end of my ticket (https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/), the X11 DPI situation is certainly not straightforward, but a) DPI parsing is where the bug (if you call it that) is, and b) I thought DPI was the mechanism used to fix this sort of thing. I can understand the focus on more modern scaling approaches, along with the fact that there are established projects underway to try and shift graphics on Linux away from X11. My concerns arise from the fact that I don't run Unity _or_ a GTK settings manager/daemon, just a straight WM like i3/openbox, and I'm wondering if I'll need to do that in order to get smaller fonts again. TL;DR: What was architecturally/theoretically wrong/incorrect with removing the std::max()?
,
Oct 25 2016
#7, sorry I didn't understand your question. It'll be using X's DPI (with --enable-xdpi-for-dsf).
,
Oct 25 2016
lightlyfluffedcopypasta@, we're debating if we should have a specific mode that uses X's DPI, or should just use gtk's font settings. That is, 1) Just allow using <1.0 scale for fonts. You use GTK's font configuration tool to set the scalw lower than 1.0. Say you set the scale to 0.9. Chrome will use 1.0 for UI + 0.9 for fonts, and other programs will use 0.9. 2) Add a flag to use X's DPI to control chrome scale. The rest of the system/application (including chrome) uses GTK's scale. You'll have to specify command line flag to use this. 3) something else? Please let me know which fits your use case.
,
Oct 26 2016
Ah, my apologies. I'd read through the CL and got confused by the DSF references. I see what you're getting at, hmm. DPI *does* specify *scaling* in the general sense; not just for fonts, but for the whole UI. The complex (high-expense) but generally intuitive scenario would be allowing the UI font size to be controlled within chrome://settings/fonts, which would allow the X11 DPI to influence the whole program while also allowing user-settable UI font size. I can see why this hasn't been done: there would need to be some kind of UI font size reset switch, but figuring out where to put that is very nontrivial (commandline switch? The people who break it won't be able to use that. Reset on reinstall? Some users will get mad. Disallow font size below calculated value? Some user's desktop will be so broken the calculated value will be insane). In my use case, I'm looking for what might be described as "ALWAYS 100%-scaled chrome_100_percent.pak + arbitrarily controllable UI font size." That sums up my use case entirely. (In part because UI scaling looks utterly terrible at anything other than 100%, but that's a different story...) I just realized this: playing with X11's DPI doesn't cause GTK and Qt applications to scale, it just changes the font size - which, in apps that use layout containers for UI (which is everything now) instead of ye-old-WinAPI-style fixed coordinates, causes the UI to flow to accommodate the bigger fonts. The UI itself doesn't scale though, eg a button might become bigger in pixel height/width, but its theme graphics remain at the same scale, IOW they remain pixel perfect. This is obviously one of the major "Linux HiDPI" problems, and what I think device scaling factor is trying to fix (a la Android scalable UI). With this in mind, as a user who understands a bit about the [broken state of the] Linux desktop but is not directly affiliated with any of them, I'd pick your (3) and say this: - X11's DPI value has historically been for font size selection, not UI scaling. X11 will go away eventually (very-long-term), and we now have this new DSF value we can play with, which is attached to the latest work in scalable UI, which is being developed within a scope that will carry over to Wayland/Mir/others. So, to me, it makes sense to depend on the DSF for actual UI scaling, and just use the old DPI value for the font size: by the time X11 is gone, we'll all have >500PPI screens (or use browsers through 3D-rendered surfaces in VR?), so we will NEED scalable UI, and web browsers will be too complex to run on the systems attachable to low-PPI displays. Yay! - Using DPI to scale the fonts without the UI stays consistent with GTK/Qt's current (broken but understandable) model of font-scaling-without-(vector-style-)UI-scaling. I'm not sure when DPI support was introduced but I suspect GTK and Qt aren't the only toolkits that interpret the DPI solely as a font-specific setting. - Using DSF (which I'm 99% certain will require a settings daemon) keeps up with current desktop development and evolution to support device scaling. As an aside, my personal concern was that I would need to run a desktop settings daemon in order to use dconf to play with GNOME-specific font settings. Chrome hard-depends on udev on Linux, but udev is such a fundamental component that's okay, virtually nobody tries to run a desktop without udev. There _are_ a much bigger number of people who don't run a full DE, though, and hard-depending on a settings daemon (the underlying architecture used by GTK's font config tool) is going to cause a small amount of angry beeping from some users.
,
Oct 26 2016
> I just realized this: playing with X11's DPI doesn't cause GTK and Qt applications to scale, it just changes the font size Most programs ignores X dpi and won't change fonts. - X11's DPI value has historically been for font size selection, not UI scaling. X's DPI is hard-coded to 96 (but still can be changed via randr/X resources) for historical reasons, and it's not used to adjust UI/font scale. You may be confused with Xft.dpi, which is NOT X dpi (that you're changing with xrandr). gtk updates this value when gtk-xft-dpi changes, but most programs simply use gtk's value, but not this one. Adding additional settings is no-go because most people do not distinguish UI / font scaling, and we generally avoid adding settings for such minor use case. So my new question is: * "do you still want old behavior : when you do "xrandr -dpi 81", chrome uses smaller font" or * you're okay with "Set the gtk font scale (which is used to scale UI on linux desktop) to less than 1.0 to let chrome uses smaller font, while keeping UI scale to 1". sorry but your 3) option doesn't work for the reasons I explained above.
,
Oct 27 2016
> X's DPI is hard-coded to 96 (but still can be changed via randr/X resources) for historical reasons, and it's not used to adjust UI/font scale. You may be confused with Xft.dpi, which is NOT X dpi (that you're changing with xrandr). gtk updates this value when gtk-xft-dpi changes, but most programs simply use gtk's value, but not this one. Okay, I'm a little confused then. Please note that in the attached screenshots, the tab font size with 397169 is being influenced - I repeat, IS - by the command "xrandr --dpi 81", "xrandr --dpi 100", etc. I concede that something may be reading this value and influencing Xft.dpi or gtk-xft-dpi. I've found that have gconfd-2 running, so maybe that's reading the core X DPI value and then propagating it through GTK. I'm running a fairly stock Slackware 14.1 system (I need to upgrade to 14.2) with Openbox, FWIW. I was curious to find out where xdpyinfo is getting the DPI info from, and learned from https://cgit.freedesktop.org/xorg/app/xdpyinfo/tree/xdpyinfo.c#n467 that it's computing it from DisplayWidth() vs DisplayWidthMM() (same for height). Wow, X11 is worse than I thought... > Adding additional settings is no-go ... Totally understandable. I've only recently fully grasped the support impact of Chrome's enterprise-level installed user base, and how keeping the number of adjustable knobs to a minimum is critical. With your two options, I would totally pick the first one, to use xrandr --dpi to change the font size. DPI has historically been used to set font sizes on Linux, and I think (personally) that this stays consistent with that behavior. Thanks for taking the time to help me understand the situation and even ask me what my preference would be :)
,
Oct 27 2016
Chrime used to use X'dpi at one point, and that's probably what you've seen. Okay I'll talk to the reviewer and see if he's okay with 1)
,
Oct 27 2016
I think to rephrase the question slightly, instead of which one you prefer, is setting the gtk font scale impossible for you? From a code + maintenance perspective, I strongly prefer not adding support for X dpi. (Respecting gtk dpi for font size below 1.0x is well and good though.)
,
Oct 27 2016
Note that, as I mentioned in the CL, it will make other apps smaller. I'm fine if that's ok with the reporter though.
,
Oct 27 2016
> that it's computing it from DisplayWidth() vs DisplayWidthMM() (same for height). Wow, X11 is worse than I thought... That's the definition of DPI (=dots per inch), and xrandr modifies these values in X (which means it alters the actual meaning of DIP). In general, DPI isn't useful to determine UI/font scale, because UI/font scale depends on the display size, pixel density and distance, not just DPI.
,
Oct 27 2016
FWIW, Chrome appears to be starting gconfd-2 when it starts (I can't think of anything else that would cause it to start), and I *think* that's what handles setting/getting GTK settings like gtk-xft-dpi. @estrade: By "gtk font scale" do you mean Xft.dpi, gtk-xft-dpi, or something else? I must admit my confusion here. @oshima: If "it will make other apps smaller" means a similar result to what I get by playing with the DPI - smaller fonts, but unscaled UI - then I am completely fine with that. (Also, you're right about the DPI value; it's supposed to accurately reflect the screen size, not be an arbitrary slider to hack around with until everything "looks nice." (I just noticed the mentioned X11 calls in the CL...)) Also, while doing a bit of Googling to figure out what "gtk font scale" might mean, I stumbled on the fact that $ cat ~/.gtkrc-2.0 gtk-font-name = "Sans 8" allows me to arbitrarily adjust the font size in the tabs! This is a working FIX for my problem - it adjusts the UI font size similarly in the way that adjusting the DPI did; in fact I think it might be an identical fix because all GTK (and Chrome) does with the DPI is adjust the base font size! Right? I had absolutely no idea this was available, twas a bit of a "d'oh" moment when I discovered it because it makes perfect sense. Furthermore, I can even do something like `GTK2_RC_FILES=path/to/custom/gtkrc chromium` to isolate the font size change to Chrome if I wanted/needed to. So, for my part, I've discovered a knob I can play with that makes me happy. I don't mind how this particular bug gets fixed, although I'm happy to continue commenting on it, because I remain interested.
,
Nov 1 2016
> - smaller fonts, but unscaled UI It may or may not. It's up to app how to handle this (that is, it may still scale UI so that text will fit). You can try it yourself now and see if it's acceptable. (In my environemnt, it's in "System Settings -> Display has the scaling UI")
,
Nov 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a98afff3156eb88b39f82cfae23d99bed436bb3c commit a98afff3156eb88b39f82cfae23d99bed436bb3c Author: oshima <oshima@chromium.org> Date: Mon Nov 07 17:55:08 2016 Allow font to use below 1.0f scale * If the raw device scale factor is lower than 1.0, shrink the font size further. BUG= 646254 TEST=manual Review-Url: https://codereview.chromium.org/2441043002 Cr-Commit-Position: refs/heads/master@{#430311} [modify] https://crrev.com/a98afff3156eb88b39f82cfae23d99bed436bb3c/chrome/browser/ui/libgtkui/gtk_ui.cc [modify] https://crrev.com/a98afff3156eb88b39f82cfae23d99bed436bb3c/chrome/browser/ui/libgtkui/gtk_ui.h [modify] https://crrev.com/a98afff3156eb88b39f82cfae23d99bed436bb3c/chrome/browser/ui/views/chrome_browser_main_extra_parts_views_linux.cc [modify] https://crrev.com/a98afff3156eb88b39f82cfae23d99bed436bb3c/ui/views/linux_ui/linux_ui.h
,
Nov 8 2016
Could someone please help us with a sample test cases so that we will triage the issue further. Thanks in Advance.
,
Nov 11 2016
Test steps: 1) Set your font scale to 0.75 for your linux desktop (not chrome). On goobuntu, "System Settings" -> "Displays", then set the "scale for menu and title bars" to 0.75. 2) Start chrome The text in browser UI should be smaller.
,
Feb 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4ef351aa3467a587e03d8d19cdd9f280ab8fff4d commit 4ef351aa3467a587e03d8d19cdd9f280ab8fff4d Author: oshima <oshima@chromium.org> Date: Wed Feb 08 23:05:19 2017 Don't allow font scale to be lower than 1.0 Many people who're using lower font scale do not expect this behavior, so Let's revert this (logically) for now, and consider a solution for low scale font if necessary. BUG= 687770 , 646254 Review-Url: https://codereview.chromium.org/2680393002 Cr-Commit-Position: refs/heads/master@{#449124} [modify] https://crrev.com/4ef351aa3467a587e03d8d19cdd9f280ab8fff4d/chrome/browser/ui/libgtkui/gtk_ui.cc
,
Feb 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ff2efa3a0e3dd8e2ec8652da5cf08e9ac1e36153 commit ff2efa3a0e3dd8e2ec8652da5cf08e9ac1e36153 Author: Mitsuru Oshima <oshima@chromium.org> Date: Thu Feb 09 23:08:35 2017 Don't allow font scale to be lower than 1.0 Many people who're using lower font scale do not expect this behavior, so Let's revert this (logically) for now, and consider a solution for low scale font if necessary. BUG= 687770 , 646254 Review-Url: https://codereview.chromium.org/2680393002 Cr-Commit-Position: refs/heads/master@{#449124} (cherry picked from commit 4ef351aa3467a587e03d8d19cdd9f280ab8fff4d) Review-Url: https://codereview.chromium.org/2683653006 . Cr-Commit-Position: refs/branch-heads/2924@{#907} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [modify] https://crrev.com/ff2efa3a0e3dd8e2ec8652da5cf08e9ac1e36153/chrome/browser/ui/libgtkui/gtk_ui.cc
,
Feb 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8d5792c797a0850cefd3e1d6169caf2c390b97c9 commit 8d5792c797a0850cefd3e1d6169caf2c390b97c9 Author: Mitsuru Oshima <oshima@chromium.org> Date: Thu Feb 09 23:59:39 2017 Don't allow font scale to be lower than 1.0 Many people who're using lower font scale do not expect this behavior, so Let's revert this (logically) for now, and consider a solution for low scale font if necessary. BUG= 687770 , 646254 Review-Url: https://codereview.chromium.org/2680393002 Cr-Commit-Position: refs/heads/master@{#449124} (cherry picked from commit 4ef351aa3467a587e03d8d19cdd9f280ab8fff4d) Review-Url: https://codereview.chromium.org/2680933007 . Cr-Commit-Position: refs/branch-heads/2987@{#423} Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943} [modify] https://crrev.com/8d5792c797a0850cefd3e1d6169caf2c390b97c9/chrome/browser/ui/libgtkui/gtk_ui.cc
,
Feb 15 2017
Tested the issue on Ubuntu 14.04 using chrome beta version-57.0.2987.54 as per comment21 & followed below steps: 1.Set ubuntu display settings for Scale for Menu and title bars to 0.75 & click on apply 2.Observed only Menu and title bars size is changed as per the above adjustment 2.Set Fonts-Scaling factor as 0.75 in Tweaks 3.Observed font size in chrome is not changing Please find the attached screencast for reference & provide us the update on the same. Thanks!! |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by lightlyf...@gmail.com
, Sep 14 2016