Closed Bug 1834342 Opened 2 years ago Closed 2 years ago

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

Categories

(Core :: Graphics: Canvas2D, defect)

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
115 Branch
Tracking Status
firefox115 --- fixed

People

(Reporter: jnicol, Assigned: sotaro)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [sp3])

Attachments

(2 files)

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?

Flags: needinfo?(sotaro.ikeda.g)

(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?

Flags: needinfo?(jnicol)

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

Flags: needinfo?(jnicol)
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)

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.

OS: Android → All
Blocks: 1832480
Blocks: gpu-canvas

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.

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

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

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

Attachment #9336346 - Attachment description: Bug 1834342 - Flush pending commands in ClientWebGLContext::DeleteFramebuffer() → Bug 1834342 - Flush pending commands in DrawTargetWebgl::~DrawTargetWebgl()
Pushed by sikeda.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/31fdbc651714 Flush pending commands in DrawTargetWebgl::~DrawTargetWebgl() r=gfx-reviewers,lsalzman
Whiteboard: [sp3]
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: