Great, thanks!
-----Original Message-----
From: Doug Twilleager [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 27, 2001 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Swing and Java3d thread priority conflicts
Effectively, it is when any Java 3D object is created. We are using
a static constructor on our thread scheduler to get the default
value. To be safe, set it yourself. When you set it, it should
take effect immediately on all Java 3D threads.
Doug.
>MIME-Version: 1.0
>Subject: Re: [JAVA3D] Swing and Java3d thread priority conflicts
>To: [EMAIL PROTECTED]
>
>Thanks Doug.. another good one for the FAQ (hint Justin)
>
>Well that makes me look at things differently. And to be clear, are we
>talking the creation of the Canvas3d, universe, or any Node? Its possible
>that I am setting the priority in the wrong place, as I think that method
is
>in the universe. So if I create my universe after I create some other
>java3d object, will the set thread priority have no effect? I tried
>changing the thread priority after the view was running and canvas was
>displaying, but it just hung the system.
>
>Dave Yazel
>
>-----Original Message-----
>From: Doug Twilleager [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, February 27, 2001 1:56 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] Swing and Java3d thread priority conflicts
>
>
>The default thread priority for all Java 3D threads is the priority
>of the thread which "started Java 3D". What this means in reality, is
>that the priority is taken from the thread which creates the first Java 3D
>object. What you are probably seeing is different behavior based upon
>which of your threads creates the first Java 3D object. To get consistent
>results, use VirtualUniverse.get/setJ3DThreadPriority().
>
>Doug Twilleager
>Sun Microsystems
>
>
>>MIME-Version: 1.0
>>Subject: [JAVA3D] Swing and Java3d thread priority conflicts
>>To: [EMAIL PROTECTED]
>>
>>I have been recently encountering a problem in our application. Under
>>certain conditions, the java3d threads "starve" the swing threads to the
>>point where swing windows and components become sluggish to the point of
>>uselessness. When we enter our program through one mechanism we do not
get
>>this problem, but when we do it through another, we do. I know that
sounds
>>cryptic, but I can't for the life of me pin-point the actual differences.
>I
>>do know that changing the java3d thread priority (using the java3d method)
>>to NORMAL solves the problem, but of course impacts framerates.
>>
>>I am going to throw out some information surrounding the condition and
>maybe
>>someone will see something:
>>
>>1) Create main JWindow, give it a default size. This is where the
canvas3d
>>will go.
>>2) Make it visible. Note that not making it visible causes the problem
100
>>percent of the time as opposed to some of the time.
>>3) Create a second JWindow called "login" using the main as owner.
>>4) make login visible
>>5) push a button on login window
>>6) launch a thread that does all sorts of initialization
>>7) when initialization complete, the thread uses
SwingUtilities.invokeLater
>>to make the login window invisible, attach the canvas3d to the main
window,
>>and make 3 or more new child windows (owned by main) also visible.
>>
>>The problem seems to have something to do with which window is the first
>>window to process awt/swing events. If I never make the main window
>>visible, then the login window is guarenteed to be the first one
processing
>>swing events. I have tried all sorts of tricks to try to solve this, but
>>since I can't figure out what the issue is, I can't seem to find the right
>>solution. So if I run the program, skipping the login screen and doing
>>everything else exactly the same, cept the login paramaters are passed via
>>the command line, I don't get this problem at all.
>>
>>Any suggestions? I would prefer to leave the java3d threads at their
>normal
>>high priority since that makes them less sensitive to cpu intensive
>activity
>>my own threads do. My procedural texture code kills the frame rates if I
>>run the java3d threads at NORMAL instead of MAX.
>>
>>Dave Yazel
>>Cosm Development Team
>>
>>==========================================================================
=
>>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".
>
>===========================================================================
>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".
===========================================================================
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".
