1023508 - Add telemetry for HiDPI usage

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Justin Dolske [:Dolske]]

We should gather telemetry data to help understand HiDPI usage.

I think this could be as simple as computing a scaling factor (or raw dpi/ppi), and reporting that value. On OS X there will basically only be two values (1x and 2x for Retina), whereas on Windows I'd expect peaks at the settings offered by default (100%/125%/150%/200%), with a range of additional value for custom settings between 100% and 500%.

One complication is that there isn't always a single value per user... One might change system setting (rare), plug in an external monitor (common), or even run multiple windows on multiple monitors (each with a different dpi).

Perhaps it would be sufficient to start with one probe that for "dpi of first window upon startup" (ie primary window?), and another boolean probe for "DPI has changed for user".

If we see that lots of users have complicated multi-DPI setups, we can then measure that. Perhaps a single "Unique DPIs used during session" probe, but it might still be useful to know how many users have more than one.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: MediaQuery experiment

I did a little experiment with MediaQuery listeners, thinking it would be a good way to watch for display DPI changes. Works fine on OS X (dragging a window from a Retina display to a normal external display).

But I'm a little wary of wonkyness from floating point representation. For example, after setting the display DPI to 133% on Window 7, window.devicePixelRatio reports 1.3333333730697632. Since you can't use media queries to ask for _any_ DPI change, I'm asking for when the DPI changes from the current _exact_ value. That's fragile unless all the code involved very carefully preserves/replicates exact values. [TBH I'm not even sure if a float value passing back and forth over xpconnect is guaranteed to do so.]

I suppose we could sidestep the whole issue with min/max...

   var dppx = window.devicePixelRatio.toFixed(3);
   var min = dppx - .001;
   var max = dppx + .001;
   // query "(min-resolution: 1.334dppx) and (max-resolution: 1.332dppx)".

But this is all overkill right now... Windows makes you logout to change DPI settings, and until Windows 8.1 all monitors share the same DPI setting. So "DPI of first window opened" will be an accurate measurement for the vast majority of Windows users. OS X users are less interesting, because we only have to deal with 1x and 2x displays.

Comment 2

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

This gives us per-platform (Win/OSX/Linux) data on what the device-pixel scalng factor is for the user's first window. This should be sufficient to let us understand what scaling factors are in use and how common they are.

A few remarks:

* OS X really only needs 100% and 200% (Retina or not), but it was just simpler to just do the same thing everywhere. Why per-platform measurement? I expect there are lots of 200% users on OS X due to Retina's popularity, and this avoids skewing the data for usage on Windows. Given the different implementation issues for OS X vs Windows, I think we want to keep the measurements separate. We may even eventually want data specific to a Windows release, since HiDPI support is marginal until Windows 8.

* The bucket sizing gives us the scaling factors in 5% chunks. EG, we can tell the difference between 100%-vs-105%, but not 100%-vs-101%. This feels detailed enough to understand how common custom/oddball levels are, and understand the variety of Windows' stock settings without checking explicitly for each.

* The top range is 500%, since as noted in bug 1023488 Windows provides UI for setting a custom value up to 500%.

Comment 3

[Marco Mucci [:MarcoM]]

Hi Dolske, can you provide a point value and if this bug should be marked as [qa+] or [qa-] for verification.

Comment 4

[Justin Dolske [:Dolske]]

https://hg.mozilla.org/integration/fx-team/rev/1409b7cf2f80

Comment 5

[Justin Dolske [:Dolske]]

Comment on attachment 8446928 [details] [diff] [review]
Patch v.1

Approval Request Comment
[Feature/regressing bug #]: n/a
[User impact if declined]: We want to understand hidpi usage on release-like users, as it's relevant to understanding how we're going to improve it (eg bug 1016543, bug 1023488).
[Describe test coverage new/current, TBPL]: n/a, no functional change
[Risks and why]: low risk as an addition of a simple telemetry probe.
[String/UUID change made/needed]: n/a

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/1409b7cf2f80

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8446928 [details] [diff] [review]
Patch v.1

Beta 5 has been released. We prefer to accept only critical bug fixes.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ad0cdb7f2b46

Comment 9

[Georg Fritzsche [:gfritzsche]]

Is there a reason why we have separate per-platform histograms here (DISPLAY_SCALING_<OS>)?
We know what platforms that data comes from (that is part of the telemetry ping) - are there any other concerns here that wouldn't be addressed by a simple DISPLAY_SCALING probe?

Comment 10

[Justin Dolske [:Dolske]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #9)
> Is there a reason why we have separate per-platform histograms here
> (DISPLAY_SCALING_<OS>)?
> We know what platforms that data comes from (that is part of the telemetry
> ping) - are there any other concerns here that wouldn't be addressed by a
> simple DISPLAY_SCALING probe?

Yes. The reason is that the per-OS breakdown was important, and I didn't realize telemetry.mo could already do per-OS breakdown until just after this landed! :P

Didn't seem worth the effort to change it after the fact, but I wouldn't object to it. Would be nice to not lose the ~5 releases of data we have, but I think our short-term questions around this are answered, and now the probe will mostly be useful for watching long term usage trends.

Comment 11

[Georg Fritzsche [:gfritzsche]]

Ah, thanks, i filed a follow-up for this.