lock screen gotcha revisited
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