GNOME Bugzilla – Bug 756302
Timer resets when pausing or ending game
Last modified: 2015-11-02 06:39:39 UTC
In the latest version of gnome-mines to hit the Arch repositories (3.18.0), any action that would normally pause the timer instead causes it to reset to zero. That is to say pausing the game results in a displayed time of zero, and finishing the game records zero to the history. While I am not entirely familiar with how this game is built, I had a look through the .vala files. Apparently, in minefield.vala, the function it references as using when freezing the clock (stop_clock ()) sets the clock to NULL regardless of circumstances. This function is referenced both for pausing and ending the game.
Guess: could it be a regression from 0b7fde3400274cf7720d4a868718377487dd2ea2?
(In reply to Michael Catanzaro from comment #1) > Guess: could it be a regression from > 0b7fde3400274cf7720d4a868718377487dd2ea2? I can confirm this. The timer is reset when the game is paused on git master, but this is fixed if 0b7fde3400274cf7720d4a868718377487dd2ea2 is reverted. commit 0b7fde3400274cf7720d4a868718377487dd2ea2 Author: Robert Roth <robert.roth.off@gmail.com> Date: Fri Jun 26 02:45:16 2015 +0300 Drastically reduce CPU usage
Thanks for the heads-up, I have checked the commit, my mistake there, one regression applying it (pause resets the timer) and another one reverting it (after several games CPU usage goes up). I decided to fix with a third option, but this will also need testing, if it works for you, I will push this back into the stable release. I have tested this with a couple of games, playing with pause, resume, start over, play again, and it all seemed to work at first sight, but I might be missing something, so your input is welcome. This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
(In reply to Robert Roth from comment #3) > Thanks for the heads-up, I have checked the commit, my mistake there, one > regression applying it (pause resets the timer) and another one reverting it > (after several games CPU usage goes up). I decided to fix with a third > option, but this will also need testing, if it works for you, I will push > this back into the stable release. I have tested this with a couple of > games, playing with pause, resume, start over, play again, and it all seemed > to work at first sight, but I might be missing something, so your input is > welcome. Thank you, works much better now on git master. However, there is still one minor thing I noticed. When starting to count, the timer sometimes jumps two seconds as first time-step (for example 0:00 -> 0:02). This can happen on the start of the game or when resuming the game after pausing i, which makes the counting feel unsmooth. This does not happen every time. If the latest fix and 0b7fde3400274cf7720d4a868718377487dd2ea2 is reverted I no longer see any two-second jumps.
Ok, reopening to fix 2 second jumps. Reverting the commit you mention would involve high CPU usage after several games, so I will work on improving the 2 second jumps, being the only issue with the current bunch of fixes. Thanks for testing.
Would Timeout.add(1000, timeout_cb) would work just as well as Timeout.add(200, timeout_cb)? There is a precision cost to using Timeout.add_seconds (but a power-saving benefit).
(In reply to Michael Catanzaro from comment #6) > Would Timeout.add(1000, timeout_cb) would work just as well as > Timeout.add(200, timeout_cb)? There is a precision cost to using > Timeout.add_seconds (but a power-saving benefit). I can try with 1000 ms timeout, wanted to use something more precise, as 1000 ms could be a bit more than 1000ms, as far as I know, due to scheduling. If we can have the 1000ms timeout run once each second, I will be fine with that.
Ok, I have tested with 1000ms timeout, there are visible irregularities in counting, alias some intervals are shorter than one second, others are longer (trying pause/resume several times). Setting the timeout to 500ms seems to work fine, being less frequent than the 200ms, more frequent than 1000ms/1s showing the counting irregularities, so I am marking this as fixed. If you see any other issues with the current timing, feel free to reopen. This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
*** Bug 757447 has been marked as a duplicate of this bug. ***