These are extensions to the Moz2D RecordedEvents to record and play back canvas
texture related functions in the GPU process.
The CanvasTranslator handles the playback of these and the Moz2D ones.
This is so we don't need to lock the previous back buffer when it might also be
locked by the compositor. These locks are generally for copying to the next
back buffer or when getting image data from the previous back buffer.
This also makes it easier to asynchronously cache the DataSourceSurface in the
GPU process, when a page is using getImageData. This is done in a later patch.
Not only animating transform-like properties, but also non-animating ones have
to be passed into the compositor, so the final transform matrix could
take them into account (on the compositor).
Differential Revision: https://phabricator.services.mozilla.com/D33580
--HG--
extra : moz-landing-system : lando
This exercises the transforms propagated in bug 1530661, which is
WebRender-specific (because the events only have the target layers id
set on them if WR is enabled).
Differential Revision: https://phabricator.services.mozilla.com/D32189
--HG--
extra : moz-landing-system : lando
I split this out so it's more obvious what pieces need to be modified
to add additional functions.
Differential Revision: https://phabricator.services.mozilla.com/D32188
--HG--
extra : moz-landing-system : lando
This introduces the framework and helpers needed to do this kind of testing,
and adds a basic sanity test that ensures some basic functionality.
Differential Revision: https://phabricator.services.mozilla.com/D32187
--HG--
extra : moz-landing-system : lando
Apparently leaving these listeners registered can leak DOM windows
(in some circumstances that I don't fully comprehend) which causes
test failures when running on debug builds. At any rate, unregistering
listeners on cleanup seems like a good thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D32185
--HG--
extra : moz-landing-system : lando
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
This class is only inherited by BrowserChild and seems to be a remnant of
the B2G days.
Differential Revision: https://phabricator.services.mozilla.com/D33567
--HG--
extra : rebase_source : 504b3185b4cf59bcd4150935b9569641fbf8f844
extra : source : 82604ba5659a292616a10d19ad3f977b3094b33e
extra : histedit_source : 24b70700a41aeac53e2f34bf1f190867ffb75af6
Code outside of BrowserParent should just get the LayersId from a getter
and not worry about RenderFrame.
Differential Revision: https://phabricator.services.mozilla.com/D33562
--HG--
extra : rebase_source : 63f9f9680a7cb16a18d9e56999e02a124aa63429
extra : source : e86839ca63260b09184755c98890fa8abf371530
extra : histedit_source : 34333f5f78ecf9b4f3e12c6175a6e81724a41fb2
gfxPlatform::GetSourceSurfaceForSurface and CreateDrawTargetForSurface
are both static methods that we sometimes use via the pattern
gfxPlatform::GetPlatform()->... This is problematic because this forces
gfxPlatform to be initialized in the process, and in the GPU process, we
don't support this. It should be safe to call these methods without
initializing gfxPlatform, so this patch removes the GetPlatform() call.
GetSourceSurfaceForSurface may end up initializing gfxPlatform anyways,
depending on whether or not a DrawTarget was given. This should not be a
concern for the crashes observed in bug 1435586.
Differential Revision: https://phabricator.services.mozilla.com/D33785
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
Bob Owen
Daniel Varga
Csoregi Natalia
Boris Chiou
Miko Mynttinen
Kartikaya Gupta
Bas Schouten
shindli
sotaro
Ryan Hunt
Andrew Osmond
Noemi Erli
Botond Ballo
Barret Rennie
Coroiu Cristina
Boris Zbarsky
Srujana Peddinti