Change NSView hierarchy in preparation for CoreAnimation windows with working vibrancy
Categories
(Core :: Widget: Cocoa, enhancement, P2)
Tracking
()
People
(Reporter: mstange, Assigned: mstange)
References
Details
Attachments
(4 files)
At the moment, the vibrant NSVisualEffectViews are placed *on top* of our main ChildView. This works as long as we're not using CoreAnimation layers because we can just make them transparent by replacing their drawRect method with something that doesn't paint. But once our window uses CoreAnimation, their drawRect implementation is going to be ignored anyway and they'll erase our window content. So we need to fix the z-order somehow. The vibrant views need to go on bottom, and have the main ChildView on top. Or maybe the NSView hierarchy should stay as it is and we can just put our window's primary CALayer on top somehow. Or maybe we should assemble our ChildView's contents using non-overlapping vibrant and non-vibrant views, with each view getting its own CALayer, but all CALayers sharing the same IOSurface.
|
||
Comment 1•6 years ago
|
||
In my patch, I fixed this by calling `setZPosition:1` on the layer.
|
||
Updated•6 years ago
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 2•6 years ago
|
||
NSView hierarchy before:
- window contentView
- ChildView
- NonDraggableView 1
- NonDraggableView 2
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
- ChildView
NSView hierarchy after:
- window contentView
- ChildView
- ViewRegionContainerView
- NonDraggableView 1
- NonDraggableView 2
- ViewRegionContainerView
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
- ViewRegionContainerView
- ChildView
This allows us to give those container views a new sibling view which stays
fixed in z-order with respect to the NSViews that get created by
mNonDraggableRegion and mVibrancyManager. More specifically, I'm going to add a
view for the drawing of our ChildView ("PixelHostingView") which is going to be
a direct child of the Gecko "ChildView" and a sibling of the
ViewRegionContainerViews; the PixelHostingView needs to always stay on top of
the vibrancy views.
Without the wrapper around the vibrancy views, whenever the vibrant region
changes, a vibrant view would be placed on top of the PixelHostingView and the
order would be wrong.
|
|
Assignee | |
Comment 3•6 years ago
|
||
Otherwise, any views inside the contentView are imbued with a vibrant effect, and
even non-NSVisualEffectView NSViews subtract from the vibrant region of any actual
vibrant views they overlap. This would cause the PixelHostingView to 'erase' the
blue context menu item highlighting.
This behavior is documented on NSVisualEffectView:
It is recommended that you enable vibrancy only in the leaf views of your view
hierarchy. Subviews inherit the vibrancy of their parent. Once enabled in a
parent view, a subview cannot turn off vibrancy. As a result, enabling
vibrancy in a parent view can lead to subviews that look incorrect if they are
not designed to take advantage of the vibrancy effect.
Depends on D19598
|
|
Assignee | |
Comment 4•6 years ago
|
||
This has two advantages:
- The drawing will now correctly be placed "on top" of the vibrancy views.
- We can turn this new view into a layer-hosting view. Layer-hosting views are
supposed to be leaf NSViews; they shouldn't have any children.
Depends on D19599
|
|
Assignee | |
Comment 5•6 years ago
|
||
This is a clearer implementation that achieves the same thing.
Moreover, disabling the clearing by overriding drawRect wouldn't work in
CoreAnimation windows because in CoreAnimation windows, the clearing happens
through a property of the NSVisualEffectView's CALayer, and not through the
view's drawRect implementation - drawRect probably isn't even called in that
context.
Depends on D19600
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/3507a9af7c90 Wrap vibrancy and nondraggable views inside container views. r=spohl https://hg.mozilla.org/integration/autoland/rev/298b7fc66858 Don't return YES from allowsVibrancy for the contentView of context menu windows. r=spohl https://hg.mozilla.org/integration/autoland/rev/61be6672af50 Move any drawing from the ChildView into a new subview called PixelHostingView. r=spohl https://hg.mozilla.org/integration/autoland/rev/be263e3d8bdf Make the ChildView always non-opaque and let NSVisualEffectView handle clearing of vibrant areas. r=spohl
|
||
Comment 7•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3507a9af7c90
https://hg.mozilla.org/mozilla-central/rev/298b7fc66858
https://hg.mozilla.org/mozilla-central/rev/61be6672af50
https://hg.mozilla.org/mozilla-central/rev/be263e3d8bdf
|
||
Updated•5 years ago
|
Description
•