Posted by Xerxes Rånby on Feb 18, 2014; 1:35pm
URL: https://forum.jogamp.org/Custom-Raster-tp4031610p4031628.html

JeanPhi wrote

How to ensure is that the DataBufferInt is filled directly from the GPU data?

This can be done by avoiding all copys from video ram to regular ram. Thus the solution is to not use any RAM buffer, like the DataBufferInt, at all for graphics. The GPU hardware can only read and write to Video-RAM, VRAM, memory, the VRAM memory can be initialized by the operating-system using the EGL API. JOGL uses EGL to initialize a native window that is then later used by OpenGL for rendering.

If you want high performance then you should make sure that all graphics API's are operating directly on the vram using native window handles and hardware accelerated API's. Thus a good start is to make OpenJFX able to expose its native window. JOGL and Java3D may reuse the OpenJFX native window handle for direct rendering without any VRAM <-> RAM data copys.

If you look inside the OpenJFX sourcecode you will notice that OpenJFX internally contains handwritten JNI code to initialize a native window using EGL and OpenGL ES 2 calls. OpenJFX currently do not contain any way to expose the native window for interoperability with other OpenGL applications and hardware accelerated API's. Access to the native window handles inside OpenJFX needs to get fixed if you want good interoperability between OpenJFX and Java3D.

JeanPhi wrote

Is the "filling" made by the GPU or the CPU?

glReadPixels is implemented by the GPU driver, on some hardware it is performed by the CPU, some hardware can use a DMA copy and some can use the GPU.
On embedded devices glReadPixels is expensive thus applications that use it will have limited framerate updated. the only solution is to avoid the copy and use direct vram rendering.