JDK-8124292 : Evaluate the restriction set on Mesh's indexBuffer (see RT-30448)
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-05-23
  • Updated: 2015-06-19
  • Resolved: 2013-06-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
JDK-8103114 - FX 8 3D: Need to validate Mesh's data size
Relates :  
JDK-8103523 - FX 8 3D: Change Mesh's indexBuffer type from unsigned int to unsigned short
Description
We have models created by the Sample Team that exceed the 64K limit.
Comments
Updating "noreg-dev-issue" to "noreg-other". See http://openjdk.java.net/guide/changePlanning.html for the list of valid tags.
19-06-2015
Could you please provide a link to the regression test that can be used to verify the fix? If a regression test is not applicable please add a noreg label as specified on http://openjdk.java.net/guide/changePlanning.html
09-09-2013
Awesome, I will update to that then when it comes out :D. I see, well I'm glad they(hopefully) fixed everything :). Did the limit just increase? Yeah, I was asking about embedded, since Mr. Bair was saying that the code has been released for Glass/Prism, it just needs a port from the OS community, so I was curious what the differences would be, and why wouldn't they use those for embedded? It seems that a lot is being left up to the OS community, but that's okay, because that means we can let them(Oracle) worry about the security aspect that is going on now, and the rest of us make it happen :) with 3D/FX8, and Mobile :P.
16-06-2013
Fixed. Changeset: 0049b4190d1b Author: Chien Yang <chien.yang@orcale.com> Date: Thu Jun 06 10:13:16 2013 +0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0049b4190d1b
12-06-2013
The fix will be in this week's JDK 8-b94 build. The change was done because because OpenGL ES only supports 16-bit index values. When you ask about the "ETA for 3D" what do you mean? 3D is already part of the main line build. Or did you mean 3D for embedded devices? That is unplanned for FX 8, although it will likely be something that a developer can enable using an unsupported system property. For FX on Java SE embedded plans in general, Daniel Blaukopf recently posted a "coming soon" message to the openjfx mailing list: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-June/008246.html
12-06-2013
In which build should we see the non-restriction again(or a change)? Why did we need to do it in the first place? I saw an issue with Raspberry Pi, is that the reason? Also @Chien Yang, is there an ETA when 3D will come out? Also will we see GUI portions of FX on Embedded, or is that part of the other Plan where the Glass/Prism code was released to the community so a port could be created for mobile?
12-06-2013
So maybe providing the public API in an 8 update release would be good enough.
23-05-2013
OK. We can look into adding it if it is not already to late to add new API. Jasper is fine if we don't provide it for FX 8 since 3D isn't a supported platform for Embedded yet.
23-05-2013
The proposed solution seems good to me. I think we still need to provide a public API to indicates the maximum number of vertices supported.
23-05-2013
Since 3D isn't a supported feature on embedded for FX 8, I believe we can get away by assuming indexBuffer as an array of unsigned int but automatically switch to unsigned short if the number of vertices in points and texCoords are less than 64K. This approach has the benefit of optimizing memory usage (native resource) for smaller data set on desktop and run on embedded. For data set greater than 64K, we can choose to skip rendering on the embedded and log a warning in the logger. Proper query can be added in the next release when we decide to add 3D support for embedded.
23-05-2013
Just found an existing use case where 64K limit per mesh will break: http://www.interactivemesh.org/models/jfx3dimporter.html STL : CylinderHead CylinderHead-ascii.stl, 14.6 MB CylinderHead-binary.stl, 3.3 MB 1 TriangleMesh, 67,252 triangles
23-05-2013
This would require a query to the native HW level for the supported data type and/or max number of vertices. The Java code would have to use this information to decide which type of buffer to create / pass down to HW. Additionally, we would need additional public API to expose this limit.
23-05-2013