There are 10 enum cases that we track internally, one of which isn't
emitted as telemetry. These cases are 0-indexed to match the enum values.
0 / NotVideo: Not used for telemetry. No video is showing.
1 / LowPower: We are showing exactly one video and we believe we are
hitting the video low power mode. We don't use "Success" because of name
collision in the telemetry generation.
2 / FailMultipleVideo: There is more than one video visible.
3 / FailWindowed: The video is being viewed in windowed mode, not
fullscreen mode, so low power mode is not possible.
4 / FailOverlaid: The video has something on top of it (like captions).
5 / FailBacking: The layer directly underneath the video does not cover
the window or does not have a black background.
6 / FailMacOSVersion: The system is running a too-early version of macOS.
7 / FailPref: The user has disabled the
`gfx.core-animation.specialize-video` pref.
8 / FailSurface: The video is encoded in such a way we can't decode it to
a qualifying pixel format.
9 / FailEnqueue: The video didn't enqueue properly, and we fell back to a
non-video display path.
Differential Revision: https://phabricator.services.mozilla.com/D129453
There are 10 enum cases that we track internally, one of which isn't
emitted as telemetry. These cases are 0-indexed to match the enum values.
0 / NotVideo: Not used for telemetry. No video is showing.
1 / Success: We are showing exactly one video and we believe we are
hitting the video low power mode.
2 / FailMultipleVideo: There is more than one video visible.
3 / FailWindowed: The video is being viewed in windowed mode, not
fullscreen mode, so low power mode is not possible.
4 / FailOverlaid: The video has something on top of it (like captions).
5 / FailBacking: The layer directly underneath the video does not cover
the window or does not have a black background.
6 / FailMacOSVersion: The system is running a too-early version of macOS.
7 / FailPref: The user has disabled the
`gfx.core-animation.specialize-video` pref.
8 / FailSurface: The video is encoded in such a way we can't decode it to
a qualifying pixel format.
9 / FailEnqueue: The video didn't enqueue properly, and we fell back to a
non-video display path.
Differential Revision: https://phabricator.services.mozilla.com/D129453
layers.
This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Depends on D128131
Differential Revision: https://phabricator.services.mozilla.com/D128545
layers.
This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Depends on D128131
Differential Revision: https://phabricator.services.mozilla.com/D128545
This makes the macOS native compositor claim the ability to handle color
layers and makes NativeLayerCA actually do it. Color layers have a different
structure than other layers. Color layers apply the color to the
wrappingCALayer, and have no contentCALayer at all. That means that the
color layers are always sized to the layer's clip rect.
This also contains a drive-by fix to handle the case where an mOpaquenessTintLayer
exists when mMutatedSpecializeVideo is set to true. Before this change, in such a
case, the opaqueness layer will not be associated with the recreated wrapping layer.
Differential Revision: https://phabricator.services.mozilla.com/D128545
This additionally changes acceptProvidedSublayers to a C++ lambda function,
which keeps the compiler happy with iterating over the new nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D143220
This additionally changes acceptProvidedSublayers to a C++ lambda function,
which keeps the compiler happy with iterating over the new nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D143220
This additionally changes acceptProvidedSublayers to a C++ lambda function,
which keeps the compiler happy with iterating over the new nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D143220
This adds additional logic to detect when video requires a specialized video
layer. The logic from NativeLayerCA::Representation::CanSpecializeSurface has
been rolled into the mainline decision of whether or not to specialize the
video layer at all.
Depends on D137082
Differential Revision: https://phabricator.services.mozilla.com/D135634
This adds additional logic to detect when video requires a specialized video
layer. The logic from NativeLayerCA::Representation::CanSpecializeSurface has
been rolled into the mainline decision of whether or not to specialize the
video layer at all.
Differential Revision: https://phabricator.services.mozilla.com/D135634
There are 13 enum cases that we track internally, 2 of which aren't emitted
as telemetry. These cases are 0-indexed to match the enum values.
0 / None: Not used for telemetry.
1 / FailNotVideo: Not used for telemetry.
2 / Active: This should be "Success" but that creates name-collision
compilation errors for Linux. This is the only enum that indicates that the
feature is working. We want this high, relative to all other states. That
would mean that the feature is providing value for the ways that users tend to
watch video on the web, and what video they choose to watch.
3 / FailPref: We expect to never see this. The pref is on by default so this
indicates that users are turning the feature off (to avoid bugs, perhaps).
4 / Fail10_13: This should go down over time as users upgrade their systems.
5 / FailFullscreen: This will teach us about user habits. If this number is
high in aggregate, it means that users tend to watch video in windows, where
we can't hit detached mode.
6 / FailIsoMouse: We had a qualifying video, but didn't isolate it because the
mouse was moving (which probably means that video controls were showing even
if they are not on top of the video).
7 / FailIsoTopVideo: This indicates that there is a video on screen, but it
is not the topmost layer.
8 / FailIsoSize: The video is topmost, but not large enough, relative to the
screen.
9 / FailIsoCenter: The video is topmost and large enough, but not centered.
10 / FailIsoOneVideo: There is a topmost video, but there's at least one other
video in the layer stack.
11 / FailSurface: This we want to see go down over time. Lowering values
here indicate that more video on the web is using paths in Firefox that support
the low power mode.
12 / FailEnqueue: We expect to never see this. If we do, the only time it
should occur is when we are out of memory. If it occurs at other times, then
we are failing to use the Core Media APIs correctly.
Differential Revision: https://phabricator.services.mozilla.com/D129453
There are 13 enum cases that we track internally, 2 of which aren't emitted
as telemetry. These cases are 0-indexed to match the enum values.
0 / None: Not used for telemetry.
1 / FailNotVideo: Not used for telemetry.
2 / Success: This is the only enum that indicates that the feature is working.
We want this high, relative to all other states. That would mean that the
feature is providing value for the ways that users tend to watch video on the
web, and what video they choose to watch.
3 / FailPref: We expect to never see this. The pref is on by default so this
indicates that users are turning the feature off (to avoid bugs, perhaps).
4 / Fail10_13: This should go down over time as users upgrade their systems.
5 / FailFullscreen: This will teach us about user habits. If this number is
high in aggregate, it means that users tend to watch video in windows, where
we can't hit detached mode.
6 / FailIsoMouse: We had a qualifying video, but didn't isolate it because the
mouse was moving (which probably means that video controls were showing even
if the are not on top of the video).
7 / FailIsoTopVideo: This indicates that there is a video on screen, but it
is not the topmost layer.
8 / FailIsoSize: The video is topmost, but not large enough, relative to the
screen.
9 / FailIsoCenter: The video is topmost and large enough, but not centered.
10 / FailIsoOneVideo: There is a topmost video, but there's at least one other
video in the layer stack.
11 / FailSurface: This we want to see go down over time. Lowering values
here indicate that more video on the web is using paths in Firefox that support
the low power mode.
12 / FailEnqueue: We expect to never see this. If we do, the only time it
should occur is when we are out of memory. If it occurs at other times, then
we are failing to use the Core Media APIs correctly.
Differential Revision: https://phabricator.services.mozilla.com/D129453
This fixes a correctness issue. Since NativeLayerCA Representations can
generate new CALayers under certain conditions, the NativeLayerRootCA must
check to see if a rebuild is necessary when committing.
Differential Revision: https://phabricator.services.mozilla.com/D131307
This guarantees that any time mMutatedSpecializeVideo is set to true, the next
call to ApplyChanges will receive the value that actually triggered the
mutation. This was *probably* already true, but this change makes it explicit
and similar to other state changes.
Differential Revision: https://phabricator.services.mozilla.com/D129452
In addition to adding locks around the accessors, this also removes the call
to `CommitToScreen` from the fullscreen accessor, which was probably
redundant and definitely made the main thread call `Commit` which introduces
possible concurrency errors.
Differential Revision: https://phabricator.services.mozilla.com/D129425
When isolating video layers, changes to sublayers that we are already ignoring
should not cause us to change our sublayers. This patch checks to see if the
changes to sublayers can all be safely ignored.
Differential Revision: https://phabricator.services.mozilla.com/D129330
This ensures that we only do the extra work of EnqueueSurface when the video
format is eligible for the low power detached mode.
Differential Revision: https://phabricator.services.mozilla.com/D128420
This is another requirement for the video display layer to be detached and use
less power: the layer must be topmost and have only a black layer behind it.
Differential Revision: https://phabricator.services.mozilla.com/D124150
This patch reconstitutes a CMSampleBuffer from an IOSurface using spoofed
timing information to display the single sample immediately. Using this method
is neccessary, but not sufficient for the video display layer to be detached
and use less power. The remaining requirements are covered by later parts of
this patch series.
Differential Revision: https://phabricator.services.mozilla.com/D116643
This is scaffolding for checking the conditions where the specialized video
layers will reduce power consumption. In the next part, we'll actually create
and fill the specialized layers.
Differential Revision: https://phabricator.services.mozilla.com/D107292
The size of the NativeLayerCA::Representation struct seems to be a factor in
the power consumption of native layer updates. Converting this series of bools
into a bitfield is an easy way to reduce the structure size.
Differential Revision: https://phabricator.services.mozilla.com/D124992
This allows the native layer code to determine when specialized video layers
might be beneficial for reducing power consumption.
Differential Revision: https://phabricator.services.mozilla.com/D124149
To be more consistent with the rest of the code base and make the
header file easier to read. Also remove an usused function declaration.
Differential Revision: https://phabricator.services.mozilla.com/D119335
Make the vsync source request frame callbacks from opaque native
layers. This is necessary as opaque layers may occlude the
MozContainer surface, which is normally used for frame callbacks.
Wayland compositors may (and are encouraged to) optimize away
such callbacks, so we need to make sure to request frame callbacks
from actually visible surfaces.
Callbacks are requested for all layers, but only the first callback
will trigger the vsync source.
In order to get this right concerning multiple requested callbacks,
possibly being called from different threads etc., introduce a
callback abstraction, `CallbackMultiplexHelper`, to make this simple
to handle for callers.
Differential Revision: https://phabricator.services.mozilla.com/D116026
This interface is never used directly, and the only consumers of the virtual functions are by the derived classes themselves.
Differential Revision: https://phabricator.services.mozilla.com/D93180
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Differential Revision: https://phabricator.services.mozilla.com/D89864
This requires passing down the window size down in a different way, because the
NativeLayerRootSnapshotter does not know the window size otherwise.
At the same time, this patch also removes WindowNLRS and makes the NativeLayerRoot
implement the profiler_screenshots::Window interface directly.
Depends on D89863
Differential Revision: https://phabricator.services.mozilla.com/D89864
