SORRY,
this discussion gets rather stupid. Everyone nows that creating a new object takes
about 1000 times more then a simple integer assignment. So why creating objects for
nothing ? Java3D already eats ( too ) much cpu performce, the gc slows down mostly
every app when starting cause (too much) objects get recreated and copied instead of
re-referenced.
BUT it looks like some think there isn't yet enough to do for it and let it get some
more.
HARR HARR
I suggest to look forward to real more important things:
- what about correct rendering to several views (using Billboard) ?
- what about correct reading Bounds from Group ?
- what about correct Event handling with Swing ?
- what about a real server side rendering that does not need awt support, and not just
a
faked one we get in the new release ?
wait & see
yeti
>--------------START EXAMPLE---------------
>1 public TCBSplinePathInterpolator(Alpha alpha, TCBKeyFrame keys[]) {
>2
>3 (stuff deleted)
>4 // Make space for a leading and trailing key frame in addition to
>5 // the keys passed in
>6 keyFrames = new TCBKeyFrame[keysLength+2];
>7 keyFrames[0] = new TCBKeyFrame();
>8 keyFrames[0] = keys[0];
>9 for (int i = 1; i < keysLength+1; i++) {
>11 keyFrames[i] = new TCBKeyFrame();
>12 keyFrames[i] = keys[i-1];
>13 }
>14 keyFrames[keysLength+1] = new TCBKeyFrame();
>15 keyFrames[keysLength+1] = keys[keysLength-1];
>---------------END EXAMPLE------------------
>
>When u create keyFrames array in line 6, its elements are not
>intialized. That is keyFrames[i] == null is true for any element of the
>array. If u would try to access this not initialized element you'll get
>NullPointerException. Now, correct me if i'm wrong, but as far as i know
>array elements store only _references_ to the objects, not the instances
>themselves. So, in order to initialize the elelement one should have
>_any_ reference to the same object type. 'new TCBKeyFrame()' in line 7
>returns _reference_ to TCBKeyFrame object which was initilized by
>default empty constructor. keys[i] also has reference to _another_
>TCBKeyFrame object. So, _both_ line 7 and line 8 are grammatically
>correct, but they do the same job. The only difference is that line 7
>operation takes much more time to compare with the one in line 8 and
>that the element would hold reference to different objects (that is to
>different places in memory)
>
>A note: the basic mistake in Java (and C as well) language is checking
>equality of two objects by means of == sign. The point is that in case
>of objects (Object1 == Object2) is true _ONLY_ in case earlier in the
>code there was an assignment Object1 = Object2. If u create Object1 and
>Object2 independently (that is via
>'Object Object1 = new Object() and
> Object Object2 = new Object(), for instance),
>then (Object1 == Object2) is always false (unless the assignment i
>talked about is present somewhere in the code), while
>Object1.equals(Object2) is always true unless you haven't changed some
>fields of these objects since the moment of creation. Remember, that
>'==' compares pointers, memory addresses, if you want, of the objects.
>So, obviously two objects created as independent instances via 'new'
>operator couldn't take up the same memory addresses and thus the result
>of '==' comparision is always false for them.
>
>It looks like the guy who wrote that code thought that he/she should
>declare that element would be of TCBKeyFrame type by means of 'new'
>operator and only after that it is possible to assign other references
>to this array element. Or possibly he/she did believe that he/she makes
>_real_ copies of the objects that would take up another memory
>addresses.
>
>It is interesting that in the cource of discussion neither has said how
>to modify the code. I wonder why. I bet there is a number of people who
>want to know it. So i'd dare to propose my variant (just comment out
>some lines)
>
>--------------START MODIFIED EXAMPLE---------------
>1 public TCBSplinePathInterpolator(Alpha alpha, TCBKeyFrame keys[]) {
>2
>3 (stuff deleted)
>4 // Make space for a leading and trailing key frame in addition to
>5 // the keys passed in
>6 keyFrames = new TCBKeyFrame[keysLength+2];
> // 7 keyFrames[0] = new
>TCBKeyFrame();
> // 8 keyFrames[0] =
>keys[0];
>9 for (int i = 1; i < keysLength+1; i++) {
> // 11 keyFrames[i] =
>new TCBKeyFrame();
>12 keyFrames[i] = keys[i-1];
>13 }
> // 14
>keyFrames[keysLength+1] = new TCBKeyFrame();
>15 keyFrames[keysLength+1] = keys[keysLength-1];
>---------------END MODIFIED EXAMPLE------------------
>
>Note1: keyFrames[keysLenght+1] (the last element of keyFrames array) is
>the same as keysFrames[keysLenght] (the second element from the end).
>That is (keysFrames[keysLenght+1] == keysFrames[keysLenght]) IS true.
>Note2: the arrays we get here (keysFrames) is actually the same we get
>in original example. Commented lines change absolutely nothing except
>for the loss of productivity and speed.
>
>No _objects_ are actually being copied in this example. Only
>_references_ do. Which means that that if keysFrames[i] object would be
>modified in this function, so would keys[i-1], and thus keys2[i-1]
>object of the class/function which called this TCBSplinePathInterpolator
>constructor would be also changed. So Java3D team guys do not follow the
>tradition of copying the objects. To do the actual copy function the
>following should have been written instead:
>
>keysFrames[i] = (TCBKeyFrame)(keys[i-1].clone());
>
>Hope this has cleared something out. Remember, that everyone can
>mistake. So, just don't get mad. Explain the mistake, so that no one
>would ever do it again. It's so simple. Thanks for your attention.
>Comments are always welcomed.
>
>vladimir
>
>Justin Couch wrote:
>>
>> Just in case anyone who is reading this is wondering what the hell these
>> guys are talking about, I'll highlight it very simply:
>>
>> > keyFrames[0] = new TCBKeyFrame();
>> > keyFrames[0] = keys[0];
>>
>> Note that the keyFrames[0] object is being assigned twice in two lines.
>> The first line creates a new instance of the object. The second line
>> throws away that newly created instance and replaces it with a
>> _reference_ to the object from the incoming array. The just created
>> object in the first line has never been used so we are dealing with a
>> big performance hit of creating a new object and then having it
>> immediately garbage collected. This is not isolated to one case in the
>> j3d utils package either.
>>
>> Now, back to Andrew's original point about source etc. Over the years of
>> working with Java I have serious doubts about the competance of many of
>> the core Java team. It's either they are just really bad at programming
>> or they have management breathing so far down their necks to get the
>> next new set of functionality out the door that they don't have time to
>> do anything other than kludgy coding. Another potential problem is that
>> nobody seems to be in charge of an entire architecture. My favourite
>> topic of Java's image loading is a classic example of this where nobody
>> seems to know what anybody else is doing. On one hand there is this
>> perfect system called URL content handlers then we have the toolkit code
>> and finally the rendering code, all of which need to take separate
>> copies of the data blowing memory usage out of the water. This goes back
>> to even little things like naming conventions - Point3d vs Transform3D
>> for example - and this done by people working on the same project!
>> Freely available source that we could modify unhindered would solve many
>> of these problems. Peer review is a wonderful thing for dealing with
>> getting bugs ironed out.
>>
>> --
>> Justin Couch Author, Java Hacker
>> Snr Software Engineer [EMAIL PROTECTED]
>> ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
>> Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
>> -------------------------------------------------------------------
>> "Look through the lens, and the light breaks down into many lights.
>> Turn it or move it, and a new set of arrangements appears... is it
>> a single light or many lights, lights that one must know how to
>> distinguish, recognise and appreciate? Is it one light with many
>> frames or one frame for many lights?" -Subcomandante Marcos
>> -------------------------------------------------------------------
>>
>>
=========================================================================
==
>> 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".
>
yetikiller
===========================================================================
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".
