1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
JOGL and OpenGL DivergenceOverviewAs described in mapping of OpenGL profiles to interfaces, JOGL is mostly API compatible with the OpenGL API while packaging functionality in OpenGL profiles. However, there are certain aspects where JOGL diverges due to managed code aspects and the Java™ language. OpenGL DebuggingIn 2009-2012 the Debug Output extensions AMD_debug_output and ARB_debug_output were created, subsumed to the core via KHR_debug. They allow applications to enable and control low-level debugging using the OpenGL implementation. These extensions have been subsumed in OpenGL 4.3 and in OpenGL ES 3.2. In JOGL a user may attached a GLDebugListener to the GLContext via addGLDebugListener(..). The GLDebugListener receives the native GLDebugMessage if debugging is enabled. To enable debugging, the GLContext must be created having CTX_OPTION_DEBUG
set via Test cases Retrieve Mapped Buffer's DataSince OpenGL 1.5, a mapped buffer object's data can be retrieved via glGetBufferPointerv(..), i.e. the client's memory pointer. In JOGL, buffers are tracked via GLBufferStorage, covering the storage size, NIO client memory reference if mapped and usage flags. This ensures lifecycle alignment of the native NIO Java client memory with OpenGL buffer semantics. To retrieve the bound buffer you may use getBoundBuffer(..) and getBufferStorage(..). Tracker Implementation Test Cases References |