Closed
Bug 857061
Opened 12 years ago
Closed 11 years ago
[HiDPI] Hovered over Taskbar Fx icon thumbnail, chrome contents and window appears smaller.
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
mozilla23
Tracking | Status | |
---|---|---|
firefox21 | --- | unaffected |
firefox22 | + | fixed |
firefox23 | --- | fixed |
People
(Reporter: streetwolf52, Assigned: jfkthame)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
jimm
:
review+
akeybl
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
(deleted),
image/png
|
Details |
STR:
1. Start up Fx.
2. Hover over the Fx icon on the Windows Taskbar to view the thumbnail picture.
3. Hover over the Thumbnail picture to produce the actual Fx window.
4. The image produced is a 96 dpi version of the page superimposed over the HiDPI page as seen in my attachment.
Expected results:
Hovering over thumbnail picture should show the page as it actually appears.
Reporter | ||
Comment 1•12 years ago
|
||
Assignee | ||
Comment 2•12 years ago
|
||
Actually, from your screenshot it looks like the -content- of the superimposed window is correctly sized; it exactly matches the "real" window underlying it. It's only the chrome elements and the actual size of the window that are smaller.
Blocks: win-hidpi
Reporter | ||
Comment 3•12 years ago
|
||
You're right.
Reporter | ||
Updated•12 years ago
|
Summary: [HiDPI] Hovered over Taskbar Fx icon thumbnail appears as 96dpi. → [HiDPI] Hovered over Taskbar Fx icon thumbnail, chrome contents and window appears smaller.
Reporter | ||
Comment 4•12 years ago
|
||
Ran with a new profile and everything works OK. Could be a pref causing the problem as it didn't work when I ran with add-ons disabled.
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to Gary [:streetwolf] from comment #4)
> Ran with a new profile and everything works OK. Could be a pref causing the
> problem as it didn't work when I ran with add-ons disabled.
Strike this. A new profile has 'browser.taskbar.previews.enable' set to 'false'. Once I set it to 'true' I got the same problem.
Reporter | ||
Comment 6•12 years ago
|
||
Seems like the pref set to false works fine from what I see. It works like any other program. When I hover over the picture all other windows disappear. What exactly is this pref supposed to do?
Reporter | ||
Comment 7•12 years ago
|
||
I get it now. It's to see previews of multiple tabs.
Assignee | ||
Comment 8•12 years ago
|
||
(In reply to Gary [:streetwolf] from comment #5)
> (In reply to Gary [:streetwolf] from comment #4)
> > Ran with a new profile and everything works OK. Could be a pref causing the
> > problem as it didn't work when I ran with add-ons disabled.
>
> Strike this. A new profile has 'browser.taskbar.previews.enable' set to
> 'false'. Once I set it to 'true' I got the same problem.
OK, with this I can reproduce on Win7 as well. Clearly the tab-preview code doesn't handle DPI scaling properly. I'll try to look into this soon, unless someone else jumps in - though as this feature is currently disabled by default, it's less urgent than some other issues.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•12 years ago
|
||
I can replicate by enabling the "Show tab previews in the taskbar" preference. I guess DPI scale isn't being picked up by these tab previews?
Assignee | ||
Comment 10•12 years ago
|
||
Ah, there's UI for that setting in the Options dialog, not only about:config. OK, that bumps it up the priority list. :)
Comment 11•12 years ago
|
||
On closer inspection, it seems like the toolbars, etc. *are* being drawn at the correct device pixel ratio, but are being raster scaled back down to 1x before being rendered.
Assignee | ||
Comment 12•12 years ago
|
||
Difficult to tell (from the screenshot -- not at my Windows machine right now), but from the corners of the URL and search boxes, I think you're right.
Another observation, fwiw, is that the "preview" content is being rendered with grayscale-only antialiasing, while the real window uses subpixel (ClearType).
Comment 13•12 years ago
|
||
Looking at it even further, the truth might be even more strange.
All the 16x16 icons (bugzilla, shortcut bar, toolbar buttons) look far too crisp to be downscaled from 2x, but both the text and boxes look much fuzzier than they would if rendered at that resolution.
I've attached my screenshot. Note that I've intentionally set my ClearType's pixel structure to monochrome since it makes non-dpi-aware apps look better.
Assignee | ||
Comment 14•12 years ago
|
||
Another issue - not quite so glaringly obvious, perhaps, but also visible in your screenshot - is that the thumbnail tab previews above the taskbar are also incorrectly scaled/clipped. They show the same sub-area of the window as appears in the incorrectly-sized preview window itself.
(With browser.taskbar.previews.enable set to false, the single thumbnail for the window is fine.)
Assignee | ||
Comment 15•12 years ago
|
||
I've got some work-in-progress here; not completely happy with the patches yet, but there's a tryserver build at https://tbpl.mozilla.org/?tree=Try&rev=6fa0417656be that should work significantly better than current Nightly. Testing and feedback welcome.
One remaining issue is that the preview is not properly sized for tabs that have not yet been loaded (e.g., after restoring a session with multiple tabs open). I haven't figured out where that needs to be fixed yet...
Assignee | ||
Comment 16•11 years ago
|
||
Here's what I've come up with for this. It seems to result in the expected behavior AFAICT. I don't like the special-casing of 'pending' tabs (see XXX comment), which feels hacky, but I don't understand why they behave differently otherwise.
Tryserver build with this patch is at https://tbpl.mozilla.org/?tree=Try&rev=71dc2a79572a; testing appreciated.
Attachment #747304 -
Flags: review?(jmathies)
Comment 17•11 years ago
|
||
Comment on attachment 747304 [details] [diff] [review]
patch, scale taskbar tab previews appropriately for hidpi
There's some odd rendering behavior on the fx button borders. Probably has to do with scaling. Overall looks good.
Attachment #747304 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 18•11 years ago
|
||
I think that's to do with rendering the button's border gradients to a transparent canvas, or something like that. It's actually a pre-existing issue (you can see the same effect with current release Firefox).
So yes, there are cosmetic issues that could do with further polishing, but at least this fixes the glaringly obvious scaling problem.
Assignee | ||
Comment 19•11 years ago
|
||
Target Milestone: --- → mozilla23
Reporter | ||
Comment 20•11 years ago
|
||
There is a problem with this patch. If I set gfx.direct2d.disabled to TRUE the location Bar box disappears and all that is left is any URL that might be in what was the Location Bar Box.
Reporter | ||
Comment 21•11 years ago
|
||
Comment 22•11 years ago
|
||
Does this happen with the default theme?
Reporter | ||
Comment 23•11 years ago
|
||
(In reply to Greg Edwards from comment #22)
> Does this happen with the default theme?
I forgot to mention that it does. Btw... I'm not using a theme but some Stylish styles.
Assignee | ||
Comment 24•11 years ago
|
||
I tried setting gfx.direct2d.disabled on my Win8 machine, but could not reproduce your problem. Greg, can you reproduce? Jim?
Comment 25•11 years ago
|
||
I can't replicate Gary's issue. I don't think my VM supports Direct2D so changing that pref does nothing anyway.
I'll test again later tonight when I can boot to native Windows.
I did notice that the tab previews are very sluggish to load. I don't remember them being that slow but I'll do some comparisons later. It also perpetually shows a waiting icon for unloaded tabs after you restore your session. (Again, I don't use this feature so I'm unsure if these issues are normal/unrelated.)
Reporter | ||
Comment 26•11 years ago
|
||
Opps... you have to set gfx.direct2d.disabled to FALSE. Sorry.
Comment 27•11 years ago
|
||
It defaults to false and I can't replicate with that setting.
Reporter | ||
Comment 28•11 years ago
|
||
I tried with a new profile and I was able to reproduce my problem.
Assignee | ||
Comment 29•11 years ago
|
||
(In reply to Greg Edwards from comment #25)
> I did notice that the tab previews are very sluggish to load. I don't
> remember them being that slow but I'll do some comparisons later.
Note that the tryserver build is not PGO'd, so it won't perform as well as a "real" Nightly. Once PGO builds with the patch are ready, comparison will be more meaningful.
> It also
> perpetually shows a waiting icon for unloaded tabs after you restore your
> session.
That's the existing behavior; it'd be nice to fix it (IMO), but that would be a separate bug.
Comment 30•11 years ago
|
||
The address bar bug has been around for a while. It wasn't caused by this landing.
Comment 31•11 years ago
|
||
Assignee: nobody → jfkthame
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 32•11 years ago
|
||
Comment on attachment 747304 [details] [diff] [review]
patch, scale taskbar tab previews appropriately for hidpi
[Approval Request Comment]
Bug caused by (feature/regressing bug #): hidpi support
User impact if declined: incorrectly scaled previews for users who have enabled the "Show tab previews in the taskbar" preference via Options
Testing completed (on m-c, etc.): on m-c for a couple of days, confirmed to work as expected in Nightly
Risk to taking this patch (and alternatives if risky): low risk - only modifies scaling within the taskbar tab-preview code, I don't see how it could affect/regress anything else
String or IDL/UUID changes made by this patch: none
Attachment #747304 -
Flags: approval-mozilla-aurora?
Assignee | ||
Updated•11 years ago
|
status-firefox21:
--- → unaffected
status-firefox22:
--- → affected
status-firefox23:
--- → fixed
tracking-firefox22:
--- → ?
Assignee | ||
Comment 33•11 years ago
|
||
Comment on attachment 747304 [details] [diff] [review]
patch, scale taskbar tab previews appropriately for hidpi
Moving approval request from aurora to beta, as this didn't get handled before the merge.
Attachment #747304 -
Flags: approval-mozilla-aurora? → approval-mozilla-beta?
Updated•11 years ago
|
Updated•11 years ago
|
Attachment #747304 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Assignee | ||
Comment 34•11 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•