lock screen gotcha revisited

hh hh at hyperhh.de
Tue Aug 22 15:01:30 EDT 2017

Thanks for your fine explanation. And the future handlers sound very promising,
both OnUpdate() and OnMarksPonder().

Graphics are meanwhile pretty fast in LCB. I timed such clock updates (in LCB):
The OnPaint of a clock needs, also with a heavy loaded CPU, less than 4 millisecs.
Even checking the time and updating only pathes that are changed doesn't make
a significant difference. We look really forward to such new handlers.

And the updates of LC in the 'SVG area' will push animating things also ...

> Mark W, wrote:
> ...
> We could add a new event 'OnUpdate' which is dispatched inline with the 
> frame-rate (suitably rate adjusted based on time taken to update a 
> single frame). The event would have to be under the 
> script-execution-lock (like OnPaint) as anything doing wait, or causing 
> re-entrancy into the widget could cause problems. When a frame update 
> occurs, all widgets would get an OnUpdate event, and this would all 
> happen atomically under a lock screen. (Indeed, this mechanism would 
> also make engine control UI animations and animated GIFs less CPU 
> run-loop intensive - they are currently all implemented as separate 
> pending messages).
> ...
> However, the 'clock' (in particular) poses another problem.
> ...
> So, in actual fact, perhaps the clock is just doing things 'plain wrong' 
> in this regard. All clocks should be being updated simultaneously with 
> the same time. So we actually need a small 'clock-lib' with which all 
> active clock widgets register, and the 'clock-lib's only purpose is to 
> tell the time they should display - and *it* is the only thing which 
> uses a pending message to check when a second goes by.
> I shall have to ponder what mechanisms we need to add (if any) to be 
> able to do the latter...

More information about the Use-livecode mailing list