Clean up mac widget acceleration decision tree
Categories
(Core :: Widget: Cocoa, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
Details
Attachments
(2 files)
Assignee | ||
Comment 1•4 years ago
|
||
We already don't support transparency on non-popup windows, but the code in
nsChildView makes it look like we do.
The changes in this patch have the following effects:
- nsCocoaWindow::SetTransparencyMode no longer sets a white background color on
non-popup windows. - nsChildView picks up the default implementation for Get/SetTransparencyMode
from nsBaseWidget, which ignores calls to SetTransparencyMode and always
returns opaque. The nsChildView methods were only called for non-popup
windows (popup windows call the nsCocoaWindow implementations), so this is
what we want.
Assignee | ||
Comment 2•4 years ago
|
||
In the past we had a problem with transparent windows and window shadows. This
is no longer a problem, because we have dropped the versions of macOS where it
is a problem [1].
So we now support acceleration on all window types.
But we don't necessarily want to use the OpenGL compositor or WebRender for all
windows, due to per-window overhead.
[1] Specifically, the problematic macOS versions are 10.9 and 10.10. On 10.9,
transparent windows with CoreAnimation content never have shadows, and on 10.10,
those windows only get a shadow when they are opened for the second time without
their size changing, see bug 1632895 comment 5. We now support only 10.12+.
Depends on D91828
Comment 4•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/363491cbbfa4
https://hg.mozilla.org/mozilla-central/rev/90d1983a92ad
Description
•