With this patch moz_container_wayland_surface_lock() always locks MozContainer and needs to be paired with moz_container_wayland_surface_unlock() even if it fails and returns nullptr.
Split moz_container_wayland_add_initial_draw_callback() to two new functions:
- moz_container_wayland_add_initial_draw_callback_locked() is called on locked container and only adds draw callback.
It asserts when MozContainer is already to draw as we don't expect it.
- moz_container_wayland_add_or_fire_initial_draw_callback() is called on unlocked container as it has it's own lock.
It behaves as original moz_container_wayland_add_initial_draw_callback(), i.e. stores draw callback when MosContainer is not visible
and fires draw callback when we're ready to draw.
Differential Revision: https://phabricator.services.mozilla.com/D152276
A requirement of calling `get_relative_transform` is that the child
node is an ancestor of the reference node. To ensure this invariant
is met, we exclude non-ancestor scroll roots from consideration when
picking a scroll root for an atomic picture cache slice. However, this
can mean we select a non-optimal scroll root in some cases. But the
`get_relative_transform` constraint only applies if the spatial nodes
are in a different coordinate system - if we know that the scroll roots
are in the same coordinate system, we can always calculate the correct
relative transform, regardless of ancestry of the nodes. We can rely on
this to relax the condition here, which means we select a more appropriate
scroll root, resulting in much less invalidation and rasterization work
in these cases.
Differential Revision: https://phabricator.services.mozilla.com/D152236
In the presence of complex effects such as backdrop-filter, it's
possible that some picture cache tiles can be drawn in a different
pass to other picture cache tiles. If there are a large number of
child render tasks that are shared between tiles assigned to different
render passes, that may result in a large number of standalone render
target allocations, which can hurt performance and reduce batching
efficiency.
This patch allows shared surfaces to be used when they have a lifetime
that spans more than one pass. We track the `free_after` in the active
shared surface list, and only allocate tasks if they match the lifetime
of other tasks in that shared surface. Existing logic ensures that
surface is returned to the shared target pool only after the `free_after`
pass has occurred.
Differential Revision: https://phabricator.services.mozilla.com/D152235
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
If MaybeRecordFrame is called after EndFrame, this means we are reading from
the back buffer state immediately after a call to SwapBuffers. The state of
the back buffer is undefined in that scenario, and mostly was just returning
old frames. We actually want to call MaybeRecordFrame before EndFrame, so we
get the valid contents of the back buffer before it is swapped out.
Differential Revision: https://phabricator.services.mozilla.com/D151988
A bug is not reported related to "zero copy hardware decoded video" on Windows. Zero video frame copy needs "reuse decoder device ". And it is already enabled on Nightly / Early Beta by Bug 1773714.
RadeonBlockNoVideoCopy is renamed to RadeonBlockZeroVideoCopy
Differential Revision: https://phabricator.services.mozilla.com/D152139
Implement the new dominant axis locking mode for the apz.axis_lock.mode
preference. When using this mode, we do not use the traditional axis locks.
Instead we only consider the input pan displacement for the axis with
a larger value, zeroing out the displacement on the opposite axis.
Differential Revision: https://phabricator.services.mozilla.com/D152104
This patch solves a performance problem and a semantic problem introduced
in Bug 1773109. That Bug changed the term tile cache 'backdrop' to mean
two distinct things:
1) An opaque region spanning the entire tiling area (the sole original
meaning).
2) An opaque region spanning the visible area.
Presently the code tries and fails to maintain both of those meanings in the
BackdropInfo structure. The problem arises when the tiling backdrop is one
color and the visible backdrop is a different color. There's only one color in
the structure! The existing code attempts to circumvent this by setting the
tile cache background_color for the tiling color, and that's slow. Even if it
wasn't slow, the opaque_rect is set for the tiling area instead of the actual
backdrop area, which is semantically confusing, and could lead to incorrect
draw on platforms that support native color layers.
This patch addresses these issues by adding a spanning_opaque_color to the
BackdropInfo structure, which will only be set when there is a backdrop that
covers the tiling area. That color can be used as a clear color for the slice
tiles, when set. This patch also adds a backdrop_rect which indicates the area
of the actual backdrop, if set. This backdrop_rect is used to size the native
color layers, if supported by the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D151942
There are potential races between insertion of the same gradient into
the cache on different threads, as well as acquiring a strong reference
to the GradientStops object racing with the expiration timer.
Differential Revision: https://phabricator.services.mozilla.com/D151981
There are potential races between insertion of the same gradient into
the cache on different threads, as well as acquiring a strong reference
to the GradientStops object racing with the expiration timer.
Differential Revision: https://phabricator.services.mozilla.com/D151981
There are some hit-test use cases that still rely on clip-chains
and invalid clip-chain handles inheriting from the root clip-id
for a pipeline.
This will become irrelevant once the clip-tree patches land next
week, but for now we can restore these to fix a regression going
out in a release.
Differential Revision: https://phabricator.services.mozilla.com/D151880
We spend a significant amount of time in profiles allocating DataSourceSurfaceWrapper
when GetDataSurface is called inside DrawTargetWebgl. We can mark some more surface
types as IsDataSurface to work around this fairly easily.
Differential Revision: https://phabricator.services.mozilla.com/D151898
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
Cristian Tuns
Bogdan Szekely
Glenn Watson
Bas Schouten
Brad Werth
Emilio Cobos Álvarez
Ryan VanderMeulen
Norisz Fay
Owen Rafferty
stransky
Hiroyuki Ikezoe
Cosmin Sabou
Lee Salzman
criss
sotaro
Dan Robertson
az
Butkovits Atila
Kelsey Gilbert
Botond Ballo
Stephen A Pohl
Andrew Osmond
smolnar
Andi-Bogdan Postelnicu