JDK-8311225 : Some 3D demos are getting slashed in Ensemble8
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: internal
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic
  • Submitted: 2023-07-03
  • Updated: 2023-07-04
  • Resolved: 2023-07-04
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.
Other
internalFixed
Related Reports
Blocks :  
JDK-8302050 - Common state management for 3D implementation
Description
Looks like we are not blitting 3D content to the window with appropriate offset and this causes some of the 3D content to go out of the window.

Attached image for OpenGL and Metal.
Comments
Changeset: 1499a7fd Author: Jayathirth Rao D V <jayathirth.d.v@oracle.com> Committer: Ambarish Rapte <arapte@openjdk.org> Date: 2023-07-04 12:53:44 +0000 URL: https://git.openjdk.org/jfx-sandbox/commit/1499a7fdbdfd94a12c5a00beee9c11917301ce23
04-07-2023
Looks like logic for using nextPowerOf64 textures for RTT was added in initial stages of metal development as a workaround. Over current code removal of nextPowerOf64 textures is not causing any errors, this is also verified by Ambarish. So removed usage of nextPowerOf64 and added texture conditions same as D3D implementation.
04-07-2023
We are creating nextPowerOf64 RTT Texture in MTLResourceFactory.createRTTexture(). So in our case we need (600,600) but we create (640,640) texture. Also the intermediate blitting between sourceRTT to DestinationRTT is happening only in case where we have 3D drawing in Ensemble8 so we don't this extra offset in other 2D demos. If i remove nextPowerOf64 texture for RTT then i dont see the artifact. In case of OpenGL or D3D we don't force creation of nextPowerOf64 textures for RTT, only in the case where "PrismSettings.forcePow2" is enabled we use nextPowerOfTwo textures.
04-07-2023
Verified that this is not a recent regression and this issue is seen from the time https://bugs.openjdk.org/browse/JDK-8305804 was fixed. Also this is not related to some offset issue in MTLContext.blit() logic. Because in this scenario both source and destination offset are (0,0).
04-07-2023