Issues with QGLWidget as QMainWindow central widget

[wysota]

Intel HD OpenGL drivers for Windows are totally broken. You should focus on getting your NVidia drivers to work properly. I'm sure the code of the program itself is correct, it works fine on my Linux+NVidia combo.

01:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1)

[norobro]

If I may interject . . .

@Zyl - I see similar artifacts using your code above on my Debian box. Try calling glClear() in your
paintGL() function:

void paintGL() {
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	. . .

void paintGL() {
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	. . .

To copy to clipboard, switch view to plain text mode 

[Zyl]

Intel HD OpenGL drivers for Windows are totally broken. You should focus on getting your NVidia drivers to work properly. I'm sure the code of the program itself is correct, it works fine on my Linux+NVidia combo.

01:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1)

I'd be thankful if you have any instructions/hints regarding this. I remember trying to install the NVidia driver before any Intel HD driver resulting in some message like "You must install Intel HD first [...]" or something along those lines. I also remember uninstalling Intel HD leaving me with a black screen once, requiring me to reinstall Windows - so I'm paranoid about ever touching it again. I still need to test if there are painting problems when doing updateGL() outside the content of a resize event. If yes, I won't be using OGL for anything, because there are too many people with systems like mine. If no, crappy resizing performance is an endurable pain.

If I may interject . . .

@Zyl - I see similar artifacts using your code above on my Debian box. Try calling glClear() in your
paintGL() function:

void paintGL() {
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	. . .

void paintGL() {
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	. . .

To copy to clipboard, switch view to plain text mode 

Good idea. glClear does the job. Actually... If I don't do glClear, everything still gets cleared with black. At least when I move my squares like so:

glBegin(GL_QUADS);
                glVertex2i(10 + (20 * i), 10 + (20 * j) + 3 * (countPaint % 150));
                glVertex2i(20 + (20 * i), 10 + (20 * j) + 3 * (countPaint % 150));
                glVertex2i(20 + (20 * i), 20 + (20 * j) + 3 * (countPaint % 150));
                glVertex2i(10 + (20 * i), 20 + (20 * j) + 3 * (countPaint % 150));
                glEnd();

glBegin(GL_QUADS);
                glVertex2i(10 + (20 * i), 10 + (20 * j) + 3 * (countPaint % 150));
                glVertex2i(20 + (20 * i), 10 + (20 * j) + 3 * (countPaint % 150));
                glVertex2i(20 + (20 * i), 20 + (20 * j) + 3 * (countPaint % 150));
                glVertex2i(10 + (20 * i), 20 + (20 * j) + 3 * (countPaint % 150));
                glEnd();

To copy to clipboard, switch view to plain text mode 

; the previously drawn ones won't stay visible in the next frame. I'm no OGL expert, but isn't this supposed to not happen unless there actually is a glClear()-call?


Another thing I noticed: I seem to be able to avoid unneccesary drawing by doing this:

void initializeGL() {
        // gl-calls here
 
        resized = true;
    }
 
    void resizeGL(int w, int h) {
        // gl-calls here
 
        resized = true;
    }
 
    void paintGL() {
        if (!resized)
            return;
 
        // gl-calls to draw here...
 
        resized = false;
    }
 
private:
    bool resized;

void initializeGL() {
        // gl-calls here

        resized = true;
    }

    void resizeGL(int w, int h) {
        // gl-calls here

        resized = true;
    }

    void paintGL() {
        if (!resized)
            return;

        // gl-calls to draw here...

        resized = false;
    }

private:
    bool resized;

To copy to clipboard, switch view to plain text mode 

; this seemingly effectively increases performance and responsiveness.
EDIT: Doing this running the program using NVidia GPU however causes a black window. The squares would only flash up while resizing it.

[Zyl]

My research regarding NVidia Optimus resulted in finding out one's either lucky and has an option in the BIOS to disable it (I don't) or else there is no way to get rid of it, as the graphics card needs to pipe frames through the Intel HD component (or something along those lines - it got too technical for me).

I tried doing something simple as throwing 5 instances of MyQGLWidget into a QHBoxLayout, as well as into a QSplitter, both resulting in a horrendous lagfest, where every widget gets repainted one frame later than the other, regardless of whether I use GPU/Intel HD. This would mean ridiculous performance once I made a proper application from these. I then tried using traditional QWidgets using QPainter and paintEvent, which works pretty much flawlessly with either graphics component. If I just turn these into QGLWidgets again, I am back to horrible performance.

Bottom line: QWidget probably has enough performance for the simple thing I plan to do, anyway. I just cannot use GLWidgets if they're going to be unreliable, and I don't even think an NVidia Optimus-infested system such as mine already represents the worst possible target machine.

Thanks for your efforts.