Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Wait for events in a real blocking way  (Read 3696 times)

0 Members and 1 Guest are viewing this topic.

dacap

  • Newbie
  • *
  • Posts: 3
    • View Profile
Wait for events in a real blocking way
« on: February 07, 2015, 07:35:08 pm »
Hi! Is there any method to wait for events in the real blocking way as the OS expect? (e.g. using GetMessage() on Win32 API).

I've found this:
https://github.com/SFML/SFML/blob/f24ca9a84012531cf886f72354c1f88341dd7ac7/src/SFML/Window/WindowImpl.cpp#L125

It is a busy wait with a sleep to avoid high CPU usage. From the comment in that line it's just because the joystick input events needs a polling mechanism, but my question is, could we just use a real blocking method if we don't need joystick input? (e.g. I'm developing an application and I don't need joystick input)

Thanks!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Wait for events in a real blocking way
« Reply #1 on: February 07, 2015, 08:30:45 pm »
No you can't, as you've seen from the source code. Why is this so important for you?
Laurent Gomila - SFML developer

dacap

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Wait for events in a real blocking way
« Reply #2 on: February 07, 2015, 09:07:37 pm »
Why is this so important for you?

I'm changing the back-end of my application (http://www.aseprite.org/) to support multiple windows. At this moment I'm using a customized version of Allegro 4 library, and busy-wait is something I would like to eradicate (I've a similar fix to avoid 100% CPU usage). I was considering SFML as a replacement, but I'd like to avoid using more CPU that needed (e.g. to improve battery life). (For video games it doesn't make sense to avoid polling, as rendering is going to happen anyway, but for applications without constant animations, it does make sense.)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Wait for events in a real blocking way
« Reply #3 on: February 07, 2015, 10:18:37 pm »
Quote
I'd like to avoid using more CPU that needed
I doubt polling OS events once every 10 milliseconds will use that much CPU. Is there anything you have already tried/benchmarked, or are you just overthinking it?

Usually, I would also answer that SFML is not the right library for such an application, and would advise to use Qt or similar. But I guess it would be hard to get that pixelated look that your application has.
Laurent Gomila - SFML developer

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Wait for events in a real blocking way
« Reply #4 on: February 07, 2015, 10:43:14 pm »
I'd just lock your window at 5-10 fps. It's what Microsoft does as well with its newer desktop programs rendering with Direct3D. If there are animations to show, the framerate is raised temporarily, and then reduced again if not required.

You could raise the frame rate whenever there's something happening and then lower it once again when there's no activity.

dacap

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Wait for events in a real blocking way
« Reply #5 on: February 08, 2015, 12:28:37 am »
Is there anything you have already tried/benchmarked, or are you just overthinking it?

I remember to have tried Sleep(0) on Windows and sched_yield() on Linux and they didn't work well. The "final" solution was this: https://github.com/aseprite/aseprite/blob/master/src/ui/message_loop.cpp#L35 (pretty close to what SFML does)

Anyway the CPU usage depends on the amount of work needed for the polling. I think that my case (checking some Allegro 4 structures, like an key[] array) is much worse than SFML (maybe a simple PeekMessage() and events.empty() check).

Usually, I would also answer that SFML is not the right library for such an application, and would advise to use Qt or similar. But I guess it would be hard to get that pixelated look that your application has.

Yeah. Anyway I think I'll have a hybrid solution in the future (parts of code with SFML/or other 2D library like Skia/Cinder + other native parts, e.g. Cocoa, Win32 controls, etc. Both interfaces: pixelated and native).
Thanks for your time!

 

anything