731 2013-05-09 02:16:33 +0200 GLJPanel: Reduce JVM/CPU Heap Memory Usage - Share IntBuffer for readPixel/flip-vert 2013-05-09 04:50:09 +0200 1 1 3 JogAmp Jogl awt 2 All all RESOLVED FIXED --- enhancement --- 1 sgothel sgothel --- ff08ebae2f6ed8788d481f4a21fc7a07a75733ee 66e3917da774b723007811e66d95f37b1ffffc97 e6a234edb1318bb38f6ab65d96518471d0c7fd68 0a7bf77b8c0765f8a53dc72a8edab8e0496938ff ed732cddbcb979062c56e9c93534a232aaa7fa20 890dabf77593732bd9833350b441a37c60f74d45 --- oldest_to_newest 2575 0 sgothel 2013-05-09 02:16:33 +0200 GLJPanel allocates one or two array backed IntBuffer for each instance. - 1: BuffereImage - 1: Vertical Flipping if GLSL flipping is n/a Extensive use leads to to out of memory errors on the CPU/JVM side. 2576 1 sgothel 2013-05-09 02:21:34 +0200 Solved by attempting to use a singleton pixel buffer. Impl. now reuses generalized GLPixelBuffer* -> SingleAWTGLPixelBufferProvider, incl. row-length-stride where available (GL2GL3). Further beneficial is the generalized [AWT]GLPixelBuffer* refactored util class, allowing users to inject a pixel-buffer provider into a toolchain, here: - GLJPanel - GLReadBufferUtil New test case: TestGearsES2GLJPanelsAWT GLJPanel SingleAWTGLPixelBufferProvider's screenshots: <http://jogamp.org/files/screenshots/gljpanels-singlebuffer/> 2578 2 sgothel 2013-05-09 02:53:50 +0200 GLJPanel still uses an individual GLPixelBuffer instance. If using SingleAWTGLPixelBufferProvider, the following creation sequence may happen: 1- 200x200 *new* 2- 400x400 *new* 3- 200x200 *reuse* the smaller prev. GLPixelBuffer are still in use, even though they could be dropped in favor of the current biggest GLPixelBuffer. Hence we have to validate, whether we can make the field static: AWTGLPixelBuffer pixelBuffer this would allow us to get rid of the prev. smaller allocations and save resources. 2579 3 sgothel 2013-05-09 04:50:09 +0200 fixed, see 890dabf77593732bd9833350b441a37c60f74d45