Device reset in test_device_reset.html replaces CompositorBridgeChild to a new one. And shutting down old CompositorBridgeChild also destroys TextureClients.
Differential Revision: https://phabricator.services.mozilla.com/D164175
.. but that is of primitive type (uint64_t, I think) and so the field remains
uninitialised in the created object. The uninitialised value eventually shows
up in WebRenderScrollDataWrapper.h,
WebRenderScrollDataWrapper::GetTransform().
Differential Revision: https://phabricator.services.mozilla.com/D164434
APZ cannot currently scroll in directions which are overflow:hidden
(it does not know the full scroll range bounds in those directions).
Therefore, main-thread scrolling in these directions should not be
handed off to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D161351
The change addressed followings problems.
- Recycling of gl::SharedSurface by RemoteTextureMap is not handled by gl::SwapChain.
- PrepareForUse()/NotifyNotUsed() of remote texture's TextureHost(SurfaceTextureHost) is not handled
- Wrapping of RenderAndroidSurfaceTextureHost by RenderTextureHostWrapper is not handled
PrepareForUse()/NotifyNotUsed() is called based on compositor ref count of TextureHost. Normally TextureHost is wrapped by WebRenderTextureHost, then the WebRenderTextureHost handles PrepareForUse()/NotifyNotUsed(). But in remote texture case, WebRenderTextureHost wraps RemoteTextureHostWrapper. And compositable ref of remote texture's TextureHost is updated within RemoteTextureMap::mMutex. Then PrepareForUse()/NotifyNotUsed() happen outside of WebRenderTextureHost in non compositor thread.
With pref gfx.canvas.accelerated=true, canvas renderings were broken on android emulator. The boroken rendering seemed to happen by GL of android emulator. The boroken rendering did not happen with tests on android hardware.
Differential Revision: https://phabricator.services.mozilla.com/D159261
The remote texture is processed asynchronously, but the WebGL rendering results are rendered synchronously with WebRender transaction by WebRender.
Async remote texture support is enabled only when CanvasRenderThread is used. This is to simplify implementation.
In async mode, remote texture of current RemoteTextureId might not be created yet when WebRenderImageHost::UseRemoteTexture() is called. In this case, RemoteTextureHostWrapper uses its own external image ID, otherwise the RemoteTextureHostWrapper uses compatible old remote texture for creating wr display list. RenderTextureHostWrapper calls RemoteTextureMap::GetExternalImageIdOfRemoteTextureSync() before is ussage. The GetExternalImageIdOfRemoteTextureSync() synchronously waits until remote texture becomes ready. The wait works since WebGL IPC handling is always done in CanvasRenderThread in async mode.
PWebGLChild::SendGetFrontBuffer() triggers sync IPC. It is called to ensure the compatible remote texture in RemoteTextureMap during RemoteTextureMap::GetRemoteTextureForDisplayList() call.
Differential Revision: https://phabricator.services.mozilla.com/D162971
The remote texture is processed asynchronously, but the WebGL rendering results are rendered synchronously with WebRender transaction by WebRender.
Async remote texture support is enabled only when CanvasRenderThread is used. This is to simplify implementation.
In async mode, remote texture of current RemoteTextureId might not be created yet when WebRenderImageHost::UseRemoteTexture() is called. In this case, RemoteTextureHostWrapper uses its own external image ID, otherwise the RemoteTextureHostWrapper uses compatible old remote texture for creating wr display list. RenderTextureHostWrapper calls RemoteTextureMap::GetExternalImageIdOfRemoteTextureSync() before is ussage. The GetExternalImageIdOfRemoteTextureSync() synchronously waits until remote texture becomes ready. The wait works since WebGL IPC handling is always done in CanvasRenderThread in async mode.
PWebGLChild::SendGetFrontBuffer() triggers sync IPC. It is called to ensure the compatible remote texture in RemoteTextureMap during RemoteTextureMap::GetRemoteTextureForDisplayList() call.
Differential Revision: https://phabricator.services.mozilla.com/D162971
Use the original start position of main thread smooth scrolls to determine
if the scroll position changed on scroll complete, and fire a scrollend
event if it did.
Differential Revision: https://phabricator.services.mozilla.com/D163550
Its only user was the BSPTree test suite, for its purposes
define a TestPolygon using an empty BSPTestData class instead.
Differential Revision: https://phabricator.services.mozilla.com/D162929
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435