852963 - system font sizes are not scaled correctly when devPixelsPerPx set to 1.0

Status: RESOLVED INCOMPLETE

(Core :: Widget: Win32, defect)

Description

[Gary [:streetwolf52]]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20130320 Firefox/22.0
Build ID: 20130320044721

Steps to reproduce:

Apply patch https://bugzilla.mozilla.org/show_bug.cgi?id=852522


Actual results:

System fonts are 96 dpi even though devPixelsPerPx set  to 1.0 and my OS dpi is 120.


Expected results:

System fonts should honor dpi

Comment 1

[Jonathan Kew [:jfkthame]]

No. System fonts should honor the Windows dpi setting -if- you leave the devPixelsPerPx preference at its default of -1.0 (which means "handle this automatically").

If you explicitly set devPixelsPerPx to a positive value, you're telling Firefox to -override- the system dpi/resolution setting, and so you'll get smaller (or larger) fonts throughout the browser, depending whether you set devPixelsPerPx to a value that's smaller or larger than the Windows resolution scaling factor.

Comment 2

[Gary [:streetwolf52]]

Setting the pref to a positive value defaults to a 96dpi for 'system' fonts?  If so, why not also downscale the chrome too?  That remains the same size.  A +1.0 is now not a method to keep Fx looking the same as before the dpi patch? 

idk Jon but all of these dpi changes so far have not been one of the best things I've seen you guy's do.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Gary [:streetwolf] from comment #2)
> Setting the pref to a positive value defaults to a 96dpi for 'system' fonts?

No, it uses whatever scale factor you specify. If you set it to 1.0, *then* yes, you're effectively asking for 96 dpi; if you set it to 1.25, you're asking for 120dpi-sized fonts; if you set it to 1.5, you're asking for 144dpi-sized fonts; etc.

Until the recent changes, I think you were seeing system fonts sized according to your chosen Windows scale (i.e. 125%), but content that ignored the Windows setting (and so you were then "zooming" the content to make things readable). That's not a sustainable model, as resolutions continue to increase. We really HAVE to start honouring the Windows resolution setting in a consistent manner across the whole browser, that's the only reasonable way forward into a world of displays with widely varying DPI.

The expectation is that there shouldn't normally be any need to change the devPixelsPerPx setting from its default of -1.0; that should give a correctly-scaled view (both the chrome and content) for your screen, consistent with other Windows applications. If you *do* start changing that preference, you are completely overriding the effective DPI setting for Firefox, and both chrome and content will scale accordingly.

Comment 4

[Gary [:streetwolf52]]

So I should consider all of this a Work In Process and the final version will be a lot better visually then what I see at this point?

Comment 5

[Jonathan Kew [:jfkthame]]

Well, we certainly want appropriately-sized graphic elements for the UI, so that we don't upscale smaller bitmaps. That's a known issue, as has already been stated. So yes, it's a WIP.

In terms of scaling things in response to the system resolution setting, I think most stuff is now working as expected; if it's not, we certainly want bug reports. But this particular one was based (AFAICT) on a misunderstanding of the whole resolution-scaling model.

Comment 6

[Gary [:streetwolf52]]

The chrome portion is something you guys can control.  Content is another thing.  Go over to www.weather.com.  At 125% the page is Hugh. Is there anything you can do about something like this? I can still do text zoom and full page zoom with the built in zoom or NoSquint to reduce the size.

The thing is that a person who writes an application taking in mind the OS dpi will provide all that is needed to handle them.  Web pages for the most part do not take into account dpi, although you said they are able to.  So each web page is like an application which you don't have full control over to make it look visually appealing.

Is there any push my Mozilla or the other browser makers to spread the news to web designers to code for different dpi's?  That's what is needed to get pages looking good.

Comment 7

[Greg Edwards]

Text-only scaling of web pages was abandoned several years ago by the w3c because it was notorious for breaking layouts. Proportionate scaling of everything (text, boxes, images) is the preferred way to scale web pages. (See -webkit-text-size-adjust for one noteworthy exception.)

Many websites these days are serving images optimized for high DPI devices. eg:
http://www.apple.com/
http://www.google.com/
http://mail.google.com/
http://www.microsoft.com/

Want me to attach images of these sites viewed at 192dpi? :D~

Comment 8

[Karl Tomlinson (:karlt)]

bug 712898 comment 28:
"System metrics and native theme drawing are always in device pixels."

System font sizes should be system font sizes.  CSS pixel sizes are not involved.

Comment 9

[Greg Edwards]

In effect, you are asking to back out Bug 852522.

Comment 10

[Masatoshi Kimura [:emk]]

It will totally break the rendering on High DPI monitors.

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to Greg Edwards from comment #9)
> In effect, you are asking to back out Bug 852522.

I don't know the pixelScale code, so perhaps that should remain.

All I know is that devPixelsPerPx should not be involved.

Comment 12

[Karl Tomlinson (:karlt)]

(In reply to Masatoshi Kimura [:emk] from comment #10)
> It will totally break the rendering on High DPI monitors.

Do you mean backing out bug 852522 would break that or fixing this bug, or are they the same thing?

Why would respecting system font sizes in this case be any different from respecting other changes in system font size settings?

Comment 13

[Masatoshi Kimura [:emk]]

What's the definition of "system font size"?

Comment 14

[Greg Edwards]

Karl: I'm pretty sure he means it will cause text to overflow outside of dialogs and widgets because the font size is too big for them. This is why bug 852522 was originally implemented--to make the sizes of containers match the sizes of fonts.

(Before you say anything, making the containers grow to match the fonts is what the default, uncustomized devPixelsPerPx setting does.)

Comment 15

[Karl Tomlinson (:karlt)]

System font sizes describe the size of fonts as specified in the system
themes.  On WINNT, the fonts in menus, for example, come from the theme Menu
font.  The Message Box font is used in much of Firefox UI.  I don't know where
other fonts come from.  The system UI for configuring the themes presents font
sizes in points, so I assume the system fonts sizes in layout device pixels
are something like  point size / 72 * logical dpi.

If LookAndFeel reports system metrics in device pixels, as it currently does,
then, on platforms where system metrics depend on window scaling, the
functions reporting the metrics need to know the window scale.

On platforms where the window scale is the same for all windows, the system
metrics functions don't need to know the particular window and can just use
the global scale.

Currently these functions are passed the device pixels per CSS pixel ratio
which defaults to the window scale, but is not the window scale if the pref
has been set.  Really the pref should affect the rendering of CSS pixels, but
system metrics are unrelated to CSS pixels.

On WINNT, fixing this bug involves simply backing out bug 852522.

On platforms with different window scales for each window, it is harder.
The pref in its current form is not so useful on systems with different
scaling on different windows.

Perhaps the pref has changed in meaning from allowing the user to specify CSS
pixel size to allowing developers to experiment with overriding system window
scaling.  But the name of the pref implies that it affects CSS pixels.

Comment 16

[Karl Tomlinson (:karlt)]

The meaning of layout.css.devPixelsPerPx has changed with changes for bug 1773342.
The pref for scaling web content and UI is now "ui.textScaleFactor", with values of 100 or 150 or 200, for example, and/or use "Default zoom" in about:preferences for scaling content only.