That was mostly meant as a joke! 
Although you could theoretically extend a renderer to did this.
You were more correct with AWT actually! The EDT is part of AWT, and you can check if your code is running on it using EventQueue.isDispatchThread(). This should mainly be in event callbacks. Neither the Java2D or JOGL renderers use this for draw().
We can type in println( Thread.currentThread() ); in order to find out the current Thread running a function: 
OT: about threads:
this would take it somewhat off topic, as i meddle more in java than processing itself.
iāve tried things like rendering things in image buffers and using executor service to run them in different threads. http://tutorials.jenkov.com/java-util-concurrent/executorservice.html
after that i combine/blit them into the canvas like tiles when each thread of the executor service completes and return images to the main routine (this could be draw()). even on AWT/Swing that significantly speed up some heavy graphing/plotting work. this is especially observable (from waiting ~10 seconds to completing in a heartbeat) on the slower but multi-core cpus thatās prevalent on laptops, netbooks, tablets PCs these days.
iād think similar strategies can be done in processing.
Yes, thatāll work if youāre CPU bound, and doing operations that Java2D canāt run on the GPU, so direct pixel stuff especially. But I would guess most people doing intensive graphical things are running one of the OpenGL renderers?! In which case theyāre probably GPU bound and this approach wouldnāt help / would break.
Good to see you using ExecutorService - most attempts at threading around here are āinterestingā 
one of those things i like about ExecutorService is that invokeAll().
it is basically first setting up a bunch of Callables put them in a Set and invokeAll().
this has the disadvantage that it would block and wait for all the threads to complete and results to return, but this could still be a lot faster if each thread/job takes about same amount of time to complete. But iād say invokeAll() is very convenient compared to managing the threads separately.
for openGL iām not too sure if separate sets of GLSL scripts may be generated in different threads and then bundled into a big script say when it gets collected up in draw(), then the whole script could be āpushedā to the hardware to render. but i think there may still be bottlenecks with this approach