Render loop is creating a lot of garbage with JOGL

OpenGL Development JOGL Development
#1

Hi,

i’m currently trying to create a render loop with JOGL.

The basic device creation looks like this:


public class ExampleScene extends Frame {
    
    private GLCanvas canvas;
    
    public ExampleScene() {
        GLCapabilities glcaps = new GLCapabilities();
        canvas = new GLCanvas(glcaps);
        
        ExampleSceneView view = new ExampleSceneView();
        canvas.addGLEventListener(view);
        
        setSize(500,500);
        setTitle("JOGL test");
        
        add(canvas, BorderLayout.CENTER);
        
        addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        });
    }
    
    public static void main(String[] args) {
        final ExampleScene app=new ExampleScene();
        
        app.setVisible(true);
    }

This implementation works fine. But when i add a render loop like this …


    public static void main(String[] args) {
        final ExampleScene app=new ExampleScene();
        
        app.setVisible(true);

        while (true) {
            app.canvas.display();
        }
    }

… the garbage collector gets active every second :frowning:

In the render loop I am NOT creating garbage.
So there has to be a problem with JOGL …

Is there a workaround for this? Or is it even normal?

#2

JOGL is itself written in Java. In order to access certain window system-specific data structures it needs to create NIO direct buffers internally. These and the Java objects which wrap them are very small, on the order of a few bytes. If your rendering loop is doing nothing and rendering at several thousand frames per second, then yes, you will see young generation GCs occurring. In any real application these allocations will be in the noise. There have been no reports of these allocations impacting the performance of any real application.

#3

So you think it is normal?

I’m just wondering, because when I use “app.setVisible(true)” only, it works, without the GC getting active every second.

#4

hi,

i think in general that
the “inner loop” or display method should not create buffers or other objects if it is not necessary.

try to allocate objects outside display(…) or inner loops and REuse them.

#5

Yuck! Sorry but that would make for really foul code having to carry all that scratchpad for JOGL. And given the rest of the heap traffic in my app (cos any real game will play with some big and complex data structures) the JOGL traffic must be lost completely in the noise.

Trust the garbage collector - particularly when it comes to high turnover of short lived young generation stuff. There’s a lot of FUD about GCs (and I’ve been using GC’d languages for 20+ years now) and it’s only really where you need realtime hardware response that avoiding GCs is advantageous and only because of its asynchronous nature.

#6

Our users beg to differ with your summation of GC. It causes noticable stutter in our rendering, even at high framerates. :frowning:

#7

We also beg to differ. Due to gc our realtime framerates look more like an EKG readout of a marathon runner (non deterministic to say the least) than the EKG of a dead guy (very very deterministic).

We prefer the dead guy (deterministic). We are porting a product from C++ to java and our current solution is to create variable pools so as not to thrash the heap. We do systems with thousands of dynamic 3D objects running at 60Hz, so we think the pools make sense for performance.

#8

It is such an easy fix for the JOGL team, that it would be a shame if they would not reuse their buffers.

Thinking that GC won’t have a noticable effect, when rendering smooth animation is just very wrong. Each and every stutter destroys perceived performance, even when you’re still rendering over 60fps.

#9

It is not an easy task to “reuse” the NIO buffers in the JOGL implementation. You would need to look at the sources to GlueGen and understand the semantics of the underlying C APIs we call to understand why.

That having been said, I don’t think that JOGL itself creates all that much garbage per frame. If you have a test case that shows otherwise please file a bug and attach it.

#10

This may help

http://www.java-gaming.org/forums/index.php?topic=13469.new#new

Keith

PS: I heard the J2D guys say the OGL pipeline creates far less agrbage than J2D, so JOGL is probably the same…