Single-Threaded Graphic Applications

../../../../_images/single_threaded_transaction_model.png

The rendering workflow of a typical single threaded application

In a ‘classic’ application design, with a user interface and several windows, all events are polled into an event loop. Paint orders are emitted by the UI event system (Qt, WxWidgets, Cocoa, MFC…) and the refresh of application windows occur. All this mechanics is hosted by a single application thread. It’s generally pointless to have different windows rendered by different threads, as this does not change the performance in the end (there’s still one display and one graphic card accessible) and this makes the application complex for no gain.

So here we are: for most HOOPS Luminate applications, one single thread should host all HOOPS Luminate based operations:

  • Transaction management

  • Data edition

  • Rendering

The rendering step can process all windows in a loop, or only refresh windows that have been modified. The real important point is to let HOOPS Luminate operate in sequence. We have one single writer thread in a HOOPS Luminate application. This thread is the application’s main thread and the same thread as the rendering thread when windows need to be refreshed.