On Thu, Oct 24, 2013 at 8:32 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
 



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.

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.


Ok, that would be this code, what clock time is it now, what clock time  do we have to wake up at?  Sleep until then, or some interrupt.

    now = ioMSecs();
    next = getNextWakeupTick();
    realTimeToWait = next - now; 
    aioSleep((int) realTimeToWait*1000);

 


Useful random insult:- A kangaroo loose in her top paddock.





--
best,
Eliot




--
===========================================================================
John M. McIntosh <johnmci@smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================