I was unable to write anything here for some time.

BUT, finally I was able to find a way to make multithread image loading using OpenGL with Windows extensions for multiple context creation.

It was quite a struggle to find anything useful in the web, only some minor things at few forums and mailing groups. But using that with some thinking and reading between lines I finally found the solution I’d like to share, as it can save (in my opinion) much time of searching and experimenting for others.

So what do you need if you’d like to create multithread texture loading in OpenGL ?

It’s tricky. First of all you have to know, that you can’t do it straight forward, as you need OpenGL context for each thread you’d like to use OpenGL procedures.

To create new rendering context (as it’s called), you need device context first. You can get it from your HWND.

For me it was not straight forward, as main window is created using SDL. But fortunately it’s quite easy to get it from there too.

#include <wingdi.h>// for wgl* stuff
#include<SDL_syswm.h>//for SDL stuff
//...
SDL_SysWMinfo wmInfo;
SDL_VERSION(&wmInfo.version);
if(SDL_GetWMInfo(&wmInfo) < 0) //returns (-1) on error
{
std::cout << "error in SDL_GetWMInfo");
}
HWND hWnd = wmInfo.window;

So, now we have HWND. To get device context, you only need to call
HDC hDC = GetDC(hWnd);.
OK, that was easy.
Now we need more OpenGL contexts.
To create those, we need some Windows extension for OpenGL.

To be honest, to create contexts we need only one – wglCreateContext.
This procedure takes device context as parameter and returns new rendering context (or NULL).
No matter what people says in forums – you CAN have more than one rendering context for only ONE device context. More than that – in my opinion it’s very natural.  And it works just fine. Let’s create two of those contexts.

HGLRC rendContext1 = wglCreateContext(hDC);
HGLRC rendContext2 = wglCreateContext(hDC);

Cool. We have two OpenGL rendering contexts. What we would like to do now is:

use one context for images loading, textures creation etc. and let second context in main thread do rendering stuff etc. This way if you have multiple images to load, you can simply load them in background thread and in rendering thread start showing loaded one. The good thing is – you can load textures in background and it won’t freeze your interface, as it’s done in other thread.

But it’s not as easy as it looks like, because you have to fix sharing of textures between contexts. Normally, if you create a texture at one context, it’s not available in second one and vice versa.

Here is another procedure from Windows extension pool:

wglShareLists(rendContext2, rendContext1);

I didn’t try different order of arguments, probably it’s not meaningless (but MSDN is useless in most important things and sadly wrong in too many places :( ). The safest solution is to do this BEFORE you load anything in any context. In documentation you can find, that you can’t have nothing loaded in second of passed contexts (in our case it would be rendContext1). To be sure, call this before you start messing with OpenGL.
Now, you have to set default context for each of your threads, so it can work properly with OpenGL calls. You don’t need to call it every time, only once in a thread.

renderingThread()
{
//...
wglMakeCurrent(hDC, rendContext1);
//...
}

loadingThread()
{
//...
wglMakeCurrent(hDC, rendContext2);
//...
}


If you have this written in above manner, you can simply ‘fork’ loading thread from main thread using e.g. boost::thread class. Again, according to some OpenGL forums, it’s important to create ‘loading thread’ from rendering thread, but I didn’t check that either. It’s important, that wglShareLists will work only in the space of one process, not between processes, so only way for parallel execution is using threads.

Calling wglMakeCurrent only makes one of rendering contexts default to the thread in which is called, so it doesn’t matter if the call is done exactly in the same time in both threads. Nevertheless, it’s important to have different contexts for each thread.

After making above steps, you should be able call whole loading stuff in loadingThread thread (as e.g. loading data from disk [ilLoadImage], then creating texture name using glGenTextures(), set parameters glTexParameteri() and finally load data to OpenGL using gluBuild2DMipmaps or glTexImage2D), and in renderingThread thread you will have access to textures loaded this way.
If you’d like to also load data in renderingThread (e.g. for blocking image loading), you have to remember that some image loading libraries (like DevIL,  indirectly mentioned earlier) doesn’t have support for multithreading, so you need mutex to provide atomic calls to it’s methods.

I didn’t try to render from both contexts, but according to some resources found in the web, it’s possible but pointless, as in that case OpenGL would have to switch between contexts (calling wglShareLists shares bunch of stuff, but not the rendering context itself), which is very memory intensive and creates unnecessary overhead.

The most important thing is waiting for as at the end of the road ;-)

