By Bug 1555544 , it became clear that D3D11TextureData and DXGIYCbCrTextureData should not be deleted before calling RenderDXGITextureHostOGL::EnsureLockable() / RenderDXGITextureHostOGL::EnsureLockable().
With WebRender, the EnsureLockable()s are called on RenderThread asynchronously. Then for achieving the above, it is simpler just to keep D3D11TextureData and DXGIYCbCrTextureData alive during host side usage.
There is already a mechanism to do it. By using NotifyNotUsed, it could be done.
Differential Revision: https://phabricator.services.mozilla.com/D33469
--HG--
extra : moz-landing-system : lando
With this change, the tests in question pass on desktop, except for
scrollbar-zoom-resolution-2.html which is annotated as failing.
Differential Revision: https://phabricator.services.mozilla.com/D32775
--HG--
extra : moz-landing-system : lando
The nsDisplayListBuilder bits were added in the previous commit.
Differential Revision: https://phabricator.services.mozilla.com/D32477
--HG--
extra : rebase_source : aec41ccaaab4c99b11ed94baf908d1ec61eaee31
extra : intermediate-source : bbcfdcc12774c1b8d78c6420614141382fed3d40
extra : source : 489c8d663f7f63ea32d3eb2226d45a84e51aabe8
Flickering happened when SharedSurface_ANGLEShareHandle is destroyed before RenderDXGITextureHostOGL::EnsureLockable() is called on Render thread. RenderDXGITextureHostOGL failed at device->OpenSharedResource() . In this case, SharedSurface_ANGLEShareHandle failed to render. Then black was rendered.
If TextureClient::CancelWaitForNotifyNotUsed() is not called, the refcount is kept until the host side ends its usage. The refcount is removed by CompositorBridgeChild::NotifyNotUsed().
Depends on D33265
Differential Revision: https://phabricator.services.mozilla.com/D33143
--HG--
extra : moz-landing-system : lando
CancelWaitForRecycle() does not cancel wait for recycling. It cancels wait for end of usage on host side.
Differential Revision: https://phabricator.services.mozilla.com/D33265
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
The WebRenderBridgeChild now records whether or not it was painting content
while sending display lists to the WebRenderBridgeParent, allowing for
composition times to be recorded for WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D32229
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
Moved assertion statement from GetFrameMetrics() to Metrics() so that internal accesses to the frame metrics are covered as well.
Differential Revision: https://phabricator.services.mozilla.com/D32300
--HG--
extra : moz-landing-system : lando
This will make this site only crash in debug, nightly, or dev edition builds.
Differential Revision: https://phabricator.services.mozilla.com/D32852
--HG--
extra : moz-landing-system : lando
When a blob image invalidates, it doesn't always repaint the entire
blob. When we stored the shared surface references in the DIGroup, it
would incorrectly forgot about images referenced by items that were not
invalidated when it repainted. As such, it could free them too early and
cause a crash when rasterizing the blob in the compositor process.
This did not crash most of the time because the image cache would bail
us out. It takes a full minute for the image cache to expire, but the
issue was more readily reproducible when that timeout was shortened.
We now store the references in BlobItemData, on a per display item
basis. This ensures that when any given item is invalidated, it will
continue referencing any resources that it needs.
Differential Revision: https://phabricator.services.mozilla.com/D32820
We now also post the releasing of the shared surface image keys and
external image ID to the main thread. This allows the current
transaction to complete before freeing the surface, which guards against
cases where the surface is referenced and released somehow in the space
of the same transaction.
Differential Revision: https://phabricator.services.mozilla.com/D32861
If ExternalImageType is just passed from C to rust, it caused crash on non-Windows platform. It was caused by stack corruption. Then &ExternalImageType is used instead of ExternalImageType to bypass the problem.
Differential Revision: https://phabricator.services.mozilla.com/D32436
--HG--
extra : moz-landing-system : lando
Some time ago (bug 819791), InfallibleTArray and nsTArray become equivalent, so
continuing to use InfallibleTArray here will just lead to confusion.
In addition, the overloaded `RegisterPayload` could take either a single
payload or multiple, so I've split it into
`RegisterPayload(CompositionPayload&)` and
RegisterPayloads(nsTArray<CompositionPayload>&)`
Differential Revision: https://phabricator.services.mozilla.com/D32227
--HG--
extra : moz-landing-system : lando
With desktop zooming, we need to separate the concepts of "may have a distinct
visual viewport" from "has mobile viewport sizing logic applied to it".
This can be thought of as completing the disentanglement of zooming from meta
viewport support started in bug 1459260.
Differential Revision: https://phabricator.services.mozilla.com/D32770
--HG--
extra : moz-landing-system : lando
There doesn't seem to be a reason *not* to do this (merely an omission),
and the results we get without it are messing up somewhere with invalidation
and image cache management.
This is likely just a bandaid over a more serious issue, but if we never observe
that issue, does it exist..?
Differential Revision: https://phabricator.services.mozilla.com/D32833
--HG--
extra : moz-landing-system : lando
By default, recycling frames for animated images is enabled. However the
first frame is never recycled because we may need the first frame
immediately if the animation is reset. If only the first frame of an
animation is displayed before shutting down a tab, then it will not
correctly register with the layer state manager prior to its
destruction. This trips an assert incorrectly.
Now we just always register with the layer state manager if recycling is
enabled, and never if recycling is disabled. This allows us to remove
from state information at the cost of requiring a restart to toggle to
recycling pref (which is almost never done now that the feature is
stable.)
Differential Revision: https://phabricator.services.mozilla.com/D32526
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando