|:||disabling the auto swap buffer mode causes very high memory consumption|
|:||[JogAmp] Jogl||:||Julien Gouesse <gouessej>|
|:||opengl||:||Sven Gothel <sgothel>|
main class of the test case
activator of the plugin with some useful flags
Description Julien Gouesse 2011-01-06 17:13:32 CET
Created attachment 215 [details] main class of the test case Overview: When I disable the automatic swap buffer mode of the GLCanvas, I have to swap buffers by myself. When I do not swap the buffers in the display() method of the GLEventListener, the memory consumption increases a lot (more than 1 MB per second). Handling manually the swap of buffers is useful to avoid redrawing very big meshes especially in scientific applications. Steps to Reproduce: Launch the example that I provide or modify an existing test: - call glCanvas.setAutoSwapBufferMode(false); - do not call glCanvas.swapBuffers(); Actual Results: The memory consumption increases hugely (at least one MB per second). Lots of StructAccessor instances are created. Expected Results: The memory consumption should not increase noticeably in comparison with the automatic swap buffer mode. Build Date & Platform: Build 266 23-Dec-2010 06:55 on Linux 64 bits, Windows 32 bits and Windows 64 bits Additional Information: Please find enclosed a small test case used in an Eclipse RCP application. Press B to disable/enable the automatic swap buffer mode. This test case contains lots of workarounds to avoid breaking the debug pipeline of JOGL 2.0 and is the only public example working with both SWT & JOGL 2 whatever the platform without breaking this pipeline.
Comment 1 Julien Gouesse 2011-01-06 17:15:00 CET
Created attachment 216 [details] activator of the plugin with some useful flags
Comment 2 Sven Gothel 2011-11-21 14:14:26 CET
I am sorry - I have validated this case w/ commit 9e99815645fe255ff3af83ba5b4108907b306a2f test case TestGearsAWTAnalyzeBug455, using jvisualvm (profiling memory). Memory consumption varies around +/- 1-3% regardless which test (auto-swap or none). - Linux, x86_64 - java Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Pls create a simple test scenario (like the above) which is capable of reproducing this situation. Until then .. fixed.