[Vm-dev] OS X Mavericks & cog tickers

[Eliot Miranda]

On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge <tim at rowledge.org> wrote:

>
>
> On 24-10-2013, at 5:09 PM, Igor Stasenko <siguctua at 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.
>

OK, but these are separable issues.  Making morphs smart enough to know
they're animated or not, and hence know whether they should be redrawn
within 50ms or not is completely orthogonal from what the VM should do at
idle.   When the VM has nothing to do it should sleep until there *is*
something to do.  One of those things to do is to wake up when the mnext
delay fires.  So *if* a Morph wants service 50ms from now the VM can still
sleep until that time.

Can we please stop confusing the conversation and concentrate on the VM's
bogus idle behaviour.  What we should eb concentrating on now is arranging
that the VM can enter a fully quiescent idle state that it will exit when
- i/o is possible (which includes input events, there are a form of "i" in
"i/o"
- a signal is delivered (except this could also be a variation of the above)
- the next delay is due to fire
- a callback has occurred
I think I'm right in thinking that nothing else can happen that justifies
the VM leaving its idle state.

Note that in the VisualWorks VM it is the scheduler that enters the idle
state whenever there is no runnable process, and hence the idle process is
conspicuously absent.  And a very nice solution that is too.



>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- A kangaroo loose in her top paddock.
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131024/b27a1d56/attachment.htm