If all of your data is created in java land, then nio doesn't get you any faster. If you read the current specifications about JNI, it talks about the potential of data being copied when it is passed from java through JNI. There are API's in JNI that prevent such a copy. And, the way that Java 3D uses geometry data allow the copy to not happen. Therefore, NIO does not buy you anything from a performance standpoint. We did a bunch of benchmarks when we added nio support to Java 3D to verify this.
NIO is only a performance win if you have data that is coming from a native source. Then NIO does not incur the cost of getting the data from native spaces to java spaces. If your data is coming from a native source, then NIO is a huge win for getting the data into Java. Doug Twilleager Java 3D Team Sun Microsystems >Subject: Re: [JAVA3D] Geometry Types >X-Originating-IP: [24.114.22.72] >To: [EMAIL PROTECTED] >MIME-version: 1.0 >Delivered-to: [EMAIL PROTECTED] >X-OriginalArrivalTime: 22 Apr 2002 21:04:46.0666 (UTC) FILETIME=[55390AA0:01C1EA41] > >Cool, I'll look into that. I was under the impression that NIO would only be >useful for custom JNI code running with java3d (as per the notes in the api >spec), but then I realized that java3d is itself custom JNI code. > >So my question then is this then: (to all you groovy Sun architects out >there, or someone who may have tested this..) > >Is there a reason to NOT use >'BYREF-NIO-UseCoordIndexOnly-IndexedTriangleStripArray' geometry for the >general case? Or is there a faster way? > > >>From: Artur Biesiadowski <[EMAIL PROTECTED]> >>Reply-To: Discussion list for Java 3D API <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Subject: Re: [JAVA3D] Geometry Types >>Date: Mon, 22 Apr 2002 15:47:46 +0200 >> >>Chris Forrester wrote: >> >>>BYREF geometry notes: >>> >>>Using the BYREF flag indicates that the data used within the geometry is >>>accessed through user arrays. Really the only way to go for volatile >>>meshes, >>>particle systems, bones animation, and multi/sub material objects, add two >>>grades for memory, one grade for ease, but lower one grade from speed >>>because of the fact that java3d (without a command-line option) cannot >>>build >>>vertex lists out of this data. >> >>I would be cautious with saying that BY-REF geometry has to be slower. >>In case of NIO-BUFFER, BY_REF geometry it can be quite fast. I have >>heard that in some cases vertex arrays are faster than display lists. >>This is certainly something to check out on particular configuration, >>but I would change this recomendation from 'lower one grade' to 'maybe >>lower one grade' - if data is NIO+BY_REF. >> >>Artur >> >>=========================================================================== >>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". > > > > >------------------------ > >Chris Forrester > >http://www.geocities.com/Psionic81 > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > >=========================================================================== >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".
