0
\$\begingroup\$

When only the main window is created, the fps is able to reach above 1000.However creating 1 more window, resulted in the fps dropping significantly down to about 100. The draw callback draws a blank black screen and writes the fps onscreen.

Q1) What is the reason behind the sharp drop in fps?

Q2) Any possible ways to improve on this fps?

int main(void){
        int mainwindow,otherwindow1;
        glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);

        glutInitWindowSize(640,480);// set the initial window  size 
        glutInitWindowPosition(0,300);//set the initial window position 

        mainwindow = glutCreateWindow("main window");
        glutDisplayFunc(Draw);

        glutReshapeFunc(ChangeWindowSize);

        otherwindow1 = glutCreateWindow("Other window");
        glutDisplayFunc(Draw);
        glutReshapeFunc(ChangeWindowSize);

        setVsync(0);

        glutMainLoop();
}

void Draw(){
    glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);

    getFPS();

    glutPostRedisplay();
    glutSwapBuffers();
}
\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Switching rendering contexts can have a huge overhead with some 3D drivers.

Another reason could be that the non-foreground window needs 2D clipping applied when displaying the image. Even if it is not covered the driver has to check for window overlap which it can safely skip for the top window when displaying the 3D frame buffer.

Yet another possibility is that the first 3D frame buffer is internally displayed using a hardware overlay with zero copy, while the 2nd one has to be copied (and clipped) to the main display buffer.

There isn't much you can do about that.

If the issue is some context/render target switch you'll have to replace GLUT with your own code and get down and dirty with window manager graphic calls (GDI, Cocoa, X11, etc) to implement a work-around that very well may not improve things at all.

Possible work around: Draw to an off-screen surface using the same context and do a 2D native API pixel copy (bitblt) call to display the buffer on the other window (or both). It may end up being much worse due to synchronization issues and image format mismatches.

Its a lot of effort and unlikely to result in an improvement.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .