Closed
Bug 602647
Opened 14 years ago
Closed 14 years ago
Fennec needs a scriptable interface to GetDPI
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
fennec | 2.0+ | --- |
People
(Reporter: mbrubeck, Assigned: MikeK)
References
Details
Attachments
(1 file)
1.67 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
Fennec multiplies values from the "viewport" meta tag by a factor that is intended to correct for differences in display density. This factor is effectively a device-pixel to css-px ratio, which applies only to pages that set their scale with <meta name="viewport">. For some more background, see: http://limpet.net/mbrubeck/2010/05/11/fennec-meta-viewport.html
Right now this factor a preference (zoom.dpiScale) with a hard-coded default of 150%. (This default is targeted at a handheld display with about 160 dpi.)
We'd like to change this value based on the actual hardware display density. To do this in the front-end as we do now, we would like a scriptable way to call nsWindow::GetDPI.
Reporter | ||
Updated•14 years ago
|
tracking-fennec: --- → ?
Component: General → Graphics
Product: Fennec → Core
QA Contact: general → thebes
Comment 1•14 years ago
|
||
this is just chrome, right?
Rationale for it blocking 2.0?
Reporter | ||
Comment 2•14 years ago
|
||
We need this to adapt our chrome to different-resolution screens, and also to choose the a CSS-to-device pixel ratio to apply to meta[name=viewport] values.
Both of these are necessary if we decide to implement bug 590777 (support lower-resolution displays), which is currently blocking-fenec:2.0+.
Blocks: 590777
Reporter | ||
Comment 3•14 years ago
|
||
Sorry, actually this isn't needed for adapting our chrome theme - we can do that using mozmm and media queries. It's only needed for adjusting our content scaling.
Updated•14 years ago
|
Assignee: nobody → mkristoffersen
tracking-fennec: ? → 2.0+
Comment 4•14 years ago
|
||
can we just add this to nsIScreen?
Comment 5•14 years ago
|
||
sure, or nsIDOMWindowUtils.
Assignee | ||
Comment 6•14 years ago
|
||
When should we use a readonly attribute and when should we use a function to get such a value from an interface?
Comment 7•14 years ago
|
||
It doesn't matter that much. An attribute is fine
Assignee | ||
Comment 8•14 years ago
|
||
Attachment #483183 -
Flags: review?(doug.turner)
Comment 9•14 years ago
|
||
Comment on attachment 483183 [details] [diff] [review]
Fix V1
roc, is it fine to expose dpi in this way?
Attachment #483183 -
Flags: review?(doug.turner) → review?(roc)
You can compute this already by calling DOMWindowUtils.screenPixelsPerCSSPixel on a window with no zoom (e.g., the chrome window) and multiplying by 96.
Reporter | ||
Comment 11•14 years ago
|
||
(In reply to comment #10)
> You can compute this already by calling DOMWindowUtils.screenPixelsPerCSSPixel
> on a window with no zoom (e.g., the chrome window) and multiplying by 96.
On my Android device where GetDPI should return 240 (and GetDefaultScale returns 1.0), DOMWindowUtils.screenPixelsPerCSSPixel*96 == 96. Is this expected?
Er, never mind, I don't know what I was thinking.
Attachment #483183 -
Flags: review?(roc) → review+
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Reporter | ||
Comment 13•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Updated•14 years ago
|
Keywords: checkin-needed
Updated•14 years ago
|
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in
before you can comment on or make changes to this bug.
Description
•