My charter for today was to figure out why the discrete-event simulation framework was not running in Opera. I had experimented with this on Thursday and Saturday of last week and traced the problem to a call in the Three.js framework file, which presumably failed because some resource was not available (the framework threw an error when a it tried to refer to elements of a variable that had a value of null). The problem existed when the internet connection was slow, which indicated that the issue arose from the fact that all resources were not yet loaded.
When I tried to run the simulation code yesterday and today, with a livelier internet connection, it ran just fine in Opera without me having changed anything.
Nonetheless I spent some time looking into ways to delay trying to draw anything until I was sure all of the resources were loaded. There are ways to do this (see here, here, and here) but there’s a problem doing it in the code as it’s currently written. The initialization code is distributed all through the file, so that would have to be gathered up and placed into a single function — without breaking anything. The global variables would have to be declared outside of the that function and then assigned values within it so they retain the required visibility. The controls allowing the user to run the simulation would have to remain disabled until the initialization is completed, whereupon they would have to be activated. The problem might not be so bad if I only have to worry about items having to do with initializing the canvas and 2D and 3D context elements.
I spent just a few minutes looking into ways to insert a pause into the beginning of the script that would periodically check to see that the load had completed before running further. The problem is that JavaScript is single-threaded (so far, but see this exception) so there is no sleep() or wait() function that will make execution pause. The existing timing functions, setInterval() and setTimeout, only run code when the JavaScript code breaks to wait for user input or some other event (like the animation loop we’ve been using). Those functions may fork off an event that will run in the future but the rest of the code keeps right on running so that’s not the answer.
Tomorrow I’ll see what it’ll take to reorganize the code as I’ve described, or I’ll simply move on. Either way I’ll be sure to revisit the issue if I can reproduce it.