Constantly updating rectangle appearance image causing memory issues in the GPU

CesiumJS
1

Hi all,

I'm trying to use hidden canvases as a material for rectangle primitive that is draped over the globe. I'm drawing to the canvases using Webgl and would like to get ~30fps. I am constantly updating the rectangle material so that I get a smooth animation.

  updateRectangleImage(canvas) {
    const currCanvas = document.getElementById(canvas.id);
    this.drapedRectangle.appearance.material.uniforms.image = currCanvas;
  }

Using the workaround that swaps between two canvases, I am able to get an something serviceable, but I quickly run out of memory in the GPU. I even tried limiting the frames per second to 10 but I still run out of memory eventually. I believe that my Webgl code is not causing memory leaks because when I comment out the line that assigns the material's image to the new canvas, the memory doesn't keep increasing (while still doing the new drawing on the hidden canvases).

For now, I'm using the toDataURL() method of the canvas, but the framerate is quite low. Is there something that I'm missing or some way that I can reap the benefits of the using an updating canvas directly as a material without running into memory issues?

I'm currently on:
Cesium 1.50
Windows 10
Chrome

Thanks

2

I’m not sure where the memory leak is coming from, but I think you should be able do this without needing to call toDataURL since that is very slow. I wonder if this line:

this.drapedRectangle.appearance.material.uniforms.image = currCanvas;

``

Causes Cesium to re-create the texture on every frame. It might be related to the issue described here: https://groups.google.com/d/msg/cesium-dev/Qd_LRhmlb50/j-_rdsVUK4IJ

Can you post a Sandcastle (https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/) recreating this? I wonder if there’s a way to just pass the framebuffer/texture directly to the material. This area of CesiumJS isn’t documented very well so I’m working on putting together code examples for this. If you can post what you’ve got so far that’d help a lot!

3

Thanks for the reply Omar!

Here's a sandcastle demonstrating the GPU memory issue I was running into. Since this is a small example, the program doesn't crash, but I believe it still displays the memory issue. Just leaving the sandcastle open causes the GPU memory to increase steadily (about 1.5 gigs) until it eventually cleans it out.

Unfortunately, my team is now taking a different approach to the problem we're trying to solve, so this approach is kind of moot for now, but again, I appreciate the response!

4

Thank you so much for providing a Sandcastle! I’ll look into it and try to determine if this is a bug or not.

In the mean time, we’ve been collecting feedback from users in order to make common workflows more streamlined, can you tell me a bit about your use case here?