Hi Cameron,
BTW lest I forget, very cool stuff.
Cameron McCormack <[EMAIL PROTECTED]> wrote on 03/15/2006 03:10:36 AM:
> I'd like your thoughts on how I will implement animation ticking.
> Currently (per the code currently in branches/anim), I have modified the
> RunnableQueue so that it has a Runnable that will be called when the
> queue is idle, thus avoiding some problems with unnecessarily flooding
> the queue with Runnables. (I may change this a bit eventually, though,
> so that busy waiting isn't done when no animations are active.)
So I was originally thinking of a fairly different approach to this.
My thought on this was that for the most part animation is 'reactive' not
'proactive'. Meaning that the animations for a particular time are
applied
just before a rendering takes place.
As far as the need the handle a 'constantly changing value' like your
stroke width. It is much better to have a target frame-rate and trigger
'repaints' on that schedule (where a repaint first applies any animation
updates). The target frame-rate should probably be member of the
UpdateManager (so applications can adjust as needed). You could also
try and implement a sort of 'auto' scheme where it monitors how long
each 'repaint' takes and slowly adjusts the frame-rate accordingly
(perhaps with a 'hint' as to how much % CPU it should be using).
> I came across a problem, though, where it seemed like the AWT event
> dispatcher thread was being starved of CPU, resulting in the canvas not
being
> updated in a timely fashion sometimes. I've found that modifying the
> runnable to sleep the UpdateQueue thread for a tiny amount of time let
> the AWT thread get some time to update the canvas
> (see o.a.b.bridge.SVGAnimationEngine.AnimationTickRunnable).
> if the
>
> Thread.sleep(1);
>
> line is removed, then at t = 10s, just as the 'animate' element finishes
> and the 'set' element begins, the display is not updated to revert
> Line1's width back to 50 and to show Line2 until a number of seconds
> afterwards. With the sleep line in, the update happens properly.
>
> So my question: is this thread sleeping an inappropriate way to get
> around the problem, and if so, any idea what a proper solution would be?
This sounds like you really want 'Thread.yield()', Probably a good
idea for the UpdateManager to do this anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
