This is a follow up to bug 1564655. It removes the offset from ToDeviceSpace
and thus moves item rects into absolute space which is now the same coordinate
space as the recordings are in.
We also adjust item bounds for fallback blobs.
Some additional changes that need happen to:
1. In Moz2DImageRenderer we can reunify the origin because the recording and
the recording metadata return to using the same coordinate space.
2. The calls to PushLayer can return to using the item bounds
which are now in the same coordinate space.
3. This dirty rect which remains in images space is adjusted during merging.
Differential Revision: https://phabricator.services.mozilla.com/D38015
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
Currently items are painted with a context that has a transform of
-mLayerBounds.TopLeft(). This means that if TopLeft() changes the commands
will be in the wrong place because the -TopLeft() offset is baked into the
recording.
I don't think we've ever needed to support painting without this transformed
baked in so there were some infrastructure changes that needed to be made to
make this possible. Most of the problems come from the use of
gfxContext::GetClipExtents which expose the bounds of the underlying surface.
The biggest of these was fixed by the CreateClippedDrawTarget rewrite. The rest
should be handled by ensuring that the DrawTarget has bounds that are at least
as big as the union of the individual item bounds. i.e. GetClipExtents should
never intersect with bounds of the item.
This change has a couple of parts:
1. Store mLayerBounds.TopLeft() in the recording so that it will be subtracted
during replay
2. Use mLayerBounds as the Rect of the RecordingDrawTarget
3. Don't include mLayerBounds.TopLeft() in the transform during recording.
4. Adjust the dirty rect by recordingOrigin before we use it as a clip so that
it stays in the right place.
5. In PaintContainerItem the bounds parameter of PushLayer is in device space
so we need to account for the shift in the location of device space in the
DrawTargetRecording.
Differential Revision: https://phabricator.services.mozilla.com/D37513
--HG--
extra : moz-landing-system : lando
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
This also disables the test on Windows 7 because the newly enabled subtests
fail intermittently there. We don't care so much about Windows 7 these days,
and I don't have a local setup to reproduce it, so I didn't investigate the
failure.
Differential Revision: https://phabricator.services.mozilla.com/D37819
--HG--
extra : moz-landing-system : lando
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
--HG--
extra : source : cb1d78b00e25dd7fcfec86216c7a83c85ce9a982
extra : histedit_source : 68a31189f05998ba3b8a29a624d7ebe37636c4d9
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
The APZ tree walk is recursive but the render root was not being updated when
walking up out of a subtree with a different render root. This changes the
code to use a stack and push/pop the render root for subtrees as we enter
and exit the subtrees as part of the tree walk.
Differential Revision: https://phabricator.services.mozilla.com/D37614
--HG--
extra : moz-landing-system : lando
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
--HG--
extra : moz-landing-system : lando
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
--HG--
extra : moz-landing-system : lando
This lets us record at arbitratry offsets. Without it gfxContext::GetClip()
would break because it uses DrawTarget::GetRect() as the initial rect that it
intersects subsequent clips with. We also can't just use a DrawTargetOffset
because that applies a transform to the inner DrawTarget and will impact the
recorded commands.
Differential Revision: https://phabricator.services.mozilla.com/D37075
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
When double buffering is enable with compositor, DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL is used without DirectComposition. There are some devices that swap chain with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL does not work well. In this case, device reset happens very often. To avoid the situation, the double buffering needs to be disabled when device reset happens.
Differential Revision: https://phabricator.services.mozilla.com/D36579
--HG--
extra : moz-landing-system : lando
