Last Comment Bug 851268 - Content and chrome changes size if Windows DPI is >96
: Content and chrome changes size if Windows DPI is >96
Status: RESOLVED INVALID
: dogfood, regression
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: 22 Branch
: x86_64 All
: -- normal with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 852093 873738 890202 890300 890522 890612 890737 891295 891331 891955 892337 893722 923987 925668 980338 (view as bug list)
Depends on:
Blocks: 844604
  Show dependency treegraph
 
Reported: 2013-03-14 13:12 PDT by Gary [:streetwolf]
Modified: 2014-03-06 09:36 PST (History)
40 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
-


Attachments
Too large and graphics are blurry. (48.35 KB, image/png)
2013-03-14 16:53 PDT, Gary [:streetwolf]
no flags Details
Fx22 vs. IE10. (921.46 KB, image/jpeg)
2013-03-16 10:06 PDT, Gary [:streetwolf]
no flags Details
Behaviour of stable releases of IE, Chrome, and Firefox on 200% (192) (956.63 KB, image/jpeg)
2013-03-16 16:37 PDT, Greg Edwards
no flags Details
Different DPI's (57.29 KB, image/png)
2013-03-16 17:21 PDT, Gary [:streetwolf]
no flags Details
150% DPI Settings make the Firefox options panel way too large (284.08 KB, image/jpeg)
2013-03-17 04:08 PDT, xyz
no flags Details
FX22 and IE10 at an OS DPI of 125% (1.84 MB, image/png)
2013-03-18 11:17 PDT, Gary [:streetwolf]
no flags Details
FX22 and IE10 at an OS DPI of 150% (2.07 MB, image/png)
2013-03-18 11:18 PDT, Gary [:streetwolf]
no flags Details

Description Gary [:streetwolf] 2013-03-14 13:12:16 PDT
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0
Build ID: 20130314030914

Steps to reproduce:

Nothing.


Actual results:

DPI of content and chrome has increased due to 20130314052213
http://hg.mozilla.org/mozilla-central/rev/96af92fa87fd. 

Only happens when DPI in the OS is >96.  The higher the OS DPI is the more noticeable the problem in Fx.


Expected results:

Content and chrome DPI should not change.
Comment 1 Gary [:streetwolf] 2013-03-14 13:13:09 PDT
STR should be change Windows DPI to 120.
Comment 2 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2013-03-14 13:16:45 PDT
Please don't modify the Priority field if you're not the owner, module owner, or other appropriate authority.

Could you describe the bug you're seeing?  "Steps to reproduce: Nothing" isn't useful.  What did you do and what are you seeing?

And if you know a regression range, please give both ends of the range, rather than one end.
Comment 3 Gary [:streetwolf] 2013-03-14 13:21:20 PDT
OK  ---> 20130314030914
http://hg.mozilla.org/mozilla-central/rev/b672877ed046

Bad ---> 20130314052213
http://hg.mozilla.org/mozilla-central/rev/96af92fa87fd 

Set OS DPI to nothing above 96 (recommend 120 or higher to really notice it).  Everything in the content and chrome is larger in size. I can't recall Fx ever changing sizes based on the OS DPI.
Comment 4 Gary [:streetwolf] 2013-03-14 13:22:58 PDT
wish you could edit previous comments.  Set OS DPI to 'nothing' should be 'anything'.
Comment 5 Jim Jeffery not reading bug-mail 1/2/11 2013-03-14 13:37:32 PDT
On win7 x64 
1.  Right-click desktop and choose Screen resolution
2.  Click on link to make items larger or smaller
3.  select 125% Medium
4.  Install latest hourly and note the huge display of fonts on web-pages.

Using hourly m-c build cset:
https://hg.mozilla.org/mozilla-central/rev/96af92fa87fd
Comment 6 Gary [:streetwolf] 2013-03-14 13:42:39 PDT
It's not just fonts on web pages it's also increased font size in the chrome.  Also chrome icons are bigger like bookmarks and other buttons.
Comment 7 Jim Jeffery not reading bug-mail 1/2/11 2013-03-14 13:47:42 PDT
Perhaps caused by https://bugzilla.mozilla.org/show_bug.cgi?id=844604 ?
Comment 8 Jim Jeffery not reading bug-mail 1/2/11 2013-03-14 14:09:14 PDT
Good m-i: 20130313040337 cf4112d50b68
Bad: m-i: 20130313043837 281971e111cd

Confirming regresses by bug 844604
Comment 9 Greg Edwards 2013-03-14 14:53:39 PDT
What?
How is this not the intended effect? You click an option in Windows named "make items larger" and it ... makes items larger.
The previous behaviour was the bug. Please, for the love of ****, read Bug 844604!

On every other platform on the planet, web browsers scale their content to match the pixel density of the device. As pixel densities continue to soar (see: Retina MacBook Pro, Chromebook Pixel, Surface Pro), the old way of making everything get smaller becomes stupid and unusable. Stop living in the past. If you don't like the "bigness", set Windows back to 96DPI.
Comment 10 Gary [:streetwolf] 2013-03-14 15:37:19 PDT
Have you even seen the problem Greg?  Your reasoning is incorrect as it relates to a desktop PC.
Comment 11 Gary [:streetwolf] 2013-03-14 15:41:58 PDT
There is a new pref that controls the size... layout.css.devPixelsPerPx.  It defaults to -1.  Changing it to 1 makes things right again.
Comment 12 Gary [:streetwolf] 2013-03-14 15:52:39 PDT
IMO this is one of those things that is not equal among all platforms.  While it might be OK for a Tablet it is not OK for a Desktop PC.  As an aside Quicken for Windows 2013 took this same approach, cover all platforms, and the fonts are huge on a desktop PC.
Comment 13 Jonathan Kew (:jfkthame) 2013-03-14 16:01:04 PDT
If you want small fonts on a desktop PC with a large/high-res monitor, set the Windows resolution option accordingly. Why should Firefox -not- respect what is supposed to be a system-wide setting to adjust the default sizes of fonts and other elements on the display?

FWIW, with this change, the default size of web pages displayed on my Win7 machine (where the default scale factor is 125%) now matches the default in IE, whereas previously Firefox displayed pages at a significantly smaller size.
Comment 14 Gary [:streetwolf] 2013-03-14 16:08:20 PDT
So why does every application display the same size text except for Fx with this patch?  96 DPI is to small.  120 DPI (125%) is just right for every application I use. 

I'm sorry but you have not grasped totally what this patch is doing.
Comment 15 Gary [:streetwolf] 2013-03-14 16:11:49 PDT
From what I remember IE defaults to a full page zoom of 120% so that's why things are larger not because of Windows DPI
Comment 16 Gary [:streetwolf] 2013-03-14 16:20:04 PDT
OK... let me detract some of what I said.  The patch does indeed work fine for content.  I was running with a zoom level of 120% in Firefox which just got added to Windows DPI of 125% producing large fonts and graphics.  Setting my zoom to 100% in Firefox now displays content fine.

However the patch also affects the UI so that all the UI buttons are too large and blurry.  The sidebars also have add space between lines.

T
Comment 17 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2013-03-14 16:25:21 PDT
Are Windows native theme drawing and perhaps Windows system fonts code correctly handling devPixelsPerPx being non-1?  Use of native theme and system fonts should yield the system sizes, not the system device pixel sizes scaled to CSS pixels.
Comment 18 Gary [:streetwolf] 2013-03-14 16:28:42 PDT
To add... Graphics in content are also blurry with the patch.  At least for those graphics that are at a low resolution.
Comment 19 Jonathan Kew (:jfkthame) 2013-03-14 16:36:24 PDT
(In reply to Gary [:streetwolf] from comment #16)
> OK... let me detract some of what I said.  The patch does indeed work fine
> for content.  I was running with a zoom level of 120% in Firefox which just
> got added to Windows DPI of 125% producing large fonts and graphics. 
> Setting my zoom to 100% in Firefox now displays content fine.

OK, that sounds exactly as expected. You -shouldn't- have to change the default zoom in Firefox in order to get properly-sized web content; the fact that you had to until now was the bug.

> However the patch also affects the UI so that all the UI buttons are too
> large and blurry.  The sidebars also have add space between lines.

Could you attach a screenshot showing an example of what you're referring to here? The UI looks reasonable to me on my system. (Certainly some elements may be blurry due to bitmap scaling. But the scaling should be correct, AFAIK.)
Comment 20 Gary [:streetwolf] 2013-03-14 16:52:11 PDT
My observations regarding this change.

1.  UI is increased in size making UI graphics larger and blurry.  Buttons are usually 16x16 but due to using the OS DPI they are now greater than 16x16 and blurry.  Attachment will be included to show this.

2.  I still have to use text and page zoom on many sites to get the text and graphics looking correct.  Text not too small and graphics not blurry.  nbcnews.com is a good site to show this.  I had to do the same thing before the patch.  I use NoSquint addon which lets me change text and page zoom together.  Now I have to start at values less than 100% to account for the OS DPI.
Comment 21 Gary [:streetwolf] 2013-03-14 16:53:27 PDT
Created attachment 725167 [details]
Too large and graphics are blurry.

Too large and graphics are blurry.
Comment 22 Gary [:streetwolf] 2013-03-14 16:54:48 PDT
screenshot I attached doesn't show the blurry buttons as blurry as they really are.
Comment 23 Gary [:streetwolf] 2013-03-14 18:13:28 PDT
IMO Bug 844604 is not ready for prime time.  For those running at 96 DPI it might be fine, but for those of us running higher there are too many things not displaying correctly.  Sidebar text has to much space between entries, text is too large in some menus especially in addons, and blurry gui graphics to name a few.

For now I am setting 'layout.css.devPixelsPerPx' to 1.  Are there any other values for this pref?
Comment 24 Jonathan Kew (:jfkthame) 2013-03-15 04:40:43 PDT
(In reply to Gary [:streetwolf] from comment #23)
> IMO Bug 844604 is not ready for prime time.  For those running at 96 DPI it
> might be fine, but for those of us running higher there are too many things
> not displaying correctly.

Just wondering, have you tried -disabling- all add-ons etc that you have installed, or (better) running with a fresh, empty profile? I don't seem to be seeing all the things you're describing...

>  Sidebar text has to much space between entries,

Specific example with screenshot, please?

> text is too large in some menus especially in addons,

Specific example with screenshot, please?

> and blurry gui
> graphics to name a few.

We know bitmap GUI elements will be blurry, until we have larger bitmaps in place. (E.g. see bug 844795.)
Comment 25 Jim Jeffery not reading bug-mail 1/2/11 2013-03-15 05:28:31 PDT
I wasn't too happy with this change either, but after spending some time and doing some side-by-side compares with IE 10 & Chrome dev version I've come to the conclusion that this change is likely OK, and that we 'end users' have for a long time been manually working around the 'size issue' in Firefox for so long we've come to accept it as OK and that adjustments are/were needed for older eyes.  (I'm 65)

While I have been running the system at 125% for yrs now since my tired eyes and my 22 inch monitor did not like the tiny over-all font size, thus the running at 125% as 'my default' settings. 

I came to further realize that in addition to the 125% setting on the system, some web-pages in Firefox needed a couple of Ctrl+ +'s to get it readable for me.

Now with this patch I set the pages back to what now appears to the 125% system setting and doing some side-by-side compares to Chrome/IE10/Nightly I can see NO difference between browsers.

I set Chrome to 125% with its zoom setting.
IE 10 respects the system setting of 125% and now with this patch so does Firefox.

See side-by-side compare on my machine, win7 x64 Hd3200 video-chipset AMD/ATI:
http://i.imgur.com/dN31XYq.jpg

For myself, I believe this will eventually resolve as INVALID.
Comment 26 Gary [:streetwolf] 2013-03-15 05:40:19 PDT
Jonathan.

Tried things with a new profile and some of my complaints don't show up like extra spacing in the sidebar and in about:config.  Probably I see this because of an addon which opens up the possibility that add-ons will have to take into account this new way of determining DPI.

Also, I bet there are many folks that use the Zoom feature and will be in for a shock, as I was, when they start using this patch and see everything as HUGE.  Perhaps the default pref should be 1 instead of -1?

How do you plan to address icons like bookmarks in the Chrome?  Most are low resolution and scale up blurry when the OS DPI is high like 120.  IMO these icons should not be scaled up.  Even icons like the forward/back buttons are to large and fuzzy as well as the built in buttons like Home etc.  Tabs are much wider too.

It seems a lot of sites still assume the user is running at 96dpi and create their sites around this.  With the advent of widescreen monitors running at 96DPI is not an option as everything in Windows is way to small to view comfortably.

In a nutshell using the OS DPI is OK for content but you need to look at using it for the chrome portion.
Comment 27 Gary [:streetwolf] 2013-03-15 05:53:18 PDT
Jim:

You have no problem with the blurry icons on your toolbar and the fact that their increased size takes up more real estate as does everything on top?

I always hated this in IE.  Just because IE does it doesn't mean FX has to.  IMO IE (and Fx now) get's it wrong as far as the chrome portion goes.
Comment 28 Gary [:streetwolf] 2013-03-15 05:55:28 PDT
Just a thought... How about a zoom feature for the chrome portion of Fx?  This way I can downscale so things are not blurry as well as fixing other chrome components.
Comment 29 Gary [:streetwolf] 2013-03-15 06:11:22 PDT
btw... I'm using a 24" monitor.  Size matters in this case.
Comment 30 Jim Jeffery not reading bug-mail 1/2/11 2013-03-15 06:21:59 PDT
(In reply to Gary [:streetwolf] from comment #27)
> Jim:
> 
> You have no problem with the blurry icons on your toolbar and the fact that
> their increased size takes up more real estate as does everything on top?
> 
> I always hated this in IE.  Just because IE does it doesn't mean FX has to. 
> IMO IE (and Fx now) get's it wrong as far as the chrome portion goes.

As you can see from the screen shots, the few icons I have are just a bit blurry, but not enough to be of concern to me, at least.  I'm more sensitive to readability of text and content that looking at icons.  I also don't use the menu bar, nor the bookmarks toolbar, I just use the awesomebar for almost everything these days.
Comment 31 Gary [:streetwolf] 2013-03-15 06:33:03 PDT
Well... there you go.  It looks good to you because you don't use the bookmark toolbar. My only gripe is the way the chrome appears.
Comment 32 Jonathan Kew (:jfkthame) 2013-03-15 06:39:25 PDT
Don't other applications scale their user interface in response to the Windows resolution settings? Certainly looks that way to me - everything about Windows Explorer (menus, icons, window chrome, etc) is enlarged when I set Windows to 150%. Likewise other applications, from Notepad to MS Word. (I even see some poorly-scaled bitmap icons in the Word UI, where larger versions of the resource clearly weren't provided.)

AFAICS, we're doing the right thing. Of course we need to provide larger graphics, to avoid the need to up-scale 16x16 icons, etc., but to suggest that we -shouldn't- scale the Firefox UI in response to the Windows resolution seems ... odd.
Comment 33 Gary [:streetwolf] 2013-03-15 07:17:49 PDT
I do think you are doing the right thing Jonathan.  In fact when I fist started using Fx3 I questioned how come Fx didn't honor the OS DPI setting.

I just don't like the blurry chrome icons.  Since bookmark icons are the websites favicon which are almost always 16x16 how to you propose to correct the blur unless each site ups the rez for their icon?  

I also think you will have problems with some add-ons because of this change.  I already see problems with some Stylish styles I use where the spacing on things like the sidebar, about:config and other things have extra spacing between items.

As I said why not have a zoom feature for the chrome especially for the stuff on top.  You have it for content, why not for chrome?  This way one can downscale the chrome (icons) to 16x16 and no more blur.
Comment 34 Gary [:streetwolf] 2013-03-15 07:33:35 PDT
I notice that the pref that goes along with the change enlargens things if set to >1.  Can't you use it to make things smaller?
Comment 35 Jonathan Kew (:jfkthame) 2013-03-15 07:36:39 PDT
(In reply to Gary [:streetwolf] from comment #33)
> I just don't like the blurry chrome icons.  Since bookmark icons are the
> websites favicon which are almost always 16x16 how to you propose to correct
> the blur unless each site ups the rez for their icon?

Some (many?) sites do provide multiple sizes of favicons, but we're not currently able to use them (in most cases) - see bug 419588 and bug 828508. (Enabling resolution-based scaling on Windows increases the urgency to get these issues fixed.)

> I also think you will have problems with some add-ons because of this
> change.  I already see problems with some Stylish styles I use where the
> spacing on things like the sidebar, about:config and other things have extra
> spacing between items.

Yes, it seems likely there are add-ons that will need updating because they assume Firefox does *not* honor the OS resolution, and so they attempt to compensate for this themselves.

> As I said why not have a zoom feature for the chrome especially for the
> stuff on top.  You have it for content, why not for chrome?  This way one
> can downscale the chrome (icons) to 16x16 and no more blur.

I don't think we could justify adding such a feature to the core Firefox UI - the standard behavior should be that we follow the OS resolution setting, and we should make that work as well as possible (including support for multiple-sized favicons, and providing appropriately-sized icons for Firefox UI elements, so we don't have to upscale smaller ones).

Maybe it could be implemented by an add-on, if there are people who really want the Firefox UI to be scaled -differently- from the OS setting. I think Mozilla's priority here should be to make the correctly-scaled interface look as good as possible.
Comment 36 Dão Gottwald [:dao] 2013-03-15 08:21:01 PDT
The favicon issue is not much different than on OS X. The main difference is that we have floating-point scaling factors here, which means that bug 839923's interim solution may not be adequate for Windows.

I any case, that's not reason enough not to scale the UI automatically or to expose a preference for that.
Comment 37 Gary [:streetwolf] 2013-03-15 12:31:34 PDT
"I any case, that's not reason enough not to scale the UI automatically or to expose a preference for that."

I hate double negatives in a sentence.  What are you trying to convey?  You agree with me that large, blurry graphics in the UI are not acceptable?

I pity those with very large monitors, 27" and above, who set their OS DPI to 150%.
Comment 38 Dão Gottwald [:dao] 2013-03-15 12:57:03 PDT
(In reply to Gary [:streetwolf] from comment #37)
> You agree with me that large, blurry graphics in the UI are not acceptable?

No.

> I pity those with very large monitors, 27" and above, who set their OS DPI
> to 150%.

The idea behind setting it to 150% is to make stuff 150% larger.
Comment 39 Gary [:streetwolf] 2013-03-15 13:38:57 PDT
That's exactly my point.  The ui will be 50% larger so any graphics that were designed for 96 DPI will look awful.

Content is taken care of via Fx's zoom feature or better yet the addon No Squint.  I can use NoSquint on content to make text bigger and graphics smaller so there is no blur.  I can't do that with the UI.  I have to have big ugly icons, buttons, what have you.

Just because another browser does it this way doesn't mean it's right.  IE looks just as terrible when using a large DPI on a large monitor.

Unfortunately developers haven't totally grasped the idea that folks aren't using 15" monitors anymore.  With the advent of widescreen monitors a 96DPI produces output that is way to small for these monitors.  I also blame web designers for using low rez pictures and graphics though I suspect catering to the lowest common bandwidth denominator is the reason for this. 

Personally the way Fx works without the patch is ideal.  Chrome is crisp and any content that has blurry graphics or text that is either too small or too large can be corrected via the zoom feature.  If I want large bookmark icons all I need is a line or two of CSS code.
Comment 40 M** A**** 2013-03-15 15:22:41 PDT
While I hate adding to bug spam. May I say that for me the problem is not the size change but the blurry UI. It looks terrible and having worked with vision impaired people and now suffering slightly in that respect myself I suggest you need to re think this
Comment 41 xyz 2013-03-16 08:51:32 PDT
Ok.. While i see in general larger fonts as no problem... The state of Nightly is right now just terrible. I am an eye glass wearer and all picture related stuff is blurry like hell, it hurts to look at Nightly/Nightly UX right now...

I really think you should rethink that Change what you did here! That just looks horrible! Remembers me of the Failure of the Baldur's Gate Enhanced Edition Developers... Same Problem, same Outcry.... Make the content look larger is not bad, but at the same time affecting the GUI.. That is just plain bad, especially if gui elements are not optimized for Higher Resolutions!

Seriously, Make the GUI Smaller. Would you please? :(
Comment 42 Gary [:streetwolf] 2013-03-16 10:06:33 PDT
Created attachment 725784 [details]
Fx22 vs. IE10.
Comment 43 Gary [:streetwolf] 2013-03-16 10:07:33 PDT
(In reply to Gary [:streetwolf] from comment #42)
> Created attachment 725784 [details]
> Fx22 vs. IE10.

I did some side by side comparisons of Fx22 and IE10.  My DPI is set in my OS at 120 (125%).

You can see that IE10 does not appear to be taking the DPI from the OS at least for content.  The text on the IE10 page is the same size as the text in Fx before the patch landed on Nightly or with the patch if I set the new pref to 1 instead of -1.

The UI portion on the top of IE10 is larger and it's possible it gets the DPI from the OS or just makes it bigger itself.  Regardless, notice the favicon is much clearer in IE10.  Also clearer are the graphics in IE10 because they aren't up scaling 125%  

If you are looking to be on par with IE10 it appears you made an incorrect assumption that IE10 uses the OS DPI for everything.  IMO it's time to rethink this change.
Comment 44 xyz 2013-03-16 10:28:28 PDT
Just think of how an everday's computer user would react... Looking at that change, not knowing it can be changed over about:config - and well, you lose people faster then light.

Comparing that 2 Screenshots i really have to day, IE 10 looks much more beautiful. And that says someone who uses Firefox already since versions below 1!

Just a point you should put into the calculations too... Users are not interested in finding "complex" solutions. They want it instantly beautiful and working.

And THAT, if this feature comes to the Stable Versions perhaps is just not offering that to the Normal Everyday's Users.
Comment 45 Jonathan Kew (:jfkthame) 2013-03-16 11:17:28 PDT
(In reply to Gary [:streetwolf] from comment #43)
> I did some side by side comparisons of Fx22 and IE10.  My DPI is set in my
> OS at 120 (125%).
> 
> You can see that IE10 does not appear to be taking the DPI from the OS at
> least for content.  The text on the IE10 page is the same size as the text
> in Fx before the patch landed on Nightly or with the patch if I set the new
> pref to 1 instead of -1.

Have you reset the zoom in IE to 100%? That would make the content smaller again. In my testing, at least, it *defaults* to 125% when the OS dpi is set to 120 (that's how they implement the dpi-dependency).
Comment 46 Gary [:streetwolf] 2013-03-16 11:30:44 PDT
Yes! it is 100% for me.  So IE10 works like the pre-patched Fx22 then. You have to zoom within IE10 to get 125% for example.  No dependency on the OS DPI.
Comment 47 Gary [:streetwolf] 2013-03-16 11:35:42 PDT
jon... if you want to chat about this on IRC let me know where I can find you.  I'm pretty much a noob using IRC and I would use Chatzilla.
Comment 48 Gary [:streetwolf] 2013-03-16 12:08:00 PDT
A better screen shot.  Fx22 with a new profile on the left, IE10 on the right.

http://imageshack.us/photo/my-images/811/capturepbvj.png/
Comment 49 Josh Tumath 2013-03-16 12:47:03 PDT
Gary, a lot of the problems you have with icons are due to the Web sites; not Firefox. As high-DPI displays become more popular, more Web sites will include higher resolution favicons.

(In reply to Gary [:streetwolf] from comment #14)
> So why does every application display the same size text except for Fx with
> this patch?  96 DPI is to small.  120 DPI (125%) is just right for every
> application I use. 
> 
> I'm sorry but you have not grasped totally what this patch is doing.

There is a reason for this. Windows is a bit weird when it scales apps when you've set the DPI to be 125%. I can't remember the specific details of this quirk, but - IIRC - instead of using the correct behaviour of scaling all of the content in an app, Windows scaled the app like it used to in Windows XP, where just the text is scaled.

If you set the DPI to be 150% or greater like how I have it, *everything* is scaled in *every* app. If an app doesn't support high DPIs, then Windows will render it as a 100% scaled app and stretch it to 150% (you can see this behaviour yourself in the Firefox installer).

(In reply to Gary [:streetwolf] from comment #43)
> If you are looking to be on par with IE10 it appears you made an incorrect
> assumption that IE10 uses the OS DPI for everything.  IMO it's time to
> rethink this change.
What are you talking about? That is a bug in how Gecko's layout manager renders scaled content. The same thing would probably happen on a 96 DPI display if you just zoomed in the page. Please file a separate bug for it. :)
Comment 50 Gary [:streetwolf] 2013-03-16 12:58:21 PDT
The part of this patch I don't like is the scaling of the chrome. Makes Fx look like ****, period.  As for the content the patch will force me to set zoom levels less than 100% or just set the pref to 1.0.

See what happens when this gets rolled out in an official release.  They'll be more complaints than Moz can handle.
Comment 51 Josh Tumath 2013-03-16 13:05:38 PDT
(In reply to Gary [:streetwolf] from comment #50)
> The part of this patch I don't like is the scaling of the chrome. Makes Fx
> look like ****, period.  As for the content the patch will force me to set
> zoom levels less than 100% or just set the pref to 1.0.

Specifically what is it that "makes it look like ****"? What is it specifically that you have an issue with. It sounds like everything you have complained about (such as blurry icons and blurry tabs) is listed in this tracking bug: bug 820679. If that is so, then this bug is either INVALID or a duplicate of bug 820679. Fixing the bugs tracked in bug 820679 is a much better solution than reverting bug 844604.
Comment 52 Dão Gottwald [:dao] 2013-03-16 13:09:10 PDT
(In reply to Gary [:streetwolf] from comment #46)
> Yes! it is 100% for me.

That's not what Jonathan was asking. He was asking whether you manually set IE's zoom level to 100%, since it should be 125% by default, in accordance to the system's DPI setting.
Comment 53 Gary [:streetwolf] 2013-03-16 13:32:01 PDT
Yes if I made it 125% it would be as huge as Fx.  Setting IE at 100% and setting Fx22 at 100% shows me that IE10 does not use the OS DPI.  

Doing what your doing might be OK for a Surface Pro and the like but for a desktop it's terrible.  Not everything is compatible across all systems.

Has anyone tried it on a 24 inch monitor or larger?

Who the heck needs gigantic bookmarks not to mention large tabs and affecting other add-ons.
Comment 54 Dão Gottwald [:dao] 2013-03-16 13:38:12 PDT
Comment on attachment 725784 [details]
Fx22 vs. IE10.

(In reply to Gary [:streetwolf] from comment #53)
> Setting IE at 100% and
> setting Fx22 at 100% shows me that IE10 does not use the OS DPI.

No, it doesn't. The fact that IE presets the zoom level to 125% shows that it lets the DPI setting affect Web content.
Comment 55 Gary [:streetwolf] 2013-03-16 13:45:45 PDT
Dao, all I can say is pages look like ****.  If you plan on keeping the pref and I can just set it to 1 to get things to look like they should then that's what I'll do. 

So how does Fx's zoom feature differ from IE10's?  Isn't IE doing the zooming itself?
Comment 56 Josh Tumath 2013-03-16 13:47:08 PDT
(In reply to Gary [:streetwolf] from comment #55)
> So how does Fx's zoom feature differ from IE10's?  Isn't IE doing the
> zooming itself?

The only difference is the way that Firefox reports the zoom level.
Comment 57 Gary [:streetwolf] 2013-03-16 14:02:35 PDT
So I set my dpi to normal (96DPI).  IE10 shows me a default zoom of 80% now.  

Fx22 shows smaller content too but the chrome graphic stuff(icons, buttons, tabs, etc.) are normal like pre-patch Fx22.  Text in things like sidebars, about:, addons, etc are small.

Since all of Windows is way to small I can't run at 96DPI, I need 120DPI.

I don't like the way IE10 looks either.  Will there ever be a time when you can scale up without getting blurry graphics?

I have more control over how web pages look in Fx using zoom text and full page zoom using NoSquint.  Changing the default zoom to act like NoSuint does is the answer IMO.  Pages almost never look right unless I fiddle with zoom per site.
Comment 58 Gary [:streetwolf] 2013-03-16 14:32:34 PDT
My issue comes down to this.  Using a pref of -1 is like doing a full page zoom for every site not to mention the UI graphics.  This causes web page graphics to become blurry and text to be larger all across the board.  

I currently only use full page zoom on a couple of sites (pre-patch).  On these I use a combination of text zoom and full page zoom.  NBCnews.com is such a site as well as CNN.com.  These sites have very small text which I need to make bigger but if I use full page zoom the graphics become blurry just like the patch does.

My default zoom is 120% TEXT only.  This preserves the original dimensions of graphic stuff with no blur and increase text size. Of course there are always sites that have text issues, usually truncated, or missing.  Guess this is par for the course.  

I like the way things were and I'll bet you the ranch that I'm not the only user that doesn't like what they see.
Comment 59 Greg Edwards 2013-03-16 16:37:43 PDT
Created attachment 725810 [details]
Behaviour of stable releases of IE, Chrome, and Firefox on 200% (192)

So it looks like we have a few options:
1. Break getDefaultScale when the Windows DPI is less than 150% (144) and falsely return 100% (96) to appease existing users.
2. The same as above, only using the devPixelsPerPx pref. This might work better if users want to manually re-enable scaling.
3. Keep the patch, cue rage.
4. Revert the patch, cue other rage.

Without Bug 844604's fix, out of the box, Firefox looks downright goofy on a Retina Macbook Pro. Going back to the old behaviour is a short-term solution at best. We're going to have to dive in sometime and it's best to do it sooner rather than later and lose more install base to Chrome/IE whenever the next batch of "resolutonary" devices launch, potentially shipping with Windows this time.

Of course, high resolution art will need to be added before this reaches the release channel. When art isn't available at a given scale, it should downscale the next size up in order to show less blur. I would suggest including 125%, 150% and 200% scales.

I've attached a screenshot showing how Firefox Release behaves on a high DPI monitor, compared to other browsers. Keep in mind that I'm seeing this on a 15.4" screen. Owning an rMBP basically turns you into a DPI-awareness evangelist by necessity.
Comment 60 Gary [:streetwolf] 2013-03-16 16:52:41 PDT
You really need to get a hold of a 24" or larger LCD monitor to really see the problem.  Everyone who is fighting me is using a small monitor of some type.  The patch might do wonders for smaller mobile screens but for me it's a disaster.

If you keep the pref as it is in the final release then that is an answer.  I'll just set it to 1.0 and forget it.
Comment 61 Greg Edwards 2013-03-16 17:01:02 PDT
I'm not aware of any 24" or larger screens on the market with more than around 105dpi, so you really shouldn't be setting 120dpi on those screens anyway. So no, I don't see your problem. :P

When the user sets a higher DPI, they are telling Windows *they want everything to look larger*, which is exactly what this patch respects.
Comment 62 Gary [:streetwolf] 2013-03-16 17:10:36 PDT
120DPI is perfectly acceptable on my monitor. I don't know where you get the 105 number from.  Are you not a Windows guy perhaps.  

The problem is that unlike Windows itself and most applications these days browsers are not good at handling DPI's > 96.  Windows and apps can provide high rez graphics and icons to handle different DPI's.  Browsers on the other hand have to deal with billions of combinations of text and graphics.  If all web sites had alternate text and graphics they could use a high rez version if they detect a higher DPI (I don't know if a web page can even detect DPI) like Window icons which have different sizes. Web pages would look great.
Comment 63 Gary [:streetwolf] 2013-03-16 17:21:54 PDT
Created attachment 725813 [details]
Different DPI's

Here are the 3 default DPI's in windows.  I use medium.  Smaller is too small on my monitor.
Comment 64 Greg Edwards 2013-03-16 17:37:51 PDT
Web pages can detect DPI. See window.devicePixelRatio and min/max-resolution media queries. Many sites detect DPI and provide high resolution images, but it's typically just 200%.

The highest resolution screens at 24" or more are the 2560x1440 27" IPS displays, eg. Dell u2711, Apple Thunderbolt, etc. with ~109DPI. Users may want to set high DPIs on these screens anyway since they may be viewing them from far away or have bad vision, so this is a moot point anyway.

Imagine for a moment the year is 2030 and we're all on 600DPI monitors or whatever. This would make Firefox only display at 1/6th of a reasonable size. You would need a magnifying glass. Fixed pixel layouts are not future-proof, there's already a recommended way forward for all major platforms, all we have to do is start following it. Which this patch does.
Comment 65 Gary [:streetwolf] 2013-03-16 17:50:58 PDT
My monitor is IPS btw.

So I am destined to live with everything I mentioned if I use my OS DPI? I wish I had one of you guys looking over my shoulder while I'm running Fx22. Do you not believe that things look ****?  

If you want to go with using the OS DPI then get it right for large monitors with high DPI's.  I think you guys have made the desktop PC an orphan while mobile stuff has parents.
Comment 66 xyz 2013-03-17 04:08:13 PDT
Created attachment 725865 [details]
150% DPI Settings make the Firefox options panel way too large

Have uploaded a Screenshot how Nightly looks in my System.. Have here a HDMI TV (1080P) - And Windows DPI Settings 150% - Options Screen is WAY too large.

Had to move Windows Control Bar to the side so i am able to move options window or use ok button.

Makes more then clear that using Windows DPI Settings for the UI is a not that good idea ;)

Please think about that change again.. at least using Windows DPI also for UI Elements!
Comment 67 xyz 2013-03-17 04:30:26 PDT
Forget my last post, i am an idiot. I have forgotten that it is not useful to post screenshots if you use external themes. sorry for that!
Comment 68 Gary [:streetwolf] 2013-03-17 08:04:27 PDT
Since it seems you are intent on going with the OS DPI I decided to use it and test it out.

I run with two monitors.  I believe because you scale up the chrome to 125% in my case if I go into full screen mode (F11) the screen extends to my second monitor. It extends about 1/4th of the way which sounds like 100% DPI on first monitor, 25% on second monitor.  You already know my dislike of the oversized ui like tabs, toolbars, icons, buttons, etc.
Comment 69 Josh Tumath 2013-03-17 08:07:51 PDT
(In reply to Gary [:streetwolf] from comment #68)
> I run with two monitors.  I believe because you scale up the chrome to 125%
> in my case if I go into full screen mode (F11) the screen extends to my
> second monitor. It extends about 1/4th of the way which sounds like 100% DPI
> on first monitor, 25% on second monitor.  You already know my dislike of the
> oversized ui like tabs, toolbars, icons, buttons, etc.

Are you talking about bug 824386?
Comment 70 Gary [:streetwolf] 2013-03-17 08:25:55 PDT
(In reply to Josh Tumath from comment #69)
> (In reply to Gary [:streetwolf] from comment #68)
> > I run with two monitors.  I believe because you scale up the chrome to 125%
> > in my case if I go into full screen mode (F11) the screen extends to my
> > second monitor. It extends about 1/4th of the way which sounds like 100% DPI
> > on first monitor, 25% on second monitor.  You already know my dislike of the
> > oversized ui like tabs, toolbars, icons, buttons, etc.
> 
> Are you talking about bug 824386?

Yes it is the same problem.  I added my experience to that bug report.
Comment 71 Jim Mathies [:jimm] 2013-03-17 10:01:24 PDT
(In reply to Jonathan Kew (:jfkthame) from comment #32)
> Don't other applications scale their user interface in response to the
> Windows resolution settings? Certainly looks that way to me - everything
> about Windows Explorer (menus, icons, window chrome, etc) is enlarged when I
> set Windows to 150%. Likewise other applications, from Notepad to MS Word.
> (I even see some poorly-scaled bitmap icons in the Word UI, where larger
> versions of the resource clearly weren't provided.)

Apps can opt out (as we have been) or let windows scale the interface for them. Sort of hit and miss depending on what the developer decides to do. Windows built-in apps should be used as a reference.
Comment 72 Jim Mathies [:jimm] 2013-03-17 10:04:37 PDT
This bug is basically a bucket list for all the deps in bug 820679. I'd suggest we resolve this out.
Comment 73 Jonathan Kew (:jfkthame) 2013-03-18 04:42:35 PDT
*** Bug 852093 has been marked as a duplicate of this bug. ***
Comment 74 Gary [:streetwolf] 2013-03-18 10:59:09 PDT
I'm posting this here just to get a comment or two before I open up a bug report.

I tested Fx22 with the dpi patch against IE10. I used the two types of scaling available to windows under Display options.  XP scaling which is compatible with all programs and No XP scaling (check box is left empty) which is 'dpi awareness' that lots of programs don't handle correctly (you get fuzzy screen output).  Fx22 and IE10 are both 'dpi aware'.  I've been told, but not sure, that if you use XP scaling the chrome should not upscale with higher and higher OS dpi's. 

THE RESULTS:

Fx22 scaled up it's chrome at dpi's of 125% and 150% using XP scaling or No XP scaling.

IE10 kept the chrome the same size at dpi's of 125% and 150% using XP scaling or No XP scaling.

Looking at the zoom factor in IE10 it was either 125% or 150% depending on what the OS dpi was set to. Fx22 shows the zoom as being 100%, no matter if the OS dpi was 125% or 150%.

I really can't say with certainty that Fx22 is violating some law of XP scaling or it's just doing things it's own way. 

At least two suggestions can be made for Fx22 to keep on par with IE10 and to make it look better overall.

1. Don't scale chrome for DPI's > 96. Make it a little larger if you want like I think IE10 does, but maintain the same size with all dpi's > 96

2. Report the full page zoom like IE10 does. It should not be 100 when the dpi is 125% or 150%. It should reflect what the OS dpi is.
Comment 75 Josh Tumath 2013-03-18 11:03:57 PDT
(In reply to Gary [:streetwolf] from comment #74)
> I really can't say with certainty that Fx22 is violating some law of XP
> scaling or it's just doing things it's own way.

In the XP scaling, the old behaviour is used: icons and pixel dimensions stay the same as 96 DPI, but the chrome text is upscaled by 1.25.
Comment 76 Gary [:streetwolf] 2013-03-18 11:17:08 PDT
Created attachment 726254 [details]
FX22 and IE10 at an OS DPI of 125%

Compare the chrome for each browser to the 150% dpi in the next attachment.   Notice Fx22 get's larger, while IE10 stays the same.
Comment 77 Gary [:streetwolf] 2013-03-18 11:18:28 PDT
Created attachment 726256 [details]
FX22 and IE10 at an OS DPI of 150%

Compare the chrome size to the 125% attachment.
Comment 78 Josh Tumath 2013-03-18 11:26:55 PDT
(In reply to Gary [:streetwolf] from comment #77)
> Created attachment 726256 [details]
> FX22 and IE10 at an OS DPI of 150%
> 
> Compare the chrome size to the 125% attachment.

The reason why IE10's chrome uses the same sized icons at 125% and 150% is because Microsoft chose not to scale the large versions of their icons for different DPIs. On the other hand, Gecko will automatically scale down icons made for 150% (which haven't been created yet) so that they are suitable for 125% displays.

However, the text in IE10's chrome is not the same size at 125% and 150%.
Comment 79 Gary [:streetwolf] 2013-03-18 11:30:33 PDT
All I wanted to do is make you aware of the differences and it appears they are already known and will be worked on.
Comment 80 Jonathan Kew (:jfkthame) 2013-03-18 12:12:28 PDT
(In reply to Gary [:streetwolf] from comment #74)
> IE10 kept the chrome the same size at dpi's of 125% and 150% using XP
> scaling or No XP scaling.

This is not correct, AFAICS - certainly in my testing, I'm seeing IE10 scale the chrome according to dpi setting, as expected. It's true that it appears to use the same size -icons- within the chrome at both 125% and 150% (though they're larger than the 100% icons), but the chrome as a whole, and text within it, are all scaled to different sizes at the different dpi settings.

> Looking at the zoom factor in IE10 it was either 125% or 150% depending on
> what the OS dpi was set to. Fx22 shows the zoom as being 100%, no matter if
> the OS dpi was 125% or 150%.

Right - this is simply a design difference in how the zoom factor is reported. Firefox regards the default zoom level (for whatever dpi is chosen at the system level) to be "100% zoom".

> 1. Don't scale chrome for DPI's > 96. Make it a little larger if you want
> like I think IE10 does, but maintain the same size with all dpi's > 96

No, the chrome must be scaled according to dpi. What we need to do is provide larger versions of the icons and other bitmapped graphical elements, and choose the best available match to the user's chosen dpi scale factor. It might make sense to "snap" to a nearby standard size, e.g. so that the same bitmaps would be used for both 125% and 150%; that seems to be what IE is doing, in effect.

> 2. Report the full page zoom like IE10 does. It should not be 100 when the
> dpi is 125% or 150%. It should reflect what the OS dpi is.

I don't see why this would be preferable to the current behavior of treating the default zoom level for the current dpi as "100%".
Comment 81 Jonathan Kew (:jfkthame) 2013-03-18 12:15:59 PDT
(In reply to Jonathan Kew (:jfkthame) from comment #80)

> > 2. Report the full page zoom like IE10 does. It should not be 100 when the
> > dpi is 125% or 150%. It should reflect what the OS dpi is.
> 
> I don't see why this would be preferable to the current behavior of treating
> the default zoom level for the current dpi as "100%".

In particular, consider what this would imply in a few years' time when we have monitors with 600dpi or something. Do we really want a user interface where the default, comfortably-readable scale for a web page is claimed to be "600% zoom" by the browser? I don't think so. The standard, natural scale should be "100% zoom". A larger zoom factor than 100% means the user is explicitly asking the browser to enlarge the page, relative to its default display - which in turn was determined by the system/display properties.
Comment 82 Gary [:streetwolf] 2013-03-18 13:18:07 PDT
Do you think the following two things can be accomplished in Fx?

1. All chrome elements will display crisp and clear for dpi's > 96?

2. Content graphics that are lower in resolution than what the OS dpi is set at will also be clear, not blurry?  Can Fx compensate for this or is the solution up to the web designers to account for high dpi monitors?

I don't like any browsers full page zoom because of the way graphic items get blurred.  The only plus is that both text and graphics are scaled together which maintains the proper page layout in most cases. 

Would you want to read a newspaper or magazine where the pictures are blurry?
Comment 83 Greg Edwards 2013-03-18 13:27:39 PDT
(In reply to saphirjd from comment #66)
> Created attachment 725865 [details]
> 150% DPI Settings make the Firefox options panel way too large
> 
> Have uploaded a Screenshot how Nightly looks in my System.. Have here a HDMI
> TV (1080P) - And Windows DPI Settings 150% - Options Screen is WAY too large.
> 
> Had to move Windows Control Bar to the side so i am able to move options
> window or use ok button.
> 
> Makes more then clear that using Windows DPI Settings for the UI is a not
> that good idea ;)
> 
> Please think about that change again.. at least using Windows DPI also for
> UI Elements!

I know it's obsolete and all but still, I'd just like to point out that the fonts on that screenshot are *massive*, about the same pixel heights as my 192DPI setup. 

There's a very simple way to think of DPI scaling: Your desktop has an "effective resolution" that's the same as its true resolution divided by the scale factor. So your 1920x1080 desktop at 150% has the same *screen space* as a 1280x720 desktop without scaling. Chances are that theme of yours requires more than 720 height.

This "scale everything proportionately" approach has been what Microsoft recommends since Vista. It has nothing to do with "mobile" other than the peculiar phenomenon that mobile devices are moving to high pixel densities faster than desktops.
Comment 84 Greg Edwards 2013-03-18 13:37:10 PDT
(In reply to Gary [:streetwolf] from comment #82)
> 1. All chrome elements will display crisp and clear for dpi's > 96?
If the rest of Bug 820679 is implemented, yes. The graphics team still needs to be awoken.

> 2. Content graphics that are lower in resolution than what the OS dpi is set
> at will also be clear, not blurry?  Can Fx compensate for this or is the
> solution up to the web designers to account for high dpi monitors?
It's up to web designers to add high resolution imagery, just like on every other platform. Type "dpi image replacement" into Google and read a few articles to get a sense for how this is going.

> Would you want to read a newspaper or magazine where the pictures are blurry?
Funny you should mention this, since high DPI screens are more like print in many ways. If you print out a webpage, the images will look blurry/pixellated in a similar way to on a high DPI screen.

I agree Firefox's scaler could use some work. Bilinear upscaling gets way too fuzzy.
Comment 85 Gary [:streetwolf] 2013-03-18 15:24:44 PDT
I noticed a patch in the latest hourly that included this: image-rendering moz-crisp-edges

I added the following line to a Stylish style and the large toolbar icons looked better.


.toolbarbutton-icon{ image-rendering: -moz-crisp-edges !important;}
Comment 86 Loic 2013-03-19 12:59:50 PDT
The icons of the URL bar are pretty blurry on Win 7 at 125%.
http://i.imgur.com/DG1lcgq.png
Comment 87 Dão Gottwald [:dao] 2013-03-21 08:35:15 PDT
(In reply to Josh Tumath from comment #51)
> Specifically what is it that "makes it look like ****"? What is it
> specifically that you have an issue with. It sounds like everything you have
> complained about (such as blurry icons and blurry tabs) is listed in this
> tracking bug: bug 820679. If that is so, then this bug is either INVALID or
> a duplicate of bug 820679. Fixing the bugs tracked in bug 820679 is a much
> better solution than reverting bug 844604.

Indeed.
Comment 88 Danial Horton 2013-05-13 18:48:54 PDT
This is not an invalid complaint, the UI dpi really is larger then necessary.

Firefox already started adhering to the System DPI for UI controls back sometime after 4.0 (See all the DPI bugs for UI prior to this) (not sure on versioning at this point), prior to that the UI controls could be scaled up to system dpi using layout.css.dpi;-1

However, with this new behavior, the Fonts and icons on the UI really are larger than they should be.  This is probably a result of the corrected behavior from 3.x now being REadjusted by the new behavior, so the DPI on the toolbars is now larger than it should be.
Comment 89 Greg Edwards 2013-05-14 06:58:31 PDT
I can't replicate what you're describing. For me, the UI is always scaled proportionately to the chosen DPI scale (in Windows) as it should be, unless I start messing around in about:config.
Comment 90 Danial Horton 2013-05-14 07:10:55 PDT
actually, its been pointed out elsewhere that Firefox is completely Ignoring XP Style scaling
Comment 91 Greg Edwards 2013-05-14 07:18:01 PDT
What does that even mean? Last I was aware, "XP style" meant no DPI virtualization, so Firefox *always* uses XP style scaling...
Comment 92 Mardeg 2013-07-05 13:00:28 PDT
*** Bug 873738 has been marked as a duplicate of this bug. ***
Comment 93 Mardeg 2013-07-05 13:01:58 PDT
*** Bug 890522 has been marked as a duplicate of this bug. ***
Comment 94 Robert Longson 2013-07-06 06:18:33 PDT
*** Bug 890612 has been marked as a duplicate of this bug. ***
Comment 95 Mardeg 2013-07-07 13:31:42 PDT
*** Bug 890737 has been marked as a duplicate of this bug. ***
Comment 96 Loic 2013-07-09 03:52:24 PDT
*** Bug 891295 has been marked as a duplicate of this bug. ***
Comment 97 Cork 2013-07-09 06:15:50 PDT
*** Bug 891331 has been marked as a duplicate of this bug. ***
Comment 98 Loic 2013-07-11 08:41:28 PDT
*** Bug 892337 has been marked as a duplicate of this bug. ***
Comment 99 Loic 2013-07-11 15:59:32 PDT
*** Bug 891955 has been marked as a duplicate of this bug. ***
Comment 100 Loic 2013-07-11 16:00:02 PDT
*** Bug 890202 has been marked as a duplicate of this bug. ***
Comment 101 Loic 2013-07-11 16:00:06 PDT
*** Bug 890300 has been marked as a duplicate of this bug. ***
Comment 102 Mardeg 2013-07-15 04:24:26 PDT
*** Bug 893722 has been marked as a duplicate of this bug. ***
Comment 103 Dão Gottwald [:dao] 2013-10-08 01:15:20 PDT
*** Bug 923987 has been marked as a duplicate of this bug. ***
Comment 104 Loic 2013-10-11 10:32:33 PDT
*** Bug 925668 has been marked as a duplicate of this bug. ***
Comment 105 Alice0775 White 2014-03-06 09:36:44 PST
*** Bug 980338 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.