Closed
Bug 1200666
Opened 10 years ago
Closed 10 years ago
Units for nsDocumentViewer::GetContentSize unclear
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox43 | --- | affected |
People
(Reporter: billm, Unassigned)
Details
It seems like the return value of nsDocumentViewer::GetContentSize is off by a factor of 2 on my HiDPI display. I want to use the result to set the size of a containing <browser> element. How should I be doing this? I'm writing JS code.
Flags: needinfo?(bugmail.mozilla)
Comment 1•10 years ago
|
||
As far as I can tell nsDocumentViewer::GetContentSize is returning LayoutDevicePixels (which includes adjustment for both full-zoom and DPI) but it sounds like you want to unapply the DPI adjustment.
Can you assume a full-zoom value of 1.0? If so you can use window.devicePixelRatio to isolate the DPI. Otherwise you probably need to expose nsIWidget::GetDefaultScale() to JS somehow. Alternatively you can add another method to nsDocumentViewer which returns it in the units you want.
Also, I'm assuming this is not Retina mac because if it is there's some BackingScaleFactor() stuff you need to deal with and TBH I don't understand how that works.
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 2•10 years ago
|
||
Yes, I think I can assume a full-zoom of 1.0. window.devicePixelRatio does the trick.
I'm not on a Retina Mac. I'll make sure to test there though.
Reporter | ||
Comment 3•10 years ago
|
||
Thanks.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•