667260 - mozmm on Linux != mozmm on Win

Status: NEW

(Core :: General, defect)

Description

[Felix Miata]

Attachment: 96 DPI WinXP screenshot of multiple browsers rendering page that uses mozmm sizing

I have several web pages designed to display an image one inch wide for purpose of determining how much DTE pixel density deviates from device pixel density. These were useful until the fixed ratio of 16px per 12pt was implemented via bug 537890. That bug provided a Gecko-specific workaround for those wishing to maintain the ability to produce accurate physical sizes on a display device according to the device's pixel density, as long as the DTE was able to match that density, in the form of the mozmm unit. I rewrote some of those pages to make use of the mozmm unit, and they work as expected opened in most old non-Gecko browsers and in all tested Gecko browsers running on Linux. On Windows XP, post-537890 Geckos don't have any mozmm meaning I'm able to relate to anything. Gecko ignores the desktop's DPI setting, and displays mozmm according apparently to some formula related to device size in px without regard to the device's physical size, as follows:

Screen Width	Reported DPI
800		64
1024		81
1152		91
1280		102
1400		111
1600		127
1792		142
1856		147
1920		152
2048	163

Pages making use of mozmm include:
http://fm.no-ip.com/Auth/Font/fonts-comps-droid.html
http://fm.no-ip.com/Auth/Font/fonts-ptdemo.html
http://fm.no-ip.com/Auth/dpi-screen-window.html
http://fm.no-ip.com/Auth/dpi-screen-sample.html

and more. They all work as expected on Linux DTEs whether or not locked to 96. The screenshot shows post-537890 Geckos (rv2b13 & rv5 shown, rv7a1 tested but not shown) can't get expected results from mozmm on Windows desktops even when set to 96 DPI. They should, even when not set to 96. If I'm misunderstanding something about mozmm and it's Linux that gets it wrong rather than Windows, then versions for Linux should be fixed. In any event, mozmm should produce results that only depend on physics, not on choice of OS software.

Comment 1

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

We calculate the DPI as the screen height in pixels divided by the screen height in inches, so assuming you're not changing monitor size there, I would indeed expect the DPI to increase as you switch to higher resolutions.

Comment 2

[Felix Miata]

