Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sf::RenderTexture bug when destroyed in fullscreen #434

Closed
mariohb opened this issue Jul 23, 2013 · 4 comments · Fixed by #885
Closed

sf::RenderTexture bug when destroyed in fullscreen #434

mariohb opened this issue Jul 23, 2013 · 4 comments · Fixed by #885
Assignees
Milestone

Comments

@mariohb
Copy link

mariohb commented Jul 23, 2013

In windowed mode all run fine, smooth, without any flickering. But in fullscreen, everytime I destroy a rendertexture, or a entity that stores a rendertexture, because I don't gonna use it anymore, the flicker appears.

For 1-2 frames, the screen goes black and then return to normal. Trying to reproduce this problem, I've discovered what causes this comportament but not why.

In the following code, I find that when a RenderTexture is destroyed (out of scope/delete), the problem appears.

My specs are Win 7 64 bits, Nvidia 560Ti (driver version 320.49 WHQL), i5 2500k.

As Laurent says: "This is caused by a call to DestroyWindow in the destructor of WglContext"

For more info this is a link to the forum post.
http://en.sfml-dev.org/forums/index.php?topic=12324.0

#include <iostream>
#include <SFML\Graphics.hpp>
#include <SFML\Window.hpp>


int main() 
{
    sf::RenderWindow App(sf::VideoMode(640, 480, 32), "SFML Test", sf::Style::Fullscreen);
    App.setFramerateLimit(60);

    sf::RectangleShape rect(sf::Vector2f(300,300));
    rect.setFillColor(sf::Color::White);
    rect.setPosition(170, 100);

    sf::RenderTexture *tex_ptr = NULL;

    while (App.isOpen())
    {
        sf::Event Event;

        while (App.pollEvent(Event))
        {
            // Close Window
            if (Event.type == sf::Event::Closed)
                return 1;

            if (Event.type == sf::Event::KeyPressed)
            {
                // Exit
                if (Event.key.code == sf::Keyboard::Escape)
                    return 1;   

                // Each time F1 is pressed, screen goes black in some sort flickering
                if (Event.key.code == sf::Keyboard::F1)
                {   
                    sf::RenderTexture tex;
                    tex.create(200,200);
                }

                // Each time F2 is pressed, screen goes black in some sort flickering
                if (Event.key.code == sf::Keyboard::F2)
                {   
                    tex_ptr = new sf::RenderTexture();
                    tex_ptr->create(200,200);
                    delete tex_ptr; // if this line is commented, does not flick
                }
            }
        }

        App.clear();
        App.draw(rect);
        App.display();
    }

    return 0;
}
@ghost ghost assigned LaurentGomila Jul 23, 2013
@LaurentGomila LaurentGomila removed their assignment May 19, 2014
@eXpl0it3r
Copy link
Member

There have been changes to SFML's context management and other parts as well as new drivers for Nvidia cards in the past year, as such it be interesting to hear if this is still an issue and if someone else besides @mazellan can confirm this.

@mariohb
Copy link
Author

mariohb commented Jul 10, 2014

I tried the same code above with the lastest repository of SFML. Same OS, CPU, GPU and Nvidia drivers 337.88 WHQL.

No change at all. This problem still happening.

@ricanteja
Copy link
Contributor

I can confirm this bug!

Using the above code I can reproduce the same issues.

Windows 7 64bit
AMD 6300
EVGA Nvidia 650 Ti Boost Driver version 337.88 (latest)

@binary1248
Copy link
Member

This is because SFML uses dummy windows to create OpenGL contexts in Windows, as can be seen here. This probably won't be fixed until context management is redone in SFML 3. A more or less simple workaround for this is to keep a pool of sf::RenderTextures around and just reuse them when necessary. Don't create and destroy them when unnecessary, they are already a heavy resource to begin with.

@eXpl0it3r eXpl0it3r removed this from the 2.x milestone Nov 13, 2014
@mariohb mariohb removed this from the 2.x milestone Nov 13, 2014
@binary1248 binary1248 self-assigned this Jun 12, 2015
@binary1248 binary1248 added this to the 2.4 milestone Jun 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants