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
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
We've had a constant of 10 hard-coded there since early days.
Turning it into a configurable number allows us to easier tune it and
debug related issues.
Differential Revision: https://phabricator.services.mozilla.com/D32761
--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
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
Remove unecessary Unregister method.
The method is called only once and right prior the parent object gets deleted.
There could be a case where the VRProcessManager destructor gets called before xpcom's shutdown. This would have lead to the now deleted object being called by the Preferences.
Differential Revision: https://phabricator.services.mozilla.com//D32688
--HG--
extra : amend_source : 20b8b4740030ab141856d753a3801b55d607eea3
