Dave,
For what it's worth, my application originally used several separate JFrames
(two contained Canvas3D's and the others contained Swing components).
WindowsNT and Windows98 OS were so terrible at managing the update of the
various windows (multiple flashings, unnecessary updates, very sluggish
performance) that I finally created one single JFrame to act as a virtual
desktop into which I put the other frames (re-implemented as JPanels). This
improved performance immensely.
Raffi
-----Original Message-----
From: Yazel, David J. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 9:53 AM
To: [EMAIL PROTECTED]
Subject: [JAVA3D] Swing and Java3d thread priority conflicts
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".
