Switched times to Uint32 milliseconds in SFML 2

[Tronic]

This change is a clear and useless regression.

Use double, keep the API compatibility and keep it precise down to microsecond level for 300 years. Time precision greater than 1 ms is important for various things including audio clock sync, profiling and such. 1 ms jitter is apparent on smooth 60 FPS animation even if not particularly disturbing.

There are highly precise timers available on all major platforms, so there is also no reason to only offer 1 ms precision. Double precision floating-point is lightning fast to calculate with and the extra four bytes for a clock memory footprint cannot be significant either (especially since floats are promoted to double anyway when put into registers or passed to functions).

If you read the arguments FOR using integers in the thread, you would see that that "extra precision" you need wouldn't exist even if floats were used. OSes only guarantee precision to the millisecond level.

As others have pointed out, that belief is bogus. All OSes worth a mention provide nanosecond or similar precision in their time interfaces, and the actual timers on pretty much any platform are of very high precision too. I highly doubt SFML ever getting ported to a system where time precision wouldn't be better than 1 ms.

Also, it needs to be emphasized that double precision float (i.e. double) is needed. Single precision (i.e. float) is not enough as was demonstrated by the original issue that started this thread. Double precision floating-point calculations are extremely fast even on modern mobile platforms (not to mention x86), so the performance won't be an issue. Neither should the 8 byte memory footprint for a time value matter anywhere.

[Laurent]

It seems that everybody wants different things:
- nanoseconds, microseconds, milliseconds, seconds
- float, double, Uint32, Uint64

The most flexible approach would be to implement sf::Clock using a Uint64 number of nanoseconds. This is indeed possible on supported OSes; I can even improve the implementation to use only monotonic and non-overflowing functions.

But then I still have to decide what to provide in the public API. I have several solutions, but none of them would satisfy everyone:
- provide Uint64 nanoseconds, but then many people will complain that we're losing the S of SFML
- provide Uint32 milliseconds, but then some people will complain that the resolution is too high
- provide double seconds, but then some people will complain about the lack of exact timestamps, as well as the need to cast to float every calculation involving time (everything gets promoted to double when one of the operands is a double, but SFML uses float everywhere else)
- provide everything, but then I will complain about the bloated API

If someone can find a clean solution to this problem I'm ready to rewrite sf::Clock again if necessary.

[luiscubal]

How about some simple-to-use flexible TimeSpan class?

Code: [Select]


class TimeSpan {
   //Whatever;
public:
  //constructors come here

  Uint64 GetNanoseconds() const;
  Uint32 GetMilliseconds() const;
  double GetSeconds() const;
};


[Laurent]

How about some simple-to-use flexible TimeSpan class?

It doesn't solve points 3 and 4

- provide double seconds, but then some people will complain about the lack of exact timestamps, as well as the need to cast to float every calculation involving time (everything gets promoted to double when one of the operands is a double, but SFML uses float everywhere else)
- provide everything, but then I will complain about the bloated API

And I don't know if it's clear enough that every function returns the same thing with a different type/resolution, it could be a decomposition of a time value instead, like the "tm" struct in time.h.

[luiscubal]

To be honest, I'm perfectly fine with the current SFML 2 time API.

[Laugilus]

What about :

Code: [Select]

template <class T = Uint32>
class Clock;

template <>
class Clock<Uint32> {/* milisec implementation */};

template <>
class Clock<Uint64> {/* nanosec implementation */};

template <>
class Clock<double> {/* double implementation */};

// A float implementation ???
template <>
class Clock<float> {/* float implementation */};

If every implementation shares the same API, you won't "complain about the bloated API".

[Nexus]

The sf::Clock class is only one side of the medal. All the interfaces that work with times have to be adapted, too -- for example, sf::Sleep(), sf::RenderWindow::GetFrameTime() or sf::TcpSocket::Connect().

