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... _______________________________________________ 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