IPC congestion check was added by Bug 1839314. It is enabled only when async remote texture is enabled and after first ClientWebGLContext::GetFrontBuffer() call. There were cases that it does not work like the followings.
- ClientWebGLContext::GetFrontBuffer() was not called during IPC congestion.
- When gfx::gfxVars::WebglOopAsyncPresentForceSync() = true.
When the IPC congestion happened, it caused ouf of file descriptor on Linux. Then it is better always to enable the IPC congestion check in WebGLChild::FlushPendingCmds().
Differential Revision: https://phabricator.services.mozilla.com/D184917
There were cases that a lot of cmds messages were sent by WebGLChild::FlushPendingCmds() without calling ClientWebGLContext::GetFrontBuffer(). And the IPC messages were waiting to be handled by WebGLParent, since OpenGL handling could take longer. Then there were cases that pending IPC messages were accumulated and it caused out of file descriptor on Linux. The sync IPC could reduce the pending IPC messages if there are a lot of cmds flashes.
async Ping is used for checking if IPC message is congested at WebGLParent. If a count of flushes since last congestion check reaches maybeIPCMessageCongestion, we think that IPC message is congested at WebGLParent. Then send sync SyncPing message to flush pending IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D181484
Enabling async remote texture removes sync IPC PWebGLChild::SendGetFrontBuffer(). With the change, there are cases that pending IPC messages are accumulated and it caused out of file descriptor. The sync IPC SendGetFrontBuffer() could reduce the pending IPC messages if there are a lot of cmds flashes.
Differential Revision: https://phabricator.services.mozilla.com/D181033
When WebGL context is lost, we could not expect that pending remote texture becomes ready. We do not need to wait the remote texture ready.
Differential Revision: https://phabricator.services.mozilla.com/D180303
This patch introduces random noises to data extraction functions of
canvas element and offscreen canvas. The random noise is based on the
random key of the cookieJarSettings and the image data itself.
The random noises would interfere the ability of fingerprinters that
use canvas data to fingerprint users. The random noise will make unique
canvas finerprint to for every browsing session. Therefore, fingerprinter
cannot use canvas fingerprint to tracker individuals across browsing
sessions.
Differential Revision: https://phabricator.services.mozilla.com/D175499
This patch moves ShouldResistFingerprinting() and add a RFPTarget as
input argument. We will use this function to check if canvas
fingerprinting protection is enabled.
We also modify the caller to pass the right RFPTarget for Canvas image
data extraction prompt. Note that, we need to set the default argument
for the function to known because it's used for WebGL fingerprinting
protection too. However, We don't cut over this part in this patch and
will do it in a future bug.
Differential Revision: https://phabricator.services.mozilla.com/D175608
In current m-c, async RemoteTexture wait at RenderThread stops window update when the wait is too long. If async RemoteTexture is handled by WebRenderAPI, window could be updated during long async RemoteTexture wait.
async RemoteTexture wait of root WebRenderBridgeParent are disabled to simplify WebRenderAPI's wait handling.
offscreen canvas case is handled by WebRenderImageHost by Bug 1827578.
Differential Revision: https://phabricator.services.mozilla.com/D175590
DrawTargetWebgl renders a path by uploading vertex data to the back of
a large VBO using glBufferSubData then issuing a draw call, orphaning
the buffer when it becomes full. This results in many glBufferSubData
calls being interleaved with draw calls. On Mali GPUs this causes
severe performance issues as the driver is unable to determine that
any pending draw calls do not reference the updated region of the
buffer, and therefore must create a copy of the buffer for each
update.
However, since *we* know that we never overwrite a region that is
referenced by a submitted draw call, we can force the driver to avoid
making these copies. We do so by adding a new function
UnsynchronizedBufferSubData(), which acts like BufferSubData so long
as this rule is followed. Internally, this uses glMapBufferRange with
GL_MAP_UNSYNCHRONIZED_BIT, allowing the driver to omit the extraneous
copies.
Differential Revision: https://phabricator.services.mozilla.com/D174685
These methods only existed because nsIGlobalObject::PrincipalOrNull was not
available off-main-thread, so can now be removed.
Depends on D165198
Differential Revision: https://phabricator.services.mozilla.com/D165199
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
