Closed Bug 758011 Opened 8 years ago Closed 2 years ago

[userstory] Multiple Display Density / Pixel Ratio Options

Categories

(DevTools :: Responsive Design Mode, defect)

x86
All
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: djf, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs, )

Details

(Keywords: DevAdvocacy, Whiteboard: [multiviewport] [userstory][DevRel:P1])

User Story

Interface for handling screen resolution on devices, incorporates pixel ratio and display density

User Story:
* As a web developer testing for high resolution screens, like the Apple retina, I want the display density and / or zoom (pixel ratio) to match the device I've chosen such that I can test that our assets and layout appear correctly on different devices.

Acceptance criteria:
* Accept pixel ratio / display density from the device list options
* Setting the correct zoom level and viewport size necessary to match the device given the current users screen
* A choosable list of common device display density options
* dpi low-density (~120dpi)
* mdpi medium-density (~160dpi)
* hdpi high-density (~240dpi)
* xhdpi extra high-density (~320dpi)
* retina (for iOS devices)
* Allow for custom custom display density choices

Additional Information:
* This is the ratio between physical pixels and device-independent pixels, which is unique to devices and their screen sizes.
* For Retina like devices they often have a ratio of 2 because they are a higher resolution device but want a web site to size itself in a smaller mobile view.

http://www.quirksmode.org/blog/archives/2012/06/devicepixelrati.html

Attachments

(2 files)

Bug 749628 implements a responsive design tool for displaying websites at various mobile device screen sizes.

It would be really nice if it could also simulate the pixel densities of those devices by (for example) setting the layout.css.dpi preference so that CSS mozmm units and media queries that use device resolution work correctly.

