Just a little note : i developped a little demostration, that ran fine on AMD and P3 processors ...
But the app went berzerk when ran on a Centrino processor ( tested on 2 machines ). In fact, the timer seems to go whoosh ( the app should last 3 mins, while it ran in 20sec on Centrino !! )
I more or less expected this :(
(Hint: GLFW uses RDTSC for timing when available)
Detecting support for variable CPU core frequency on Intel CPUs has been a pain so far, and the code in GLFW isn't 100% proof.
On AMD it is very easy to detect PowerNow! (and I think it works with Cool'n'quiet! too, since it should be the same thing), by using well documented CPUID functions. Intel has not exposed this kind of functionality, at least not to user level programs, so it has been impossible to detect SpeedStep in the past.
Now with Centrino, I believe that it is at least possible, so I plan to add detection code to GLFW.
I really should add code for detecting this in a more robust way (runtime, regardless of CPU model).
I believe that I have now fixed the problem. You may pull the fixed win32_time.c/x11_time.c from the sourceforge CVS for testing.
Hmm i have used GLFW on my Centrino Laptop without any problems.
The thing is, we're talking about time-based application using the GLFW timer ... when i posted this, i used GLFW 2.4.2 ...
New cvs addition by Marcus ( making it it to GLFW 2.5 ) should fix this issue
Is there anyone who can verify that the CVS version has fixed these problems (on a Centrino system)?
kohaistyle: I lost your mail address. Could you contact me via mail when you have the chance (I would like to hear about your experiences/problems with GLFW)?
Marcus > Well, so far i didn't have any really bad experiences ... i'm still searching for a 'Centrino-equipped' fellow to make some GLFW tests ...
I'll contact you ASAP !
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.