event dispatch thread vs processing animation thread

eatthecasket

I came across a line in the Papplet description "events (like mouse movement and key presses, which are fired by the event dispatch thread or EDT) are queued to be (safely) handled at the end of draw()." If I'm understanding this correctly then even though these ui events are triggered by the edt they're actually processed on the animation thread.

is this reading accurate? I need my key events to be millisecond accurate, if I'm already doing a bunch of video manipulation on the animation thread is this going to cause timing errors?

I'm pretty green with processing but having done a lot of work with max and jitter it's all very exciting!

GoToLoop

Although I'm not an expert, I believe that's what you've described:
Events are indeed enqueued by a separate Thread, yet only fully dequeued in the main animation Thread, once draw() finishes.

Yea, it means events don't run at the same time as draw(). All of them belongs to the same Thread and runs sequentially. :ar!

Anyways, there's an "unofficial/undocumented" Processing method called thread(""):
It invokes a function as a separate Thread, so it can be used for more precise computation.

There's also another 1 called method(""). It does the same thing as its counterpart, but w/o creating a Thread.

eatthecasket

I was really hoping that wasn't the case but I already have a separate thread setup for timing. Could I just add something like

void keyReleased(){ //key logic }

into the class body and then it would run in my timing thread?

eatthecasket

the other solution I came up with was creating a separate key listener java.awt.event.KeyAdapter but I'm still not really comfortable with java

quark

Processing 2 captures the mouse and keyboard events triggered by the OS and creates new equivalent events based on the classes

processing.event.MouseEvent

processing.event.KeyEvent

...

which are then queued by Processing. This allows a Processing sketches to use a common set of event handlers no matter what mode/renderer is being used.