tkh’s blog

Qt Designer and OpenGL

I designed a GUI for an OpenGL application using Qt Designer, and encountered some glitches. First, you have to subclass QGLWidget class, say MyGLWidget, and put OpenGL stuff there. Then open Qt Designer and place a some container widget in a window as a place folder for MyGLWidget. You should use QWidget because QGLWidget inherits directly from it. However, QWidget is not available in Qt Designer. So you are forced to use QFrame as a place folder and promote it to a custom widget class and specify MyGLWidget. Now save the GUI layout to a .ui file, and hand edit it and delete the lines which declares some of QFrame properties. You also need to rename QFrame in the custom widget section to QWidget. Now you should be able to compile your code.

Actually I found a ML thread about this and a Trolltech engineer said that they would add QWidget in Qt Designer. Apparently it’s not fixed yet. I really want the fix!

VTK and Qt license

I had to check if VTK license is compatible with GPL. The archive of a debian ML shows that it is compatible. Now I’m sure I can use Qt as a GUI for VTK based programs.

OpenGL on Windows Vista

Microsoft has planned to drop full OpenGL support *again* on Windows Vista with their compositing desktop engine like Quartz 3D in Mac OS X. When the desktop composition is enabled, OpenGL commands are translated to Direct X equivalent ones at run time, dropping OpenGL based applications performance to ~50%. If you disable the desktop composition, OpenGL applications run in full speed using the OpenGL ICD, but who wants to disable the desktop composition? This decision is so Microsoft, and it is the second time they do this kind of stuff. Obviously it led to the huge uproar in the OpenGL community.

Yesterday, I noticed the blog entry that OpenGL will be fully supported even with the desktop composition enabled. It seems that finally Microsoft listened to users, but we should be wary until they really release it and the performance is as good as Direct X.

3Dlabs

3Dlabs announced that it will de-emphesize the professional graphics buisiness and focus on the portable handheld device market. I knew that their products are not very impressive, but they have driven the evolution of the OpenGL API. They pushed the OpenGL ARB very hard to make GLSL part of OpenGL 2.0. I didn’t even know that 3Dlabs is a subsidiary of Creative Technology. It’s a sad news.

Setting raster position in OpenGL

When writing an OpenGL application, there are many occasions you want to draw texts or pixels in a window. To do that, you need to set the current raster position in the window coordinates, and the following is a typical code to achive it:

void drawPixelsOnScreen(const int x, const int y)
{
    glMatrixMode(GL_PROJECTION);
    glPushMatrix();
    glLoadIdentity();
    gluOrtho2D(0, windowWidth, 0, windowHeight);
    glMatrixMode(GL_MODELVIEW);
    glPushMatrix();
    glLoadIdentity();
    glRasterPos2i(x, y);
    glDrawPixels(...);
    glPopMatrix();
    glMatrixMode(GL_PROJECTION);
    glPopMatrix();
    glMatrixMode(GL_MODELVIEW);
}

There are so many state changes involved in this code just to draw texts/pixels. However, I just found today that I can set the current raster position in the window coordinates with glWindowPos*() which is introduced in OpenGL 1.4. Then the above code will become:

void drawPixelsOnScreen(const int x, const int y)
{
    glWindowPos2i(x, y);
    glDrawPixels(...);
}

It’s much more simple. I should have known this earlier.