797833 - Metrofx currently has layout.css.dpi hard coded to 160

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: General, defect)

Description

[Jim Mathies [:jimm]]

I don't think we should have this set. When this isn't present, platform code dynamically adjusts to the dpi of the screen.

http://mxr.mozilla.org/mozilla-central/search?string=layout.css.dpi

I'd like to remove this pref, but when I do certain xul interfaces like preferences are going to scale down. The css for these will need updating.

related: bug 797828

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Jim Mathies [:jimm] from comment #0)
> I'd like to remove this pref, but when I do certain xul interfaces like
> preferences are going to scale down. The css for these will need updating.

I don't think that's true, unless you have interface elements specified in mozmm (which maybe you do; mozmm is good for sizing touch elements).

Regardless, if you let layout.css.dpi take its default value, then we should automatically set it to the true screen DPI and mozmm units will match physical mm, and things should be good.

Comment 2

[Matt Brubeck (:mbrubeck)]

Attachment: patch

This removes the override, and translates all of our mozmm lengths into CSS px units.  I just multiplied all of the lengths by 6.3 and rounded to the nearest whole px.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why are you switching from mozmm to px? I would have thought at least touch button sizes should be a constant physical size across screens.

Comment 4

[Matt Brubeck (:mbrubeck)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> Why are you switching from mozmm to px? I would have thought at least touch
> button sizes should be a constant physical size across screens.

For basically the same reason web developers use "px" and Android developers use "dips" and Mac developers use "points" -- they make it possible to combine images, text, and CSS boxes in a predictable way.

The "mozmm" sizes here were never actually designed to work with arbitrary physical resolutions.  On Android the exact resolution is not reliably available (bug 605024) so mozmm lengths are scaled by the nominal resolution, which is always one of {120dpi, 160dpi, 240dpi, 320dpi} -- and in fact XUL Fennec had some UI bugs when the first 320dpi devices shipped (e.g. bug 712506) because some parts of our layout could not resize to match the mozmm lengths on those devices.

On other platforms we hard-coded a resolution of 160dpi to match the "medium" Android resolution.  The initial Metro work over the summer was done with that hack in place and added a lot of px lengths, some of which will not play nicely with mozmm lengths once the resolution can change.

Switching all lengths to "px" for now will preserve the current layout, and will let us keep physical sizes *roughly* consistent by setting an appropriate device-pixel::px ratio.  We can switch back to mozmm for specific cases where the *exact* physical size is important and we have tested to make sure the layout accommodates different scales.  But for now I want to avoid accidentally regressing styles.

I'll file bugs for any work needed to make the Metro UX scale correctly on different displays, and track them in bug 800999.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That makes total sense, thanks.

Comment 6

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/projects/elm/rev/2c32a623ad96

Comment 7

[Matt Brubeck (:mbrubeck)]

Resolving bugs in the Firefox for Metro product that are fixed on the elm branch.  Sorry for the bugspam.  Search your email for "bugspam-elm" if you want to find and delete all of these messages at once.