public class DrawListener implements GLEventListener {
private boolean isInit = false;
public void display(GLAutoDrawable drawable) {
if (!isInit) return;
if (display.getEDTUtil().isCurrentThreadEDT()) {
// For some unknown reason, a few frames of the animator run on
// the EDT. For those, we just skip this draw call to avoid badness.
// See below for explanation of this two line hack.
pgl.beginRender();
pgl.endRender(sketch.sketchWindowColor());
return;
}
…which is an inauspicious beginning, and it doesn't get much better from there.
We need to figure out:
why those calls are coming from the EDT, and
how we should handle them properly
I think the answer to the first question is that any time the window manager (OS) does a UI update, rather than the Animator thread doing its thing. That said, we need something definitive on whether we should be drawing there (at the moment, the understanding is that we shouldn't) and how it should be handled instead (i.e. re-queue the event in another thread).
But this is also related to https://github.com/processing/processing4/issues/370 to some degree, where it's unclear to what degree we're paying for badness like this lurking in the code, or something that's not entirely our fault.
Inside
PSurfaceJOGL
, we've got:…which is an inauspicious beginning, and it doesn't get much better from there.
We need to figure out:
I think the answer to the first question is that any time the window manager (OS) does a UI update, rather than the
Animator
thread doing its thing. That said, we need something definitive on whether we should be drawing there (at the moment, the understanding is that we shouldn't) and how it should be handled instead (i.e. re-queue the event in another thread).But this is also related to https://github.com/processing/processing4/issues/370 to some degree, where it's unclear to what degree we're paying for badness like this lurking in the code, or something that's not entirely our fault.