Julian,
I have done a fair bit of timing (in another life) using the Win32 API. As
far as I know there are three ways:
- tick count, ~50 ms resolution
- multimedia (MIDI) timer, ~1 ms resolution
- profiling frequency timer, (NT only) - as high as possible in software
I'd be interested to hear which one you chose, and the DLL/Java code if you
have it! It sounds like you used the NT profiling timer. If you are crossing
the JNI barrier to call into the DLL you are you also measuring a lot of
Java related overhead. Accurate (sub millisecond) timing is very difficult
in Win32, even using hardware timers, as the old adage that you can't
measure something without effecting it really comes into play!
Regarding indexed geometry. I think the point is that no hardware supports
indexed geometry, therefore anything you do in software will be much slower
than just pumping a nice strip of triangles to the hardware. Transformation
and lighting can both be performed in hardware (well, some).
Until we have "4th generation" (yuck) hardware that accepts whole objects
for rendering instead of a few vertices we will probably be stuck with this
limitation.
Just some (random?) thoughts.
Sincerely,
Daniel Selman
[EMAIL PROTECTED]
http://www.tornadolabs.com
> -----Original Message-----
> From: Discussion list for Java 3D API
> [mailto:[EMAIL PROTECTED]]On Behalf Of Julian Scheid
> Sent: 06 February 2000 15:57
> To: [EMAIL PROTECTED]
> Subject: [JAVA3D] AW: [JAVA3D] IndexedGeometryArrays Vs. GeometryArrays?
>
>
> >> Er.. it's not obvious about the indexing. Because I gather
> from postings
> >> on this list from Sun folk that the IndexedGeometry gets unfolded to
> lists
> >> of triangles or polygons or whatever before it gets sent to
> the graphics
> >> subsystem. And since this has to happen, you probably pay a
> performance
> >> penalty while waiting for the unfolding.
>
> If its true that indexed triangle lists always get unfolded to non-indexed
> ones, it still might be a performance advantage to use it, because
> "unfolding" is nothing but copying some bytes around - but transforming,
> clipping and lighting the same vertex three times means a whole bunch of
> matrix transformations.
>
> It always depends on the implementation. Best thing would be to have some
> benchmarks on the Java3D implementation. Daniel, what does
> JBench say about
> it?
>
> Apropos benchmarking: Anyone knows a standard API method which I
> can use to
> read the system timer at a higher accuracy than that provided by
> System.currentTimeMillis()?? I haven't found one and therefore
> implemented a
> small native DLL for windows which uses Windows' high resolution timer
> (which has a resolution of a few nanoseconds). Works well, but isn't
> portable. Does anyone know a portable way for this?
>
> -- Julian
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
