I've got an idea to put an end to the rendering 'pause'. I'll keep two copies of the data needed to draw each widget, one for the latest data (datacurrent) and one for the previous data (dataold). The second copy will only be used if a lock could not be obtained. eg:
#
<render thread>

try to lock window
if successful then draw window using 'datacurrent'
if failed then draw window using 'dataold'
move to next element

when say, the position of a window is updated, 'datacurrent' is locked, the change is written, 'datacurrent is unlocked' then 'dataold' is locked, the change is written, 'dataold' is unlocked.

'dataold' is locked by the render thread before the render thread tries to lock 'datanew'. So this way, if 'datacurrent' is locked then the render thread can draw 'dataold' without fear of the thread updating 'datacurrent' locking 'dataold' before the render thread does (because if we lock 'old' then find 'current' is locked, we know that the render thread gets to use 'dataold' first.

so I believe that this solves the problem by guaranteeing that while there's minor overhead locking/unlocking mutexes, the render thread will never be left in a position where it has to wait on another thread as it will always have access to lock free data.

(there's all kinds of techniques for handling such threadding issues, I'll do some research, perhaps there's a better solution)

All of this will be totally transparent to the end user. They don't even know about the threads, all they need to know is that callbacks can come from multiple threads, so they must lock any shared data on their end. the TJUILockable class is a good choice for this. (user side locking will not effect the window manager as when callbacks are called, the element that called them is unlocked as it does so. element properties (button captions, size, colour etc) are accessed using thread safe properties)