Open Bug 820679 (win-hidpi) Opened 11 years ago Updated 1 year ago

[tracking] [meta] support for hi-dpi display (resolution scale factors > 100%) on desktop (non-Metro) Windows

Categories

(Core :: Widget: Win32, defect)

All
Windows 7
defect

Tracking

()

People

(Reporter: roc, Unassigned)

References

(Depends on 18 open bugs)

Details

(Keywords: meta, Whiteboard: tpi:-)

Attachments

(4 files)

Setting layout.css.devPixelsPerPx to -1.0 in all.js will do the trick, but there are bugs we'll have to fix first.

For one thing, all Firefox UI will have to have artwork for the common Windows font DPI scale factors (1.25, 1.5). (Some of this may already exist.) We may also wish to modify nsWindow::GetDefaultScaleInternal to limit the value to 1, 1.25 or 1.5 to avoid our UI looking terrible if someone has chosen a different DPI.

There are probably other bugs too.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #0)
> We may also wish to modify nsWindow::GetDefaultScaleInternal to
> limit the value to 1, 1.25 or 1.5 to avoid our UI looking terrible if
> someone has chosen a different DPI.

Wouldn't it only look terrible if scaled up? So say someone has a factor between 1.25 and 1.5 wouldn't taking the artwork for the larger factor and scaling it down be an option?
Depends on: 818940
Depends on: 818935
Depends on: 818927
Please add 2.0x to that list for the sake of Retina Mac owners. (Windows 7 does in fact offer 200% as an option in the Set custom text size (DPI) dialog.) 

