True. That is why we don’t execute time consuming blocks of code inside an event handler.
In the code you provide there appears to be two applet instances. If that is correct then each applet has its own event-handling thread and you shouldn’t be calling the draw method or event handlers of one applet instance from another instance.
i dont know how the internals work but im assuming the thread and the Applet are seperate classes and as such it as a reference to the current running Applet, eg
To get a reference to the running PApplet we use the Java keyword this. If you run the following code you will see the output PApplet PApplet which demonstrates this.
First we distinguish between event capture and event handlers. When the mouse moves or a mouse button clicked or a key typed … then this is captured by the OS which creates an event-data-object that is forwarded to the currently active application, our sketch perhaps.
Now our sketch will have several threads running one of which will add the event-data-object to a fifo queue (fifo = first in first out) to be processed later.
So now we come to the interesting bit - the main event-handling-thread (EHT). This thread handles both rendering and event handling so when the thread is not rendering it will look remove the first event from the queue and depending on its type call the appropriate event handler to process the event. the EHT might process several events between each frame render so you get
Events are processed in the order they were captured but there is no way to predict how many event will be handled between frames.
Now you have your answer - all event handlers will block the draw method so it is important that large time consuming tasks are not performed inside the event handlers. If we do, not only will it block draw but it will prevent other events being processed, making the sketch unresponsive.