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.
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.
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.
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".
