So as I understand it, the scheduling in Mavericks is designed to cut down on wasted time and energy powering up and down the CPU/GPU. I have no idea what that's going to do to the heartbeat. AppNap is I think orthogonal to the processor scheduling thing.
Anyway, has anyone built a VM on Mavericks yet? Seems like the best way to find out what the impact of this stuff might be.
On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge tim@rowledge.org wrote:
On 24-10-2013, at 5:09 PM, Igor Stasenko siguctua@gmail.com wrote:
you mean stepping? you can signal that semaphore if someone needs to step, as easy as:
[ [stepTime asDelay wait. sema signal ] repeat ] fork
(sure not exactly like above, but you got an idea)
i see no problem here.
That - or something similar, as you say - would provide current morphic behaviour BUT it is really just a way to cause the problem time coalescing is trying to solve.
I strongly suspect there is a lot of improvement in Morphic performance that can be gained by making the morphs do smarter (or less) stepping work. Obviously an animated widget is going to want to, well, animate. Almost all widgets to do with text display (editors, lists, buttons) aren't animating. They don't need to step unless there is good reason to think something relevant has changed. As an example, Scratch performance on a Pi took a good step (d'oh, bad pun) forward simply by stopping UpdatingStringMorphs (used for watcher-morphs, for game scores etc) from querying and redisplaying their value every time and instead only re-displaying when the value changed. I suspect here are a lot of cases where we know that some code is going to change state that will then need displays updating and instead of relying on a large number of dumb polling tests we might use an analogue of the old changed/update mvc protocols that *only* advise of a need to step soon.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A kangaroo loose in her top paddock.