The biggest thing for m-c is the addition of a single-duration API for
timing_distribution that was previously papered over in the FOG-specific impl
using the SDK's multi-duration API.
This ought to drop unnecessary `vec![]`-caused allocations for some fairly-
high-frequency calls to AccumulateRawDuration.
Differential Revision: https://phabricator.services.mozilla.com/D209864
The quad primitive info takes a scale+offset transform which is applied to the coordinate space of the pattern. This allows the quad coorinates to be optionally specified in device space while the pattern remains in layout space.
Differential Revision: https://phabricator.services.mozilla.com/D209694
During display list and scene building, there are two coordinate
remapping steps that occur:
1) From stacking context coords -> reference frame relative coords
2) From pre-scrolled coords -> removed external scrolling offsets
These were previously handled in one place, however we want to
split these up so that we can apply snapping _after_ step 1 but
prior to step 2. This will allow us to have fractional external
scroll offsets that don't affect snapping. These will be snapped
later on during frame build after applying any (possibly fractional
APZ scroll offsets). This is a cheap operation during frame building
as we only need to snap and modify the transform matrices, not
individual primitives.
This patch should have no functional changes, it's prep work for
the changes referenced above. It does move all of step 1 to be
done during DL building in the content process, and all of step
2 to be done during scene building in the GPU process. In future,
if/when we resolve the issues we have with reliance on cross-iframe
knowledge for fractional snapping, we can move step 2 (including
snapping) in to the content process as well.
Further, as part of the DL bypass work, we will need to remap coord
spaces during DL building in a differeny way, which this simplifies.
Differential Revision: https://phabricator.services.mozilla.com/D208427
Bug 1886739 made it so that we attempt to give sticky frames their own
tile caches as a performance improvement. A consequence of this is
that it may shift content in to non-opaque tiles, which in turn
prevents subpixel AA from being used.
This tradeoff already exists when deciding to give fixed position
frames their own tile caches, therefore we allow users to prefer
subpixel AA over the improved performance via the pref
gfx.webrender.quality.force-subpixel-aa-where-possible. This patch
makes us take the value of that pref in to account when deciding
whether to layerize sticky frames, as well as fixed position ones.
Differential Revision: https://phabricator.services.mozilla.com/D209923
When we reset the dirty rect to PictureRect::zero() on a Tile, we must
also mark the Tile as valid. This prevents the propagation of zero-area
rectangles which can otherwise ultimately cause BeginDraw failures.
Differential Revision: https://phabricator.services.mozilla.com/D209340
This will cause a (small) GPU performance regression in some cases
(large radial gradients that have a clip mask on them), but fixes
the correctness issues we have for now. We intend to fix the
underlying problem (bug #1892398) soon and then re-enable these
primitives to use tiled / nine-patch render modes.
Differential Revision: https://phabricator.services.mozilla.com/D209077
This will cause a (small) GPU performance regression in some cases
(large radial gradients that have a clip mask on them), but fixes
the correctness issues we have for now. We intend to fix the
underlying problem (bug #1892398) soon and then re-enable these
primitives to use tiled / nine-patch render modes.
Differential Revision: https://phabricator.services.mozilla.com/D209077
Not immediately necessary but when cached quads or patterns that read a texture are implemented, There will be opaque segments taking render tasks as input. Currently the code is a bit error prone because some parts of the code advertize a certain behavior that is later overruled. This patch makes things more explicit and flexible.
Differential Revision: https://phabricator.services.mozilla.com/D208508
The two cases share some code, but the next patch will add extra logic
specific to the StickyFrame case, which makes it cleaner to split them.
Differential Revision: https://phabricator.services.mozilla.com/D208236
The two cases share some code, but the next patch will add extra logic
specific to the StickyFrame case, which makes it cleaner to split them.
Differential Revision: https://phabricator.services.mozilla.com/D208236
To determine whether to work around a known driver bug (bug 1787520)
affecting certain Mali drivers, we parse the GL_VERSION string which
follows a common format on Mali devices.
In this bug, however, we encountered a device with a slightly
different version format. The "v", "r" and "p" numbers we care about
are still present, but the trailing string that begins with a "-" was
not. This was tripping up our parsing logic even though we ignore its
value. This patch handles the case where the trailing string is not
present, meaning we correctly apply the existing workaround, and avoid
the bug on this device.
Differential Revision: https://phabricator.services.mozilla.com/D209004
During display list and scene building, there are two coordinate
remapping steps that occur:
1) From stacking context coords -> reference frame relative coords
2) From pre-scrolled coords -> removed external scrolling offsets
These were previously handled in one place, however we want to
split these up so that we can apply snapping _after_ step 1 but
prior to step 2. This will allow us to have fractional external
scroll offsets that don't affect snapping. These will be snapped
later on during frame build after applying any (possibly fractional
APZ scroll offsets). This is a cheap operation during frame building
as we only need to snap and modify the transform matrices, not
individual primitives.
This patch should have no functional changes, it's prep work for
the changes referenced above. It does move all of step 1 to be
done during DL building in the content process, and all of step
2 to be done during scene building in the GPU process. In future,
if/when we resolve the issues we have with reliance on cross-iframe
knowledge for fractional snapping, we can move step 2 (including
snapping) in to the content process as well.
Further, as part of the DL bypass work, we will need to remap coord
spaces during DL building in a differeny way, which this simplifies.
Differential Revision: https://phabricator.services.mozilla.com/D208427
Before this patch, a large occluder can end up being rendered late if current_batch_index does not point to the top of the batch list.
This helps swgl a lot on slack which has an enormous background conic gradient.
Differential Revision: https://phabricator.services.mozilla.com/D207556
Before this patch, a large occluder can end up being rendered late if current_batch_index does not point to the top of the batch list.
This helps swgl a lot on slack which has an enormous background conic gradient.
Differential Revision: https://phabricator.services.mozilla.com/D207556
This simplifies the common infrastructure, removes two varyings from the common set and will allow other patterns to handle sampling differently if they need it (for example an upcoming repeating pattern).
In addition:
- the color parameter is always passed to the fragment shader (it used to be only when no uv_rect was passed).
- v_flags was reorganized a bit so that w is used by the common infrastructure and xyz are available for patterns to use.
Differential Revision: https://phabricator.services.mozilla.com/D206098
For now we skip the quad path if the gradient is tiled. The plan is to add a repeating quad pattern that can repeat the result of a render task and get all quad patterns to use that.
Differential Revision: https://phabricator.services.mozilla.com/D204774
The loop was submitting a single command in the command buffer, always using the textured quad shader which worked when the interior is a solid color but not for other patterns.
This patch goes over the nine-patch segments twice, first generating a segmented primitive for the interrior with the appropriate pattern shader, and then the corners with the textured shader.
The patch tries to stay in the spirit of the existing code. I'm not super fond of the result. If the pattern isn't opaque the nine-patch will batch poorly since the both the interrior and corner parts are batched using the same rect. Also I suspect we'll find that we need more flexibility if/when we implement borders using quads. By then we'll probably have a clearer idea of the best way to handle segments in general.
Differential Revision: https://phabricator.services.mozilla.com/D206036
Update:
- UniFFI to 0.27.1
- Glean to 59.0.0
- App-services to a recent version
This removes the need for the goblin build hack, although we still have
duplicate versions of goblin since UniFFI is ahead of the moz-central
version. I think that should be easy to resolve as a follow-up.
Updating uniffi-bindget-gecko-js based on upstream changes:
- Clone objects before lowering them
(https://github.com/mozilla/uniffi-rs/pull/1880)
- Use u64 for the RustBuffer length and capacity field
(https://github.com/mozilla/uniffi-rs/pull/1978)
I didn't implement the new callback interface VTable code. Instead I
simply disabled the one fixture that tests it. I'd rather implement
https://bugzilla.mozilla.org/show_bug.cgi?id=1888668 first, since that
will simplify the process a bunch. The only real-world use-case for
callbacks that I know of is Mark's logging changes, but that will
require implementing trait interfaces anyways so I'd rather wait than
write a bunch of C++ code that we then throw away.
Differential Revision: https://phabricator.services.mozilla.com/D206130
Update:
- UniFFI to 0.27.1
- Glean to 59.0.0
- App-services to a recent version
This removes the need for the goblin build hack, although we still have
duplicate versions of goblin since UniFFI is ahead of the moz-central
version. I think that should be easy to resolve as a follow-up.
Updating uniffi-bindget-gecko-js based on upstream changes:
- Clone objects before lowering them
(https://github.com/mozilla/uniffi-rs/pull/1880)
- Use u64 for the RustBuffer length and capacity field
(https://github.com/mozilla/uniffi-rs/pull/1978)
I didn't implement the new callback interface VTable code. Instead I
simply disabled the one fixture that tests it. I'd rather implement
https://bugzilla.mozilla.org/show_bug.cgi?id=1888668 first, since that
will simplify the process a bunch. The only real-world use-case for
callbacks that I know of is Mark's logging changes, but that will
require implementing trait interfaces anyways so I'd rather wait than
write a bunch of C++ code that we then throw away.
Differential Revision: https://phabricator.services.mozilla.com/D206130
Tamas Szentpeteri
Yannis Juglaret
Glenn Watson
Chris H-C
Nicolas Silva
Jamie Nicol
Ashley Hale
Sandor Molnar
Norisz Fay
Botond Ballo
pstanciu
Stanca Serban
Jan-Erik Rediger
Aron Cseh
Ben Dean-Kawamura
Cristian Tuns