On 2017-08-22 17:31, hh via use-livecode wrote:
@Mark.
Say I have 24 copies of the LC clock widget in order to display
different time zones.
How can I have them in "seconds-sync"?
In LC Script, with LCS-clocks I would do a screenLock, update the
clocks and then unlock.
In LC Builder I even tried to make a composed widget, without
improvement.
Seems one has to make a grid of clocks in LCB, as one widget (with one
single OnPaint)?
Okay - so this is a slightly different problem. You would have the same
issue in LCS if you implemented a clock in the same way the clock widget
works.
The clock widget uses the 'schedule timer' syntax to do the equivalent
of 'send in time'. Indeed, this is implemented using the same mechanism
as 'send in time' and so each pending message (timer, in this case) is
dispatched separately, and not under a lock screen.
I spent some time pondering whether there was anything we could do to
the OnTimer mechanism in widgets to help here - e.g. quantize the
delivery time, and then dispatch all timers which are quantized to the
same time at the same time under lock screen...
However, I quickly realized that this is perhaps not appropriate - the
OnTimer mechanism is probably just the wrong abstraction for animation
and is more appropriate for 'timed events in the future which don't need
synchronization' - e.g. the timer which is needed to do an Android Toast
with a suitable delay before closing it automatically.
In this case, I think the clock widget's behavior is definitely an
animation behavior. So we perhaps need an 'OnUpdate' mechanism.
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).
So, such a mechanism definitely works - we used in Galactic Gauntlet to
great effect, and AnimationEngine does precisely this to make its
animations as silky-smooth as possible.
However, the 'clock' (in particular) poses another problem.
In most cases animation is parameterized by the 'time since you started
the animation' - i.e. it is relative. So, what you do is you have a
'master clock' which starts at 0 when the app starts, and increases as
actual time does - it isn't based on the system clock as that can change
arbitrarily (pesky users fettling with their system time settings!).
When you start an animation, you store the 'time of the last frame
update', and then on each update you use 'time of current frame update -
stored frame time' to work out how far into the animation you are.
However, in this case, the clock's animation is *actually* tied to the
the system time which changes things slightly. It would be perfectly
possible (if you had 24 clocks) that a frame update would start at
18:00-epsilon and take until 18:00+epsilon (for some small value
epsilon). This means that the first 12 clocks would display 18:59, and
the last 12 clocks would display 18:00 (all being equal) - all because
the update *just* happened to start at an inappropriate time.
The thing is that this seems like a very special case in the world of
things you might want to animate. It seems a bit 'silly' to add an extra
parameter ('synchronized actual time') to the OnUpdate message, when (in
all likely-hood) displaying *real* clocks is maybe its only use
(remember OnUpdate is about animation - nothing else).
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...
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