(In reply to comment #1)
> We calculate the DPI as the screen height in pixels divided by the screen
> height in inches,

1-Why?
2-Why differently from on Linux (which gets it from the DTE IIUC) & (AFAICT) WebKit, Opera & IE?
3-Where, if at all, is it used internally?

> so assuming you're not changing monitor size there, I
> would indeed expect the DPI to increase as you switch to higher resolutions.

Of course, but the table in comment 0 is a subset (columns 5 & 7) of the following actual observations:
                                  DPI   DPI  DPI Native
"Size" AspectX mm Y mm X px Y px WgeckoActualDTE  Res
  15    4:3   305  229  800  600    64  66.6  96      LCD
  15    4:3   305  229 1024  768    81  85.2  96   Y  LCD
  18    4:3   366  274 1152  864    91  80.1  96      CRT
  18    4:3   366  274 1152  864    91  80.1 120      CRT
  20    4:3   406  305 1152  864    91    72  96      CRT
  18    4:3   366  274 1280  960   102    89  96      CRT
  17    5:4   337  270 1280 1024   102  96.3  96   Y  LCD
  14    4:3   284  213 1400 1050   111 125.2  96   Y  LCD
  18    4:3   366  274 1400 1050   111  97.3  96      CRT
  18    4:3   366  274 1400 1050   111  97.3  96      CRT
  20    4:3   406  305 1400 1050   111  87.4 120      CRT
  32    16:9  406  305 1920 1080   152  89.9  96   Y  LCD
  18    4:3   366  274 1600 1200   127 111.2  96   Y  CRT
  20    4:3   406  305 1600 1200   127  99.9  96   Y  LCD
  20    4:3   406  305 1600 1200   127  99.9  96   Y  CRT
  20    4:3   406  305 1792 1344   142 111.9  96      CRT
  20    4:3   406  305 1856 1392   147 115.9  96      CRT
  18    4:3   366  274 1920 1440   152 133.5  96      CRT
  18    4:3   366  274 1920 1440   152 133.5 120      CRT
  18    4:3   366  305 2048 1536   163 127.9  96      CRT
  20    4:3   406  305 2048 1536   163 127.9  96      CRT

Where does "screen height in inches" come from on Windows?

Comment 3

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

(In reply to comment #2)
> (In reply to comment #1)
> > We calculate the DPI as the screen height in pixels divided by the screen
> > height in inches,
> 
> 1-Why?

Because it's simple to do and it makes sense.

> 2-Why differently from on Linux (which gets it from the DTE IIUC) & (AFAICT)
> WebKit, Opera & IE?

How would you test it in Webkit, Opera and IE?

We calculate it very much the same way on Linux:
    double heightInches = DisplayHeightMM(dpy, defaultScreen)/MM_PER_INCH_FLOAT;
    ...
    return float(DisplayHeight(dpy, defaultScreen)/heightInches);
Maybe X calculates DisplayHeightMM in a very different way than Windows does. That's beyond our control.

> 3-Where, if at all, is it used internally?

Only for mozmm AFAIK.

> Where does "screen height in inches" come from on Windows?

I don't know.

Comment 4

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

This is the code we use on Windows:

  HDC dc = ::GetDC(mWnd);
  ...
  double heightInches = ::GetDeviceCaps(dc, VERTSIZE)/MM_PER_INCH_FLOAT;
  int heightPx = ::GetDeviceCaps(dc, VERTRES);
  ...
  return float(heightPx/heightInches);

Pretty straightforward.

Comment 5

[Felix Miata]

(In reply to comments #3 & #4)
...
> Because it's simple to do and it makes sense.

If both pixel height and screen height in inches are not bogus...
 
> We calculate it very much the same way on Linux:
>     double heightInches = DisplayHeightMM(dpy,
> defaultScreen)/MM_PER_INCH_FLOAT;
>     ...
>     return float(DisplayHeight(dpy, defaultScreen)/heightInches);
> Maybe X calculates DisplayHeightMM in a very different way than Windows
> does. That's beyond our control.
... 
> Pretty straightforward.

Seems like it should be, but maybe there's another label for what you need to query for on Windows so as not to be using an arbitrary value for screen height in inches (or mm)? Maybe Windows thinks an app isn't supposed to be able to know such a thing, and provides junk instead of nothing? Maybe it knows DPI and can provide a correct result if given the right query?

http://home.browsercam.com/public.aspx?proj_id=555757 indicates Mac doesn't have this problem either.

Could this be related to why bug 69205 was not fixed before browser.display.screen_resolution was replaced by layout.css.dpi?

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Attachment: provide URI-without-ref and test for existance of a ref

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 551780 [details] [diff] [review]
provide URI-without-ref and test for existance of a ref

Sorry, wrong bug

Comment 8

[Felix Miata]

Attachment: testcase to substitute for URL used in screenshot 541982 & comment 0 URLs

Comment 9

[Felix Miata]

Attachment: screenshot: current state of affairs on 144 DPI WinXP

Summary of selected about:config settings not apparent in viewport content:
					rv1.9.x	rv17	rv28	rv30
layout.css.devPixelsPerPx		1.0	1.0	1.0	1.0
layout.css.dpi				0	0	0	0

Note that only rv1.9.x renders everything in the viewport and in the UI sized the way it ought to be.

Comment 10

[Felix Miata]

Attachment: screenshot: current state of affairs on 144 DPI Linux/KDE

In contrast to WinXP, except for trivial rounding error in the ancient KHTML browser, everything on the Linux desktop is as expected in both the viewports and the UI.