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
This is the result of `cargo +nightly fix --all-features --all-targets`
using a recent rust nightly.
Depends on D33781
Differential Revision: https://phabricator.services.mozilla.com/D33782
--HG--
extra : moz-landing-system : lando
These warnings have been around forever; unused things in the workspace
Cargo.toml file that just need removing.
Differential Revision: https://phabricator.services.mozilla.com/D33781
--HG--
extra : moz-landing-system : lando
This brings DrawTargetCairo and DrawTargetD2D1 inline with DrawTargetSkia's
ability to handle SourceSurfaceOffset properly.
Differential Revision: https://phabricator.services.mozilla.com/D33536
--HG--
extra : moz-landing-system : lando
Having `ItemRange` contain a byte slice means that the `display_list` and
`pipeline_id` don't need to be threaded through code that accesses items from
ItemRange.
Differential Revision: https://phabricator.services.mozilla.com/D32781
--HG--
extra : moz-landing-system : lando
This refactor is in preparation for P3.
When refactoring `next_raw()` to use `peek_from` instead of
`deserialize_in_place`, it became clear that `ItemRange` is holding a slice of
bytes from the incoming serialized display list and `peek_from` could be adapted
work directly on the byte slice.
It was also noticed that the `get()` interface was potentially unsafe; any
`ItemRange` can be passed into `get()` for any display list.
Differential Revision: https://phabricator.services.mozilla.com/D32780
--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
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--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 : 62b7bd85df6475ba6e40fcf3d775daa2a3607f89
extra : source : 489c8d663f7f63ea32d3eb2226d45a84e51aabe8
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 AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--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 AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--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
