Using SFML built-in rendering methods in another context

[natinusala]

Hello,

I would like to know if it would be possible to use only the drawing methods of the SFML components ? The point is to use them in another context that an SFML window ? It's actually a raw glx window with some options like a depth and stencil buffer and some already existent drawing methods in 2D and 3D.

The point would be to draw SFML things on the top of what is already in the window (which is not my code). I've tried to create a RenderTexture but it obviously breaks everything (black screen and GL error, oops), because I guess it tempers with gl states and nothing can be drawn.

Could you help me ?
Thanks !

[zsbzsb]

I would like to know if it would be possible to use only the drawing methods of the SFML components ? The point is to use them in another context that an SFML window ? It's actually a raw glx window with some options like a depth and stencil buffer and some already existent drawing methods in 2D and 3D.

This is impossible, you can use SFML textures in raw gl code yourself through (and thus render textures, see below). But just drawing SFML's drawable isn't really going to work well.

I've tried to create a RenderTexture but it obviously breaks everything (black screen and GL error, oops), because I guess it tempers with gl states and nothing can be drawn.

Look at the tutorials, you must call the push/pop functions.

[natinusala]

But it breakes when I create the rendertexture, I can't even use the pop and push methods =/ (or I'll push a black screen, yay)

[binary1248]

You can't use SFML to draw stuff (using the graphics module) to your window without letting SFML take ownership of the window in question. If you don't mind letting SFML take over the window, there is an example that shows you how to do this here.

That was the simple solution. The more "involved" solution involving the RenderTexture should only be chosen if you can't or don't want to let SFML take control of the window.

Like zsbzsb said, you need to watch your OpenGL states, and also which context is currently active. Any time you draw something to an SFML RenderTarget, it will activate that target's context so you don't need to worry about that. What the drawing doesn't do, is reactivate your own (window's) GLX context. If you try to do any OpenGL stuff after drawing to the RenderTexture, the operations will still affect the RenderTexture and not your window. pushGLStates() and popGLStates() are only useful if you are working with OpenGL within the same context in which you use SFML's draw methods. If you have completely independent contexts as in your case, then pushing/popping doesn't do anything useful.

Now... what you also must not forget is that if you do just try to grab and bind the texture to draw in your own context, it won't work. You will end up binding the texture which only exists in SFML's context and not yours. From your context's perspective nothing is bound, since the bind didn't happen in it. This will end up being really slow, since the only way of transferring the texture data from SFML's context to your context would be via a CPU round trip.

The problem lies in the fact that SFML doesn't let you share its contexts with your application, even if you let it take ownership of the window. In the case you do let SFML take over the window, it would still create its own context for drawing to it.

So, long story short, let SFML construct a RenderWindow from your window, and it will work great. Don't do it, and it can work, albeit really slowly.

[natinusala]

Okay I see. I could use SFML's window system but I need to be able to switch contexts (like  glXMakeContextCurrent) because in the already existing app there is one made for 2D rendering and one made for 2D and 3D rendering (it's for compatibility purpose, for example if you don't have graphics acceleration).

And would there be a way to only use the drawing methods of the SFML components ? I can handle gl states myself (the app already does), I only would like to draw shapes, sprites and fonts in a more convenient way.

[binary1248]

Okay I see. I could use SFML's window system but I need to be able to switch contexts (like  glXMakeContextCurrent) because in the already existing app there is one made for 2D rendering and one made for 2D and 3D rendering (it's for compatibility purpose, for example if you don't have graphics acceleration).

SFML doesn't care if you already have a context you want it to use, it will always create its own context anyway. You can't tell SFML what context to use and you have no control over when SFML will activate/deactivate its context. I already posted above that it will activate its context when drawing but it will not deactivate it when it's done. You will have to manually switch back to one of your own contexts using glXMakeContextCurrent if you need to after SFML is done drawing.

And would there be a way to only use the drawing methods of the SFML components ? I can handle gl states myself (the app already does), I only would like to draw shapes, sprites and fonts in a more convenient way.

I have a feeling you don't really understand what "handle gl states" really means. OpenGL is full of state, and there is absolutely no way you can draw anything without having to change any of its state. As such, there is no way for SFML to let you handle the GL states yourself, it is part of the rendering process. I still don't know what you really mean by "only use the drawing methods of the SFML components". Sure, you can only use the draw() methods of the RenderWindow, but it will go ahead and change a lot of GL states within its own context when it draws stuff. If you are thinking of simply using SFML as a "macro" for a sequence of GL operations, then maybe you should just write them yourself. If you are already willing to handle the GL states yourself, there isn't much else that SFML can do for you. OpenGL is 90% about state management.

[natinusala]

Okay, I understand. I thought that the draw() method was only a sequence of, well actually drawing stuffs, but if it alters GL states then it's not going to work.

I will create my own macros then, thanks for the help.