Separate Window.Display from event polling

[l0calh05t]

It's not actually a memory leak since it's the intended behavior.

Certainly not intended by the person who only wants to use asynchronous input :wink:

Splitting event handling from window display is a great suggestion, I've thought of it a few times, but your model isn't really adequate.

Polling the system through system calls (even if highly optimized) every time GetEvent is called is all but efficient.
I understand backward compatibility issues, but I submitted another suggestion a few weeks ago which aimed at the same system of SFML, so :
There could be two functions, PollEvents() et WaitEvents(), which would poll the event loop of the system. The two would add events to SFML events queue, as it currently is. WaitEvents would act as PollEvents do, unless the first poll is empty, if so, WaitEvents would enter in passive wait from the system.

The way it is done right now, is that GetEvent only polls system events when the queue is empty, so on average you will be polling system events twice every event loop (at the beginning and at the end). It is highly unlikely that this will become a bottleneck for your app.

EDIT: Which of your threads are you talking about? I only found http://sfml.sourceforge.net/forum-fr/viewtopic.php?t=419 but I assume you mean a different one?

[Aszarsha]

The way it is done right now, is that GetEvent only polls system events when the queue is empty, so on average you will be polling system events twice every event loop (at the beginning and at the end). It is highly unlikely that this will become a bottleneck for your app.

Ok. I haven't read the code and supposed poll was done every call. :oops:
Sorry.

I'll never have my passive waiting ! :cry:

EDIT : Yep, it's a different one Look at this one : Attente passive.

[l0calh05t]

Ok. I haven't read the code and supposed poll was done every call. :oops:
Sorry.

I'll never have my passive waiting ! :cry:

EDIT : Yep, it's a different one Look at this one : Attente passive.

Ah, I see. Although I don't need passive waiting myself I see why you'd like to have it.

Under Win32 it's easy enough to wait for events, just use GetMessage instead of PeekMessage, similar commands should exist for X11 and OSX as well

[Aszarsha]

Ah, I see. Although I don't need passive waiting myself I see why you'd like to have it.

Youpi ! I'm not alone !

Under Win32 it's easy enough to wait for events, just use GetMessage instead of PeekMessage, similar commands should exist for X11 and OSX as well

That's why i've asked for it under SFML.

Laurent, pliiiz !

[l0calh05t]

btw, if you mainly want to save cpu time when no events are received you could do the following:

instead of:

Code: [Select]


while(running)
{
  while(GetEvent())
  {
    // process event
  }
}


which is obviously inefficient if you don't do anything except for processing events do the following:

Code: [Select]


while(running)
{
  if(GetEvent())
  {
     // process event
  }
  else
  {
    Sleep(0.01f); // sleep for 10ms
  }
}


This should lower cpu usage from 100% to ~2% (as long as there is no excessive processing associated with any specific event)

But if you really, really need passive event polling there are 3 options:
1) Add it yourself (should be easy enough)
2) Use SDL, despite it's somewhat large size, C-Style interface and LGPL license
3) Use GLFW, despite it's lack of support for multiple windows, C-Style interface and being only a framework for creating a valid GL context. (No audio, high-level graphics objects etc.)

[Aszarsha]

Hehe, that's what I actually do.

I don't really have time to add things to SFML, I don't have time for my own projects... :x
SDL ? No, thanks.
And as I use 2d drawing facilities of SFML, GLFW is not really usefull (as you said).

Thanks for your suggestions l0calh05t.

[l0calh05t]

Hehe, that's what I actually do.

I don't really have time to add things to SFML, I don't have time for my own projects... :x
SDL ? No, thanks.
And as I use 2d drawing facilities of SFML, GLFW is not really usefull (as you said).

Thought as much. (Who in the right mind would use SDL if they can use SFML...)

Thanks for your suggestions l0calh05t.

No problem.

[T.T.H.]

EDIT:
And why would event handling and graphics both have to access gui data?

E.x. "is a mouse move or mouse click event inside a certain GUI element?" in the event thread and "draw a certain GUI element" in the graphics thread - both would be accessing some rectangle (x, y, width, height) which would then have to be made threads safe with a mutex which would then lower performance due to thread synchronization.

Please note that this only is some naive thinking from me - I've never really used a GUI system.

[l0calh05t]

E.x. "is a mouse move or mouse click event inside a certain GUI element?" in the event thread and "draw a certain GUI element" in the graphics thread - both would be accessing some rectangle (x, y, width, height) which would then have to be made threads safe with a mutex which would then lower performance due to thread synchronization.

Please note that this only is some naive thinking from me - I've never really used a GUI system.

Some things might be shared (hard to avoid, but should be minimized as much as possible), but in this case for example, both accesses are read accesses, so they can be done in parallel. And for write accesses (which should never be caused by the renderer thread) we'd either have to lock, or find a lockless solution. Or use a pipeline approach. Or double buffer the GUI data. There are many solutions to these kind of problems, the hard part is figuring out which one's the best.

[Joe Somebody]

Hi Laurent.  For I pulled down the latest from svn this weekend.   I noticed in the OpenGL Demo (I'm running win32, in Vista x64), that with the latest, whenever there are events coming in, such as the mouse moving, that the cube stops spinning.

This does not happen with the Release 1.2, the cube spins continuously on this version.

It seems like the changes made to the event handling are likely causing this behavior.  Does the sample program have to be updated in order to properly handle the new separate Render/Event system?

I've just finished the modifications.

The event handling is now automatically independant from Display() (you don't have to do anything).

The window's context can be unbound with SetActive(false) (SetActive(true) replaces SetCurrent).

You can get the modifications with SVN.

[Laurent]

No, the OpenGL sample (and the code in general) shouldn't be affected by this modification. I've never noticed what you describe, but I'll do more tests to make sure.

Thanks for your feedback.

[Laurent]

I've tested the OpenGL sample again (WinXP 32 bits), there's no problem with events. The code hasn't changed much, I can't see any reason why this issue appears now on your system. I don't even know if it has something to do with Vista or 64 bits.

Did you clean / rebuild all SFML libs and samples, just to be sure ?

[Joe Somebody]

I've tested the OpenGL sample again (WinXP 32 bits), there's no problem with events. The code hasn't changed much, I can't see any reason why this issue appears now on your system. I don't even know if it has something to do with Vista or 64 bits.

Did you clean / rebuild all SFML libs and samples, just to be sure ?

The code was pulled down into a fresh directory, from SVN, then built, so it had to be clean, right?

I copied the executable, etc on to a Windows XP system, but it won't run.  I get an error "This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem."

The code was built using Visual Studio Express Edition 9.0 for C++.   It definitely is set to have a win32 target, so it has me scratching my head.  I will let you know when I figure it out.