Closed Bug 818935 Opened 11 years ago Closed 11 years ago

[HiDPI] Download Manager file icons are disproportionately large


(Toolkit :: Downloads API, defect)

19 Branch
Windows 7
Not set





(Reporter: edwardsgreg, Assigned: jfkthame)


(Blocks 1 open bug)



(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20121204 Firefox/19.0
Build ID: 20121204042015

Steps to reproduce:

Set Windows to a DPI higher than 96.
Download some files.
Open the Download Manager if it isn't already.

Actual results:

Observe that the icons are much bigger relative to font sizes and other UI elements.
(In other words, icon pixel sizes are scaling proportionate to the *square* of the DPI scale.)

Expected results:

Icons should scale proportionately.

I figure icon sizes from Windows are being interpreted as px units instead of device pixels.
Attached image 96DPI reference
Reproduced on the 12/10 Nightly, on Windows 7 64bit.
Component: Untriaged → Downloads Panel
Ever confirmed: true
This is not the panel
Component: Downloads Panel → Download Manager
Product: Firefox → Toolkit
Blocks: win-hidpi
The only problem I see @ 192 is other icons too small.
Attached image current screenshot
We need to do a better job of using the appropriate resolution if it is available. We are currently scaling up a lower resolution icon in some cases.
What do we have to do in these cases? I sense the patch might be a pretty simple moz-icon change, but I'm not sure.
This is a simple fix, actually. We just need to ensure the icon is always displayed at the proper size (in terms of CSS pixels), so that the larger icons we get on a hidpi system are used to provide better resolution, not simply rendered at a larger physical size (with blurry, upscaled pixels).
Attachment #729754 - Flags: review?(jmathies)
Assignee: nobody → jfkthame
I see this method still producing less-than-perfect results if devPixelsPerPx doesn't match the platform's scale. (But it's a step in the right direction.)
Ideally, Fx would fetch the raw .ico and run it through the new media fragment parser from Bug 419588.
(In reply to Greg Edwards from comment #8)
> I see this method still producing less-than-perfect results if
> devPixelsPerPx doesn't match the platform's scale.

FWIW, I suspect many things will be less-than-perfect in that scenario. We should be (strongly) discouraging people from messing with devPixelsPerPx, and focus on making the browser work correctly (and look good) by default.
Attachment #729754 - Flags: review?(jmathies) → review+
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.