MakeCurrentContext cost

Hi guys it’s me again,
I’m setting up the level editor and i planned to insert like a material editor window (like Unreal Engine and CryEngine do), i thought that this could be done by making the context of the window where i’m going to draw current.
My question is simple but i can’t find a concrete answer, how much expensive is make a context current, should i do it every draw call, should i do it every frame update for every window i want to draw on, should i do it only when the focus is gained by another window that owns an OpenGL Context?
Thanks advanced.

[QUOTE=Ruggero Visitnin;1263473]how much expensive is make a context current, should i do it every draw call, should i do it every frame update for every window i want to draw on, should i do it only when the focus is gained by another window that owns an OpenGL Context?
Thanks advanced.[/QUOTE]

It is pretty expensive, but how expensive depends on the vendor GL driver and hardware you’re using. You should avoid calling this more than you absolutely have to. Best case: call it once on in your thread and never call it again. If you have to render to multiple drawables/windows in the same thread, then MakeCurrent on one of them, do all the drawing for that window, and repeat for the other windows. You could have separate threads, one per window, one context per thread, so you don’t need to MakeCurrent in your threads but once. However, without any kind of scheduling coordination, this can lead to more context swapping than the single thread approach.

You might give this a browse:

thanks, one context per thread is what i want to achieve, i needed a confirmation.

Also, I should also qualify that for the separate context+drawable per thread approach, if the windows are on separate GPUs, then with some vendor’s drivers there is no “context swap” overhead for this case. Generally what you want to minimize is context swaps per GPU per unit time.

thanks again, I’ll keep in mind.
It’ s a bit off topic but i don’t want to fill the forum with my questions.
I’m working on the game loop and i’m a little confused.

I read on various books that the path is something like:

UpdateInput();
UpdateObjectsBasedOnInput();
DoRendering();
SwapBuffers();

I’m ignoring physics and animations for now, so my doubt is: what i should do in “UpdateInput();” and what in “UpdateObjectsBasedOnInput();”?
I mean, what i’m thinking is check which keys are down in “UpdateInput();” and then in “UpdateObjectsBasedOnInput();” check for example if the “w” key is down move the camera forward. Am I wrong?

PS: i’m sorry for my poor english.

Something like that, except that UpdateInput() would also handle the translation from specific input devices (mouse, keyboard, joystick) to “logical” controls (i.e. mouse+keyboard vs joystick input, user-defined key-bindings, mouse/joystick sensitivity, invert Y axis, etc), and also handle input recording and playback (which is useful for providing repeatable test cases for debugging and profiling).

UpdateObjectsBasedOnInput() would only consider an idealised controller; it wouldn’t need to know the low-level details or interface directly with the platform’s input API(s).

[QUOTE=GClements;1263493]Something like that, except that UpdateInput() would also handle the translation from specific input devices (mouse, keyboard, joystick) to “logical” controls (i.e. mouse+keyboard vs joystick input, user-defined key-bindings, mouse/joystick sensitivity, invert Y axis, etc), and also handle input recording and playback (which is useful for providing repeatable test cases for debugging and profiling).

UpdateObjectsBasedOnInput() would only consider an idealised controller; it wouldn’t need to know the low-level details or interface directly with the platform’s input API(s).[/QUOTE]

I think I understood, for example “w” and “up arrow” keys match an ideal forwardKey, in updateObjectBasedOnInput() I check if forwardKey is pressed, and if so the object moves forward, right?

last thing i swear, if i open another window that owns a different context, for example a material preview window, i imagine this window has to use a different camera from the camera of the main renderer, so how can i organize this situation in a proper way? could the camera belong to the window that uses it?

i’m going crazy to organize this stuff.

[QUOTE=Ruggero Visitnin;1263496]last thing i swear, if i open another window that owns a different context, for example a material preview window, i imagine this window has to use a different camera from the camera of the main renderer, so how can i organize this situation in a proper way? could the camera belong to the window that uses it?

i’m going crazy to organize this stuff.[/QUOTE]

Don’t worry – it sounds like you’re doing fine.

Windows can have multiple views. A view has a camera. A camera has a viewing transform and a projection associated with it.

Context’s relationship with windows is whatever you want. You can have one per window, or you can “share” it among multiple windows (by rebinding the context). So you might best model this with windows can have a context. And context’s have a thread ID they’re associated with (behind-the-scenes, you need to make sure a context is only active on one thread at once).

thanks for the answer, now i know that i’m doing right.
Sorry it’s me again i know i’m boring but i can’t find the information i need, It is correct to use a scene for every gui window?
For example the Material preview window, it’s correct say that what i’m rendering in this window is a scene different from the one of the main window? how do you organize things like this in your engine?

my loop is like this



if(peekMessage())
   doWindowsStuff();
else
   currentWindow()->onIdle();

* onIdle()
{
    updateInput();

    // i have a scene for every window but is the correct way of doing?
    updateScene();
    renderScene();
    swapBuffers();
}


the current window is the window that has the focus and that is performing the rendering if has to.

Ps
I really appreciate all the time you are dedicating to me.

You’re off the OpenGL map at this point into application-specific land. It depends on what a scene is, and what is necessary to update and render it. Think about the data and the processing involved? Can you share it? Does it even make sense to share it? You’re on your own there!

(Thread split to: VAO and VBO permutations)