Hardware Event Loop vs. Software Event Loop

In this page, we will not cover advanced multi-threaded event loop models that may be required by performance critical applications. We’ll cover the basics of setting up an event loop with > for a basic hardware application and then for a basic software based application. The picture below illustrates the two models:

Building an event loop with HOOPS Luminate is very simple in the case of a hardware based application: Changes in HOOPS Luminate require a transaction (as detailed here: Transaction Management) to be opened - before changes can be recorded - and then closed before it can be rendered on screen. Therefore a simple way of proceeding with HOOPS Luminate in the case of a hardware application is to open a transaction after a rendering has occurred. This way, a transaction is always open, and closed just before the rendering.

In the case of a software application, we may need to continue an existing frame, because it was not finished in a single rendering call. To do so, we can’t define any new transaction, or the engine will restart a new frame to render a new closed transaction. Therefore, if we just use the left schema picture for the management of our transactions within a software application, we’ll never terminate a frame: each loop will start the rendering of a new transaction, even if no changes have occurred.

We need to define a more elaborated event polling in the case of a software application: we’ll define a new transaction only if we have changes to record in HOOPS Luminate. That way, if the user don’t change anything, we’ll continue (e.g. we’ll repeatedly call RED::IWindow::FrameTracing) the rendering of the frame, until it’s flagged complete by the method’s return value. If the user do changes in HOOPS Luminate (for example he moves the camera) using a new transaction, then, the RED::IWindow::FrameTracing call will start over a new frame rather than continuing the existing one that has become obsolete.