Performance

Hello community,

I recently stumbled upon a project that uses JogAmp libraries for rendering graphics and using a bird's eye like perspective of objects in an old swing application.

We are currently using gluegen-rt-main and jogl-all-main in the version 2.3.2.

I tried to update to the version 2.5.0 as there seemed to be a problem with Citrix messing with the OpenGL32.dll or so I have read in another thread. This caused a problem, that the library did not work at all at computers running Citrix. Unfortunately the user feedback was, that the performance in relation to the 2.3.2 degraded.

If one applies the "NVIDIA Hardware Acceleration" instead of the "Integrated graphic driver" directly to the corresponding program, it is fast as before with the 2.3.2 version. However, as the software is used in quite old machines, we can not enforce customers upgrade their hardware.

So I tried to pinpoint the issue by trying out the 2.4.0 as well as the 2.5.0 version, but the result was the same.
The old one renders the objects "fluently" and the new versions judder.

As I am no expert with the library, I just used VisualVM to get a few methods we use quite often:

jogamp.opengl.gl4.GL4bcImpl.glNormal3f (float, float, float)
jogamp.opengl.gl4.GL4bcImpl.glVertex3f (float, float, float)
jogamp.opengl.gl4.GL4bcImpl.glBegin (int)
jogamp.opengl.gl4.GL4bcImpl.glBindTexture (int, int)
jogamp.opengl.gl4.GL4bcImpl.glEnd ()

The runtime environment is the Temurin release jdk-21.0.1+12. The issue has been reproduced with an Intel UDH Graphics 630.

Have there been any changes with regards to the nature of the graphics processing, that could explain this issue?

Thank you in advance!

Hello

Sorry but if I were you, I would look for potential root causes elsewhere, not within JOGL. We can sometimes work around some driver bugs but it's time consuming (and sometimes not technically possible) and actually, it's not up to us, GPU manufacturers should provide better drivers and customers should at least accept to update their drivers and upgrade their hardware at last resort. No one is held to the impossible. JOGL is NOT responsible of picking the most capable GPU, we don't support Optimus and similar technologies. Maybe you can use Nvidia GPU affinity somehow. Keep in mind that bad things might happen if your operating system switches from a more capable GPU to a less capable GPU at runtime, this isn't specific to JOGL.

By the way, using immediate rendering is a very bad idea for many reasons. For example, a program using this type of rendering with shaders and/or picking can become very slow on some GPUs (I met this case more than a decade ago). Some drivers just convert immediate rendering into retained mode by using buggy code paths. I cannot promise that it will solve your particular issue but maybe you could use com.jogamp.opengl.util.ImmModeSink or directly rewrite your source code with VBOs.

I advise you to ensure that the same GPU is used during the execution of your software and that the most capable GPU is chosen when starting it, it's an acceptable policy and a good practice. I know that it's annoying, it means that you can't just run the software, you'd prefer not having to deal with that.
Keep in mind that you could probably find a machine who would be very slow with JOGL 2.3.2, JOGL is not to blame.

P.S: Please choose a more specific title when you create a new thread.

Hello

Thank you very much for your fast response and improvement suggestions!

I am very sorry, if my question sounded like finger-pointing. That was certainly not my intention.

My goal was to get possible tips on how to improve the current solution.

Do you have any how-to recommendations with regards to such a migration away from immediate rendering?

I am grateful for any help.

Thank you in advance!

Hello

I have no ready-to-use guide about that subject but feel free to ask questions.

At first, you must know your intended audience and have a clear idea of your software's minimum requirements, it will help you to determine where you start and where you stop. For example, if you have to support OpenGL 1.4, you'll be able to switch from immediate mode to retained mode by using VBOs but you won't be able to use VAOs.

Moreover, you have to use the right type of VBOs depending on the frequency of changes, a static VBOs is enough when you rarely or never change a geometry.

After that, avoid useless (re)creations of VBOs (see glBufferData), it's the typical newbie's mistake, don't push or upload the data when it isn't needed. If you're really a beginner with VBOs, start by tinkering a tiny example in order to understand the basic principles.

You'll have to understand how to use glGenBuffers, glBindBuffer, glBufferData, glDrawArrays and glDrawElements. I advise you to focus on examples illustrating how to use VBOs alone.

Hi JC,

to remove the confusion, your issues boils down to:

- Temurin release jdk-21.0.1+12.
- Some Windows machine (x64?)
- Intel UDH Graphics 630
- Old fixed function pipeline GL code
- Works well w/ JOGL 2.3.2
- Works slow w/ JOGL >= 2.4.0

Is the above correct?

Is the mentioning of 'Citrix' relevant here?

+++

Can you vouch that previously your NVidia didn't get used w/ JOGL 2.3.2
and hence we can ignore all the text in this regard?

+++

Not sure if I have a compatible system to test (esp Windows on such hardware - Linux is available).

Would you detail this performance regression in a bug report?
Also add a good enough little test producing numbers to validate (expected vs has) ?

We had a bug report before .. but then author figured its gone
and reviewing JOGL 2.3 delta within GLContext didn't enlighten me.

This would be a good task for sponsoring as well, if any company is all eyes ;-)
https://jogamp.org/wiki/index.php?title=Maintainer_and_Contacts#Commercial_Support

Hello again,

Thank you for your valuable feedback gouessej I guess I will have to take it slow and get into the examples first to be able to ask more sensible questions.

Yes the information above you mentioned is correct Sven.

Oh I forgot to mention it: I tried to upgrade the library, because with some kind of Citrix update we received in our company our tool that uses Jogl libraries stopped working. I then analyzed a bit and noticed, after deinstalling Citrix the issue disappeared. Unfortunately this was no presentable solution. I also found some other threads where people mentioned similar problems with Citrix, although I do not know, if it is comparable. This blog post: https://jogamp.org/bugzilla/show_bug.cgi?id=1380

As I only looked into Maven Central I was not aware, that there are newer versions of Jogl. After that insight I tried to use different versions.

I am sure the NVIDIA did not get used with 2.3.2. I watched my colleague trying both versions and trying different NVIDIA settings (Internal / Accelerated).

There is a high certainty the code itself can be improved to solve this issue, especially as the code has been written around 10 years ago, but it is quite difficult to unravel it and migrate it to a newer version, because of its complexity and my yet lacking knowledge of OpenGL.


Okay thank you very much Sven!
I will have a look on how I can to make this issue presentable in a way you can work with.