Work: Emulating GLUT with wxWidgets (wxGLCanvas)

[m-7761]

I've had some success with wxWidgets. To make it simple I've just emulated GLUT. I put its core API in a namespace I've called glute, or glut-emulated.

I think it can function as a hybrid. But I haven't looked at freeglut. The APIs I don't want to implement are APIs that really just do straight calls to OpenGL. Those are text and teapot business.

Switching fully to wxWidgets requires a pretty ambitious dive into finding another way to draw text.

I think GLUT's way of using glBitmap and GLUI's using glDrawPixels actually works well, because how GLUT creates so many contexts, this avoids managing resources to a great degree.

I think it's interesting to keep GLUT around to run comparison tests against wxWidgets and provide hybrid features. However wxWidgets provides much more mature functionality around so many things that GLUT lacks. GLUT seems to consciously sabotage itself so it can only be a toy/demo paradigm. Whereas wxWidgets can do basic things like menus and close buttons and frameless windows and all kinds of things very well.

The good news is (as long as GLUI's maintainers aren't dead set on holding it back harder than GLUT's) I think this work can be easily copy/pasted into GLUI even though I've already moved away from it for my work. It actually works well as it's own thing. It doesn't really need to be based on GLUI at all, but I haven't thought of how to package it otherwise.

I used identical names for its APIs as GLUT's. I didn't expect it, but this makes the names "ambiguous" when used together. This is kind of annoying, but it's actually possible to do it as long as you wrap your code in a namespace. The ambiguity is something that only affects code in the global namespace. It means it's possible to use both without wrapping every single GLUT API.

I changed over my GLUI (like) code to not #include the GLUT headers, so it can be certain it's not using them. But the example code uses both, mixed. And the file that implements the wrapper uses both, naturally.

Eventually I want to provide in my own code an option to use native controls in place of OpenGL controls. But I suppose GLUI would be happy to only provide the wxGLCanvas. The main trouble with wxWidgets I see is how to work with it as a dependency. It can easily be provided as an option enabled with a macro.

[nigels-com]

Out of interest. There was a similar sort of adaptor effort using Qt some time ago. I doubt it was complete enough for GLUI to work.

https://github.com/nigels-com/qglut-nvidia

[m-7761]

I'm doing this work in order to avoid Qt. I already have GLUI working this way without any code changes.

The code involved is quite simple. It's one small definition file. GLUT is quite simple. I thought I'd emulate it because it's a good a start as any to wrap wxWidgets in a simplified container. I think there is value in having highly expressive APIs, but that the real value comes when you use those as raw materials to build more focused software.

I would try to define GLUI in terms of a high-level wrapper around a simple, low-level system. GLUT is as good as any candidate for a low-level system. It just needs more flexibility. I think GLUI can be a good proof of concept that GLUT can better be emulated by wxWidgets. Another project can do that and finally put all of the old laborious GLUT code to rest. (It can be written in one small file written in terms of wxWidgets or any other decent cross-platform system. I don't know about QT. But wxWidgets was surprisingly straightforward for GLUT.)

[m-7761]

FWIW at this point I have everything working correctly with wxWidgets. It's 1000 lines of code.

There's just some microscopic things to attend to. The devil is in the details. I will probably set on it for a little while, but I will add to my fork's code after I go over it with GCC and run it on an indirect X server.

I have to parse the command-line as GLUT would. wxWidgets has some command-line helper facilities, but I don't think it does the X command-line automatically. But maybe there is a subroutine in there somewhere to do that.

Right now my test setup is to pass 1 through 6 for the first demo on the command-line, and negate the number to use the wxWidgets emulator. I guess it's emulating GLUT, but it's implementing it too. It's just an incomplete/unadvertised version of GLUT.

Oh, I have to implement GLUT's pop-up menu facility. I have some Win32 code I wrote to do that for freeglut, so maybe it will translate easily to wxWidgets. It won't complete waste if so.

The user experience feels better than GLUT or freeglut. But there is some problem with the frame-rate jamming up right now. It would probably not happen if I removed the timer fix for Nvidia GLUT. I think it probably uses a high-resolution multimedia timer, and wxTimer still uses the old timer system.

The GLUT_ELAPSED_TIME report is using the QueryPerformanceCounter timers. But I don't know if there is a wxWidgets event for that. I have to look into what can be done here. I traced it now to SetTimer. timeSetEvent would be better for Win32. It seems like a tough one. I'm think the idle loop just has to keep its own stack of timers and manually compare them to the wxStopWatch values used for GLUT_ELAPSED_TIME.

[nigels-com]

I recommend discussing a wxWidgets GLUT layer elsewhere. If and when it's suitable and ready for broader adoption, please do let us know that we ought to take a look.

[m-7761]

please do let us know that we ought to take a look.

Who is the "us" and "we" you have in mind?

[nigels-com]

It's possibly of more interest as a complete, tested and working solution. It's not clear what's actionable here from a GLUI point of view. So take it as a "we wish you well, happy adventures".

[m-7761]

https://github.com/mick-p1982/mm3d/ demonstrates emulating (partially implementing?) GLUT with wxWidgets, in one source file: https://sourceforge.net/p/widgets-95/code/HEAD/tree/trunk/src/xcv_widgets.cpp