Closed
Bug 950511
Opened 11 years ago
Closed 11 years ago
OS X Context Menu uses incorrect Antialiasing Settings even on non-HiDPI screens
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla30
Tracking | Status | |
---|---|---|
firefox27 | --- | unaffected |
firefox28 | --- | unaffected |
firefox29 | --- | fixed |
firefox30 | --- | fixed |
People
(Reporter: armin.ronacher, Assigned: mstange)
References
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20131215030202
Steps to reproduce:
Clicked right to open a context menu in the browser.
Actual results:
The dialog did not use the correct antialiasing settings. The font rendering uses grayscale antialiasing.
Expected results:
I expected subpixel rendering for this menu like any other OS X dropdown.
Reporter | ||
Comment 1•11 years ago
|
||
This occurred first in today's nightly and it did not happen before. It can easily be checked by making a screenshot and zooming in on it. In Nightly the pixels will be gray whereas a screenshot of a Cocoa context menu will show colored pixels upon zooming in from the subpixel rendering algorithm.
Reporter | ||
Comment 2•11 years ago
|
||
Reporter | ||
Comment 3•11 years ago
|
||
Updated•11 years ago
|
Comment 4•11 years ago
|
||
Markus/Steven
Comment 5•11 years ago
|
||
(In reply to :Gijs Kruitbosch (Extremely limited availability until Dec. 18, then PTO until January 2) from comment #4)
> Markus/Steven
Egh, bugzilla fail. Markus, Steven, any idea what's going on here?
Flags: needinfo?(smichaud)
Flags: needinfo?(mstange)
Comment 6•11 years ago
|
||
(In reply to Armin Ronacher from comment #1)
> This occurred first in today's nightly and it did not happen before.
Can you doublecheck it did not occur in the Nightly from the 14th? It's generally very helpful if we have as narrow a regression range as possible. :-)
Reporter | ||
Comment 7•11 years ago
|
||
I can confirm it works with the "2013-12-14-03-02-04-mozilla-central" nightly.
Reporter | ||
Comment 8•11 years ago
|
||
Reporter | ||
Comment 9•11 years ago
|
||
I believe that would be any of those changes: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9d593727eb94&tochange=c049cb230d77
Comment 10•11 years ago
|
||
(In reply to Armin Ronacher from comment #9)
> I believe that would be any of those changes:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=9d593727eb94&tochange=c049cb230d77
Thanks! Close, but it should be: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d593727eb94&tochange=c049cb230d77
(that's mozilla-central vs. mozilla-inbound)
That shows:
47aac229cc2d Benoit Girard — Bug 941095 - Part 2: Disable subpixelaa + component alpha. r=mattwoodrow
7b9ff0798201 Benoit Girard — Bug 941095 - Part 1: Support SetPermitSubpixelAA with Quartz. r=bas
Which sounds highly relevant. There are comments on that bug also lamenting this change. Marking this blocking the other bug. :-)
Blocks: 941095
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(smichaud)
Flags: needinfo?(mstange)
Reporter | ||
Comment 11•11 years ago
|
||
I should point out that this is on a non retina screen notebook obviously but it is a higher than normal DPI screen (1680 x 1050 resolution).
Assignee | ||
Comment 12•11 years ago
|
||
Context menus have text on transparent background and no opaque backdrop to blend with, that's probably why they get subpixelAA disabled even on non-HiDPI displays.
The context menu background is roughly rgba(255, 255, 255, 0.95), so there's still enough of a background to do meaningful subpixelAA blending with, even if it's not completely opaque.
Why do we turn off subpixelAA when drawing into transparent surfaces? Is it because Windows subpixelAA text rendering is buggy when we do that? Should we special-case Mac here?
Summary: OS X Context Menu uses incorrect Antialiasing Settings → OS X Context Menu uses incorrect Antialiasing Settings even on non-HiDPI screens
Reporter | ||
Comment 13•11 years ago
|
||
I know it looks like a really insignificant issue but font rendering being wrong makes an application immediately feel non-native. I would really appreciate if this was fixed :)
Comment 14•11 years ago
|
||
I don't think this is cased by 941095. I have the changes backed out locally and I still see this.
Comment 15•11 years ago
|
||
Do you have both patches backed out locally or just part 2?
This is almost certainly caused by part 1's patch.
Assignee | ||
Comment 16•11 years ago
|
||
I'm going to back out part 1, on both mozilla-central and aurora.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
status-firefox27:
--- → unaffected
status-firefox28:
--- → unaffected
status-firefox29:
--- → affected
status-firefox30:
--- → affected
tracking-firefox29:
--- → ?
Assignee | ||
Comment 17•11 years ago
|
||
Backed out part 1 of bug 941095 on inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c04b296c127
Assignee | ||
Comment 18•11 years ago
|
||
Assignee | ||
Comment 19•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
tracking-firefox29:
? → ---
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in
before you can comment on or make changes to this bug.
Description
•