Window drag keep rendering (solution) [SFML 2.0]

[coolhome]

Hello there! After doing research on why the SFML window is paused when you dragged I think I found a decent solution. It works on windows, maybe linux. I don't think it will on mac tho. Anyways I just wanted to see what you guys thought of this code I wrote up.

If you were to use this, I'd recommended creating a thread safe event manager to pass the events on into the other thread.

Code: [Select]


#include <iostream>
#include <math.h>
#include <SFML/Graphics.hpp>


void GameThread(sf::RenderWindow *window)
{
window->SetFramerateLimit(60);
sf::Image sfmlLogo;
sfmlLogo.LoadFromFile("HaikarainenSFMLLogo.png");
sfmlLogo.SetSmooth(true);

sf::Sprite sprLogo;
sprLogo.SetImage(sfmlLogo);
sprLogo.SetOrigin(floor(sfmlLogo.GetWidth() / 2.f), floor(sfmlLogo.GetHeight() / 2.f));
sprLogo.SetPosition(400,300);

while (window->IsOpened())
{
sprLogo.Rotate(0.5f);

window->Clear();
window->Draw(sprLogo);
window->Display();
}
}

int main()
{
sf::RenderWindow window;
sf::Thread gameThread(&GameThread, &window);
sf::Event event;

window.Create(sf::VideoMode(800,600,32), "Test");
window.SetActive(false);

gameThread.Launch();

while(window.WaitEvent(event))
{
if (event.Type == sf::Event::Closed)
{
window.Close();
}
}

gameThread.Wait();

return EXIT_SUCCESS;
}


Party on,
Preston Alvarado

p.s. I didn't know where to post this to be honest. This forum category seemed good enough.

[OniLinkPlus]

Seems like a reasonable solution. I don't know much about the internals, but I'm guessing it works because as long as the window is resizing, you won't run out of resize events, and this separates rendering from events, correct?

[coolhome]

Seems like a reasonable solution. I don't know much about the internals, but I'm guessing it works because as long as the window is resizing, you won't run out of resize events, and this separates rendering from events, correct?

Kind of... Windows pauses the main thread when the window is being dragged or resized. Therefore to keep rendering you need to do it in another thread. Now if you where to use that thing above I'd recommend taking all the events in the main thread and push them into a vector. Put it back into the rendering thread. Just make sure its thread-safe! I'll post an example if needed.

Can someone try this on linux?

[Disch]

An alternative approach to this would be to make a new Window class.  One that has the same interface as sf::RenderWindow, but runs all the messages through an internal (threadsafe) messaging system (I'd use a list or deque over a vector, though.  Deque is probably the way to go).

That way the end user doesn't need to worry about spawning a new thread and keeping it threadsafe, and people who want to add this functionality don't need to rewrite their code -- they just use this new class instead of sf::RenderWindow, but all function calls and whatnot are the same.

[MorleyDev]

There are numerous lock-free first-in first-out queue implementations floating around the internet based on the usage of Compare-And-Swap that would be well suited for an event queue ^^

[Disch]

I'd be very interested in knowing how you could make it safe without a lock.  I have been thinking about it, and the more I think about it, the more I'm convinced a lock would be necessary.  But I've been wrong before.

Can you show an example?

[coolhome]

I'd be very interested in knowing how you could make it safe without a lock.  I have been thinking about it, and the more I think about it, the more I'm convinced a lock would be necessary.  But I've been wrong before.

Can you show an example?

I've been researching these 'lock-free' queues. Very interesting. Haven't tested one but I learned sometimes lock-free doesn't mean there are no locks. It could mean non-blocking? Pretty interesting stuff indeed. I hate feeling like a noob!

[Disch]

I can see a lock-free system working where:

1)  There are never fewer than 2 nodes in the queue
2)  only 1 thread is adding things to the queue
3)  only 1 thread is taking things from the queue

As soon as you step beyond any of those criteria, I'm lost as to how you can retain thread safety without a blocking lock.

[MorleyDev]

Yeah, the "lock-free" stuff is just a type of non-blocking algorithm. "A non-blocking algorithm is lock-free if there is guaranteed system-wide progress; wait-free if there is also guaranteed per-thread progress."

They are a fascinating field of study, and most of it goes right over my head at the moment xD

Valve often publish presentations they give at various conferences and have one such presentation on making games for multi-core where they briefly go into detail about non-blocking algorithms:
http://www.valvesoftware.com/publications/2007/GDC2007_SourceMulticore.pdf