bugfix suggestion: OpenGL 2.1 initialization fails on startup

[FlorianBlauth]

short version:

There is a bug in the imgui OpenGL 3 framework version used with SDR++ (nightly) which causes ImGui_ImplOpenGL3_Init(glsl_version) to fail. I could locally fix this issue by replacing in core/src/imgui/

imgui_impl_opengl3.cpp
imgui_impl_opengl3.h
imgui_impl_opengl3_loader.h

with the files from the newest version of imgui (1.9. from https://github.com/ocornut/imgui/tree/master/backends The imgui issue with OpenGL 2.1 was fixed in early 2023: https://github.com/ocornut/imgui/pull/6154 It is probably a good idea to upgrade imgui completely and not just the backend, as unexpected interactions may occur. The fix described however made SDR++ start and operate on my old OpenGL 2.1. capable machine on linux mint.

long version:

As I enjoy the look and feel of SDR++, I would like to run it on my somewhat dated Core2 T7300 with Intel graphics in case of static discharges from long antenna cables. I also had the the issue on startup mentioned in #1408 #1325 #1322 and #1306 where OpenGL 1.2 initialization failed. The problem was always dedicated to old hardware. I could also reproduce the problem my manipulating the MESA_GL envionment variables as demonstrated in #1325.

After some digging, I found that imgui handles the UI for SDR++ and the OpenGL 3 backend (despite its name) also should support GL 2.x. The imgui opengl 3 example however ran nicely with GL 2.1 and there was no real difference in the initialization in sdr++. Apparently, the early imgui versions had a bug in cheking the OpenGL 2.x version correctly and always failed ImGui_ImplOpenGL3_Init(glsl_version). This issue was reported in a pull request https://github.com/ocornut/imgui/pull/6154. Therefore I replaced the files mentioned above with the files from the newest version of imgui and SDR++ started and ran with the manipulated MESAGL variables and also on my old machine. There however are problems to be expected with the imgui backend from a much earlier version than the rest of the library. I will continue testing the fix. If you are able to compile SDR++ yourself, this is an easy fix for the older machines.

I (locally) created a branch for this fix, but as I am relatively new to "professional" software development, I do not know if I can/should push this branch.

[JVital2013]

Howdy there! I'm one of the developers over at SatDump, and I re-wrote much of the OpenGL system over there about a year ago. SatDump uses the same graphics library as SDR++, and I've seen a lot of these issues being submitted on this repo, so I thought I'd chime in.

Unfortunately, it's not quite as simple as updating the imgui_impl_opengl3_loader.h file for many systems, like the PR you linked to attempts. The opengl3 backend still requires some level of GLSL to function, which excludes many graphics cards that would otherwise support OpenGL 2.1. This is an issue for a whole slew of legacy systems. In SatDump, I solved the problem by including both imgui_impl_opengl3_loader.h and imgui_impl_opengl2_loader.h. The basic init sequence is:

1. Try getting at least an OpenGL 3 context with glfw. If it gets a valid context, use imgui_impl_opengl3_loader.h with a GLSL version chosen with some basic #ifdefs.
2. If it fails, try getting at least an OpenGL 1.0 context with glfw. If it gets one, use imgui_impl_opengl2_loader.h with no GLSL

Before we used the new system, SatDump frequently had reports of issues with the UI on legacy systems, but it's practically a problem of the past now.

Despite its name, imgui_impl_opengl2_loader.h works all the way down to OpenGL 1.1 - in theory. I have validated it on an OpenGL 1.6 system, though, and it works fine. It even works fine on Windows XP, but that's a whole 'nother beast that did require some more wrangling. SatDump also has a build option to use OpenGL ES 2.0 instead, for things like SBCs. Very few systems need this anymore, because most SBCs these days support at least Desktop OpenGL 2.1 out of the box.

All that to say: yes, this is a solvable problem, with logic that can be made to work out of the box on 95% of systems with at least a basic graphics chip. However, @AlexandreRouma does not accept pull requests, so your or my code would not be welcome here (as is a project maintainer's prerogative). It would be up to him to implement if he so chooses.

[FlorianBlauth]

Hello, thanks for your addition (SatDump is a great piece of Software by the way!)... You are absolutely right. I just realized I named the issue incorrectly (just edited that), as the fix above will only work for OpenGL Versions 2.x. and above It was late yesterday. To give a bit of context how it worked for me: On my old laptop, my glxinfo shows for OpenGL support: (remark: my grep is case sensitive, therefore grepping for opengl will show nothing.)

> glxinfo | grep OpenGL 
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) 965GM (CL)
OpenGL version string: 2.1 Mesa 23.2.1-1ubuntu3.1~22.04.2
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 23.2.1-1ubuntu3.1~22.04.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

so apparently my machine supports OpenGL 2.1 with GLSL Version 120 (1.20) and OpenGL 2.0 ES with GLSL 100, but still did not execute SDR++. On those machines, the fix above might work. Without the updated imgui, only OpenGL 3.0 and above will run. Support below 2.1 and GLSL 120 will need the other backends as you pointed out.