Doug, that last bit is some very sweet information! That also explains why
queueing major scene graph changes to a WakeUpOnElaspedFrame(0) behavior has
been more consistant in its results then making the updates right in my
threads. I have this behavior called SceneUpdater that wakes up, scans a
queue of messages and executes them, after removing the oldest duplicates
(like view transforms). Now I know why that works better than updating
right in threads.
Thanks for the info. Feedback like that really helps us.
Dave Yazel
----- Original Message -----
From: Doug Gehringer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 18, 2000 8:07 PM
Subject: Re: [JAVA3D] Attribute change performance Issue.
> From Norihito Hiruma <[EMAIL PROTECTED]>
> Right now, I am trying Java3D but Java3D's attribute change performance is
> too bad.
Your program has exposed a performance problem with Java3D 1.2. If there
are
too many shapes with the same appearance the performance can suffer due to
an
n^2 algorithm. In your case there are 10,000 shapes with equivalent
appearances, so the slowdown is more severe. The problem is being
addressed,
it won't be fixed for 1.2.1 beta, but it should be fixed for the final
release
of 1.2.1.
In the meantime, you may find that the performance of smaller data sets is
much
better, due to the n^2 factor of the algorithm. On my system making the
data
set 4x smaller makes the performance more than 8x faster.
> > From: Justin Couch <[EMAIL PROTECTED]>
> > - You may be stumbling on something j3d is doing with the rendering
> > process if it is taking so long. Have you tried calling stopRender(),
> > changing all the values, and then calling startRender() again?
> Yes, I had tried this too.
> ( call stopRender() -> setDiffuseColor() -> startRender() )
> But the result didn't change, so I deleted the code.
This is another problem. When making many changes to the scene graph
outside of
a behavior there is no way for Java3D to know when you are done and Java3D
will
probably update before you are ready. Stopping/starting the renderer or
detaching/attaching the scene graph can fix the problem, but both have
unnecessary overhead. A better way is to use Behavior.postId(). The idea
is to
set up a behavior which can be triggered when the edits need to happen. The
edits happen in the processStimulus() method for the behavior. This way
Java3D
can hold off on updating the display until after processStimulus() has
returned.
See the updated Test.java for an example of this. Search for
"updateBehavior".
Doug Gehringer
Sun Microsystems
===========================================================================
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".
