Glut Animation with glutPostRedisplay

A main loop generally looks like this:

1. Process and handle events

   calling stuff like glutKeyboardFunc/glutMouseFunc.

2. Advance/update 3D state (physics/animation etc)

   typically in glutIdleFunc

3. Re-draw the scene if needed

   use glutDisplayFunc

glutPostRedisplay simply sets a flag, that tells glut to call the display callback on the next loop iteration. It doesn't actually call display ^{[1] [2]}.

If you have a game, which always updates every frame this might not be that useful. Maybe if you're alt-tabbed or dragging the window you don't need to be calling display. Or you might be frame limiting by dropping frames (although I'd suggest this).

void idle()
{
    ...
    animatedThing.value += deltaTime
    glutPostRedisplay(); //scene is always changing. always call display
}

Having a "dirty" flag becomes more useful when you don't need to re-render continuously. Maybe in something like a 3D modelling package where there isn't any animation and you only move the camera occasionally. Or a GUI where you only need to update when you hover and click on stuff.

void mousedown(int button, int state, int x, int y)
{
    if (clickedGUI(x, y))
        glutPostRedisplay();
}

void idle()
{
    ...
    if (myKeys[MOVE_VIEW_FORWARD])
    {
        view.z -= deltaTime;
        glutPostRedisplay();
    }
}

Anyway, to answer your question, no, there's probably not much difference. However...

1. I'd put the glutPostRedisplay in idle as above. Calling from within display works but gives up some control you might want later. It's essentially this:

   bool shouldDraw = true;
   while (1)
   {
       // check events, input etc
   
       // idle/update state
   
       if (shouldDraw)
       {
           shouldDraw = false;
           // draw
           shouldDraw = true;
       }
   }
   

2. I also wouldn't call display from idle from a design perspective as it removes some control from glut. For example if there's a case where glut needs to override the post-redisplay (not that I know of one) it won't be able to.