And if Laurent is against a TimeSpan class with its conversions, the candidates are float seconds (like in early SFML 2) or unsigned int milliseconds (like now). Are there interfaces for which float is too unprecise in real life situations? Or did the change to milliseconds mainly happen to allow long time measuring with sf::Clock?

In this case, an option might entail offering two sf::Clock methods. One for daily wark with the practical seconds, and one for rare high-resolution measuring.

Code: [Select]

float      GetElapsedSeconds();      // or just GetElapsedTime()
sf::Uint64 GetElapsedNanoSeconds();

[luiscubal]

Are there interfaces for which float is too unprecise in real life situations?

That question has already been answered.

Yes, the problem is that they become less accurate too quickly (apparently it becomes a problem after 2.33 hours).

[Nexus]

No, it has not. I explicitely asked for real life situations, because no one will call sf::Sleep() with 2.33 hours. So, at which places in the SFML API apart from sf::Clock itself is the inaccurateness an issue?

[kolofsson]

Yes, I think that if we care about the "Simple" in SFML, then the time unit should be 1 second, thus forcing to use a floating point variable. With a millisecond as a unit, if you want to keep all your variables true to the SI units, each time you have to divide the time by 1000.

[TomCatFort]

- provide double seconds, but then some people will complain about the lack of exact timestamps, as well as the need to cast to float every calculation involving time (everything gets promoted to double when one of the operands is a double, but SFML uses float everywhere else)

Casting a floating point type to an another one works by loading the data into one of the FPU registers then unloading it into the target type, this takes a little time yes. But if you do calculations they are loaded in those registers anyway and they are stored in the internal format of the FPU (As I know in Intel processor these registers use 80 bit extended precision) so the most drawback of doubles comes from the double memory usage.

I would personally use unsigned 64 bit integer with nanoseconds so SFML can use the best available timer on the platform. It can be simply converted to milliseconds or the desired floating point value if the programmer want something else.

A TimeSpan class could be made that internally use nanoseconds and provides methods to retrieve it in various other formats. The programmer doesn't even need to carry this class around, they just extract the needed value and propagate that in they code.

Code: [Select]


TimeSpan ts = foo.EllapsedTime();
double deltaTime = ts.AsDoubleSecunds();
update(deltaTime);
render(deltaTime);


[Laurent]

the most drawback of doubles comes from the double memory usage

I was talking about the required static_cast, which makes the code verbose and ugly. I don't really care about memory or CPU usage

I would personally use unsigned 64 bit integer with nanoseconds so SFML can use the best available timer on the platform. It can be simply converted to milliseconds or the desired floating point value if the programmer want something else.

I was thinking about something similar, yes. Except that I'd use microseconds, nobody needs nanoseconds.

A TimeSpan class could be made that internally use nanoseconds and provides methods to retrieve it in various other formats. The programmer doesn't even need to carry this class around, they just extract the needed value and propagate that in they code.

That's more or less what I'm investigating.

[TomCatFort]

Quickly wrote a test in java to see how good is the time precision using nanoseconds:

Code: [Select]


final int C = 10;
long[] res = new long[C];
int i = 0;
long tp = System.nanoTime();
while (i < C)
{
    long tn = System.nanoTime();
    if (tn != tp)
    {
        long d = tn - tp;
        tp = tn;
        res[i] = tn;
        i++;
    }
}

for (i = 0; i < C; i++)
    System.out.println(Integer.toString(i) + " = " + res[i]);


This is the result:

Code: [Select]


0 = 181327039326786
1 = 181327039328598
2 = 181327039329503
3 = 181327039330409
4 = 181327039331315
5 = 181327039332221
6 = 181327039332674
7 = 181327039333580
8 = 181327039334485
9 = 181327039335391


It seems that my ordinary laptop can produce far better (although not true nanotime) precision than milliseconds. It is hard to say no to this (personally).

[Laurent]

Yeah yeah, I already said that I agree for sub-millisecond precision (but microsecond is enough)

[TomCatFort]

Well micro is still a thousand times better then milis!