When does a Window delete its Opengl Context?

[golgoth]

Hello SFML Wizards,

Quick question, once you've created a GL Context in a Window, is there a time where this context is being delete/replace before the window is finally destroy? What about resizing the Window, is the Context kept?

THX

[Laurent]

The context is destroyed when the window is destroyed, and it is recreated when you call the create function. It is kept when you resize the window.

[golgoth]

Marvellous, merci Laurent for your input!

cheers,

[golgoth]

hum, would it be possible to create a Window without SFML dealing with the creation of the OpenGL Context and especially, loading the OpenGL libraries?

I'm asking because I don't need SFML doing any OpenGL related stuff as I would like to handle this on my own, like creating the Context and swapping buffers?

[Laurent]

But then why do you need SFML? And why do you want to handle contexts, the most annoying and platform-specific part of the code?

[golgoth]

Hi Laurent,

To answer your question, I use SFML mainly for the window creation and user inputs, threading and networking. I’m very happy with this but my problem is that SFML seems to takes over my graphic pipeline and I believe it might be causing very hard to find bugs that I’m trying to solve.

The reason behind my last question is that gDEBugger GL is telling me that 3 GL contexts are being created and it spits out memory leaks as some VBOs are being deleted on a context that did not created them. Why do I end up whit 3 GL Contexts is beyond my understanding right now and I’m trying to investigate why is this happening.

My guess is that SFML Window is creating its own proc addresses like this one:

        PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB = reinterpret_cast<PFNWGLCREATECONTEXTATTRIBSARBPROC>(wglGetProcAddress("wglCreateContextAttribsARB"));

…and it might not play well as I also have to do it before SFML does.

I also noticed in WindowImplWin32.cpp:

#include <SFML/Window/glext/wglext.h>
#include <SFML/Window/glext/glext.h>

I might be missing something, but this is not needed over there.

The bottom line is, I’m trying to strip down any OpenGL calls from SFML Window and make sure there is no mumbo jumbo name mangling issues of some sort.

regards,

[Laurent]

Why do I end up whit 3 GL Contexts is beyond my understanding right now and I’m trying to investigate why is this happening

The internal context handling in SFML is complicated. Hidden contexts are created. You shouldn't care about that, it's implementation details.

it spits out memory leaks as some VBOs are being deleted on a context that did not created them

All SFML contexts share their resources, so this shouldn't be a problem. Are you sure that the leask are caused by that? Usually, OpenGL memory leaks are caused by the graphics driver.

My guess is that SFML Window is creating its own proc addresses like this one:

        PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB = reinterpret_cast<PFNWGLCREATECONTEXTATTRIBSARBPROC>(wglGetProcAddress("wglCreateContextAttribsARB"));

…and it might not play well as I also have to do it before SFML does.

It really doesn't matter. I don't "create" anything, I just get the function pointer. Yours will be the same.

I might be missing something, but this is not needed over there.

I removed them, thanks.

There shouldn't be any problem between SFML and your own code. Before rewriting parts of it you should explain your problem here.

[golgoth]

Very well thank you for your support Laurent,

The internal context handling in SFML is complicated. Hidden contexts are created. You shouldn't care about that, it's implementation details.

Once the first Window is created, SFMF has created 3 different contexts. I understand resources are being shared between contexts but regarding to GL gDEBugger, it does not like it.

From:
http://www.opengl.org/sdk/docs/man/xhtml/glDeleteShader.xml

If a shader object to be deleted is attached to a program object, it will be flagged for deletion, but it will not be deleted until it is no longer attached to any program object, for any rendering context (i.e., it must be detached from wherever it was attached before it will be deleted)

I try to "set Active Window" before creation and before deletion but I’m having the same issue, any ideas?

[golgoth]

I finally found the leaks, quite a catch and you were right, sharing context seems to work fine.

[golgoth]

There is definitely something fishy with the contexts, It seems like there's a swap of context after the Window is created that might cause this issue. And it would be very handy to know what triggers the swap before we make GL calls.

gDEBugger returns:

Debug String: Detected error: The debugged process asked for an extension function pointer (glCreateProgram) from one render context, but called this function pointer in another render context (context #3)
Debug String: Detected error: The debugged process asked for an extension function pointer (glBindAttribLocation) from one render context, but called this function pointer in another render context (context #3)
Debug String: Detected error: The debugged process asked for an extension function pointer (glCreateShader) from one render context, but called this function pointer in another render context (context #3)
Debug String: Detected error: The debugged process asked for an extension function pointer (glShaderSource) from one render context, but called this function pointer in another render context (context #3)

SNIP...

OpenGL Render Context 3 Deleted
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteBuffers) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glUseProgram) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glDetachShader) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteShader) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteProgram) from one render context, but called this function pointer in another render context (context #2)

It would help if:
- The dummy contexts could be destroyed leaving only the main one... or
- We could track which context is the main one (the one that uses glswapbuffers) and/or...
- A way to set the main context active before making gl calls. (I'm guessing that is "set active window" but it does not seems to do any good here).

[Laurent]

Dummy contexts are used only if you no "regular" context is active in the current thread. If you have a window, and you didn't call setActive(false) on it, the window's context will always be used.

Why don't you post a complete and minimal code that reproduces the problem, so that we can work on real stuff rather than on your own conclusions?

[golgoth]

Yes of course,

int main()
{
        sf::Window window(sf::VideoMode(800, 600), "SFML window", sf::Style::Default);

        glewInit();

        UINT l_id = glCreateProgram();

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
                window.display();
        }

        glDeleteProgram(l_id);

        return EXIT_SUCCESS;
}

Run this with:
http://www.gremedy.com/download.php

and you get:
Debug String: Detected error: The debugged process asked for an extension function pointer (glCreateProgram) from one render context, but called this function pointer in another render context (context #3)
SNIP...
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteProgram) from one render context, but called this function pointer in another render context (context #2)

[Laurent]

Strange... I'd have to investigate this further, but I don't have much time.