1834342 - React-Stockcharts uses a huge amount of render-texture-hosts memory

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Jamie Nicol [:jnicol]]

https://speedometer-preview.netlify.app/?suite=React-Stockcharts&iterationCount=10

I've noticed this on Android but it's possible it affects Linux and Macos too, as they also use
accelerated canvas.

Running ten iterations of react-stockcharts (as in the above URL) uses 805MB of render-texture-hosts. Switching away from the tab does not free this memory, however closing the tab does.

Sotaro, any idea why we are holding on to so many render texture hosts?

Comment 1

[Sotaro Ikeda [:sotaro]]

(In reply to Jamie Nicol [:jnicol] from comment #0)

https://speedometer-preview.netlify.app/?suite=React-Stockcharts&iterationCount=10

URL did not work for me. Error message was 'No suites selected. "React-Stockcharts" does not exists'.
Does the URL work for you?

Comment 2

[Jamie Nicol [:jnicol]]

Not any more, no. The test was removed from speedometer yesterday. I'll find a different link for it.

Comment 3

[Jamie Nicol [:jnicol]]

Sotaro, can you try this url instead: https://stockcharts--speedometer-preview.netlify.app/?suite=React-Stockcharts

Comment 4

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add log around remote texture

Comment 5

[Sotaro Ikeda [:sotaro]]

For each iteration, a DrawTargetWebGL was created and a new FrameBuffer was created and they were alive until the test end. At the end of the test, DrawTargetWebGLs and FrameBuffers were deleted, but their destruction did not trigger RemoteTextureOwnerClient::UnregisterTextureOwner(). Then TextureHosts of RemoteTextureOwners remained alive.

Comment 6

[Sotaro Ikeda [:sotaro]]

RemoteTextureOwnerClient::RegisterTextureOwner() is called in WebGLContext::PushRemoteTexture(). It uses function's argument webgl::SwapChainOptions.

RemoteTextureOwnerClient::UnregisterTextureOwner() is called when its owner swap chain is destructed.

• https://searchfox.org/mozilla-central/rev/603b9fded7a11ff213c0f415198cd637b7c86614/dom/canvas/WebGLContext.cpp#1150

Delete frame buffer happens at HostWebGLContext::DeleteFramebuffer().

Delete frame buffer is requested by ClientWebGLContext::DeleteFramebuffer().

Comment 7

[Sotaro Ikeda [:sotaro]]

Even when ClientWebGLContext::DeleteFramebuffer() was called, HostWebGLContext::DeleteFramebuffer() was not called when the problem happened. From it, pending commands were not flushed at ClientWebGLContext.

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1834342 - Flush pending commands in DrawTargetWebgl::~DrawTargetWebgl()

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/31fdbc651714
Flush pending commands in DrawTargetWebgl::~DrawTargetWebgl() r=gfx-reviewers,lsalzman

Comment 10

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/31fdbc651714