Changing the 5000ms timeout?

Processing Electronics (Arduino, etc.)
1

I have some code where we’ve changed the initalization sequence, and we’re right up against the 5000ms timeout where, so I read, JOGL is waiting for an initial draw to the canvas.

I’d really rather not put processing code in some of my constructors. Those objects are used in a variety of places, and creating an abstract “pet the watchdog” function with registration from the different frameworks is… ugly.

I’ve found out where my time is going. 2.5 seconds is going to initializing the LX framework. 2.0 seconds is going to loading in a massive JSON file which is the LED playlist. The MIDI init subsystem is hitting about 0.5 seconds, so I’m right on the edge…

Yes, I can fix all the. Sort-of.

I’d rather just change that value to 10 seconds. I’m OK waiting that long, I’m OK having a watchdog, I just don’t want the value to be 500ms.

Any help out there?

2 Likes
2

Oh man, been having a ver similar problem with my sketches in eclipse. This seemed to work

public void settings(){
  delay(5000);
  size(your width, your height, P3D);  
}

Though this is processing code, it did seem to put the drawing thread to sleep for a bit but still allowed my other setup type of functions to execute.

3

I actually found a better fix. On a github repo where processing is used, there are statements about the “frameRate()” call being dangerous during setup. I changed my code to not do that ( the processing3 default seems great, there are comments saying it’s a good idea in processing2 ), and suddenly my errors went away… and, it seems like the JOGL watchdog doesn’t get created, because my init sequence is still > 5000ms.

I’d be interested to hear if you have a “frameRate()” call, and if removing this fixes your errors. Did for me at least.

1 Like
4

Yup, I sure was using frameRate in my setup. Good call! I commented out the delay function and the frameRate function and it started right up at 60 fps.

5

It’s rare one gets to fix a bug simply by commenting out a line… but happy!

6

I was using frameRate(1000); to try and get audio data via sound library as fast as possible so it now makes sense that frameRate was causing the start up issues

7

For others who find this thread, if you find you need to set “frameRate()”, you can set it at the last moment of startup. I believe what is happening is when you mandate a frameRate, the watchdog starts running to make sure you are getting it, and doing that during your initialization stage causes the risk.

8

If the watchdog starts during setup (before drawing frame 1) then this sounds like it might be a bug worth reporting:

I’m not certain there is an easy workaround (other than calling frameRate last – although Ant could move that automatically), but still, might be worth reporting.