This can cause a crash.
On startup the Application::processOctreeStats method on the network thread will call into entities entity->isReadyToComputeShape() (without a tree lock) and trigger Model::simulate. Model is NOT thread safe. This was leading to a single model to be initialized on two threads simultaneously.
This might be somewhat rare, I only caught it because I was running a debug build.
* Prevent clusterMatrices from being invalidated and re-computed in each updateItem lambda.
We do this by not setting _model->_needsUpdateClusterMatrices = true;
* Prevent redundant work if Model::enqueueLocationChange is called multiple times per frame.
We do this by introducing a preRenderLambdas map in the Application class.
Instead of adding work directly to the scene PendingChanges queue Model::enqueueLocationChange
adds a lambda to the Application preRenderLambdas map. The Application ensures that only one lambda will
be invoked for each model per frame.
This extraordinary event can occur if a MessageBox is popped up by the opengl driver.
* removed AvatarData::avatarLock
* removed AvatarUpdate
This code was left over from an earlier avatar threading experiment.
Removed AvatarData avatarLock and AvatarUpdate class
If the application "Interface Crashed" dialog is shown at startup, it can cause Application to receive events before it has been fully constructed.
In this case the QMainWindow _window pointer is uninitialized, causing Menu::getInstance() to de-reference an invalid pointer.
The fix for this is three fold.
1. Construct the QMainWindow before calling setupEssentials (which in turn spawns the "Interface Crashed" dialog).
2. Change Menu::getInstance() from a static_cast to a dynamic_cast. This will cause it to return a nullptr if [QMainWindow::menuBar()](http://doc.qt.io/qt-4.8/qmainwindow.html#menuBar) returns an instance of QMenuBar and not a ui::Menu instance.
3. In Application::event return false if Menu::getInstance() returns a nullptr. This should prevent any code that relies on having a valid ui::Menu instance from running.
Instead, we just store two controller::Poses in MyAvatar.
Existing behavior and scripting APIs have been preserved.
The hand controller debug drawing is slightly different, but still works.
