Re: Moving TimelineEngineThread into Toolkit specific code

[Kirill Grouchnikov <kirillcool@yahoo.com>]

Hi Paul

One idea that i'm thinking over for post-1.0 release is to provide an API to change the "pulse source" for the main Trident thread. Right now it has a hard-coded sleep period, but i would like to have the applications able to control that.

While support for UI toolkits is an important part of the library, i don't think that the thread creation belongs as an API in the UIToolkitHandler interface. An application can mix UI components from different libraries, or not have the UI at all.

The way i see it, Trident will provide an abstract thread class that will have a (tentatively named) waitUntilNextPulse() method. The core implementation will continue using Thread.sleep(40), while custom application code will create its own extension class and implement that method. Is this something that will be easy to integrate with your frame cycle manager?

Thanks
Kirill

---

From: Paul Byrne <Paul.Byrne@Sun.COM>
To: dev@trident.kenai.com
Sent: Tuesday, June 23, 2009 8:52:27 AM
Subject: Moving TimelineEngineThread into Toolkit specific code


Hi Kirill,

One thing we do in Wonderland which is a little different from other UI toolkits is to control the systems framerate explicitly. This helps with responsiveness on slower system and preserves resources on higher powered systems. As a result it's more efficient to trigger animation updates on a frame cycle rather than a timer (or timed sleep).  On principal how would you feel moving the TimelineEngineThread into the toolkit specific code ?

I'm just bouncing around ideas at the moment, not formally requesting a change :-)

Rgds

Paul