Bug 820679 (win-hidpi)

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

NEW
Unassigned

Status

()

Core
Widget: Win32
5 years ago
5 months ago

People

(Reporter: roc, Unassigned)

Tracking

(Depends on: 26 bugs)

Trunk
All
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:-)

Attachments

(4 attachments)

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.

Comment 1

5 years ago
(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?

Updated

5 years ago
Depends on: 818940

Updated

5 years ago
Depends on: 818935

Updated

5 years ago
Depends on: 818927

Comment 2

5 years ago
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.

Updated

5 years ago
Depends on: 820831

Comment 3

5 years ago
Could someone with rights please add Bug 594695 to the dependency list?

Comment 4

5 years ago
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.

Updated

5 years ago
Hardware: x86_64 → All
Version: 18 Branch → Trunk

Updated

5 years ago
Depends on: 832524

Updated

4 years ago
Alias: win-hidpi

Updated

4 years ago
Depends on: 843790

Comment 6

4 years ago
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.

Updated

4 years ago
Depends on: 844604

Updated

4 years ago
Depends on: 844795

Updated

4 years ago
Depends on: 844846

Updated

4 years ago
Blocks: 833192

Updated

4 years ago
Blocks: 833195

Comment 7

4 years ago
Sorry for the bug spam, I see this is desktop only.
No longer blocks: 833192, 833195

Updated

4 years ago
Depends on: 844857

Updated

4 years ago
Depends on: 824386

Updated

4 years ago
Depends on: 851952
Depends on: 852522

Updated

4 years ago
Blocks: 852586

Updated

4 years ago
No longer blocks: 852586
Depends on: 852586

Updated

4 years ago
Depends on: 854135
Depends on: 828508
Depends on: 854956
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

Comment 9

4 years ago
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).

Comment 11

4 years ago
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.

Comment 12

4 years ago
Created attachment 732281 [details]
Taskbar preview problem at HiDPI
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.)

Comment 14

4 years ago
Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=857061
Depends on: 857061

Updated

4 years ago
Depends on: 857089

Updated

4 years ago
Depends on: 857192
Depends on: 859266

Comment 15

4 years ago
Created attachment 737199 [details]
Before and after scaling change

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

Comment 16

4 years ago
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.

Comment 17

4 years ago
Created attachment 737297 [details]
Making 21 and 22 look the same

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.

Updated

4 years ago
Depends on: 861723

Updated

4 years ago
Depends on: 863992

Updated

4 years ago
Depends on: 865746

Updated

4 years ago
Depends on: 866365

Updated

4 years ago
Depends on: 867818

Updated

4 years ago
Depends on: 868704

Updated

4 years ago
Depends on: 869343
No longer depends on: 868704

Comment 18

4 years ago
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.

Updated

4 years ago
Depends on: 878288

Comment 19

4 years ago
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.

Comment 20

4 years ago
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.

Comment 21

4 years ago
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)

Comment 22

4 years ago
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.

Updated

4 years ago
Depends on: 886198

Comment 23

4 years ago
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.

Comment 24

4 years ago
(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?)

Updated

4 years ago
Depends on: 888781

Comment 26

4 years ago
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.

Comment 27

4 years ago
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.

Comment 28

4 years ago
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

Updated

4 years ago
Depends on: 890374

Comment 30

4 years ago
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.

Comment 31

4 years ago
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.

Comment 32

4 years ago
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_.

Comment 33

4 years ago
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%.

Comment 34

4 years ago
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.

Comment 35

4 years ago
I meant without changing devPixelsPerPx.
Depends on: 892888
Depends on: 894216
Depends on: 895096

Comment 36

4 years ago
May I draw your attention to Bug 890445 and Bug 890383?

Updated

4 years ago
Depends on: 957307
Depends on: 966017

Updated

3 years ago
Depends on: 981673

Updated

3 years ago
Depends on: 982819
Depends on: 946987

Updated

3 years ago
No longer depends on: 966017

Updated

3 years ago
Depends on: 911409

Updated

3 years ago
Depends on: 986010

Updated

3 years ago
Depends on: 332275
No longer depends on: 892888
Depends on: 995733
See Also: → bug 967100
Depends on: 1016543
Depends on: 1034929

Updated

3 years ago
Duplicate of this bug: 1074871
Depends on: 852963
Depends on: 248648

Updated

2 years ago
Duplicate of this bug: 839091

Updated

a year ago

Updated

a year ago
Depends on: 1256195

Updated

a year ago
Depends on: 1257071

Updated

a year ago
Depends on: 1257103

Updated

a year ago
Depends on: 1262398
Depends on: 1271810

Updated

11 months ago
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:-

Updated

10 months ago
Depends on: 1162441
Depends on: 1271838

Updated

5 months ago
Depends on: 1336396
You need to log in before you can comment on or make changes to this bug.