Hello there,
we're doing some really intensive graphics rendering with open gl and from time to time have framerates below 15.
we want the normal ui to stay responsive, but also draw some other stuff over the gl context.
is there another way to seperate the render thread from the main loop, than setComponentPaintingEnabled()
Thank you :)
Which platform are you using?
we're on linux, nvidia mostly
As I understand your problem, the component rendering is taking a long time and you would like to have the opengl stuff render as fast as it can without waiting for the component painting, right? The problem is that it's very hard to seperate the main and render thread when component painting is involved: obviously, when the OpenGL render thread starts rendering the components it must lock the main thread to be sure that the components are not already repainting otherwise the paint methods would be called recursively and many ugly things would happen. One solution would be to render only the components into a frame buffer by the main thread and the OpenGL render thread could then use this as a texture. Then this framebuffer would only be updated when necassary (i.e. on the main thread). Unfortunately, mobile platforms (OpenGL ES) do not allow access to the same context from different threads (in fact on android you are only allowed to use OpenGL calls when the OS sends you an OpenGL "idle" callback). So there is no way for the main thread to write into the opengl framebuffer or texture.
A solution for you might be to have the components render into an ImageBuffer with software rendering instead. Everytime your component receives a paint call you then redraw into this ImageBuffer (instead of the screen) with software rendering and set a global flag that a new ImageBuffer is available. The OpenGL thread would then check this flag periodically and update any internal textures with the new ImageBuffer when necessary. I don't know how fast this would be as uploading new textures to the GPU will have some overhead but it may be worth a try. Does this make sense?
Thank you for your help Fabian.
Yeah you're probably right, our OpenGl rendering takes a really long time, and so the whole user interface gets really slow. It seems like the main loop gets blocked, like you already stated.
The ImageBuffer solution could solve this problem, we will give it a try and report the performance of the buffer uploading.
Is there a good way to catch calls to paint() and do the rendering into the buffer, even if context.setComponentPaintingEnabled(false) is used? A quick test revealed that the paint() function won't get called in this case. Or is there another way to seperate the gl from the main thread?
Hey, I’m working on something similar at the moment. For me what solved the problem was splitting the rendering in smaller tiles to a frame buffer, which broke up the gpu work into bite size chunks allowing the GUI to get its foot in the door. One tile per render loop, but with no frame rate lock until the framebuffer is full. Really sped up the gui in my case at the expense of gl rendering frame rates slightly. But not as much as you might imagine. Is your gl rendering tileable? Can you render the same scene a bunch of times altering the camera and viewport? I don’t imagine it would work with perspective scenes but in my case (complex shaders) it worked a treat.
