Skip to main content.


This page serves as a reference to a couple of key concepts to be aware of when using this library.

The concept of 'current window'

The OGLWFW maintains a 'current window' at all times, this is either 0 for no window when a valid window doesnt exist or a window handle. The reason for this is partly because I'm lazy and didnt want to have to keep telling the library which window I was operating on when I only had one window in existance. So for every day, single window, useage this concept can save you having to both save the window handle or telling the framework which window you want commands (either window related or OpenGL related) sent to.

However, as soon as you switch into a multi-window system then this tracking of current becomes very important as you need to make sure that you are sending the right commands to the right window at the right time. Now, with a single thread multi-window setup this is as easy as telling the system which window is current and then issuing commands (see the Multi-window test as an example). As soon as you throw multi-threading into the mix things become a bit more intresting, see the following section for details.

OGLWFW and Multi-threading.

As indicated on the front page and in the API reference the OGLWFW can be used to initalise an OpenGL context in a thread which is different to the window creation (and thus message pump) thread. While this leads to some flexibility it is not without its considerations.

The library its self doesnt know anything about threading, as such it doesnt perform any locking against being reentrant. If this proves a significant issue then a locking system might well be added later, however for the time being the overhead was not deemed worth while. This lack of locking means that you can possibly be calling two functions at the same time, each on a different window, this is where the interaction with the 'current window' concept gets intresting.

Consider a basic example of two window, one in each thread. Now, thread 1 makes its window current and plans a call to swapbuffers, however between the call to make it current and the call to swap the buffers thread 2 is woken up, it too sets it window as current however this thread manages to execute its swapbuffers and then goes back to sleep, at which point thread 1 wakes up and calls swapbuffers and window 2's buffers are swapped again because as far as the manager is concernered that is the current window.

Instead, what should have happened is that both threads should have called swapbuffers with their window handle passed, this will ensure that the correct window is swapped and all is good in the world once more.

As a general rule unless you ensure that two threads cant act on the window manager at the same time dont use 'SetCurrent' or any functions which relie on the window manager to track the current window for you.

Keep this in mind and you shouldnt run into any problems.

OGLWFW's basic user event handling system.

After much delaying a basic user event handling system has been added to the OGLWFW as of version Beta 1.1.0.

The Custom Handler Example and Custom Handler Multiple Windows examples show the basic way to use the system, one thing to keep in mind is that when using multiple windows you shouldnt place the WindowManager::Dispatch() call in the While section of the loop, instead you should find some other exit condition as per Custom Handler Multiple Windows.

If you return 'true' from your handler it will prevent the default handler from being called, returning false will cause the default handler to be called.

When dealing with mutple windows you must prevent the destory message from firing otherwise the system will crash. The release notes will be updated when this issue has been corrected.

The following messages are the only ones which can currentl be registered;

While quitmsg is present in the winmsgs_enum it isnt currently propigated back to the end user, thus registering this message wont have any effect.

Copyright © 2004, Rob Jones
Home | Site Map | Contact Us | Disclaimer | Privacy Statement