pollEvent in Fullscreen mode clears the screen

[xqbt]

Hi, people
Consider this:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow mWindow(sf::VideoMode(1600, 900), "World", sf::Style::Fullscreen);

    sf::Texture texture;
    texture.loadFromFile("red.png");

    sf::Sprite sprite;
    sprite.setTextureRect(sf::IntRect(0, 0, 1600, 900));
    sprite.setTexture(texture, true);
    sprite.setPosition(0, 0);

    sf::Event event;
    //uncomment the following line to see red screen
    //mWindow.pollEvent(event);
    mWindow.draw(sprite);
    mWindow.display();

    while (mWindow.isOpen())
    {
        while (mWindow.pollEvent(event))
        {
            switch (event.type)
            {
                case sf::Event::Closed:
                    mWindow.close();
                    break;

                default:
                    break;
            }
        }
    }
   
    return 0;
}

If the code sample is run as is, white screen is shown.
If that one line is uncommented, a red screen appears.
When in windowed mode, both show red screen.
So, apparently, when in fullscreen mode, the very first pollEvent() clears whatever was draw()n. Which looks like a bug to me. Or maybe I am doing something wrong.

Config:
Windows 7 64 bit
SFML 2.3.2 32 bit
gcc 4.7.1
static linking

[Mario]

It's not really defined what's in the back buffer after initializing it. It could also be garbage from a previous program using that memory area. Clear the window before that line and you won't notice any difference.

If you still think there's some bug, look up the source for sf::Window::pollEvent(). There's no OpenGL call in there last time I checked (it really just querries the "event queue").

[xqbt]

It's not really defined what's in the back buffer after initializing it. It could also be garbage from a previous program using that memory area. Clear the window before that line and you won't notice any difference.

If you mean change this:

sf::Event event;
    //uncomment the following line to see red screen
    //mWindow.pollEvent(event);
    mWindow.draw(sprite);
    mWindow.display();

to

sf::Event event;
    //uncomment the following line to see red screen
    //mWindow.pollEvent(event);
    mWindow.clear();
    mWindow.draw(sprite);
    mWindow.display();

then, yeah, nothing changes, I still see a white screen.

I just want to clarify something. red.png is drawn just fine. If I put cin.get() right before this line

while (mWindow.isOpen())

in the code from the first message, I see a red screen. However, as soon as the program enters that loop and a call to pollEvent is made, the screen becomes white. Magic.

Ran the code from the first message (unchanged) on Linux (32 bit) and Mac (32bit and 64 bit) - the code works just fine. It doesn't on Windows.

If you still think there's some bug, look up the source for sf::Window::pollEvent(). There's no OpenGL call in there last time I checked (it really just querries the "event queue").

Looked it up, there is a whole chain of calls to popEvent() inside pollEvent(), which leads to the win32 implementation files and there is a lot of code there  I do not have a debugger now, but I will give it a couple of more shots.

[xqbt]

Some more expressive code here:

#include <windows.h>

#include <SFML/Graphics.hpp>

int main()
{
    int screenX = 1600;
    int screenY = 900;

    sf::RenderWindow mWindow(sf::VideoMode(screenX, screenY), "World", sf::Style::Fullscreen);

    sf::Image im;
    im.create(screenX, screenY, sf::Color::Red);

    sf::Texture texture;
    texture.loadFromImage(im);

    sf::Sprite sprite;
    sprite.setTextureRect(sf::IntRect(0, 0, screenX, screenY));
    sprite.setTexture(texture, true);
    sprite.setPosition(0, 0);

    mWindow.draw(sprite);
    mWindow.display();

    Sleep(1000);    //enjoy red screen for one second

    sf::Event event;
    mWindow.pollEvent(event);

    Sleep(1000);    //enjoy white screen for one second

    return 0;
}

[zsbzsb]

I think you are looking at this the wrong way, you shouldn't be caring what is drawn on the screen after 1 frame. If you follow the tutorial and write your game loop the proper way this is a non issue. Just do as the tutorial says: handle all of the events every frame and redraw your entire scene every frame (clear/draw/display).

As for what is actually causing the screen to turn white is probably due to you not polling/handling the internal events sent by the OS. Also whenever you call pollEvent(...) it needs to be in a loop as there can be multiple events generated.

