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

Author Topic: [Android] Best way to handle sf::Event::LostFocus and sf::Event::MouseLeft  (Read 2904 times)

0 Members and 1 Guest are viewing this topic.

Daid

  • Newbie
  • *
  • Posts: 29
    • View Profile
A bit of searching let me to the following. On Android, SFML currently generates the following events:
* sf::Event::LostFocus when the main window is destroyed, but the Activity is still active
* sf::Event::MouseLeft when the application needs to "pause"

The pause is clear to me, explained quite well here: http://developer.android.com/training/basics/activity-lifecycle/pausing.html
But I have no idea when the main window is destroyed but the activity keeps being active.

Right now, my application does not handle these events yet. And this caused my application, while not being visible, to drain my phones battery over night.


Now, I could just go into a sf::Window::waitEvent() loop till I get the corresponding "counter" event. But if I look at the code:
https://github.com/SFML/SFML/blob/master/src/SFML/Window/WindowImpl.cpp#L128
It seems that waiting for an event still causes the application to live 100x per second. Which does not feel that good for battery life.


So I'm not sure what's the best way to handle is. Just close the application on sf::Event::LostFocus? And "wait-loop" on sf::Event::MouseLeft?

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Answer cause of this thread: http://en.sfml-dev.org/forums/index.php?topic=18662.msg134104

Sadly i do not have the Kroniax (android) source anymore, stupid misstake  :( . But I used a pause flag (when mouse left or lost focus occured,  and then i just used sf::sleep(1000-3000?, dont remeber the exact value) between every pollEvent. Don't know if this helps, and i've never checked the battery drain of my app in background, but non of my friends reported any problems.


AlexAUT

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 878
    • View Profile
If you really care about (even minimal) power consumption, store your gamestate when the context is destroyed and close your app. The next time you start, check for that state and load it right away.

Otherwise using waitEvent() should be just fine.

Daid

  • Newbie
  • *
  • Posts: 29
    • View Profile
If you really care about (even minimal) power consumption, store your gamestate when the context is destroyed and close your app. The next time you start, check for that state and load it right away.

Otherwise using waitEvent() should be just fine.
Problem is, closing the app does not really seem to work properly right now. If I end the main thread, and start the application, I get an exception. Second start seem to start it from scratch again.


waitEvent DOES loop the CPU as I pointed out, as it sleep 10 milliseconds in a loop. It works, but pretty it is not IMHO. As you are putting extra drain on the battery even tough your user isn't actively using the application.

(Losing state isn't a huge issue for my app)