----- Original Message -----
From: Andrew Moulden <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: September 2, 1999 5:07 PM
Subject: [JAVA3D] Will Java3D source ever be published?
> Hi,
>
> Are there any plans to release source code for javax.media.j3d? I'm sure
> there are many who would agree that performance would take a huge leap
> forward if all developers could point out code optimizations, and it
> would be far easier to suggest API changes if we could see the 'whole
> picture'.
>
> My profiling of running J3D apps suggest there is a tremendous amount of
> object creation (and hence gc-related destruction) which could probably
> be substantially reduced if we could see the code. This is especially
> true in the area of behaviours which I assume rely more on Java
> implementations than being channelled through to underlying native
> implementations. As I'm sure just about everyone knows, creating objects
> in Java is hideously expensive.
>
The Java3D team is aware of this. Most of the API calls currently copies
objects you supply to it and work with the copies. If you look at the
latest proposed API changes for Java 3D 1.2, you will notice the addition of
many methods that can be used to pass your objects by reference .ie. they
won't copy your objects, they will just use them. This should get rid of
the majority of the object creation overhead.
> I know the argument often goes: Build a stable API first then make it
> faster, but my experience is that code optimization *always* requires
> API changes, which can be impossible or impractical in a public API.
> Hence we get so many APIs which remain permanently inefficient.
>
> I'm not in any way suggesting that developers know any better than the
> J3D team, it's merely that our goals at this stage are usually
> different: while one side is concentrating on ironing out problems with
> the underlying platform, developing the API and working on
> documentation, the other side is trying to get code running as fast and
> as efficiently as it can.
>
> As one of many examples take this code snippet from the
> TCBSplinePathInterpolator class in the com.sun.j3d.utils package
> (comments are the code author's):
>
> --------------START EXAMPLE---------------
> public TCBSplinePathInterpolator(Alpha alpha, TCBKeyFrame keys[]) {
>
> (stuff deleted)
>
> // Make space for a leading and trailing key frame in addition to
> // the keys passed in
> keyFrames = new TCBKeyFrame[keysLength+2];
> keyFrames[0] = new TCBKeyFrame();
> keyFrames[0] = keys[0];
> for (int i = 1; i < keysLength+1; i++) {
> keyFrames[i] = new TCBKeyFrame();
> keyFrames[i] = keys[i-1];
> }
> keyFrames[keysLength+1] = new TCBKeyFrame();
> keyFrames[keysLength+1] = keys[keysLength-1];
> ---------------END EXAMPLE------------------
>
> Now if I'd read this in anything other than a Sun source document I'd
> have said that the programmer had a fundamental misunderstanding of how
> the Java language works, but obviously this is just an oversight in this
> particular case. Nevertheless it does mean that completely redundant
> objects are being created by this behaviour class which immediately
> entail time-consuming garbage collection.
>
Actually, this is another case of copying supplied objects as mentioned
above. The only weird thing I see there isn't that they just didn't put
everything in the loop but that is probably an optimization to deal with
empty keyframe lists.
> Also in the same class we have the computePathInterpolation() method
> which is called *every frame*:
>
> --------------START EXAMPLE---------------
> protected void computePathInterpolation() {
> float value = (this.getAlpha()).value();
>
> // skip knots till we find the two we fall between
> int i = 1;
> while ((value > keyFrames[i].knot) && (i<keysLength-2)) {
> i++;
> }
> (rest of method deleted)
> ---------------END EXAMPLE------------------
>
> There are a number of comments that can be made about the while loop,
> but basically: 1) the (i<keysLength-2) can easily be made redundant and
> 2) there are very fast alternative methods to finding which keyFrame
> knot the alpha value falls between. Counting up from 1 is about as slow
> as you can get.
>
Aside from using a hashtable of some kind (which will take up much more
memory), I think the way they did it is probably the best method for trading
off performance versus memory usage.
> I'm sure I've raised some hackles with this message, but I hope it will
> be taken constructively. As many open-source APIs have shown, hundreds
> of developers coming up with small code modifications can have a
> dramatic effect on the ultimate power of a programming library.
>
> Andrew Moulden
>
>
===========================================================================
> 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".
Roberto Speranza
President, Dot Internet Solutions Inc.
mailto:[EMAIL PROTECTED]
http://www.dotinc.net/
===========================================================================
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".