Don’t forget to release created contexts. In each of threads you should call default rendering context to none using wglMakeCurrent(NULL, NULL).
Deinitialization step in main thread should look similar to code below

wglMakeCurrent(NULL, NULL);
wglDeleteContext(rendContext2);
wglDeleteContext(rendContext1);


Don’t forget to call this NULLed-wglMakeCurrent in loadingThread on exit from it.

Hopefully I covered most of important things in multithread and multicontext image/texture handling using OpenGL and WGL.

Please, do not hesitate to ask a question regarding those problems.
If you find a bug or something, that looks weird to you, let me know ASAP – maybe I’m missing something (or you are ;-) )

Till next time…

I just lost 2h because of this macro.

I used it to disable C4996 warnings from boost/thread/win32/condition_variable.hpp (65) and similar (as I prefer code without any warnings).

According to MSDN, using _SCL_SECURE_NO_WARNINGS should be fine, but didn’t help much.

So I found at some forum, that it’s possible to disable warnings using #define _SECURE_SCL 0 and there will be no problem.

There were no problems until I tried to compile release of my project.

I get runtime errors when I tried to insert new value to std::vector. When I used std::vector::reserve method, it was fine, but I got some random runtime errors in other places, when I was using iterators. At the end I decided to stay with boost’s warnings, without defining _SECURE_SCL macro.

I know, that you can gain some performance, when you disable checked iterators, but I’ll do more testing when I finish my MSc ;-)

Until next time :)

some links:

_SECURE_SCL, _SCL_SECURE_NO_WARNINGS, _SECURE_SCL_THROWS, disscusion on std::vector

Enjoy reading ;-)

wordcount

windowing=GaussWindow("2048","0","0.2")

In the example above (it’s working one, for my MSc app),it looks quite nasty and it feels tough to write that every time you’d like to run your soft.
But when you try to write application, which could be run from e.g. a batch file, which i generated by another, testing app – then this kind of solution seems useful.

Another news are great too. Following line

windowing=GaussWindow("2048","0","0.2")

calls proper constructor from class GaussWindow with proper, parsed values.
Definition of that constructor is:

GaussWindow(int inWindowWidth, int inStartIndex = 0, float inSigma = 0.4);

so you can see there are some int‘s and float, but everything is handled by xParam.
Now, imagine that class GaussWindow inherits from Windowing, like e.g. HammingWindow. If you’d like to use Hamming window instead of Gauss window, you only need to specify it through command-line like:

windowing=HammingWindow("1024")

and that’s it. You don’t need to recompile anything – it works out of the box.

Part of your program, that enables parsing arguments with xParam could look like that:

Windowing * windowing = NULL;
ParamSet ps;
ps << "This program computes pitches."
<< iParamPtrVar(windowing, "windowing	! windowing function");
ps.input(argc, argv);
// some computations (...)
ps.output();
delete windowing;

And that’s it.
Don’t forget to delete pointers created by xParam. :)

Update:
Unforutnately, when I use xParam, I get whole bunch of memory leaks reports from Paul Nettle’s Memory Manager. I don’t know, if the problem is inside xParam or I do something wrong – if someone read my post and saw some weird error – please write to me. For now I have to test memory leakages without xParam, with setting up parameters in my code manually and recompile every time, which is pain…
secundo:
The problem could be even in Memory Manager (which IMHO is unlikely), because xParam uses quite much global/static fields and initialize things before entering to main.
Any solution proposals are very welcome :)

The subject of my thesis is: Acoustic signal processing algorithms for automatic music transcription.

I’ll try to publish some news about progress of work and results. Mostly I’m working on algorithms computing fundamental frequency of the signal. In my thesis I’m going to present comparison of few algorithms and provide some system for choosing applicable algorithm for specific case.

Because everything I’m writing in C++, it would be almost impossible (and stupid ;-) ) to build this kind of solution without external libraries (or it would just take ages). At the moment I’m using:

1. GSL for mathematical computations (especially for calculation of Short-Time Fourier Transform using Fast Fourier Transform)
2. QT and Qwt as libraries for plot management and printing to .svg
3. pngwriter as library for png files creation (currently is off due to export to .svg from Qwt)
4. boost – for everything ;-) boost::filesystem, boost::thread, boost::unit_test_framework etc…
5. xParam for parameters parsing
6. Fluid Studios Memory Manager (also known as Paul Nettle’s memory manager) as memory leak detector [download from www.paulnettle.com ]

As compiler and IDE I’m using Visual Studio 2005 with SP1.

In following posts I’ll try to describe problems I encounter and solutions, which can save some time.