I'm trying to set up a simple OpenGL game on macOS, using an NSTimer to set up a run loop as explained here. The idea is to create a repeating timer with a very small (~1ms) time interval and rely on vsync to regulate the frame rate.
I'm setting my NSOpenGLContext swap interval to a value of 1, which should enable vsync. I was under the impression that this would cause NSOpenGLContext.flushbuffer to block, but this doesn't seem to be the case. My render code is firing off much more frequently than 60 times per second.
The document I linked has been marked as retired, but all the official documentation I've read suggests that it's possible to throttle an NSTimer loop to the display's refresh rate somehow. I haven't been able to get this working though, and I'm wondering if this approach is no longer viable.
Am I missing something? In a modern project, is it better just to go with a CVDisplayLink?
My understanding is that it's unlikely that an NSTimer will fire more frequently than about 10-20 times per second, and with timer coalescing you aren't likely to get guaranteed fire times appropriate for this type of application. For example, one answer to this question points out that the docs say:
Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds. If a timer’s firing time occurs during a long callout or while the run loop is in a mode that is not monitoring the timer, the timer does not fire until the next time the run loop checks the timer. Therefore, the actual time at which the timer fires potentially can be a significant period of time after the scheduled firing time.
CVDisplayLink is definitely the preferred solution. It's quite simple to use, too.
And to answer your other question, yes something has changed. The OS has changed how timers are handled to help improve energy performance. I worked on an app that used the method you're suggesting up until about OS 10.9 or 10.10. Once that came out we had to rethink our strategy because timers worked differently.
Related
In Flutter if I create a Timer, will the supplied callback get executed if the application is in background?
I think documentation is not clear on this or I might have missed it (please supply a link if you find it anywhere).
I just tried doing this with a timer set up to 10 seconds and it works fine.
I assume that is approach is not very reliable and other methods* should be used instead. I think if the app is paused/terminated by operating system to preserve battery or due to low memory, nothing will be executed. But for me this situation could be an ok approach.
* I know there are isolates so I guess I could spawn the timer inside one of these. Downside is that the isolate must be regular function (or static method) so no access to application data in my scenario. Then there are different scheduling packages etc but I'm trying to avoid these for now. I know about background tasks but I'm really looking for an answer on code execution using timers.
I need to synchronize Unity app to a 3rd party app where time synchronization is crucial (1-2ms varient max).
The way this is done today (without Unity) is getting priority of the OS scheduler with a designated app which will assure a constant delay.
A constant delay is good enough as it can be used in the data analysis which is not done in real time. Today the constant delay is measured once on the beginning.
Thanks in advance.
This kind of delays should be easy to achieve in a background thread.
Threads work well in Unity, despite common belief. The only thing you need to look out for is not to access Unity objects from the thread.
Easiest way to do this is to start a thread in a MonoBehaviour.Start with the IsBackground property set to true (so you don't have to worry about it blocking your application exit) and communicate to and from it with a message queue (for example a List<Action> with locked access).
I am trying to figure out how to use a background thread to execute a command ever 4hrs.
I have never created anything like this before so have only been reading about it so far.. One of the things I have read are this
"Threads tie up physical memory and critical system resources"
So in that case would it be a bad idead to have this thread that checkes the time then executes my method... or is there a better option, I have read about GCD (Grand Central Dispatch) but I am not sure if this is applicable as I think its more for concurrent requests? not something that repeats over and over again checking the time..
Or finally is there something I have completely missed where you can execute a request every 4hrs?
Any help would be greatly appreciated.
There is a max time background processes are allowed to run (10 min) which would make your approach difficult. Your next best attempt is to calculate the next event as save the times tamp somewhere. Then if the app is executed at or after that event it can carry out whatever action you want.
This might help:
http://www.audacious-software.com/2011/01/ios-background-processing-limits/
I think that it would be good to make use of a time stamp and post a notification for when the time reaches for hours from now.
Multithreading is not a good means to do this because essentially you would be running a loop for four hours eating clock cycles. Thanks to the magic of operating systems this would not eat up an entire core or anything silly like that however it would be continuously computed if it was allowed to run. This would be a vast waste of resources so it is not allowed. GCD was not really meant for this kind of thing. It was meant to allow for concurrency to smooth out UI interaction as well as complete tasks more efficiently, a 4hr loop would be inefficent. Think of concurrency as a tool for something like being able to interact with a table while its content is being loaded or changed. GCD blocks make this very easy when used correctly. GCD and other multithreading abilities give tools to do calculations in the background as well as interact with databases and deal with requests without ever affecting the users experience. Many people whom are much smarter then me have written exstensively on what multithreading/multitasking is and what it is good for. In a way posting a message for a time would be method of multitasking without the nastiness of constantly executing blocks through GCD to wait for the 4 hr time period, however it is possible to do this. You could execute a block that monitored for time less then the max length of a threads lifetime then when the threads execution is over dispatch it again until the desired time is achieved. This is a bad way of doing this. Post a notification to the notification center, its easy and will accomplish your goal without having to deal with the complexity of multithreading yourself.
You can post a notification request observing for a time change and it will return its note, however this requires you application be active or in the background. I can not guarantee the OS wont kill your application however if it is nice and quiet with a small memory footprint in "background" state its notification center request will remain active and function as intended.
I am trying to use iPhone for some sort of measurement and I need an event that fires every mSec (or sooner), this event will turn on/off the LED.
I have tried a few options to make this work without any success. If I use NSTImer event, the maximum frequency I can reach is around 100Hz.
If I turn on/off the LED in a simple for loop, the frequency goes to 300Hz but that seems to be the maximum. Also it is not purely periodic, a context switch happens and I get the control back much later.
I also experimented with Mach API but no luck. Do you think is it even possible to turn on/off LED at a frequency around 1KHz.
NSTimer has a limited resolution as you have discovered.
Apps are not designed to be real-time systems and system processes can (and do) occur from time to time which may delay processing periodically (memory alerts, system functions, etc). These may not be manifested in obvious ways for usual apps, but if you are attempting to do some intense loops then you will observe them more frequently.
I'm working on an iPhone Game where the player tilts the iPhone to make the character move, but unfortunately all of the timers I'm using to animate the scenario are slowing down my game. I've been told to use NSThreads, but I really don't know anything about them. My question is, What are the differences between using NSThreads and NSTimers? Or what are the advantages of using NSThreads? How are they useful?
Timers are used for asynchronous, not concurrent, execution of code.
A timer waits until a certain time interval has elapsed and then fires, sending a specified message to a target object. For example, you could create an NSTimer object that sends a message to a window, telling it to update itself after a certain time interval.
Threads are for concurrent execution of code.
An NSThread object controls a thread of execution. Use this class when you want to have an Objective-C method run in its own thread of execution. Threads are especially useful when you need to perform a lengthy task, but don’t want it to block the execution of the rest of the application. In particular, you can use threads to avoid blocking the main thread of the application, which handles user interface and event-related actions. Threads can also be used to divide a large job into several smaller jobs, which can lead to performance increases on multi-core computers.
See also:
How do I use NSTimer?
Timer Programming Topics
Threaded Programming Guide
Timers are objects that simply call methods at a later time. Threads are additional "streams" of stuff to be processed, in psuedo-parallel. It's like comparing apples to oranges—they're not really related. The only relation I can see is if you want to do some processing in the background, but you shouldn't be doing UI calls in background threads, Why are you using timers to make your character move? Knowing that, we might be able to supply an alternate solution.