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

Author Topic: WaitEvent loop but with some timed updates  (Read 6170 times)

0 Members and 1 Guest are viewing this topic.

barnack

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
WaitEvent loop but with some timed updates
« on: December 22, 2020, 02:39:08 pm »
Hi,
I'm not making a game, I'm making a desktop tool for monitoring performance (on top of LibreHardwareMonitor), in C#.
Ideally I'd update the metrics (and the window content) every 1 or more second. However if I add a sleep in a simple loop of one second, events dispatching is noticeably laggy.

Is there some straightforward way I'm not seeing to have a WaitEvent loop, but force it to get past the waiting every X seconds even if no event occurred?

I thought about having 2 threads, one looping with WaitEvent, the other updating every X seconds, but I'd rather avoid the mess of dealing with SetActive and synchronization.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: WaitEvent loop but with some timed updates
« Reply #1 on: December 22, 2020, 03:42:18 pm »
waitEvent can't return without an event. The common solution is the one you mention: using waitEvent in main thread for events management only, and the rest in a secondary thread.

No need to deal with setActive if all graphics calls are done from the same thread (ie. the secondary one), you'll just have to call window.setActive(false) once before launching your thread. Then you'll just need one synchronization point to pass events from the primary thread to the secondary one.

Or you could implement a fake waitEvent (as SFML does internally): call pollEvent at a given frequency, fast enough so that you don't notice any lag, but not too much to preserve CPU cycles. waitEvent uses 10 ms sleep.
Laurent Gomila - SFML developer

barnack

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Re: WaitEvent loop but with some timed updates
« Reply #2 on: December 22, 2020, 04:47:59 pm »
No need to deal with setActive if all graphics calls are done from the same thread (ie. the secondary one), you'll just have to call window.setActive(false) once before launching your thread. Then you'll just need one synchronization point to pass events from the primary thread to the secondary one.

Only issue with that is i need to re-draw on the resize event, besides the timed updates

 

anything