It depends on complexity of the objects. I’d redisplay the whole window.
I do not know what the subwindow is. Usually one OpenGL context is faster then using and switching more contexts.
Updating only part of the window makes troubles in SLI.

I’m not sure about creating a new post, because my issue is kind of related to this topic.
My C main process spawns a GLUT window, but this C process retrieves textures that are updated 30 times a second, that I would like to display on the shapes inside the GLUT window. Obvioulsy the glutMainLoop() stops my C process, so, instead of reading data from the serial port, how is it possible to read from another c function that should be executed “in parallel” with all the GLUT process ?

Ok, so if I am right, this means that the glut main loop should spawn the c children processes, and not the contrary (which is the way it is currently working).
I guess it can be possible, but that way I should reorganize the whole project architecture.
So have I understood well what you meant?

GLUT is quite limited for this, so if you have other uses for more fine grained multitasking within your GL program, I suggest looking for GLFW, cross-platform toolkit to create fullscreen/windowed rendering, event driven or not, with threads, fancy inputs, etc. Very simple to use, yet powerful. However not built-in menus like glut.

I’ve been reading the GLFW user guide, it seems indeed powerful and easy to use. Before I try to go any further, since yo seems aware, in my case (triggering the GLFW loop from my C process), can I still have my C process running in parallel (which updates the textures notably)?

Okay, to make sure that I got it:
I include my whole main process, called once, in an OpenGL context. I modify this c main process so that it checks/outputs some way the textures data, say 30 times a second (this ckecking/returning operation would be the readSerial() you mentioned above).
And then follows the opengl rendering loop, which reads from the readSerial() (that actually reads, and writes the data to the shared object “newtexture”)thread.
Am I still on the right thinking way?

As for the pixel buffer object, it is very possible that I use this extension, since I “constantly” need to read/write from the c classes/subclasses to my opengl interface.

Just following my post to tell that I got it working! Temporarily, what I did is :
from my main process, create a thread that contains my glut main loop, so both can run at the same time. But I am going to switch to glfw… Thanks for your help !