Replace GLEW with epoxy

[Chris Mayo]

GLEW is installed for either GLX or EGL, making it impossible to switch to EGL if some applications need GLX.
epoxy also does not need to be initialised, making startup faster.
GTK, Firefox and Libreoffice are among those using epoxy.

Patch (not sure the best way to work with Launchpad and/or Sourceforge...):
https://sourceforge.net/p/hugin/hugin/merge-requests/2/

A draft that has only been tested on Linux and at the moment uses PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is available in Homebrew) but more work for Windows and other supporting scripts.

[Bruno Postle (brunopostle)]

I haven't tested the patch, just noting that epoxy is available on fedora

[tmodes (tmodes)]

First I need to check how to build on Windows. The readme does not provide instructions specific for Windows. It seems epoxy needs 2! different build systems (currently not used by Hugin or its dependencies) which would be a high obstacle for building such a small library.

Second this lib is new for me and I don't know how enduring it is or how good the maintenance is. Last year there were only 5 commits to the repo.

A further point is that the patch is very invasive. It changes many files where GLEW is not used at all. Is this really necessary?

[Chris Mayo (chris-mayo)]

For Building on Windows, yes it does need Meson [1]. If Python 3 is installed:

pip install meson

Apparently meson can generate Visual Studio project files with `--backend vs` option [2] (also xcode).

[1] https://github.com/anholt/libepoxy/issues/65#issuecomment-277750480
[2] https://mesonbuild.com/Using-with-Visual-Studio.html

I've created a new patch with fewer changed files. It's added to the merge request as an additional commit (a consequence of using git-remote-hg) but is a stand-alone commit:
https://sourceforge.net/u/cjmayo/hugin/ci/f39a985d12d74b171f5794b783e5ea120d4442bf/

The original did reduce the number of lines of code, but fair enough to change less.

Anyway, I created this because it was impossible for me to install GLEW compiled for EGL at this time. Just sharing in case it is of interest and of course any change makes work, especially when trying to support 3 platforms - and there is still more to do on this.

[tmodes (tmodes)]

I tried to test it on Windows.
First I needed several more changes to get it to compile.

But it does not work:
nona --gpu is only printing "Attempting to dlopen() while in the dynamic linker." and then crashes.
Opening the fast preview crashes Hugin without feedback/further information.

[Chris Mayo (chris-mayo)]

I installed MSYS2 on MS Windows and built with that, most of the work was hacking Hugin CMakeLists to find the MSYS2 packages.

MSYS2 has an epoxy package, and supports pkg-config, the actual code changes from the last patch required below (I also modified win_bundle.cmake but that was a quick MSYS2 hack).
There were compilation errors in including glu.h in utils.cpp. Instead I changed from gluOrtho2D to glOrtho:
https://learn.microsoft.com/en-us/windows/win32/opengl/gluortho2d#remarks
And also lost the conversion of the GL error code to a message, something else to look at.

But I can then run nona from PowerShell:

PS > ./nona -g -o out .\TEST.pto
nona.exe: using graphics card: ATI Technologies Inc. AMD Radeon HD 6950

and hugin.exe by double-clicking from file explorer, and open fast preview.

Updated complete patch:
https://sourceforge.net/u/cjmayo/hugin/ci/274d3b105105a3b2db892095609f23d34a21134d/

```diff
--- a/src/hugin_base/hugin_utils/utils.cpp
+++ b/src/hugin_base/hugin_utils/utils.cpp
@@ -58,7 +58,9 @@
 #endif

 #include <epoxy/gl.h>
-#if defined __APPLE__
+#ifdef _WIN32
+#include <epoxy/wgl.h>
+#elif defined __APPLE__
   #include <GLUT/glut.h>
 #endif

diff --git a/src/hugin_base/vigra_ext/ImageTransformsGPU.cpp b/src/hugin_base/vigra_ext/ImageTransformsGPU.cpp
index b1271ae75..635e9d8fe 100644
--- a/src/hugin_base/vigra_ext/ImageTransformsGPU.cpp
+++ b/src/hugin_base/vigra_ext/ImageTransformsGPU.cpp
@@ -27,14 +27,6 @@
 #include <iomanip>

 #include <epoxy/gl.h>
-#ifdef __WXMAC__
-#include <OpenGL/glu.h>
-#else
-#include <GL/glu.h>
-#endif
-#ifdef __APPLE__
- #include <GLUT/glut.h>
-#endif

 #include <string.h>
 #ifdef _WIN32
@@ -121,7 +113,7 @@ static void checkGLErrors(int line, char* file) {
     {
         while (errCode != GL_NO_ERROR)
         {
- const GLubyte* message = gluErrorString(errCode);
+ const GLubyte* message ; //= gluErrorString(errCode);
             std::cerr << "nona: GL error in " << file << ":" << line << std::endl;
             if (message)
             {
@@ -806,7 +798,7 @@ bool transformImageGPUIntern(const std::string& coordXformGLSL,
     const int viewportHeight = std::max<int>(destChunks[0].height(), sourceChunks[0].height());
     glMatrixMode(GL_PROJECTION);
     glLoadIdentity();
- gluOrtho2D(0.0, viewportWidth, 0.0, viewportHeight);
+ glOrtho(0.0, viewportWidth, 0.0, viewportHeight, -1, 1);
     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glViewport(0, 0, viewportWidth, viewportHeight);
```

[tmodes (tmodes)]

For ImageTransformsGPU.cpp you need to include <windows.h> before gl.h. Then the glut call work (removing an error reporting is a no-go).

But when I use the released epoxy lib (compiled with MSVC) I'm getting the crashes.
After more testing it appears there is a bug in libepoxy build system or in meson.
Depending on the selected meson backend different code is generated.
The backend vs and ninja are both using the some compiler and linker, but produce a different sized library.
The library generated by the vs backend is crashing.
But when building with the ninja backend epoxy is working.

So now I need to clean up the modified code.

[tmodes (tmodes)]

I committed the changes to the repository.
But I made the choice of GLEW or epoxy user configurable in the CMake build.

[Chris Mayo (chris-mayo)]

Thanks. That works for me.