The change contains a number of incremental improvements with the main goal of:
- allocating exactly as many tile as required by the app
- respecting the picture caching option
Differential Revision: https://phabricator.services.mozilla.com/D24740
--HG--
extra : moz-landing-system : lando
Moved non-POD member of VRDisplayInfo to VRDisplayHost
VRDisplayInfo is now also a POD type (And asserted so)
Use PlainOldDataSerializer for POD types in VRMessageUtils
Moved non-POD member of VRDisplayInfo to VRDisplayHost
VRDisplayInfo is now also a POD type (And asserted so)
Differential Revision: https://phabricator.services.mozilla.com/D24577
--HG--
extra : moz-landing-system : lando
Several tests in marionette are failing in `Mn`, `MnH`, `MG` for windows10-aarch64.
This patch disables the tests that are failing.
Individual issues are recorded in:
- 1536278
- 1536369
Differential Revision: https://phabricator.services.mozilla.com/D23991
--HG--
extra : moz-landing-system : lando
This has no functional effect but makes it consistent with other similar
sites.
Depends on D24650
Differential Revision: https://phabricator.services.mozilla.com/D24651
--HG--
extra : moz-landing-system : lando
If we try to send them separately as we were before, we can run into
cases where we try to destroy the actors and then send the OpRemoveTexture,
which crashes.
Differential Revision: https://phabricator.services.mozilla.com/D23987
--HG--
extra : moz-landing-system : lando
As discussed in IRC. AFAICT the ORTHO_NEAR|FAR_PLANE should match
up with the ranges of valid ZBufferIds, but please double-check
me.
Differential Revision: https://phabricator.services.mozilla.com/D23599
--HG--
extra : moz-landing-system : lando
This corrects A) An issue encountered with our strategy for skipping
the end_pass call for all but an offscreen render target. See the
comment above the end_pass call for details, and B) An issue with
depth clearing where we do not clear the whole rect if there are
multiple non-intersecting documents.
Differential Revision: https://phabricator.services.mozilla.com/D23056
--HG--
extra : moz-landing-system : lando
Just a little rename for clarity - I ended up scratching my head at
something for a little more time than I should have because I assumed
this was synchronous without looking at the implementation.
Differential Revision: https://phabricator.services.mozilla.com/D21584
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
Instead of having special code in the velocity tracker to deal with axis
locking and cancel out the position delta, we can apply axis locking
when we transition from the pan to the fling and simply cancel the
velocity on locked axes. This avoids the problem where we start a fling
from an axis lock but velocity information from prior to the axis lock
is used to compute the (perhaps unexpected) fling trajectory.
Differential Revision: https://phabricator.services.mozilla.com/D24060
--HG--
extra : moz-landing-system : lando
If we try to send them separately as we were before, we can run into
cases where we try to destroy the actors and then send the OpRemoveTexture,
which crashes.
Differential Revision: https://phabricator.services.mozilla.com/D23987
--HG--
extra : moz-landing-system : lando
As discussed in IRC. AFAICT the ORTHO_NEAR|FAR_PLANE should match
up with the ranges of valid ZBufferIds, but please double-check
me.
Differential Revision: https://phabricator.services.mozilla.com/D23599
--HG--
extra : moz-landing-system : lando
This corrects A) An issue encountered with our strategy for skipping
the end_pass call for all but an offscreen render target. See the
comment above the end_pass call for details, and B) An issue with
depth clearing where we do not clear the whole rect if there are
multiple non-intersecting documents.
Differential Revision: https://phabricator.services.mozilla.com/D23056
--HG--
extra : moz-landing-system : lando
Just a little rename for clarity - I ended up scratching my head at
something for a little more time than I should have because I assumed
this was synchronous without looking at the implementation.
Differential Revision: https://phabricator.services.mozilla.com/D21584
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
A possible alternative would be to have the main thread already paint a
displayport at the target position of a requested visual update as part of
the same transaction that requests the update.
There are a couple of reasons we may not want to do that:
1) APZ could reject the requested visual update under certain conditions,
e.g. if there is a higher-priority layout update.
2) It would break the property that the displayport in the main thread's
scroll metadata is relative to the scroll offset in said metadata.
Various places assume this and untangling that seems tricky.
This does mean that if the main thread requests a visual update to "far away"
(outside the existing displayport), we can get temporary checkerboarding
before the content at the target position is painted. However, it's
straightforward for callers to work around that, by changing the layout scroll
offset _and_ scheduling a visual update if they wish to visual-scroll far
away.
Differential Revision: https://phabricator.services.mozilla.com/D23902
--HG--
extra : moz-landing-system : lando
This patch shouldn't have any functional effect. It's motivated by
some changes needed to implement clip masks in pixel local storage,
but these are also general improvements that stand alone. Specifically:
- Remove clip_task_index from the global PrimitiveHeader struct.
In most cases, the clip task is supplied in the BrushInstance
structure, so it makes no sense to have this as a common field,
where it is generally unused. Instead, there is now an extra
'user data' field available in the PrimitiveHeader. Non-brush
shaders (text_run and split_composite) use that extra field to
store the clip task address, while the brush shaders gain an extra
(currently unused) user data field.
- In turn, this means there is no need to unconditionally try
and retrieve the first clip task address for a primitive
during batching. This was previously used to initialize the
PrimitiveHeader structure.
Differential Revision: https://phabricator.services.mozilla.com/D24312
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando