melekor wrote on Thursday, June 13, 2013:
So with glfwSleep removed, what should I be using instead?
The translation guide says something about C11 and C++11 threads, but I’m using C on visual studio which only has C90 support or something like that.
elmindreda wrote on Sunday, June 16, 2013:
Read the entire paragraph. There are links to software that works with Visual Studio.
melekor wrote on Sunday, June 16, 2013:
Cameron: thanks, but usleep doesn’t exist on all GLFW’s supported platforms.
Camilla: So your suggestion is to install a multi-threading library so I can call sleep in my single-threaded program? What guarantee is there that the threading library’s sleep function even works together with my default/main thread which is not created via that library? Even if that is always the case in practice, this seems quite inelegant compared to a simple glfwSleep call. Could you explain why this situation is preferable to the GLFW 2.x way?
elmindreda wrote on Sunday, June 16, 2013:
Those libraries use native OS threads, of which the main thread is one, so it is guaranteed. You can also pluck out the implementation of sleep from one of them and use only that.
Proper, per-thread sleep is in the domain of a threading API, not of a window and context creation one. Even if your application is single-threaded, frameworks you are using directly or indirectly may be using worker threads that shouldn’t be put to sleep by a naive, process-wide sleep function.
melekor wrote on Sunday, June 16, 2013:
You can also pluck out the implementation of sleep from one of them and use only that.
That’s what I thought 
I am just going to end up copying and pasting the code for the glfwSleep function (or the one from the thread lib, same thing) into my code, because it doesn’t make any sense to require a threading library to sleep when I am not doing any threading. The end result is my code is less portable, has more ugly #ifdefs, more maintenance burden and more frustration. I don’t expect my experience here will be unique either.
Proper, per-thread sleep is in the domain of a threading API, not of a window and context creation one. Even if your application is single-threaded, frameworks you are using directly or indirectly may be using worker threads that shouldn’t be put to sleep by a naive, process-wide sleep function.
If I am not doing anything whatsoever with threads, then I shouldn’t have to worry about any of this. Single threaded programs still need to be able to sleep, so with that function gone we are in trouble.
What I would suggest is either (a) bring back glfwSleep or (b) make a version of glfwWaitEvents which takes a timeout parameter. Either would be sufficient for implementing cpu throttling / FPS limiting type things.
vittoriolassini wrote on Sunday, June 16, 2013:
If I am not doing anything whatsoever with threads, then I shouldn’t have to worry about any of this. Single threaded programs still need to be able to sleep, so with that function gone we are in trouble.
What I would suggest is either (a) bring back glfwSleep or (b) make a version of glfwWaitEvents which takes a timeout parameter. Either would be sufficient for implementing cpu throttling / FPS limiting type things.
I think, GLFW3 “strives” to be focused, minimalistic and clean. And this philosophy is one of the reasons many of us love GLFW. While glfwSleep() is occasionally useful, it is (in my opinion) not useful enough to justify including it in GLFW, it’s really in domain of threading and out of focus of GLFW. For the same reason we don’t have in GLFW3 many other things, such as limited image loading, text drawing, config files parsing or sound routines etc. It’s just not the focus of GLFW and there are mature, complete and featureful solutions for such things. Do we really need limited and “overlapping” functionality in GLFW? Rationale for API cleanup and all deprecations presented perfectly in “2 to 3” transition guide.
And in most cases (i don’t know about yours) sleep is just no good for fps limiting, because of granularity issues and sleep time upper bound guaranties. Usually, best tool for this job is vsync. What we really need is to polish glfwSwapInterval (mostly under win, desktop composition check currently blocks any control over swap interval).
melekor wrote on Monday, June 17, 2013:
Vsync is not good for fps limiting either (in general) because a lot of drivers implement it with a busy wait, resulting in 100% cpu use. Nvidia on windows does this even on the latest drivers (May 23, 2013). Of course, advanced programs will offer multiple options for fps limiting.
Without a sleep function, GLFW3 has no ability to write a proper main loop to control CPU use or FPS rate. In my opinion, it is completely insane to require 3rd party libraries to write a proper event loop. The cross platform event loop is the absolute core of what GLFW is supposed to provide, it is not tangential functionality like image loading or text drawing.
vittoriolassini wrote on Monday, June 17, 2013:
Vsync is not good for fps limiting either (in general) because a lot of drivers implement it with a busy wait, resulting in 100% cpu use. Nvidia on windows does this even on the latest drivers (May 23, 2013).
It is simply the best that you can get. With sleep-based solutions you’ll get tearing, your fps will likely be lower than you expect and there will be jitter. It’s a cure worse than disease. Vsync issues are only driver issues and drivers get better, but sleep solution is fundamentally broken.
I have win7, 560Ti with latest drivers and there is no 100% cpu usage in my GLFW3 applications with vsync. Can you give more details about your system and your application? Do you use glFinish() in your code? What is the status of “Threaded optimization” and “Vertical sync” in your Nvidia Control Panel?
Of course, advanced programs will offer multiple options for fps limiting.
Most commercial games have just vsync switch in options.
Without a sleep function, GLFW3 has no ability to write a proper main loop to control CPU use or FPS rate.
You don’t need sleep in main loop in the first place. For example, you can look at Doom 3 source code. There is no sleeping for fps limiting.
Sleeping in main loop is rare and questionable. For those rare cases you just use some threading solution, it’s not that difficult.
melekor wrote on Monday, June 17, 2013:
I am sorry but you are just misinformed here. It is not “questionable” or a “rare case”. Every main loop needs to have some kind of yield call in it, unless it is acceptable for the application to consume the entire CPU. Vsync cannot be relied on, and even if it could be relied on, you don’t always want to run at the refresh rate. Mostly fullscreen games will consume 100% CPU, but these days even games are becoming more aware of power efficiency issues, the need to not excessively drain the battery on laptops or tablet devices.
Secondly, Vsync off does not imply tearing. For example on modern windows systems, the entire desktop surface is always vsynced when compositing is enabled.
Thirdly, sleep-based solutions can work just fine. I am not speculating about stuff I haven’t tried in real life here.
I don’t want to get into specific details my system since it is orthogonal to the point I am attempting to make here. I will say that I do a lot of tech support for graphics issues for the product I maintain, and I have seen vsync causing 100% cpu on many different setups. Please google “vsync 100 cpu” if you don’t believe me.
vittoriolassini wrote on Monday, June 17, 2013:
Every main loop needs to have some kind of yield call in it, unless it is acceptable for the application to consume the entire CPU.
It’s just that you don’t need sleep in your main loop. And commercial games don’t do that.
Vsync cannot be relied on
Of course you can rely on vsync, because you simple don’t have another sensible options for most cases. You can’t rely on sleep because on desktop OSes you don’t have any guaranties about sleep time upper bound. Sleep(10) basically means that you’ll get no less then 10 time units of sleep. And there is problem with granularity (for example, to achieve low granularity on win you need to mess with timeBeginPeriod()/timeBeginPeriod(), which globally affects scheduler resulting in lower performance and decreasing chances for cpu to use power-saving modes).
In fact, i never experienced vsync busy-waiting on large range of hardware, so i wonder how much this is a problem at all.
even if it could be relied on, you don’t always want to run at the refresh rate.
Yes, and most of such cases can be described with words “render as fast as you can”.
but these days even games are becoming more aware of power efficiency issues, the need to not excessively drain the battery on laptops or tablet devices.
Properly implemented vsync to the rescue.
Secondly, Vsync off does not imply tearing.
Yet i see tearing all the time with vsync off.
Thirdly, sleep-based solutions can work just fine. I am not speculating about stuff I haven’t tried in real life here.
Vsync can definitely work just fine. Can you list some of sleep-based commercial games for reference?
If you really need sleep, just use some threading solution.
melekor wrote on Monday, June 17, 2013:
It’s just that you don’t need sleep in your main loop. And commercial games don’t do that.
What function do you call to yield CPU then? *nix sched_yield() is equivalent to what glfwSleep(0) does in 2.x.
Of course you can rely on vsync.
No. See previous post. It is not always reliable, and even if it was reliable, it isn’t always the desired behavior.
You can’t rely on sleep
Sure, you can’t rely on it to sleep for exactly the amount of time requested, but it works well most of the time in practice. There’s also no alternative that I am aware of.
Yes, and most of such cases can be described with words “render as fast as you can”.
No. There are more possibilities than “refresh rate” and “as fast as you can”. Examples would be playing an animation at its native rate, or limiting FPS to a specific maximum.
Yet i see tearing all the time with vsync off.
I said implies. In other words, vsync off does not guarantee tearing. On modern windows for example, you typically only get tearing when compositing is off, or when in fullscreen/exclusive mode with vsync off.
Can you list some of sleep-based commercial games for reference?
Any game with a MaxFPS option. World of Warcraft for example.
vittoriolassini wrote on Monday, June 17, 2013:
What function do you call to yield CPU then?
I’m just using vsync. If i’ll be in need of explicit yielding, sleeping or other threading-related things, then i’ll use some portable threading solution.
No. See previous post. It is not always reliable
Nothing is always reliable. But (in my opinion) need for workaround for some problem of some hardware/software configurations is poor reason to include some “unrelated” functionality to the library.
even if it was reliable, it isn’t always the desired behavior.
I’m not denying that. I’m just saying that the other cases are pretty rare.
Sure, you can’t rely on it to sleep for exactly the amount of time requested, but it works well most of the time in practice.
Vsync works well most of the time in practice too. In my practice, at least. But i cannot say anything good about sleep-based methods (especially for active, high fps games).
No. There are more possibilities than “refresh rate” and “as fast as you can”. Examples would be playing an animation at its native rate, or limiting FPS to a specific maximum.
Yes, there are more possibilities. But this two used much more frequently then the other. And that reflected in commercial games. Do we need rarely used “out-of-focus” features in glfw? Besides, just adding glfwSleep() is not enough. You must add some means for controlling granularity.
typically only get tearing when compositing is off, or when in fullscreen/exclusive mode with vsync off
I feel this “only” happens much more frequently than busy-waiting vsync problems…
Any game with a MaxFPS option. World of Warcraft for example.
It’s a good example, but most games i played were without such option.
melekor wrote on Monday, June 17, 2013:
So what you are telling me is that the ability to control the frame rate and CPU use of my application is an advanced feature which is outside the scope of GLFW? I find that rather incredible.
vittoriolassini wrote on Monday, June 17, 2013:
So what you are telling me is that the ability to control the frame rate and CPU use of my application is an advanced feature which is outside the scope of GLFW?
I think that the ability to control the frame rate and CPU use through sleep calls is outside the scope of GLFW.
melekor wrote on Monday, June 17, 2013:
I just don’t know how to get through to you. I believe I presented a strong argument in my previous posts, if you don’t get it then I guess we will have to agree to disagree. For me, if I need more than one library to write my basic event loop, then GLFW has failed its job. That simple. Removing glfwSleep will help no one, but it will waste people’s time as it has wasted mine. If your way of thinking about this issue represents the maintainer’s views, I think it is very sad for GLFW.
marcel_metz wrote on Monday, June 17, 2013:
If I am not doing anything whatsoever with threads.[…]
But you do, you put the calling thread of your process to sleep. If your application only uses one thread that’s your design decision.
vittoriolassini wrote on Monday, June 17, 2013:
David, i’ve just stated my personal view as a random glfw user and i really have nothing to add. Of course you are free to disagree.
This proposal is seen from my eyes like that:
Let’s return glfwSleep() because there are some people that
melekor wrote on Monday, June 17, 2013:
want to control framerate through sleep calls
I wasn’t going to reply again, but you keep saying “through sleep calls” like you are implying there is some other way to accomplish these things other than with sleep calls. Is there? What is it?
refuse to use some threading solution
I must I do whatever it takes to make my program work correctly, otherwise my users will be in trouble. But I am saddened when an elegant library like GLFW is suffering poor design decisions and going backwards, forcing me to add ugly hacks to my code to accomplish my job. Like requiring an entirely different library just to write my freaking main loop (seems like a bad joke).
vittoriolassini wrote on Monday, June 17, 2013:
you are implying there is some other way to accomplish these things other than with sleep calls. Is there? What is it?
It is vsync (again). It limits your fps (to monitor refresh rate) and cpu use (with proper implementation, and personally i don’t experienced “improper implementation” in years). And i have a feeling (i don’t have hard numbers to support that claim, but neither are you, it seems) that most people are happy with just that (many if not most commercial games don’t use sleep-based system). I’m personally one of such people.
If you need fps limits other than monitor refresh rate then vsync is not for you. But i’m not convinced that your needs are common. And even with your needs it’s no big deal to just use threading library.
forcing me to add ugly hacks to my code to accomplish my job
There is no need for any hacks. You just need additional dependency. It’s not that painful.
Okay, lets stop at this and just wait for opinions from other users or Camilla.