Well, in the example, I have a high resolution timer to test the ability to defer the redraws. In reality there could be any number of functions/events that need to update the UI going on that may overlap, and any timer firing would cause the UI to redraw and drag everything to a crawl. This just takes UI updates out of the hands of unrelated code.
AH, I think I get it now. Thank you. Having a timer doesnt cause a refresh unless there are invalidated regions outstanding and then they will be redrawn when the timer fires even if it had nothing to do with them. As falling into the run loop causes anything invalidated to be redrawn. That seems wrong to me from a logic standpoint but maybe I dont understand the reasoning or what it was supposed to fix in the first place…
This is a correct summary. My understanding is that this is Apple’s approach to unifying AppKit and Core Animation’s layout and drawing cycles. An application can make all of the invalidations or animations they want during event processing and everything will get processed at the very end of the event loop in one go.
[quote=232921:@Jeff Tullin]Doesnt that lead to jerky animation and screen artefacts?
Surely this is a retrograde step?[/quote]
A standard application event loop is very very quick, much quicker than you would imagine. I don’t quite know how to explain it, but it’s not loop that you would create in Xojo code.
I keep failing to wrap my head around how this will affect things though, I keep coming back that it should be fine under almost any normal circumstances. But I realize that I dont really know what Im comparing it against. How did it previously decide how to start a redraw?