Bonus points if you provide an option tozoom or -moz-transform the resulting layout so that mozmm units on the simulated screen are actual millimeters on the host display.  (See http://davidflanagan.github.com/Flex/screens.html for an example that transforms the simulated screens, but that cannot actually set the layout.css.dpi pref to process stylesheets correctly.)

This would be a really, really helpful feature for B2G/Gaia developers!
Blocks: 749628
See also bug 758129.
Scaling is easy (and we have some code already).
Changing the DPI for just one page might need some platform work.

As I understand it, being able to do that would be very useful for Gaia developers.
Severity: enhancement → normal
Priority: -- → P2
(In reply to Paul Rouget [:paul] from comment #2)
> Scaling is easy (and we have some code already).
> Changing the DPI for just one page might need some platform work.
> 
> As I understand it, being able to do that would be very useful for Gaia
> developers.

Yes. It will also be useful for Mobile Apps developers in general.
If I'm not mistaken the pixel density has an impact only on the "mozmm" unit and on some media queries.

From MDN:
> 1in is now 96px
> 3pt is now 4px
> 25.4mm is now 96px


We can make a change that will impact "mozmm" and the media queries (changing layout.css.dpi in the pref do that). But this change impact the whole browser. If we want to have something that works for only one document, we will need some platform help.

We could also only scale the viewport (as we did in the first versions of the Responsive Mode) with a CSS transform. But then, values with the "mozmm" units will be wrong.
(In reply to Paul Rouget [:paul] from comment #4)
> If I'm not mistaken the pixel density has an impact only on the "mozmm" unit
> and on some media queries.
> 

That's my understanding as well. The resolution, min-resolution and max-resolution queries care about this. I don't know if there are others. And I don't know if anyone uses these much yet. But maybe with a tool like this they would!

> 
> We can make a change that will impact "mozmm" and the media queries
> (changing layout.css.dpi in the pref do that). But this change impact the
> whole browser. If we want to have something that works for only one
> document, we will need some platform help.

Can you get away with changing it for the whole browser if you restore it when you exit responsive mode?
 
> We could also only scale the viewport (as we did in the first versions of
> the Responsive Mode) with a CSS transform. But then, values with the "mozmm"
> units will be wrong.
Summary: Support variable display densities in Responsive Design Tool → [responsive design - dpi] Support variable display densities in Responsive Design Tool
(In reply to David Flanagan from comment #5)
> (In reply to Paul Rouget [:paul] from comment #4)
> > We can make a change that will impact "mozmm" and the media queries
> > (changing layout.css.dpi in the pref do that). But this change impact the
> > whole browser. If we want to have something that works for only one
> > document, we will need some platform help.
> 
> Can you get away with changing it for the whole browser if you restore it
> when you exit responsive mode?

Not really. The chrome might be affected, and the other pages and windows as well.
And we don't leave the responsive mode when switching to a new tab.
Blocks: 778169
Component: Developer Tools → Developer Tools: Responsive Mode
Roc, for the developer tools, we'd like to be able to fake the pixel density for one tab only. Would there be any simple way to do that?
Flags: needinfo?(roc)
Full zoom should do that, basically.
Flags: needinfo?(roc)
I guess fullzoom doesn't handle mozmm properly.

This is quite easy to implement at the platform level. We should add something like "attribute long overrideDPI" to nsIMarkupDocumentViewer, next to fullzoom.
Ok. I'll look at this. Thanks.
Basically you want it to work like fullZoom, and be routed to a new method nsPresContext::SetOverrideDPI. That will need to call a new method on nsDeviceContext, parallel to SetPixelScale, let's say nsDeviceContext::SetOverrideDPI. And that will have to set a new field of nsDeviceContext, say mOverrideDPI, which is read by nsDeviceContext::SetDPI().
Once that's implemented, I think a combination of fullZoom and overrideDPI will give you exactly what you need.
Assignee: nobody → paul
Attached patch Patch v0.1Splinter Review
Something along these lines?

To try this patch in a browser scratchpad [1]:

> function setDPI(dpi) {
>   let window = gBrowser.contentWindow;
>   let DOMUtils = window.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDOMWindowUtils);
>   DOMUtils.overrideDPI = dpi;  
>   window.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
>     .getInterface(Components.interfaces.nsIWebNavigation)
>     .QueryInterface(Components.interfaces.nsIDocShell)
>     .contentViewer
>     .QueryInterface(Components.interfaces.nsIMarkupDocumentViewer)
>     .fullZoom = dpi / 96;
> }
> 
> setDPI(192);

This apparently works well. I was wondering if it's possible to then downscale the rendering. Use case (I should have started with that):

A Gaia developer prototypes a webapp in Firefox Desktop, targeting a high DPI display. 2X for example. He doesn't want the rendering to be twice the size in Firefox Desktop, but he wants the mediaQueries to match (min-resolution: 192dpi) and mozmm to be affected as well.

[1]: https://developer.mozilla.org/en-US/docs/Tools/Scratchpad#Using_Scratchpad_to_access_Firefox_internals
Attachment #771363 - Flags: feedback?(roc)
(In reply to Paul Rouget [:paul] from comment #13)
> This apparently works well. I was wondering if it's possible to then
> downscale the rendering.

Use CSS transforms.
Comment on attachment 771363 [details] [diff] [review]
Patch v0.1

Review of attachment 771363 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, fantastic.
Attachment #771363 - Flags: feedback?(roc) → feedback+
I suggest that we expose these densities:

default
ldpi 	low-density (~120dpi).
mdpi 	medium-density (~160dpi).
hdpi 	high-density (~240dpi).
xhdpi 	extra high-density (~320dpi).
(In reply to David Flanagan [:djf] from comment #0)
> Bonus points if you provide an option tozoom or -moz-transform the resulting
> layout so that mozmm units on the simulated screen are actual millimeters on
> the host display.  (See http://davidflanagan.github.com/Flex/screens.html
> for an example that transforms the simulated screens, but that cannot
> actually set the layout.css.dpi pref to process stylesheets correctly.)

It seems this page also doesn't apply the viewport meta. I have created an issue: https://github.com/davidflanagan/Flex/issues/2

I don't know if it is useful for this bug through.
Adding DevAdvocacy keyword; emulating higher / lower pixel density has been a common request at conferences in the past few months.
Keywords: DevAdvocacy
Specifically, the use cases tend to be:

1. Wanting to scale the responsive viewport so that the whole thing fits within the native browser window. This helps get a sense of the overall visual feel of the page on a given device. E.g., what's above and below the fold at a given size? How does that look from afar?

2. Checking to ensure that the correct media queries are firing. E.g., does the site load HiDPI / @2x images when at iPhone 6  /"retina" density?
No planning to work on this anytime soon.
Assignee: paul → nobody
Summary: [responsive design - dpi] Support variable display densities in Responsive Design Tool → Support variable display densities in Responsive Design Tool
Whiteboard: [devtools-ux]
User Story: (updated)
Flags: qe-verify-
Priority: P2 → --
Summary: Support variable display densities in Responsive Design Tool → [userstory] Multiple Display Density Options
Whiteboard: [devtools-ux] → [multiviewport] [userstory]
Depends on: 1237870
Duplicate of this bug: 1153318
Bug 1153318 for pixel ratio has been duped into here, so combining the user stories for now, until it can be simplified.
User Story: (updated)
Summary: [userstory] Multiple Display Density Options → [userstory] Multiple Display Density / Pixel Ratio Options
User Story: (updated)
See Also: → 1153318
Notes:

In the event that an actual device is chosen, the device pixel ratio 
isn’t editable. It only displays the device pixel ratio the device sets,
and is grayed-out and uneditable.

If a device isn’t selected, it defaults to 2. (This is arbitrary; let's change it if need be.)


This becomes editable with options 1, 2, and 3.
(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #24)
> If a device isn’t selected, it defaults to 2. (This is arbitrary; let's
> change it if need be.)

Perhaps it should default to pixel ratio of your monitor?  So, a retina screen would default to 2, and otherwise 1?  Really all I mean is it would default to the pixel ratio that you'd get during regular browser given the monitor / OS setup already in use, so our tool wouldn't modify the dPR at all by default.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #25)
> (In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #24)
> > If a device isn’t selected, it defaults to 2. (This is arbitrary; let's
> > change it if need be.)
> 
> Perhaps it should default to pixel ratio of your monitor?  So, a retina
> screen would default to 2, and otherwise 1?  Really all I mean is it would
> default to the pixel ratio that you'd get during regular browser given the
> monitor / OS setup already in use, so our tool wouldn't modify the dPR at
> all by default.

This makes sense to me.
:helenvholmes, I just remembered that on Windows (where most of our users are) you can have a non-integer dPR pretty easily by changing system settings even on a desktop / laptop.  For example, on Windows 10, if you go to Windows logo -> Settings -> Display, there is a slider that says "Change the size of text, apps, and other items", which lets you select between 100%, 125%, and 150% (I am in a VM, there may be other choices on real hardware).  In Firefox, these affect the dPR value, so they give me 1, 1.25, and 1.50 respectively.

Should we consider offering a way to enter a non-integer value based on this?  Also, it means the "default" value when unmodified by RDM could easily be non-integer.  So the menu in your design would allow going from the default to an integer, but no way to return to the default floating point value.

If we'd prefer to avoid entering arbitrary values still, we may at least want a specific "default" menu item, so you can return to the unmodified floating point value that you (may have) started with.

Might be worth discussing at tomorrow's meeting.

(It would interesting to capture dPR values in telemetry for future decision making.)
Flags: needinfo?(hholmes)
Depends on: 1251006
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #27)
> :helenvholmes, I just remembered that on Windows (where most of our users
> are) you can have a non-integer dPR pretty easily by changing system
> settings even on a desktop / laptop.  For example, on Windows 10, if you go
> to Windows logo -> Settings -> Display, there is a slider that says "Change
> the size of text, apps, and other items", which lets you select between
> 100%, 125%, and 150% (I am in a VM, there may be other choices on real
> hardware).  In Firefox, these affect the dPR value, so they give me 1, 1.25,
> and 1.50 respectively.
> 
> Should we consider offering a way to enter a non-integer value based on
> this?  Also, it means the "default" value when unmodified by RDM could
> easily be non-integer.  So the menu in your design would allow going from
> the default to an integer, but no way to return to the default floating
> point value.
> 
> If we'd prefer to avoid entering arbitrary values still, we may at least
> want a specific "default" menu item, so you can return to the unmodified
> floating point value that you (may have) started with.
> 
> Might be worth discussing at tomorrow's meeting.
> 
> (It would interesting to capture dPR values in telemetry for future decision
> making.)

I'm fine with us entering arbitrary values—in my designs, I tried to follow the user story as best I could. I think the only awkwardness UX-wise would come from us trying to do both of these things at once (have a select box that is also somehow an input field).

So, I think we should do one or the other, but not both.
Flags: needinfo?(hholmes)
Depends on: 1254385
Whiteboard: [multiviewport] [userstory] → [multiviewport] [userstory][DevRel:P1]
Depends on: 1299154
Depends on: 1325578
I believe this feature is complete according to the user story in 52 and later.  We can track bugs and tweaks separately.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.