Hi, thanks for your thoughts
Yes, in order to get vertical sync going I am using the:
This does as it says, just in an unacceptably inefficient fashion!
It certainly does make calls to:
wait for the vertical retrace, but while it is waiting, the CPU is at 100%. In the Windows drivers, the CPU would be at 0%.
Does this make sense? Same functionality, but one uses 100% CPU, and one doesnt. This is probably OK if you are running a game (where you generally dont care if other tasks get access to the CPU) but for a desktop application it is not good.
You are quite right about the poll() code - this was only ever a hack (albeit one that had been reported to work at one point on Linux) which I thought may trigger some peoples memory of this sort of thing.
What I would love is just for the code which is behind the:
to actually work like its Windows counterpart, not as a hack, but a reliable feature.
To see if it really is just me (!) please do compile up a simple OpenGL test program, and make sure it sits in a tight loop, with only glXSwapBuffers() to slow it down (no sleep() etc.).
Run this with vertical sync enabled and you should see on Linux/FreeBSD that it will consume 100% of CPU power whilst running. On windows, it will consume only a few % (depending on your setup) to do the same task.
I think the problem is, most people use OpenGL for games, and so are used to their CPU running at 100%. Games in general suck as much CPU power as possible.