OpenCPN Beta Version 4.5.204

[deltasig]

Originally Posted by ejs

Hi D-Sig,
Could you post a list of th Symlinks? Mine compiles but doesn't actually use OpenGL.

Eric

Hi Eric,
I trust you had a look on my previous posts, esp. the ones where I list the results of the "locate" command so that you can see the libraries I have installed.
This last try, I made the following changes to the CMakeLists.txt line 336
and made sure (added as needed) there were symbolic links for each of the elements of the libraries in /usr/lib/arm-linux-gnueabihf/; e.g. for dri2 I added libdri2.so -> libdri2.so.1. For the XXX_static libs you need to have a libXXX.a or libXX.so; I had the libGLU.a but I could not decide what libGL.so to use and it appeared the mesa/libGL.so was giving errors. So, I let the src/glshim that comes with OpenCPN provide the libGL.a (/OpenCPN/build/lib/libGL.a)

SET(OPENGL_LIBRARIES "GL_static" "GLU_static" "EGL" "X11" "drm" "dri2")

and commented out lines 397-398 because each creates its own problem.
#add_subdirectory(src/glu)
#SET( OPENGL_LIBRARIES "GLU_static" ${REVISED_OPENGL_LIBRARIES})

The behaviour of chart handling and the graphics have a marked improvement but I'm concerned that using the glshim and not the GLES version I do not get the full benefit of hardware acceleration.
I have posted a section of the log concerning the OpenGL and there are entries that I would like an explanation. Let's hope someone with more knowledge on the subject can enlighten us

Good Luck and let me know how you did
DS

[ejs]

DS,
My Locate output looks exactly the same as yours, I added symlinks to the arm-linux-gnueabihf level for libraries that were buried deeper and mentioned in Cmake and I did the edits you suggested in cmakeLists. I get a clean build of OpenCPN but it crashes as soon as I enable OpenGL.

I also cannot run es2gears, (it fails with failed to initialize EGL display. I can run glxgears at 300 to 400 FPS. I am using my laptop through realVNC as the display, is that the reason it isn't working?

Eric

[deltasig]

Eric
I use the OPi with attached TV(HDMI). Your comment intrigued me enough to try accessing OCPN from remote. I use tightvncserver and xrdp in the OPi and vanilla rdp on a WIN10 tablet. No crashes with OpenGL enabled; just, NO MAPS displayed. When I reset to NO OpenGL, maps come back. For a moment, I though this as a bug but then I realized that OpenGL is graphics card dependent. So, my guess is that remote VNC and OpenGL don't go together.
DS

[ejs]

DS,
Thanks for the experiment, I suspected that might be part of the problem. I guess I'll need to look into different VNCs a bit, maybe some are more OpenGL friendly than others.

Cheers, Eric

[bdbcat]

ejs...

Try NoMachine VNC system. Works across all platforms seamlessly in my test lab. It installs simply and just does the right thing, from Windows, Apple, linux/86, linux/arm, etc. GL supported well.

Example use case for stress testing OCPN: Main linux32 dev system through NoMachine wired connection to a headless Win10 box hosting a Mac Mavericks VBox client, through another NoMachine Wifi connection to a headless rPI linux system running OCPN in GL mode.

And this all works fine. Amazing, really.

No connection, just happy and very impressed with this non-fiddly solution..

Dave

[ejs]

Dave,
You are right! The NoMachine VNC system works on my headless OrangePi2 displaying on a win10 laptop using OpenGL on the Pi. Thanks for the tip.

Interestingly subjectively it does not seem to provide much if any speed improvement. It is usable, but not peppy. It may get better as the texture cache fills up. I am very glad to be able to build the latest code and to use the features without crashing in any event. I don't like to fall behind the curve even if the improvements don't directly benefit me.

Not that they are a very good indication but glxgears runs much slower (about 50FPS) vs about 350 on the realVNC system. Since I can't run es2gears on the realVNC system I don't have a a comparison but it runs about 150FPS on the NoMachine system. It may also be that the wireless connection is the bottleneck, I may try to dig out some ethernet cables and test that hypothesis.

Thanks again for the No Machine tip.
Eric