Does GLUT slow down things? Most libraries have a tendancy to do this, so I was just wondering. Or when exactly should one use GLUT? Should final code include GLUT use, or should one make all their own code for the sake of speed? And in the end, is the difference in speed noticable? I’m just wondering if it would be starting a bad habit, using glut that is.
GLUT is not that much slower than pure Win32 API calls, or at least you won’t see any difference. Infact, GLUT uses the pure Win32 API to do anything. But GLUT is mostly used for two things, learning and testing. Learning, because it’s very easy to get it working. And testing becasue you can very quickly write a program that, for example, shows a technique who to do something. And you can write one program, and it will compile on litterally any compiler/platform supporing GLUT and OpenGL. Perfect for distributing small pieces of demonstrationcode.
And you shouldn’t use GLUT unless you want to make extremely portable code. Not because GLUT can’t be used to more advanced stuff, it can be used for great games for example, but because when using the pure Win32 API you got nearly maximum control over whats happening. This is something you don’t have in GLUT. I suggest you go for Win32 API as fast as you can, it’s because of control, not because of slowness/weakness or anything.
I agree. Glut is nice to get an app up and running quickly so you can test the OpenGL stuff, but you have a lot more control when using Win32 API calls.
I built another library named GlutPlus that encapsulates glut in a C++ API. I used virtual and static functions heavily to do this and I see no noticeable difference in performance between several Win32 examples and corresponding GlutPlus versions.