Renderwindow from an existing process

[DrEvil]

I posted this on the SDL mailing list, but in an effort to find an alternative to SDL I found SFML, and as much as I like it, it too suffers from the same problem I'm getting with SDL. I'm hoping this time there will be a workaround for the problem.

Hi all, new subscriber here.

This request might sound a bit odd but please bear with me.

Suppose you have a pre-existing program, in this case an existing game. Enemy Territory to be precise, or slightly more generically the Quake3 and Quake4 engine.

I've set up SFML to allow me to open an additional window from the same process to provide a canvas for debug tools and an attached gui for debugging and such. When I spawn the window, using sf::RenderWindow,  from within the game process the game stops rendering, presumably because it's an OpenGL powered game already, and maybe there can only be 1 OpenGL window to a process by default?

The question is, is there a way around this so one can spawn multiple OpenGL windows from a single process(and still have both render)? In my case I just want to prevent my SFML RenderWindow from breaking the game rendering. The game keeps running, I can break in the code and such, it's just the rendering appears to stop.

Any help greatly appreciated.

[DrEvil]

After playing with it a bit it looks like I can give control back to the main game with a bit of wglMakeCurrent hackery, and saving and restoring the contexts before creating the window, since that wants to override the context, Now the problem is that the SFML window doesn't render, because my context code has overridden it, and the if (Window::SetCurrent()) isn't doing anything because it thinks it already has the context set.

It looks like what I need is to modify SFML to respect an existing context.

If I comment out the

ourCurrent = this;

in

WindowImpl::SetCurrent()

so it doesn't track its own context it seems to work correctly, and both the game and the SFML window render properly it seems. Is wglMakeCurrent expensive to call so often? Is there an alternative to achieve the same effect or is this the only option to address this?

Any recommendations on how this can be cleanly addressed? Is this something that should be handled internal to SFML? Or is it too special case and I should just hack around it?

Thanks
J

[Laurent]

Is wglMakeCurrent expensive to call so often?

Yes it is. I added this tracking code after running a benchmark ; it improved the performances a lot. It didn't expect such a difference.

Or is it too special case and I should just hack around it?

I think it is very specific, and it won't need to be added to SFML. However you can hack the code to achieve this. I think the easiest way is just to remove the tracking code, as it's just an optimization.

[DrEvil]

SFML only uses opengl correct? It doesn't have an alternative 2d more like SDL does it? Reason I ask is that I'm rendering mostly a GUI(using http://guichan.sourceforge.net/), and when I tried OpenGL as a renderer in SDL, it actually performed slower than when I used the SDL 2d renderer(direct draw I think). I'm especially concerned about the need to do these expensive context switches every frame and that I might be taking a step backwards performance wise. Is there an alternative to the context switching you know of?