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

Author Topic: Peeking for events  (Read 6412 times)

0 Members and 1 Guest are viewing this topic.

nitram_cero

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Peeking for events
« on: June 17, 2009, 02:54:07 am »
Is there a function to know if there are any pending window events?

It would be great to avoid constant CPU use for applications that only change their display with user input (like multiple SFML windows integrated in a GUI).

Something like "bool Window::HasPendingEvents();" would be great.

Thanks
-Martín

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Peeking for events
« Reply #1 on: June 17, 2009, 08:16:39 am »
What would be the difference with the current bool Window::GetEvent ?
Laurent Gomila - SFML developer

nitram_cero

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Peeking for events
« Reply #2 on: June 17, 2009, 11:54:44 pm »
That it wouldn't get the event out of the queue, allowing it to be processed in another function.

e.g.
Code: [Select]

void Base::OnUpdate() {
    if(wnd.HasPendingEvents())
        ProcessTheEvents();            //virtual
        DrawStuff();                       //virtual
    }
}

void Derived::ProcessTheEvents() {
    Event ev;
    while(wnd.GetEvent(ev)) { /*...*/ }
}


Allows non-centralized processing of events. Gives the ability to process the events in the way that the derived class feels proper (all/some/one per frame)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Peeking for events
« Reply #3 on: June 18, 2009, 09:19:56 am »
What's the problem if you call ProcessTheEvents() when there's no pending event? You're just saving one function call.

Regarding this kind of design, I would rather use a ProcessEvent(event) function that processes a single event at a time, and have the event loop at a higher-level (like in the Game / Application / ... class).
With your design, when an object processes an event it is no longer usable by other objects. With mine you can dispatch it to multiple objects.
Laurent Gomila - SFML developer

nitram_cero

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Peeking for events
« Reply #4 on: June 18, 2009, 04:21:48 pm »
Yes, good point.

I'll explain what I was trying to do:
I'm working with wxWidgets with the out-of-the-box example in the tutorials.

But having it refreshed on each idle moment kills my CPU and I want to be multitasking; using other software for editing the graphics that I'm using in this one I'm making.

Basically I have an "OnIdle()" derived function that wxWidgets calls when the system is idle. But it actually makes the system go on full load (WinXP).
Maybe it was thought for small timespan processing instead of rendering & buffer swapping, etc.

I will take your approach, but I will still need a way to know if an event ocurred.
I think I will have a flag like "mustRedraw" that gets set on wxWidgets' ProcessEvent() and on the loop that dispatches the SFML events and reset it after RenderWindow::Display()

Just to prove my stubborness: Every other existing window interface has event peeking. :roll:  :P

Thanks for all
-Martín

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Peeking for events
« Reply #5 on: June 18, 2009, 05:21:35 pm »
Quote
But having it refreshed on each idle moment kills my CPU

Yes, this is the purpose of the idle event. However you can use something else if you want more control on the refresh rate, like a timer; the Qt sample uses such a solution.
I guess there are other solutions but I don't know wxWidgets that much. Maybe you can try something on SFML side, like using vertical-sync or a fixed framerate.

Quote
I will take your approach, but I will still need a way to know if an event ocurred.
I think I will have a flag like "mustRedraw" that gets set on wxWidgets' ProcessEvent() and on the loop that dispatches the SFML events and reset it after RenderWindow::Display()

Sorry I don't get it, could you show me an example?

I also don't get the relation between the refresh rate and the event loop :?
Laurent Gomila - SFML developer

nitram_cero

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Peeking for events
« Reply #6 on: June 19, 2009, 05:50:22 pm »
Heheh, I'm not so well explaining in English.

It's not a game, but a 2d model editor. I don't want it to be refreshed (redrawn) all the time. Avoiding this, avoids the constant CPU use.

The relationship is that, usually, it should be redrawn on SFML/GUI events (like window repaint, mouse move, selection of a node in a treeview...)

I just hacked the SFML canvas class, now it only draws on idle if an event happened (either from wx or sfml) between the idle event and the last draw. Need to handle this on the idle events to avoid redrawing on each non-idle event. This way I flag when an SFML/GUI event happened, and the process it on the idle event.

I happened to be switching between my graphics editor and this utility I'm making... and having 100% cpu load from the utility didn't allow me to work on the graphics editor.

Solved now, also dispatching events to another virtual function as you suggested.

-Thanks
-Martín

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Peeking for events
« Reply #7 on: June 19, 2009, 06:34:43 pm »
Why don't you refresh your view on a paint event from wxWidgets?
Laurent Gomila - SFML developer