Like Bug 1798624, image of SurfaceDescriptorD3D10 needs to be kept alive until WebGLContext::TexImage() call with in-process WebGL.
Differential Revision: https://phabricator.services.mozilla.com/D165109
Bug 181137 made ContentIteratorBase no longer refcounted, but
it did not remove this bit of CC boilerplate. With the inline
root, using this macro in a non-refcounted class is an error.
ObjectModel.h and ClientWebGLContext.cpp used macros to define
root and unroot, but that is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D164828
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
This adds a path vertex buffer where triangle list output from WGR is stored.
Each PathCacheEntry can potentially reference a range of vertexes in this buffer
corresponding to triangles for that entry. When this buffer is full, it gets
orphaned and clears corresponding cache entries, so that it can start anew.
Differential Revision: https://phabricator.services.mozilla.com/D161479
This adds a path vertex buffer where triangle list output from WGR is stored.
Each PathCacheEntry can potentially reference a range of vertexes in this buffer
corresponding to triangles for that entry. When this buffer is full, it gets
orphaned and clears corresponding cache entries, so that it can start anew.
Differential Revision: https://phabricator.services.mozilla.com/D161479
GPUVideoTextureClient of SurfaceDescriptorD3D10 needs to be kept alive until WebGLParent::RecvTexImage() is handled by parent side.
Confirmed that test_conformance__textures__misc__texture-npot-video.html test failure was addressed.
Differential Revision: https://phabricator.services.mozilla.com/D161015
There was still a timing that hit the assert. When ClientWebGLContext::Event_webglcontextrestored() was called just before ClientWebGLContext::UpdateWebRenderCanvasData() the assert was failed.
Differential Revision: https://phabricator.services.mozilla.com/D161243
Originally, we special-cased shmems to try to send them directly
without a copy.
Unfortunately, ipc::Shmem doesn't support that, so we
allocated a new shmem on PWebGL and sent that.
However, we didn't include shmem-cleanup steps in RecvTexImage, so we
leaked the shmem.
We would be tempted to check inside the Desc in RecvTexImage and cleanup that
shmem, *however* RawTexImage from dtwebgl also uses this path, and its shmems
are UnsafeShmems, which are *not* supposed to be cleaned up.
Rather than adding e.g. a bool to differentiate them, let's just explicitly do
the cleanup in the caller that knows it needs to clean up.
One pattern I want to use more often for cross-process lifetimes is:
```
foo = new RefcountedResource();
SendUseAsync(foo);
SendPing()->Then([foo]() {});
```
By the time we the promise from SendPing is resolved, we know the remote side is
done with `foo`, and so our trivial capturing lambda will take care of releasing
it on the Send side. It's straightforward and safe, and the lifetimes have one
extra return-trip of latency, but that's almost always fine.
Differential Revision: https://phabricator.services.mozilla.com/D160996
Also scale back some asserts from debug-fatal to just warnings, because
I kept hitting them during testing because of our poor surface lifetime
handling.
Differential Revision: https://phabricator.services.mozilla.com/D157993
```
// We guarantee our robustness via these requirements:
// * Object.MutTiedFields() gives us a tuple,
// * where the combined sizeofs all field types sums to sizeof(Object),
// * (thus we know we are exhaustively listing all fields)
// * where feeding each field back into ParamTraits succeeds,
// * and ParamTraits is only automated for BytesAlwaysValidT<T> types.
// (BytesAlwaysValidT rejects bool and enum types, and only accepts int/float
// types, or array or std::arrays of such types)
// (Yes, bit-field fields are rejected by MutTiedFields too)
```
BytesAlwaysValidT<T> is the same as the IsTriviallySerializable<T> that
it replaces, however the emphasis is different, and should discourage
tagging structs as IsTriviallySerializable, since they more clearly
aren't BytesAlwaysValid.
Differential Revision: https://phabricator.services.mozilla.com/D151676
`Maybe` isn't is_trivially_copyable, and std::optional isn't either on
the old libstdc++ we use from gcc7 still.
I'm working on more robust approach to serialization but that's beyond
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D151421
ClientWebGLContext::DrawingBufferSize() could cause context lost. Then IsContextLost() check is added after the DrawingBufferSize() call.
Differential Revision: https://phabricator.services.mozilla.com/D152138
`Maybe` isn't is_trivially_copyable, and std::optional isn't either on
the old libstdc++ we use from gcc7 still.
I'm working on more robust approach to serialization but that's beyond
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D151421
When rendering large and/or fullscreen Canvas2Ds, excessive time can be spent
in calls to TexImage/ReadPixels copying into and out of Shmems to the separate
buffer for DrawTargetSkia. To alleviate this, we can make the DrawTargetSkia
directly wrap the Shmem, so that calls to TexImage/ReadPixels then directly
read or write to this without any separate copy. We modify RawTexImage to use
the IPDL SendTexImage path so that Shmems can be sent via SurfaceDescriptor.
Since SendTexImage is nominally async (which is beneficial), we rely on a
call to GetError later to verify that the Shmem processing is completely before
we further modify the DrawTargetSkia. We further add a ReadPixelsIntoShmem IPDL
call to allow sending the Shmem in the other direction directly.
Differential Revision: https://phabricator.services.mozilla.com/D151286
