three.js: Maybe a memory leak when using canvas to show images.
Description of the problem
I record the performance in Chrome when running this JSFiddle, it shows:
The memory peak value getting higher and higher, but the valley value always keeps a low value.
Then uncomment the two lines in line number 30 and 31:
width = 1000;
height = 1100;
The canvas size is not power of two, and the memory usage increases rapidly
the performance record shows:
The memory peak value and valley value both getting higher and higher.
I call the dispose method of material and texture explicitly, and remove the mesh from scene in every loop.
Three.js version
- Dev
- r85
- …
Browser
- All of them
- Chrome
- Firefox
- Internet Explorer
OS
- [] All of them
- Windows
- macOS
- Linux
- Android
- iOS
Hardware Requirements (graphics card, VR Device, …)
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 25 (4 by maintainers)
I think it should work with
makePowerOfTwo()because only gets called on single map upload. ButclampToMaxSize()is used by cubemaps and this approach would definitely break.https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLTextures.js#L248
I do like the solution though, I think it makes sense to only have one canvas.
I’ll clean this all up.
For those who need workaround before patch is released. Add this code before your threejs code:
It seems like this issue is still exist in r92, I changed canvas size to 1000 * 1000 in webgl_test_memory.html , chrome crash the page after 10s
When I go to that link my page memory stays stable and does not rise. ( latest Chrome, OSX )
Unless I open the console. I believe it is the console messages that are consuming the memory. Try it with the console closed.
@tommytee An online little test using your fix: http://139.196.28.110/npot/index.html
You can see the warning:
[Modified] THREE.WebGLRenderer: image is not power of two (240x260). Resized to 256x256Notice that I added a “[Modified]” in front of this warning sentence to make sure that your fix is in use.This page’s memory usage increased rapidly.