sfml equivalent of GetMessage()

[kfriddile]

I would really like to see support for a blocking call to get events, similar to the Win32 API's GetMessage() call.  It would be nice to be able to run sfml's message pump in a separate thread using this blocking call.  This would allow the app to idle nicely when there's nothing to do, without any of this hacky Sleep(0) silliness.  I've implemented a Win32-only windowing abstraction that does this, but I'd rather use something like sfml to easily make it cross-platform.  Does polling make anyone else feel dirty inside?

[Laurent]

It has already been discussed. There are two main reasons why I won't implement it :
- It's almost useless in this context (SFML graphics is meant for real time)
- It's implementable with 3 lines of code (the hacky Sleep(0))

But the discussion is still opened, and feel free to try to convince me if you think it's worth it

By the way, I'm curious to know how you achieved to call GetMessage in another thread than the one which created the window ? MSDN says this is technically impossible
More generally, multi-threading with windows is another potential issue which makes a good 3rd reason not to implement what you request.

[kfriddile]

- It's almost useless in this context (SFML graphics is meant for real time)

Real-time in no way requires polling (wasting CPU by continually asking if something has happened instead of just being told when something happened).  For example, the windowing abstraction I wrote that I mentioned earlier asynchronously calls subscribed methods when an event has occured.  I've had no trouble writing a real-time opengl app using this solution.  Those particular apps may use a lot of CPU, but I know all of that CPU is being consumed by something that actually needs it (the update/render loop)...not by continually asking if there are window events.  It also drastically reduces the coupling of the window object with the rest of the app.  I can just create a 'Window' on the stack and if an event occurs that some part of my code has subscribed for, it gets called.  My app doesn't have to concern itself with constantly checking up on the window to see if anything has happened only to be disappointed when nothing has.  That functionality is the window's responsibility.

- It's implementable with 3 lines of code (the hacky Sleep(0))

That isn't implementing the same thing at all.  It's still fundamentally different because it's still polling.  It's been discussed all over the internet why polling and the Sleep(0) "fix" is bad, so I'll just provide one of the better links:

http://blogs.msdn.com/oldnewthing/archive/2005/10/04/476847.aspx

Also, Microsoft themselves has this to say about using PeekMessage() (polling):

"PeekMessage shouldn't be needed in modern, well-written applications."

