From Kelsey, webgl(and canvas2d) can't actually by-default be async by spec.
RemoteTextureMap::GetTextureHost() could handle a case that there are already multiple remote textures. But it does not handle a case that remote texture is not pushed yet by WebGLParent. This bug is going to handle it.

RemoteTextureMap is going to be added by Bug 1712486 .

CanvasTranslator::WaitForSurfaceDescriptor() already does similar thing.

Kelsey prefer more simplified way. Close the bug for now.

(In reply to Sotaro Ikeda [:sotaro] from comment #2)

Kelsey prefer more simplified way. Close the bug for now.

Oh, it was my misunderstanding.

1. be fixed so it follows the spec with regard to showing exactly the right buffer, and 2) Very eventually, we should have a better way to do things
   but we don't have time to do #2 right now and it sounds like #1 isn't that hard so we should just fix it up to work with your current approach.

(In reply to Sotaro Ikeda [:sotaro] from comment #1)

CanvasTranslator::WaitForSurfaceDescriptor() already does similar thing.

Block compositor thread is not ideal. If it is possible, it is better not to block compositor thread.

For the sync remote texture rendering, it seems that the followings places could be used for sync handling.

• [1] Wait before starting wr transaction at WebRenderLayerManager.
  • WebRenderLayerManager::EndTransactionWithoutLayer()
  • WebRenderLayerManager::EndEmptyTransaction()
• [2] Defer to receive wr transaction at WebRenderBridgeParent.
  • WebRenderBridgeParent::RecvSetDisplayList()
  • WebRenderBridgeParent::RecvEmptyTransaction()
• [3] Retry WebRenderBridgeParent::MaybeGenerateFrame() if remote texture is not ready.
• [4] Defer WebRender rendering on render thread if remote texture is not ready.
• [5] Modify and use RenderTextureHostWrapper and swap remote texture within RenderTextureHostWrapper on render thread.

[1] blocks main thread of client process. It is not good. Situatoin seems similar to current situation.
[2] seems hard to implement correctly.

[5] seems ideal place. We could do the swap just before WebRender rendering. At the rendering, remote textures might be ready more. But [5] has a problem. Display list of async pipline needs to be updated on compositor thread.
Then [5] might need also [3] partially. WebGL swap chain uses a same type of texture continuously.
If there are already previous texture of same swap chain. PushResourceUpdates() and PushDisplayItems() could be handled by using the previous texture if current remote texture is not ready.

At first, I tried [5] and [3].

• On Windows, even when ClientWebGLContext sent IPC message before wr transaction,
  WebGLParent in compositor thread received the message after wr transansaction at WebRenderBridgeParent in compositor thread.
  TopLevelProtocols are different, it might be related.
• There were cases that remote textures were not ready when they were used for wr rendering.

Then [5] and [3] was not enough. Then [4] was added.
With [5], [4] and [3], the sync rendering seemed to work without blocking threads.

But current implementation have a problem when WebGL run on compositor thread.
It basically works when WebGL run on compositor thread.
But there are cases that does not work. Since compositor thread could call a task in render thread synchronously.
It breaks [4]

Current solution requests that WebGL run on non-compositor thread.

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Backed out for causing reftests failures in ReleaseCompositableRef.

• Backout link
• Push with failures
• Failure Log
• Failure line: SUMMARY: ThreadSanitizer: data race /builds/worker/workspace/obj-build/dist/include/mozilla/layers/TextureHost.h:578:5 in ReleaseCompositableRef

Oh, I updated RemoteTextureHostWrapper::NotifyNotUsed() wrong way by mistake.

Addressed test failure.
https://treeherder.mozilla.org/jobs?repo=try&revision=9fc9e6f8eca1fcf4f68b4860904ef963f9bd46ae

On a try build, the improvements from this bug didnt seem to kick-in unless I set webgl.out-of-process.async-present.force-sync= False. I may have done something incorrect though...

https://hg.mozilla.org/mozilla-central/rev/1725d4942ce7