Closed Bug 970993 Opened 10 years ago Closed 7 years ago

Font rendering issues when mouse focus shifts from Aero Peek window to actual window

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: thee.chicago.wolf, Unassigned)

Details

Attachments

(4 files)

font-wonkiness.avi
1.62 MB, application/octet-string
Details
Possible patch
1.29 KB, patch
Details | Diff | Splinter Review
clip.avi
2.60 MB, video/x-msvideo
Details
blank-preview-windows-spinning-circle.jpg
33.12 KB, image/jpeg
Details 
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 (Beta/Release)
Build ID: 20140203230027

Steps to reproduce:

I updated from SM2.23 to 2.24 on Windows 7 x64 SP1..

1. Open two windows to two sites with plenty of text on the home page (I choose cnn and osnews).

2. Hover the mouse over the two session in the task bar and choose one session while *carefully* looking at the font.

3. You will see the font briefly go from slightly fuzzy (but readable) to sharp and clear.

This behavior does not happen in SM2.23. Just tested on two different machines with two different video cards (Intel & NVidia). Problem persist on machines running SM 2.24.


Actual results:

When choosing the browser window via Aero peek and switching to it, the font went from slightly fuzzy to sharp.


Expected results:

When choosing the browser via Aero peek and switching to it, the font should stay sharp.
OS: Windows XP → Windows 7
Hardware: x86 → x86_64
Attached file font-wonkiness.avi — 
So I have a visible example of the font weirdness in action. This was done on SM 2.25. As you can see from the vidcap, when hovering the mouse over the Aero-peek window and then moving the mouse focus to the window being peeked at (and then back), the fonts change somewhat.
Summary: Font rendering issues when more than one window is open and selected via Aero Peek → Font rendering issues when mouse focus shifts from Aero Peek window to actual window
I can confirm that setting browser.taskbar.previews.enable=false (mentioned in bug 921874, fixes a different issue) fixes this issue so this bug this appears to be related to bug 839891 as well.
I think what happens here is that we generate previews of all of the tabs as bitmaps, so that when you peek at a tab it will display the bitmap preview rather than the actual tab.

Unfortunately we miscalculate the bitmap size on hi-dpi screens, which might be the problem you're seeing here. We need to port Firefox bug 857061.
Now, if only I could understand how the scaling affects the width and height... also having access to a hi-dpi display would be an advantage.
(In reply to neil@parkwaycc.co.uk from comment #4)
> Now, if only I could understand how the scaling affects the width and
> height... also having access to a hi-dpi display would be an advantage.

Don't know if it matter but I'm only using a 1280X1024 Dell monitor. Certainly not hi-DPI.
OK, so if I peer really closely (it's been two years since I last had my astigmatism checked so I might need updated glasses) I can see a very subtle difference, but that might be an artefact of the way the page is rendered to an intermediate bitmap.
OK, so I asked a GFX developer and he said that the result depends on the flags we use to draw the previews. There is a flag which forces accurate rendering but it's slower so they don't normally suggest using it.
Attached patch Possible patch — — Splinter Review 
The advantage of writing the patch is that I don't have to decide whether we should change the behaviour ;-)
Attachment #8415916 - Flags: review?(bugzilla)
I guess this only gets called when you preview a tab or does Windows periodically generate tab previews in the background (to avoid having no preview when a program is not responsive at that moment), do you happen to know? I wanted to check with Remote JS debugger, but this makes SeaMonkey crash as soon as I set a breakpoint in drawPreview and Windows tries to get a preview. Though I could also just surf around a bit and see if it crashes during that time I guess..
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: SeaMonkey 2.24 Branch → Trunk
Still present on SM 2.26.1.
Still present on SM 2.29b1.
Still present on SM 2.30 and 2.31b.
This seems to be fixed on SM 2.23b2. It was present in SM2.23b1 though. Any idea what patch fixed this?
Attached video clip.avi — 
I guess I spoke to soon. While I was no longer seeing this on betanews.com, it's still present on cnn.com. Interestingly, on betanews I now only see the font issue on text within the "Like" buttons of Facebook, LinkedIn and Twitter. I attached a video of this behavior.
Still present on SM 2.33.1.
Still present on a 2.35 contrib build 20150616034436.
Flags: needinfo?(bugzilla)
Still present on a 2.38 contrib build 20150905154222.
Still present on a 2.39 contrib build 20151021030937.
(In reply to Arthur K. from comment #18)
> Still present on a 2.39 contrib build 20151021030937.
@Arthur, we know it's broken. No need to add extra comments to that effect.

@mcsmurf: any update on your review?
Any news?
Arthur, could you check with a 2.45 to 2.48a1 release built after 08/11. Aero Peek was broken in 2.43 and 2.44 and I used a sledgehammer for WindowsPreviewPerTab.jsm in bug 1256714 and more or less ported the Firefox one 1:1.

You can try Adrians 2.45 release for a test drive:

https://l10n.mozilla-community.org/~akalla/unofficial/seamonkey/nightly/latest-comm-release-windows32/
Flags: needinfo?(thee.chicago.wolf)
Tested with the 2.45 build and it appears to be working again. Nice work! \o/
Flags: needinfo?(thee.chicago.wolf)
Was hoping this would also have helped with bug 921874, but alas. As an added bonus, it seems to have also fixed the blank Aero peek preview windows I've seen in recent builds. 

I was using the 2.46 (build 20160804082024) from akalla's to repro that.
>> Was hoping this would also have helped with bug 921874, but alas.

No I looked at this one too and its somewhere in the browser code. 

There is still a problem with Aero. If you set the zoom level  < 100% you will get the blank preview again and > 100% results in some corruption. This is likely a toolkit bug and also occurs in Firefox. The correspondig Bug 1269810 has not been confirmed by a Firefox dev yet.
Ok. I'll close it noting it's fixed in SM builds newer than 8/11, yes?
You have my blessing :) I am clearing needinfo and review. The patch would need to be changed anyway.
Flags: needinfo?(bugzilla)
Comment on attachment 8415916 [details] [diff] [review]
Possible patch

Clearing review for obsolete patch.
Attachment #8415916 - Flags: review?(bugzilla)
Frank's patch works for builds newer than 8/11/2016.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.