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
The prefs handled in this patch are:
apz.paint_skipping.enabled
apz.force_disable_desktop_zooming_scrollbars
apz.mac.enable_double_tap_zoom_touchpad_gesture
dom.event.default_to_passive_touch_listeners
dom.visualviewport.enabled (one use left over)
Differential Revision: https://phabricator.services.mozilla.com/D151795
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
Norisz Fay
Kelsey Gilbert
Stephen A Pohl
Dan Robertson
Brad Werth
Andrew Osmond
smolnar
Andi-Bogdan Postelnicu
Hiroyuki Ikezoe
Glenn Watson
Lee Salzman
criss
Botond Ballo
Kagami Sascha Rosylight
Travis Long
Bogdan Szekely
Jim Blandy
az
Narcis Beleuzu
Sebastian Hengst
Cosmin Sabou
Kai Engert