RecordedTextureData records TextureData calls for play back in the GPU process.
CanvasChild and CanvasParent set up the recorder and translator.
They also help to manage the starting of translation and co-ordinating the
translation with the frame transactions.
This patch also includes other changes to wire up recording and playback.
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
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 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
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
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
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
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
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
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
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
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
Typically this would be handled by the visible region of the layer
changing. However, since we build the container layer for the filter
item directly the visible region doesn't get set or checked. As a
shortcut to using more of FLB we just ensure the building rect hasn't
changed.
The situations under which this bugs shows up are somewhat rare:
- The filtered item needs to be in transform so that it's bounds
are not changed by scrolling.
- The filtered item needs to contain items that change their drawing
depending on the building rect. In this case an image with downscale
on decode.
- The filter needs to be unsupported by WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D29879
--HG--
extra : moz-landing-system : lando
We could do some work to make sure that we don't unnecessarily
PushLayer, but that's better left for the future.
Differential Revision: https://phabricator.services.mozilla.com/D29744
--HG--
extra : moz-landing-system : lando
BGRA may not be supported on GLES implementations, such as on the
Pixel 2 device. Since WR on Android uses GLES, we should use RGBA
when getting snapshots so that it actually works instead of failing
silently.
Differential Revision: https://phabricator.services.mozilla.com/D29060
--HG--
extra : moz-landing-system : lando
A test was intermittently crashing because it was calling
restoreNormalRefresh after closing the window. This meant
LayerTransactionParent::RecvLeaveTestMode fired after the
CompositorBridgeParent had been destroyed.
This fixes the test by calling restoreNormalRefresh before
win.close. It also checks mDestroyed in RecvLeaveTestMode (for both
LayerTransactionParent and WebRenderBridgeParent).
Differential Revision: https://phabricator.services.mozilla.com/D29228
--HG--
extra : moz-landing-system : lando
We need to do this separately in the WR and non-WR codepaths for picking up
scroll updates for skipped paints.
Differential Revision: https://phabricator.services.mozilla.com/D29061
--HG--
extra : moz-landing-system : lando
GeckoSurfaceTexture could bind to only one GL context at once. With WebRender, GeckoSurfaceTexture is soon bounded to sharedGL on render thread. It caused the problem if GeckoSurfaceTexture is rendered to WebGL. It could happen only for video's GeckoSurfaceTexture. To avoid the problem, the GeckoSurfaceTexture is bound to gl context when it is actually rendered on WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D27873
--HG--
extra : moz-landing-system : lando
The gist of the problem I introduced with the framebuffer coordinate system is that we provided the window rect (effectively) twice:
1. when computing the document rectangle (and Y-inverting it)
2. when rendering
If between these points the window got resized (during scene building), we end up with our document aligned to bottom left corner.
The user expects content to still be aligned to the top left, so that's what is visible as a bug.
The change here switched scene building to only care about device coordinate space, restraining the framebuffer coordinates to be mostly
an implementation detail of the renderer/device (the way it was originally meant to be, when introduced). This way the current window size
is only considered once during rendering.
Differential Revision: https://phabricator.services.mozilla.com/D28731
--HG--
extra : moz-landing-system : lando