http://msdn.microsoft.com/en-us/library/ms644928(VS.85).aspx
(toward the bottom...it is under community content, but that statement has been there for years, so I'm interpreting that as an endorsement from Microsoft)

By the way, I'm curious to know how you achieved to call GetMessage in another thread than the one which created the window ? MSDN says this is technically impossible

You are correct in that it isn't possible, but I never said I was calling it in a thread other than the one that created the window  My window abstraction owns and spawns a thread that creates the window and then starts the blocking message pump.

[Laurent]

You're right and I completely agree with you, actually

Except for one thing : calling a function that does nothing if no event happened, doesn't waste CPU at all. But I agree it's much less elegant than a signal / slot system. The problem is that this kind of stuff is not yet part of the C++ standard, and libraries providing it are too heavy to be used by SFML (it really requires a lot of code in order to be implemented). Moreover, it's confusing for beginners and doesn't mix well with C, which is required to write bindings. One more thing : calling an event handler from a separate thread is too much dangerous to be the default behaviour (requiring to be thread safe for a basic application is too much to ask, especially for beginners who might not even know what threads are).

The conclusion to this discussion (in my opinion) is that SFML won't change the way it handles events, for the reasons I said previously, but it's up to users to implement a more elegant event handling on top of that. Polling is far from elegant, but it works and can be used to implement a clean signal / slot system.

[kfriddile]

calling a function that does nothing if no event happened, doesn't waste CPU at all.

This is simply false.  Calling a non-blocking function to check for events ( such as PeekMessage() ) in a loop uses 100% of the CPU core that thread is running on.  I'm sure laptop users running on battery would consider that "wasteful".  Even with a Sleep(0) to relinquish the rest of your time slice, you're still making at least one function call which, by definition, uses CPU.

The problem is that this kind of stuff is not yet part of the C++ standard

What does that have to do with anything?

libraries providing it are too heavy to be used by SFML

I would love to see some profiling or benchmark data to support this claim.

Moreover, it's confusing for beginners

I'm sure C++ was confusing for them at first too.

doesn't mix well with C, which is required to write bindings.

If you're talking about the name-mangling differences between C and C++, I think that is solved by simply using "extern C" with your C++ functions.  If you're talking about something else I'm not aware of, then you may have a point.  I will admit that bindings for other languages aren't important to my particular use case.

calling an event handler from a separate thread is too much dangerous to be the default behaviour (requiring to be thread safe for a basic application is too much to ask, especially for beginners who might not even know what threads are).

I couldn't disagree more.  EVERYONE needs to be conscious of thread safety issues, because single-threaded applications won't be an option for much longer, especially for resource-intensive real-time applications like your library seems to be designed for.  Individual cores aren't getting faster at the rate that they used to (in some cases they are even getting slower).  Instead, additional cores are being added.  If your application's performance can't scale with the addition of more cores via multithreading, then your application won't be viable in the very near future.  Furthermore, if you, as a library developer, don't realize this and design your library to be safely usable in such an environment, then nobody will be able to write viable applications with your library.

Anyways, it's also come to my attention that sfml contains intentional memory leaks, so it can't be used in any production-quality code anyways.  It seems odd to me that you would point to the C++ standard above, while at the same time relying on the operating system to clean up your memory leaks...behavior which is obviously not garaunteed by the standard.

[Laurent]

1/ I'm making a difference between using CPU and wasting CPU. Of course a function call uses CPU, but for sure doesn't waste it.

2/ I'm talking about dependencies, not about performances. Libraries providing clean signal / slot features are just too big; the other solution is to wait for their integration into the C++ standard but it's not for now.

3/ SFML must be 100% bindable to C. Signals / slots are not.

4/ I think SFML is appreciated because I care about beginners. Trust me. And believe me, thread safety is not beginner-friendly at all.

5/ Regarding the memory leaks... it's a long story

[Ceylo]

4/ I think SFML is appreciated because I care about beginners. Trust me. And believe me, thread safety is not beginner-friendly at all.

Is SFML supposed to be used for beginners only ? (I admit this would somewhat disapoint me)
I think the point is : do you prefer to focus on the library popularity or the library quality ?

5/ Regarding the memory leaks... it's a long story

Why don't you just explain to him there is only ONE leak that happens only ONCE in the whole program execution ?
Or are there other leaks under Windows ?

Anyways, it's also come to my attention that sfml contains intentional memory leaks, so it can't be used in any production-quality code anyways.

As the Mac OS X developer for SFML, I can tell I noticed no leak the OS dependant part (at least, that's what the "leaks" tool told me, and the memory amount used by SFML apps is not increasing over time).

Now about this...

I would really like to see support for a blocking call to get events, similar to the Win32 API's GetMessage() call.

I've not thought of this for a long time, but whenever it would be easy for me to support blocking calls for events, that would also block display updates because I manually have to tell the OpenGL context when to swap the back and front buffers (which is done from the polling loop). Is this what you wish ?

[Laurent]

Is SFML supposed to be used for beginners only ? (I admit this would somewhat disapoint me)
I think the point is : do you prefer to focus on the library popularity or the library quality ?

SFML is for beginners (most users are), as well as experts. I don't see why a library which is beginner-friendly couldn't be also expert-friendly. My goal is to make quality available for everybody. Too many libraries are either scary (i.e. for experts only) or too limited (i.e. for beginners only).

Why don't you just explain to him there is only ONE leak that happens only ONCE in the whole program execution ?

Because I had to leave when I wrote my last post
Ok, more details : the leak is indeed a small and controlled one, and its purpose is to enable a very important feature of SFML. Some people would even say it's not a leak; a leak is something which is not controlled and makes the memory consumption grow up and grow up. Actually, some implementations of STL or popular libraries can't free all the memory they use at program exit, and this is perfectly alright.

[Ceylo]

SFML is for beginners (most users are), as well as experts. I don't see why a library which is beginner-friendly couldn't be also expert-friendly. My goal is to make quality available for everybody. Too many libraries are either scary (i.e. for experts only) or too limited (i.e. for beginners only).

Then what about the threads ?

[Laurent]

Then what about the threads ?

What's the problem with threads ? As I said, you can add whatever you want on top of SFML.

[Ceylo]

I meant thread safeness (safety ?).

But... I don't know much about this topic. Doesn't the main thread need to be thread-safe in order to allow the use of threads "on top of SFML" ?

And by the way, any Mac OS X application already uses multi-threading for the event handling. Do I need to take care of this ?

[Laurent]

The most critical parts of SFML are thread safe (mainly OpenGL contexts stuff), but I'm sure there are still many others that would need to be improved. The point is that only a few functions of SFML are usually used in separate threads, so I have almost no multi-thread oriented feedbacks.

[Ceylo]

This sounds somewhat approximative to me...

[Laurent]

That's basically what I meant
But it's impossible for me to test every single combination of possible multi-threaded situations. So I need feedbacks, but I get only very few of them.

[Ceylo]

That's basically what I meant
But it's impossible for me to test every single combination of possible multi-threaded situations. So I need feedbacks, but I get only very few of them.

Then why not protect everything you can ?