The fix for RT-38289 added a new runWithoutRenderLock static utility method in QuantumToolkit that takes a Supplier (lambda) and checks whether the renderlock is held; if it is, it releases it prior to calling the supplier and reacquires it afterwords. There is one more place where this method could be used.

Additionally, the following pattern appears in several places:

    lock
    try {
      code that runs with the lock held
    } finally {
        release lock
    }

I propose to add a new runWithRenderLock method to centralize the code that actually handles the lock.