The worst that could happen if the user sets a non-conventional DPI is icons looking a little fuzzy. I agree with [Baboo] that choosing the artwork from the next scale up will look fine. (For that matter, using 1.5x artwork for x1.25 would probably turn out alright.) WPF applications already scale to whatever DPI the user has chosen, at the cost of displaying fuzzy icons. Non-conventional DPIs should be rare enough as it is.
Depends on: flash-hidpi
Could someone with rights please add Bug 594695 to the dependency list?
Pardon me, Bug 600207 is what I was looking for. (Bug 594695 appears to be fixed already.)
Depends on: 600207
(In reply to [Baboo] from comment #1)
> Wouldn't it only look terrible if scaled up? So say someone has a factor
> between 1.25 and 1.5 wouldn't taking the artwork for the larger factor and
> scaling it down be an option?

It would probably look bad (fuzzy).

Sure, it would be tolerable for many users, but based on past experience I'd expect a lot of users to explode in incoherent rage.
Hardware: x86_64 → All
Version: 18 Branch → Trunk
Depends on: 832524
Alias: win-hidpi
Depends on: 843790
Bug 843790 is a very good example why we should turn on HiDPI for Windows right away. We are well past the point where there are now more bugs by keeping the setting turned off than there are by turning it on.
Depends on: 844604
Depends on: 844795
Depends on: 844846
Blocks: 833192
Blocks: 833195
Sorry for the bug spam, I see this is desktop only.
No longer blocks: 833192, 833195
Depends on: 844857
Depends on: 824386
Depends on: 851952
Depends on: 852522
Blocks: 852586
No longer blocks: 852586
Depends on: 852586
Depends on: 854135
Depends on: 828508
Tracking the Windows HiDPI situation is a bit messy at the moment. To try and clarify things, I'm morphing this bug from "turn on HiDPI..." to a more general tracking bug for Windows HiDPI issues; we have in fact turned on the basic HiDPI support already in bug 844604, as that is how we get correctly-sized text.

As such, there's no actual patch to be landed here; this is just a place to track HiDPI-related issues.

For specific -regressions- that arise from enabling HiDPI, we should file them as blocking bug 844604 (where the preference was switched); and if we need to back out the change until regressions are addressed, that's the place to do it.
Summary: [tracking] turn on HiDPI for non-Metro Windows by default → [tracking] support for hi-dpi display (resolution scale factors > 100%) on desktop (non-Metro) Windows
Depends on: 854441
Is there a bug fixing the icons on things like the bookmark toolbar, sidebar history and bookmarks, etc.?  Tabs icons are much better now, btw.
There's bug 854956 (already listed in the dependencies of this bug).
Thanks Jonathon.  I looked at the dependencies and couldn't find a problem I am having with taskbar preview under W8.  When I am in Fx and hover over the Fx icon and then hover hover the thumbnail it appears almost as another smaller window on top of the real one and seems to be at 96dpi although I'm at 120dpi.  I don't want to file a bug if there is already one.
That's kinda weird. I haven't seen anything like that, but I'm currently testing under Win7; will try Win8 again later. Please file a separate report for it.

(That's generally the best strategy, if you can't find an existing bug on file. It's much easier for us to close a few duplicates if necessary than to keep track of multiple issues in a lengthy bug that ends up going in several directions. Just mark the report as blocking win-hidpi and it'll show up here as a dependency.)
Depends on: 857061
Depends on: 857089
Depends on: 857192
Depends on: 859266
I've poked around some of the other threads about this change but I can't find a way to disable the new behavior. Is there a way? Attached find a comparison of the way 21.0a2 and 22.0a2 look on my Windows 7 computer. My display preference is set at 125% (120 dpi).

I much prefer the way Firefox looked prior to the change. I tried setting layout.css.devPixelsPerPx to 1.0 but that seems to ignore my Windows font sizes (set via Advanced appearance settings).

It would be nice if there could be an option to revert to the old behavior. Thanks
I think the implementation of Bug 852522 removed the old behaviour, unfortunately.

You can come pretty close to simulating the old behaviour by using NoSquint to zoom out the pages back to their old size. Icons and stuff will still be big. Assuming hires icons are added before Firefox 22 is released, this shouldn't be much of a problem.
Thanks Greg. I installed the add-on 'Theme Font & Size Changer' and changed the font size to compensate for that. It's not perfect because a blanket font size change also changes it in some places where I don't want it changed. Good enough though.

re NoSquint, because I have set layout.css.devPixelsPerPx to 1 it appears I can preserve my current site preferences just as they were in 21. For now anyway. There's an open issue at https://github.com/jtackaberry/nosquint/issues/75 . One way to go would be some change to get the default scale and then it can calculate and scale up/down the difference so that when you specify, say, 135% you'll get the same view just as in earlier versions of Firefox.
Depends on: 861723
Depends on: 863992
Depends on: 865746
Depends on: 866365
Depends on: 867818
Depends on: 868704
Depends on: 869343
No longer depends on: 868704
I also have a problem there is no easy or efficient way to adjust to this new configuration. The webpage text size is routinely configurable, but my new big and fuzzy toolbars are horrid. The possibility of researching yet another addon to revert this is not great. 
   
Allowing the UIs DPI to be set as a user preference would be most considerate.
Depends on: 878288
I would venture that fuzzy icons are the only major problem with the new scaling behaviour? I created Bug 878288 to discuss creating a higher resolution icon set--something that really should be done anyway. Reverting to the old behaviour is a stop-gap and unsustainable in the long run as resolutions keep increasing.

Favicon issues are covered in Bug 854956.
In my own case i prefer a more compact UI size for webrowser also, which ff21 had on my system. 

Different versions of windows are hard to customise visually so i happen to run with higher dpi for making certain dialogues easy to read, but with commonly used programs like firefox, their toolbars are busy and dont need to be "read", just "spotted" so it can be better for them to be compact. In my case it is important and I have to stick with ff21 for it. 

As a visual themeing issue it would just be very much preferable for this UI dpi size to be configurable rather than dictate the OS global value is the only sensible option - which is what not providing a pref to set it, does here.
You can change the UI scale by going to about:config, and finding the pref called layout.css.devPixelsPerPx and set it to 1.0 to make everything smaller.

If you're on Windows 8, there's an option in Display Properties to make text bigger without changing the DPI. This seems to be more like how you want your programs to behave.

By changing Windows DPI settings, you're telling Windows you want to scale everything up by some factor. It's like changing screen resolutions only things stay sharp. A 1920x1080 screen at 150% should behave similarly to a 1280x720 screen. (Unfortunately for Microsoft, they left it to app developers to implement this scaling, to varying degrees of success. Firefox 21 was one such failure.)

I'm not aware of any other programs that have an option to change their size like what you're asking for. I'm not sure why you think Firefox should have this special option. (which it does anyway, see above)
Thanks i didnt understand layout.css.devPixelsPerPx mentioned earlier. It is exactly what i want. Not to pester this thread more - Ill just say i think many people will be looking for this setting when the main release changes.
Depends on: 886198
What are a web developer's options in dealing with Fx22 scaling content in certain common setups?
I've attached how our site looks in a side-by-side comparison of Firefox with a brand new profile, IE10 and Chrome 27, on a Win7 machine with default (125% DPI scaling) settings. As you can see, the content in Fx22 scales where they should not.
(In reply to Alex Lee from comment #23)
> Created attachment 767563 [details]
> Side-by-side comparison of Fx22, IE10, Chrome27
> 
> What are a web developer's options in dealing with Fx22 scaling content in
> certain common setups?
> I've attached how our site looks in a side-by-side comparison of Firefox
> with a brand new profile, IE10 and Chrome 27, on a Win7 machine with default
> (125% DPI scaling) settings. As you can see, the content in Fx22 scales
> where they should not.

There is a strange behaviour at 125% DPIs on Windows where many applications that do not fully support high-DPIs are not scaled. In the case of IE, it chooses to lower all Web pages' DPIs to 100% by default. In the case of Chome, it has no support for high-DPIs at all on Windows (except that Windows does Windows XP-style scaling where it increases the font size in Chrome's chrome to 125%).

If you want Firefox to use IE's strange behaviour for screens at 125% DPIs, you should file a new bug.
In my testing, at least, on a Windows system with 125% DPI scaling, both IE10 and Chrome will load your site *by default* with the page zoom at "125%", with the result that the size matches Firefox's (new) default view. I suspect you have at some point zoomed out to "100%" zoom, and that's why you see a difference.

(In IE10, if you press Ctrl-0 to explicitly reset the zoom factor to its default, how does the page look?)
Depends on: 888781
FFS, implement the option in about:config to use the old GUI scaling method instead of this new ****.
I've been using FF for years now and this is the worst update I've ever seen and enough reason for me to switch to other browsers if this won't be fixed.
My suggestion:
1. Back out Bug 852522. (This is where "FF21 style" scaling got removed.)
2. Include default zoom level in Options. (like a simplified NoSquint built in)
3. Show zoom levels in device pixels.
4. Implement Bug 878288.

#2 and #4 are probably the most important since "fuzzy UI" and "pages not at 100%" are the leading complaints.
Both Chrome and IE allow changing the default zoom level for all pages.
(In reply to Greg Edwards from comment #27)
> My suggestion:
> 1. Back out Bug 852522. (This is where "FF21 style" scaling got removed.)

As I understand it, that would leave us with increasingly-bad UI breakage, at least for anyone who tinkers with the devPixelsPerPx setting. The point of bug 852522 was to apply scaling factors more consistently across the entire browser.

> 2. Include default zoom level in Options. (like a simplified NoSquint built
> in)

Personally, I'd have no issue with that, but such a feature would be a Firefox UX decision. Maybe you could file a separate bug asking for it, if there isn't one already?

> 3. Show zoom levels in device pixels.

A page displayed at "100% zoom" should be at the appropriate size for normal reading (such that there are roughly 96 CSS px to the physical inch, when viewed on a desktop monitor typically viewed at arm's length - devices with much different form factors, such as phones or projectors, will of course have different "normal" sizes).

Although I know some people seem to want zoom levels defined in terms of device pixels at present, I don't think it's a good long-term direction. As resolution increases, the "zoom level" needed to make a page comfortably readable would also increase, which I think is an unnatural situation. Do we want to find ourselves in 2020 having to display pages at "800% zoom" by default in order to make text readable?

> 4. Implement Bug 878288.

Yes. Also bug 854956, which I think contributes significantly to the "fuzzy UI" perception.
Depends on: 890156
Depends on: 890374
FF22 has set the gui font size in accordance with devPixelsperPx. This causes problems with my firefox configuration. Is there a current about:config setting to alter gui font scale?

As i see it the following things are changing here, to be in line with better default standards:
Gui Font scale
Gui Icon scale
Webpage Font scale

Whatever is changing, i think it is important to have a setting for users who have already configured their systems for specific preferences - to keep their preferred configuration (revert or tweak new default settings) - and not be forced to roll back ff version, or forced to 'correct' OS settings (with all the side effects implied ) The ideal defaults are worth straightening out, but existing users configurations are worth consideration also.
UI font size: https://addons.mozilla.org/en-US/firefox/addon/theme-font-size-changer/
Webpage font size: https://addons.mozilla.org/en-US/firefox/addon/nosquint/

There's no way to change the icon size yet but you can achieve the same effect with devPixelsPerPx and the other two addons.
Thanks Greg. Im going to stick with ff 21 for a while, maybe configure these sizes myself when i learn how to program chrome. 

Ideally, i believe, these changes would have observed what users current configuration is and altered internal about:config settings by the difference to maintain their configuration on update. But these surprise changes - icon size change with ff21 and now gui font scale with ff21, should at least have considered users familiarity (and perhaps previous config work), by including simple options to revert them. 

I dont say this in anger, im happy to stick with 21 on this system for a while. I think there is an occasion here to think about whether changes towards _ideal_defaults_ in a program mandate developement to force non-ideal default users to 'correct' system wide settings or just put up with possibly undesired _change_.
The GUI font size should match FF21. Everything else grew up around it but it should stay the same.

I agree that the default zoom shouldn't have changed with the upgrade to FF22. (That was kind of the goal with Bug 851520 and Bug 858185 but I guess their strategy didn't go as planned.) A default zoom setting should really be added ASAP (as in Chrome) and it needs to contain 66.6667%.
Interesting - On my system the Gui font size (menus and tabs) goes very small in ff22 with devPixelsPerPix set to 1. On ff21 fonts seem unaffected by ~devPPP.
I meant without changing devPixelsPerPx.
Depends on: 892888
Depends on: 894216
May I draw your attention to Bug 890445 and Bug 890383?
Depends on: 957307
Depends on: 966017
Depends on: 981673
Depends on: 982819
No longer depends on: 966017
Depends on: 911409
Depends on: 986010
Depends on: 332275
No longer depends on: 892888
Depends on: australis-tabs-v2
See Also: → linux-hidpi
Depends on: 1016543
Depends on: 1034929
Depends on: 852963
Depends on: 248648
Depends on: 1256195
Depends on: 1257071
Depends on: 1257103
Depends on: 1262398
Depends on: 1271810
Summary: [tracking] support for hi-dpi display (resolution scale factors > 100%) on desktop (non-Metro) Windows → [tracking] [meta] support for hi-dpi display (resolution scale factors > 100%) on desktop (non-Metro) Windows
Whiteboard: tpi:-
Depends on: 1162441
Depends on: 1271838
Depends on: 1336396
Depends on: 1391209
No longer depends on: 1391209
Depends on: 1412975
Depends on: 1327324
No longer depends on: 1412975
Depends on: 1450566
Depends on: 1339799
Depends on: 1246126
Severity: normal → S3
Depends on: 1666626
You need to log in before you can comment on or make changes to this bug.