[Marble-devel] Review Request: Fix the timeChanged() signal emission timeout calculation in MarbleClock

[Dennis Nienhüser]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104861/
-----------------------------------------------------------

(Updated May 4, 2012, 10:43 p.m.)


Review request for Marble.


Changes
-------

The updated patch checks for zero speed (time halted, no need for any updates) and also restarts the timer before emitting the signal to avoid delays caused by attached slots.

Discussing things with the original bug reporter on IRC it turns out that on his Windows system the QTimer precision seems to be quite bad compared to the one I get here on Linux: With high speed values a certain drift is noticable on Linux, whereas on Windows depending on the update interval delays of several milliseconds seem to be common.

We could try to account for that by measuring the difference between the scheduled and the actual timeout in each loop. But that sounds to me like trying to solve a problem that QTimer should solve (and possibly would if it could). Reports like [1] indicate similar.

[1] https://bugreports.qt-project.org/browse/QTBUG-18872


Description
-------

MarbleClock currently rounds the internal clock to minutes. The implementation has rounding errors that result in the sleep timeout being calculated incorrectly and a fallback mechanism then sets it to one second. The same fallback mechanism handles negative speeds (time running backwards), which is wrong as well.

I'm not sure why the time is rounded to minutes. If it's done for aesthetic reasons, then it should rather be done in the UI code by setting the time once to the desired nice looking time. The timeout calculation however should stick to what is set from the outside. For a similar reason I'd like to remove the restriction that the timeout cannot be shorter than one second. If that is to be done for performance reasons, it should be done elsewhere (e.g. in the user interface where the clock settings can be manipulated). On my system I don't experience any problems though even when using the most extreme time settings (100x realtime at 1 second refresh = 100 fps) with the satellites plugin running.

The patch removes the rounding to minutes and timeout restriction. It also handles negative speeds correctly. This fixes the wrong signal emission timing.


This addresses bug 299388.
    http://bugs.kde.org/show_bug.cgi?id=299388


Diffs (updated)
-----

  src/lib/MarbleClock.cpp 56b2fe4 

Diff: http://git.reviewboard.kde.org/r/104861/diff/


Testing
-------

Custom application using
    mapWidget->model()->clock()->setSpeed( 40 );
    mapWidget->model()->clock()->setUpdateInterval( 20 );

and

    mapWidget->model()->clock()->setSpeed( 10 );
    mapWidget->model()->clock()->setUpdateInterval( 20 );

and some other values.

Marble with satellites plugin and various time / refresh settings.


Thanks,

Dennis Nienhüser

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20120504/c6083c4d/attachment.html>