One strategy is to create and start the animation thread before
accepting
any drag-n-drops at all. It can wait() indefinitely, and the
dragEnter
handler then just has to notify() in order to start the animation.
Similarly, dragExit or drop would not cause the thread to
terminate, only
reset its frame-counter and return to its idle wait() state.
This would only work if the animation is always the same, and not
dependent
on the dragged object. If it is dependent on the dragged object,
then a
FIFO queue of actions serviced by another thread might be needed.
Then the
handlers just queue an action (or a token signifying an action)
with the
drag-object parameter, and return. The queuing should be written
to take
as little time as possible, which means not creating big or complex
objects. All the "heavy lifting" is to be done only by the servicing
thread, who takes things out of the FIFO and performs the actions they
represent.
-- GG
I'll cook something up but right now its seems maybe I'm just to
paranoid about users doing really fast DnD's.
I mean if a DnD doesn't work a person would most likely do it again.
Thanx GG.
Yours sincerely,
Mohsan Khan.
_______________________________________________________________
Programmer, Animator, Musician
www.xybernic.com
There is no place like 127.0.0.1.
If everybody would give everybody a million would everybody be
millionaires?
Nothing has got to do with anything, and something has got to do with
everything.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
