? JOGL Rendering Issues - Different for v1.1.1 and v2.0 and with Laptop docked vs not ?

elect wrote

I understand.. and what about opening only the graphic part/engine? Does it also involve proprietary stuff?
Is it feasible to isolate it from the rest?

The graphic part is primarily the JOGLUTILS 3DS rendering - that I should be able to release, but it will take me some time to do so - I need free time. Basically my main renderer simply draws simple shapes like the Earth, moon and then calls the 3DS renderer to draw the models. So in reality the heart is the 3DS renderer and I'll release that. Mostly because I know it needs to be improved. I originally took the old version of JOGLUTILS for 3DS reading/rendering and had to fix it - it wasn't reading 3DS models correctly or even rendering them correctly. I believe even today the JOGLUTILS 3DS doesn't do it right - but they changed the API a bit from the first version so I've not had the opportunity to update their code with mine because it would take a lot of effort.

Unfortunately my code is all fixed function pipeline and so kind of antiquated but I'll release it in the next month or two - I just need to find the time to do it. Maybe then people can fix the VBO issues I have with it - which is why I mainly use the Display Lists version. The main issues were with lighting across vertices or across faces - I believe. I couldn't figure out how to setup the color buffers properly. Kind of hard to remember right now without looking at it more indepthly, but I'll explain things when I do release it. As I said, give me a month and I'll see what I can do.

Z-Knight wrote

I understand, but it was the best solution for my setup and it has worked thus far. Also, my VBO implementation - though it seems to work - is likely wrong since I seemed to have better performance with Display Lists. But, that's a different question and I'll get to it eventually.

Display lists are faster only with extremely tiny data sets (about ten triangles) on all hardware that doesn't emulate display lists with VBOs under the hood (i.e between OpenGL 1.3 and maybe OpenGL 2.1) when they are reliable (sometimes they cause a crash or a huge slowdown when used with shaders) and with huge data sets with OpenGL 1.3 hardware supporting the old ARB VBO implementation if and only if you don't get any stability problems. If you get "better" performance with display lists in other situations, there is probably something wrong in your code but I admit that optimizing VBOs performance isn't trivial but doable whereas it's very easy to break everything or at least ruin your performance with display lists just by modifying a single parameter within OpenGL.

I get better performance from display lists in most of the analytic visualizations I've developed as well. I also have had to deal with issues from old drivers and having to support the Intel HD garbage (I seriously have Intel HD nightmares.) In the end I created a system that will utilize the best that the system can use: immediate mode, vertex arrays, display lists, or VBOs. I was actually able to open source some of my government funded work. Maybe it can help.

https://github.com/pnnl/svf 
https://bintray.com/pnnl/maven/svf/view 

I disagree with you, I tested with numerous graphics cards manufactured between 2000 and 2016 and I confirm that display lists are slower than wisely used static VBOs on absolutely all drivers taking into account the static draw mode. I've seen lots of examples using VBOs like vertex arrays and this is exactly what you mustn't do if you expect better performance than in stream or dynamic draw mode.

Moreover, as I explained several times here, using display lists break shaders and/or OpenGL picking on some drivers.

In my humble opinion, some features are noticeably slower on Intel chips, especially FBOs. Some OpenGL 1.5 Intel chips don't support VBOs. Sometimes, they claim to support greater textures than they really do. There are even some restrictions on context creations under Windows with Intel. "nightmare" is the right word.

Unlike a game framework, SVF was designed to use fewer resources

It's a prejudice. There are some game frameworks designed with performance in mind.

Edit.: You still use color picking, it doesn't work with GPUs using partially emulated color palettes, for example on some low end laptops.