Slow rendering on El Capitan solution

Hi all. I put together a module that defers invalidate calls to avoid some issues El Capitan introduced (timers causing excessive redraws). Try it out. It’s free.

To use it, just add the module to a project, then replace calls to control.invalidate and window.invalidate with control.invalidateDeferred and window.invalidateDeferred.

It essentially makes a list of objects needing to be invalidated and then invalidates them all at once from a timer.

One side effect is that it can be called from a thread without issue.

Another side effect is that it solves the same issue on Linux. (go figure)

Here it is http://www.pidog.com/share/DeferredInvalidate.xojo_binary_project.zip

Post any results (good or bad)!
I’d like to know if it causes any issues I didn’t foresee.

It still seems like a bad idea to have such a high resolution timer and having it invalidate the UI…

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.

is there an issue with timers causing refreshes on ElCapitan? Even if they don’t actually call refresh or invalidate? I would like to know more about that if thats the case!

@James: See https://forum.xojo.com/27651-graphics-slow-on-el-capitan/p2#p229054

AH, I think I get it now. Thank you. Having a timer doesn’t 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 don’t understand the reasoning or what it was supposed to fix in the first place…

Seems very wrong indeed. Maybe Joe can enlighten us …

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.

Doesnt that lead to jerky animation and screen artefacts?
Surely this is a retrograde step?

Nope.

[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 don’t really know what I’m comparing it against. How did it previously decide how to start a redraw?