Open
Bug 820679
(win-hidpi)
Opened 12 years ago
Updated 2 years ago
[tracking] [meta] support for hi-dpi display (resolution scale factors > 100%) on desktop (non-Metro) Windows
Categories
(Core :: Widget: Win32, defect)
Tracking
()
NEW
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?
Comment 2•12 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•12 years ago
|
Depends on: flash-hidpi
Comment 3•12 years ago
|
||
Could someone with rights please add Bug 594695 to the dependency list?
Comment 4•12 years ago
|
||
Pardon me, Bug 600207 is what I was looking for. (Bug 594695 appears to be fixed already.)
Reporter | ||
Comment 5•12 years ago
|
||
(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•12 years ago
|
Hardware: x86_64 → All
Version: 18 Branch → Trunk
Updated•12 years ago
|
Alias: win-hidpi
Comment 6•12 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.
Comment 7•12 years ago
|
||
Sorry for the bug spam, I see this is desktop only.
Updated•12 years ago
|
Updated•12 years ago
|
Depends on: hidpi-favicon-ui
Comment 8•12 years ago
|
||
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
Comment 9•12 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.
Comment 10•12 years ago
|
||
There's bug 854956 (already listed in the dependencies of this bug).
Comment 11•12 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•12 years ago
|
||
Comment 13•12 years ago
|
||
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•12 years ago
|
||
Comment 15•12 years ago
|
||
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•12 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•12 years ago
|
||
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•11 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.
Comment 19•11 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•11 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•11 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•11 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.
Comment 23•11 years ago
|
||
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•11 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.
Comment 25•11 years ago
|
||
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•11 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•11 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•11 years ago
|
||
Both Chrome and IE allow changing the default zoom level for all pages.
Comment 29•11 years ago
|
||
(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•11 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•11 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•11 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•11 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•11 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•11 years ago
|
||
I meant without changing devPixelsPerPx.
Comment 36•11 years ago
|
||
May I draw your attention to Bug 890445 and Bug 890383?
Updated•11 years ago
|
Depends on: australis-tabs-v2
Updated•11 years ago
|
Updated•8 years 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•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•