[xqbt]

I think you are looking at this the wrong way, you shouldn't be caring what is drawn on the screen after 1 frame. If you follow the tutorial and write your game loop the proper way this is a non issue. Just do as the tutorial says: handle all of the events every frame and redraw your entire scene every frame (clear/draw/display).

As for what is actually causing the screen to turn white is probably due to you not polling/handling the internal events sent by the OS. Also whenever you call pollEvent(...) it needs to be in a loop as there can be multiple events generated.

I am getting you.
I just want to find the reason for the behavior and it looks like you have the answer: I did not read/clear the event stack. Now, this leads me to a couple of questions.
1) Why is not reading the event stack hangs the program? This question has been bugging me for quite a while. I suppose OS sets some flag. If this flag's value does not get reset within specified amount of time, a program is "not responding". But it is only a guess. (Any good article on this, may be?)
2) And why is it a reason for the problem outlined in this topic? It is strange. (if answer is different from 1st question answer)
3) What if there happens to be an event right after event polling loop is done, but before I call draw() and display()?
Thank you!

[Hapax]

1) Why is not reading the event stack hangs the program? This question has been bugging me for quite a while. I suppose OS sets some flag. If this flag's value does not get reset within specified amount of time, a program is "not responding". But it is only a guess. (Any good article on this, may be?)

The operating system is aware that the application isn't receiving the events it should be. This is how it determines that it is "not responding".

3) What if there happens to be an event right after event polling loop is done, but before I call draw() and display()?

It will be caught in the next event loop on the next frame/cycle/tick.

The "not responding" is most likely to be decided by an operating system dependant on how long events have been "waiting to be seen". It's possible that an operating could decide this on how many events are waiting too (queue is full).

[xqbt]

Hapax, thanks for the response.
Yeah, I read some stackoverflow - OS checks if queue gets polled regularly and checks the time.
But as this is clear now, I see absolutely no correlation between the screen being cleared because of the very first event poll. I just hope the situation is only for this exact first poll.

(click to show/hide)

It's a trap bug!

[Hapax]

I tested both of your codes (the second one in all four modes - debug/release, static/dynamic) and neither caused the effect you are describing for me.

Similar set-up to yours but using VC.

Do you have the problems with other resolutions too? Does a window the size of the screen still not have the effect?

Does the second code you posted ("enjoy white screen for one second") really change what is drawn on the screen when you create and event and then poll one?
Have you also tested clearing the screen with a colour before the drawing of the sprite to see if it's returning to that state or creating a new white state?

[xqbt]

I tested both of your codes (the second one in all four modes - debug/release, static/dynamic) and neither caused the effect you are describing for me.

Similar set-up to yours but using VC.

Just to make sure, I have Windows 7 Ultimate 64 bit.
I tested it on a similar setup on another computer, white screen appeared indeed.
Should I attach a binary?

Do you have the problems with other resolutions too?

Yes, I tried using 1024-768 (with actual screen size of 1600 by 900) and I am getting a white rectangle covering right bottom part of the screen (attached a screenshot). On the native size, it covers full screen.

Does a window the size of the screen still not have the effect?

Yes, no effect, just the red screen.

Does the second code you posted ("enjoy white screen for one second") really change what is drawn on the screen when you create and event and then poll one?

I do not understand the creating an event part of this question. If I make a keypress on the red screen (but before the white one), behavior is similar. But, yeah, the program really does change what's drawn on the screen. However, I have recently noticed some irregularity. Just sometimes, it would all draw fine and it would be a red screen all the way. But not most of the time.

Have you also tested clearing the screen with a colour before the drawing of the sprite to see if it's returning to that state or creating a new white state?

Yeah, put

mWindow.clear(sf::Color(0, 255, 255, 255));

right before drawing the sprite, behavior is still the same. But I think it is creating a new state indeed, because if I write

 mWindow.display();
Sleep(1000);

right before drawing the sprite, I see black -> red -> white.


Now, here is something else that I found out.
1) There is no such problem on OS X (10.8) or Linux (Bunsenlabs).
2) If I kill dwm.exe (desktop window manager)... more precisely, if I kill it twice, because it reincarnates, the program works just fine! Open -> red screen -> red screen. So, I guess, to observe the problem, you gotta have that running.