Last Comment Bug 820679 - (win-hidpi) [tracking] [meta] support for hi-dpi display (resolution scale factors > 100%) on desktop (non-Metro) Windows
(win-hidpi)
: [tracking] [meta] support for hi-dpi display (resolution scale factors > 100%...
Status: NEW
tpi:-
:
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: Trunk
: All Windows 7
: -- normal with 23 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 839091 (view as bug list)
Depends on: 248648 332275 852586 852963 hidpi-favicon-ui 857089 866365 878288 886198 895096 957307 982819 986010 australis-tabs-v2 1034929 1197497 1200887 1204375 1204376 1226905 1235582 1235834 1257103 1262398 1271810 600207 603880 818927 818935 818940 flash-hidpi 824386 828508 832524 843790 844604 844795 844846 844857 851952 852522 854135 854441 857061 857192 859266 861723 863992 865746 867818 869343 888781 890156 890374 894216 911409 946987 981673 1016543 1162441 1201829 1221174 1224732 1256195 1257071
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-11 20:25 PST by Robert O'Callahan (:roc) (email my personal email if necessary)
Modified: 2016-09-02 14:32 PDT (History)
46 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Taskbar preview problem at HiDPI (211.28 KB, image/png)
2013-04-02 05:29 PDT, Gary [:streetwolf]
no flags Details
Before and after scaling change (73.71 KB, image/png)
2013-04-13 19:23 PDT, Ray Satiro
no flags Details
Making 21 and 22 look the same (47.78 KB, image/png)
2013-04-14 12:29 PDT, Ray Satiro
no flags Details
Side-by-side comparison of Fx22, IE10, Chrome27 (394.18 KB, image/jpeg)
2013-06-25 19:59 PDT, Alex Lee
no flags Details

Description Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-11 20:25:02 PST
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 [Baboo] 2012-12-11 23:53:12 PST
(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?
Comment 2 Greg Edwards 2012-12-12 06:45:13 PST
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.
Comment 3 Greg Edwards 2012-12-12 07:10:58 PST
Could someone with rights please add Bug 594695 to the dependency list?
Comment 4 Greg Edwards 2012-12-12 07:17:55 PST
Pardon me, Bug 600207 is what I was looking for. (Bug 594695 appears to be fixed already.)
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-16 20:43:45 PST
(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.
Comment 6 Greg Edwards 2013-02-21 13:44:40 PST
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.
Comment 7 Jim Mathies [:jimm] 2013-02-25 07:29:12 PST
Sorry for the bug spam, I see this is desktop only.
Comment 8 Jonathan Kew (:jfkthame) 2013-03-26 11:34:29 PDT
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.
Comment 9 Gary [:streetwolf] 2013-04-02 04:46:58 PDT
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.
Comment 10 Jonathan Kew (:jfkthame) 2013-04-02 05:08:14 PDT
There's bug 854956 (already listed in the dependencies of this bug).
Comment 11 Gary [:streetwolf] 2013-04-02 05:24:47 PDT
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 Gary [:streetwolf] 2013-04-02 05:29:11 PDT
Created attachment 732281 [details]
Taskbar preview problem at HiDPI
Comment 13 Jonathan Kew (:jfkthame) 2013-04-02 06:12:11 PDT
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 Gary [:streetwolf] 2013-04-02 06:36:12 PDT
Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=857061
Comment 15 Ray Satiro 2013-04-13 19:23:16 PDT
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 Greg Edwards 2013-04-13 19:40:02 PDT
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 Ray Satiro 2013-04-14 12:29:10 PDT
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.
Comment 18 comethope 2013-05-31 05:16:49 PDT
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.
Comment 19 Greg Edwards 2013-05-31 13:59:14 PDT
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 comethope 2013-05-31 18:52:21 PDT
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 Greg Edwards 2013-05-31 19:22:23 PDT
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 comethope 2013-06-01 04:16:46 PDT
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.
Comment 23 Alex Lee 2013-06-25 19:59:29 PDT
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 Josh Tumath 2013-06-26 01:07:08 PDT
(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.
Comment 25 Jonathan Kew (:jfkthame) 2013-06-26 06:04:23 PDT
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?)
Comment 26 Rz666 2013-07-03 02:11:57 PDT
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 Greg Edwards 2013-07-03 07:07:41 PDT
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 Greg Edwards 2013-07-03 07:10:35 PDT
Both Chrome and IE allow changing the default zoom level for all pages.
Comment 29 Jonathan Kew (:jfkthame) 2013-07-03 07:38:30 PDT
(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.
Comment 30 comethope 2013-07-11 08:09:18 PDT
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 Greg Edwards 2013-07-11 08:18:04 PDT
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 comethope 2013-07-11 09:29:24 PDT
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 Greg Edwards 2013-07-11 09:41:45 PDT
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 comethope 2013-07-11 10:51:04 PDT
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 Greg Edwards 2013-07-11 11:46:03 PDT
I meant without changing devPixelsPerPx.
Comment 36 T.Rosenau 2013-07-24 15:35:20 PDT
May I draw your attention to Bug 890445 and Bug 890383?
Comment 43 :Gijs Kruitbosch 2014-09-30 07:34:23 PDT
*** Bug 1074871 has been marked as a duplicate of this bug. ***
Comment 44 Ian Thomas ('thelem') 2015-03-17 03:46:06 PDT
*** Bug 839091 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.