FULL PRODUCT VERSION :
JDK 8u152 ea (and other recent versions)
ADDITIONAL OS VERSION INFORMATION :
OS X 10.10.5 MacBook Pro (Retina) NVIDIA GeForce GT 650M 1024 MB
A DESCRIPTION OF THE PROBLEM :
This is a test case to show the excessive memory consumption in TriangleMesh/MeshView
as I was asked for in this mail on the openjfx mailing list.
In its default setup the test case shows a triangle mesh which displays
10,000 rectangles (built via two triangles each). For simplicity reasons I am
only tracking the float arrays here because they dominate the final memory consumption.
These are the results I get via VisualVM:
float memory (after enforced garbage collection)
480,068 bytes nominal memory (definition of mesh)
1,494,920 bytes actual memory before BaseMesh.buildGeometry
27,416,832 bytes actual memory after BaseMesh.buildGeometry
The test case was developed to examine the usefulness of a triangle mesh
to do accelerated 2D graphics so it may be a bit special (identical normals
for all vertices and a special usage of the artificial texture). But
even if the ratio is just 1:30 or so in a more typical case this is still
far too much.
The origin of the problem seems to be that the BaseMesh class keeps
all the intermediate memory in order to be able to do a fast update
of the geometry later. But in many user scenarios this will never
happen because you just load a 3D model once and then just move it around.
In practice it is often much more important to conserve resources.
It might be worthwhile to consider a flag where the user can indicate
his specific priorities.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached test program and meassure the memory consumption via some tool like VisualVM.
EXPECTED VERSUS ACTUAL BEHAVIOR :
A much lower memory consumption.
A 57X increase of the float memory compared to the nominal memory needed to define the mesh.
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
---------- END SOURCE ----------