Vertex Buffers : inequal time of traitment (animation)

On 12/17/2013 12:00 AM, jmaasing [via jogamp] wrote: <http://jogamp.org/git/?p=gluegen.git;a=commitdiff;h=77687335f7fae3727c902c678b9525e6f4631da1>

+++

+    
+    /**
+     * Returns the unix based current time in milliseconds, based on <code>gettimeofday(..)</code>.
+     * <p>
+     * This is an alternative to {@link System#currentTimeMillis()} and {@link System#nanoTime()}.
+     * While the named {@link System} methods do provide the required precision,
+     * <code>gettimeofday()</code> <i>also</i> guarantees time accuracy, i.e. update interval.
+     * </p>
+     * @see #currentTimeMicros()
+     */
+    public static native long currentTimeMillis();
+    
+    /**
+     * Returns the unix based current time in microseconds, based on <code>gettimeofday(..)</code>.
+     * <p>
+     * This is an alternative to {@link System#currentTimeMillis()} and {@link System#nanoTime()}.
+     * While the named {@link System} methods do provide the required precision,
+     * <code>gettimeofday()</code> <i>also</i> guarantees time accuracy, i.e. update interval.
+     * </p>
+     * @see #currentTimeMillis()
+     */
+    public static native long currentTimeMicros();

+++

~Sven

On 12/17/2013 12:49 AM, Sven Gothel wrote: We use the above Platform methods for accurate audio/video (A/V) synchronization
in our GLMediaPlayerImpl class, otherwise the lack of accuracy would cause
a disastrous A/V diversion.

> ~Sven
>
>

Sven Gothel wrote

We use the above Platform methods for accurate audio/video (A/V) synchronization
in our GLMediaPlayerImpl class, otherwise the lack of accuracy would cause
a disastrous A/V diversion.

Does this lack of accuracy only occur under Windows? I use a known hack to force Java (System.*) to use the high precision timer.

On 12/17/2013 09:57 AM, gouessej [via jogamp] wrote:
>     Sven Gothel wrote
>     We use the above Platform methods for accurate audio/video (A/V)
>     synchronization
>     in our GLMediaPlayerImpl class, otherwise the lack of accuracy would cause
>     a disastrous A/V diversion.
>
> Does this lack of accuracy only occur under Windows? I use a known hack to
> force Java (System.*) to use the high precision timer.

The specification states there is not guaranteed accuracy here,
i.e. impl. may choose to use less expensive 'time queries'.

I have experienced the inaccuracy on Oracle's JRE on GNU/Linux
and Windows w/ both System methods (milli/nano).

~Sven

Now I'm confused, or  mistaken (haven't read C(pp) code in many years)  

But it looks like the gluegen code uses the same as the JDK uses, unless the newer clock_gettime(CLOCK_MONOTONIC) is supported by the kernel, so the jitter, accuracy, and precision should be identical?

http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/d835d67bfb88/src/os/linux/vm/os_linux.cpp

 jlong os::javaTimeNanos() {
     1479   if (Linux::supports_monotonic_clock()) {
     1480     struct timespec tp;
     1481     int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
     1482     assert(status == 0, "gettime error");
     1483     jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
     1484     return result;
     1485   } else {
     1486     timeval time;
     1487     int status = gettimeofday(&time, NULL);
     1488     assert(status != -1, "linux error");
     1489     jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
     1490     return 1000 * usecs;
     1491   }
     1492 }

On windows JDK uses performance counters if they are supported
http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/d835d67bfb88/src/os/windows/vm/os_windows.cpp

 823 jlong os::javaTimeNanos() {
      824   if (!has_performance_count) {
      825     return javaTimeMillis() * NANOSECS_PER_MILLISEC; // the best we can do.
      826   } else {
      827     LARGE_INTEGER current_count;
      828     QueryPerformanceCounter(¤t_count);
      829     double current = as_long(current_count);
      830     double freq = performance_frequency;
      831     jlong time = (jlong)((current/freq) * NANOSECS_PER_SEC);
      832     return time;
      833   }
      834 }

On 12/17/2013 01:09 PM, jmaasing [via jogamp] wrote:
> Now I'm confused, or  mistaken (haven't read C(pp) code in many years)  
>
> But it looks like the gluegen code uses the same as the JDK uses, unless the
> newer clock_gettime(CLOCK_MONOTONIC) is supported by the kernel, so the
> jitter, accuracy, and precision should be identical?

http://stackoverflow.com/questions/12158307/accuracy-of-system-currenttimemillis-new-date-gettime-and-calendar-getin

^^ one onswers quotes the Java API doc, which explicitly states
that not guarantee of accuracy is given, i.e. clock being queried.

I have not checked the source code, so I don't know when
those JNI functions may get called .. or not.

However, I have experienced a millisecond difference to real-time clock
w/ the JRE System method, which - when used - caused an A/V lag.

However it's implemented, if the API doc states 'no accuracy'
there cannot be any expected.

I also remember some hacks in this regards many years ago
where this method was 'optimized' to allow faster calls for logging functions.

If you find more details, please share it w/ us.

~Sven

Sven Gothel wrote

On 12/17/2013 01:09 PM, jmaasing [via jogamp] wrote:
> Now I'm confused, or  mistaken (haven't read C(pp) code in many years)  
>
> But it looks like the gluegen code uses the same as the JDK uses, unless the
> newer clock_gettime(CLOCK_MONOTONIC) is supported by the kernel, so the
> jitter, accuracy, and precision should be identical?

http://stackoverflow.com/questions/12158307/accuracy-of-system-currenttimemillis-new-date-gettime-and-calendar-getin

^^ one onswers quotes the Java API doc, which explicitly states
that not guarantee of accuracy is given, i.e. clock being queried.

I have not checked the source code, so I don't know when
those JNI functions may get called .. or not.

However, I have experienced a millisecond difference to real-time clock
w/ the JRE System method, which - when used - caused an A/V lag.

However it's implemented, if the API doc states 'no accuracy'
there cannot be any expected.

I also remember some hacks in this regards many years ago
where this method was 'optimized' to allow faster calls for logging functions.

If you find more details, please share it w/ us.

~Sven




signature.asc (911 bytes) <http://forum.jogamp.org/attachment/4030934/0/signature.asc>

The javadoc was amended with JDK 1.7 to explain what was meant with precision and accuracy. However, the guarantees are the same, i.e. "This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes) - no guarantees are made except that the resolution is at least as good as that of currentTimeMillis()."

This disclaimer is because not every OS supports nanosecond resolution (notably old Windows XP). The javadoc does state that it will use a high-resolution timer (i.e. stop watch - it can not be compared to wall clock time). So the JVM does appear to use a best effort but of course it can not guarantee better resolution than is available in the OS.

Hello guys,

i am not sure i have understand deep youre answers but i retain what i have allready read about the lack of accuracy of the timers (Animator too). My problem is that i am animating a clock... so real time could be fine :)

My problem now is that my threadDATA wait for the display has been done, but the display don't wait for threadDATA that he has updated the data buffers. So the display happen twice or more while threadDATA happen just once so the display is slowlier and irregular (because probabilist).

For my other question, i have to synchronize opengl stuff with data traitment. How could it be done ? Cade source availaible ? Is it possible to do wait the JOGL process ? This thread is necessary in a AWT-Queue ? This queue seems to be impossible to be waiting... it seems logic.

Is it possible to call the display method outside, in a artisanal Animator for example to put it in a specific thread ?

i continue my search but don't find,
Nico.