Skip to main content

Issue: JFileChooser, JColorChooser & WakeupOnElapsedFrames

13 replies [Last post]
nvaidya
Offline
Joined: 2004-08-03

With an empty Canvas, a live WakeupOnElapsedFames set to anything from 0-10000, instantiating a JColorChooser or JFileChooser takes ages. Initially, I thought it was a Swing + WinXP issue but was told by the Swing Team that it wasn't.

Profiling shows that the code blocks in JColorChooser constructor, for example. This issue affects only the instantiation of the above widgets - the rest of a fairly complex GUI is otherwise quite responsive.

A fix would definitely help since my GUI is constructed module by module lazily on user demand.

If needed, I can submit an Issue + testcase.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Florin Herinean

The human eye can detect more than 60 fps. 25 is the bare minimum and I'm
pretty sure that you don't want to have a display with 25 Hz refresh rate.
On a CRT display @ 60 Hz you still "feel" the flickering.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Dienstag, 17. August 2004 20:48
An: interest@java3d.dev.java.net
Betreff: RE: RE: [JAVA3D-INTEREST] Re: Issue: JFileChooser,
JColorChooser & WakeupOnElapsedFrames

I'm not an expert on AWT nor its synchronization mechanisms, but one reason
that you maybe seeing this with the JCC and not JButton is that JCC uses a
Dialog, which is a heavyweight AWT component (I believe). This would require
AWT to get any locks it needs to access the video card/underlying window
system.

JButton is a lightweight Swing container that can draw and update without
requiring access to the underlying window system.

I am not saying that this is definitely the case, but it would make sense.
Try instantiating and showing other heavy weight components (other
dialogs/frames) and see if you get the same delay. You may just be seeing a
heavyweight vs. lightweight difference when the system is forced to
synchronize so much.

Note that your monitor will only refresh so often, so letting J3D render as
fast as possible doesn't make sense. Setting the cycle time to 100 - 200
frames should be more than adequate and allow CPU cycles for AWT. Of course,
you can always fall back on the fact that the human eye can only see about
25 FPS! :)

-mike

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Tuesday, August 17, 2004 1:24 PM
To: interest@java3d.dev.java.net
Subject: Re: RE: [JAVA3D-INTEREST] Re: Issue: JFileChooser, JColorChooser &
WakeupOnElapsedFrames

Well, whatever you had to say about passive/non-passive behavior, I had
already mentioned them in the same thread corresponding to my link above -
the test, BTW, is called NonPassiveTest.java !

FWIW, here's the summary:

1. The problem isn't with the creation of *any* Swing widget - see the title
of this thread and my mention of a complex JTabbedPane above.

2. If AWT has an attitude toward grabbing its lock, then the attitude seem
to be directed only to JColorChooser(JCC). For example, in the testcase
completely comment out the showDialog for JCC with:
[code]
JButton button = new JButton();
[/code]

Or, if you think that showing the Dialog is what is causing the problem,
replace everything in the anonymous listener with:
[code]
JColorChooser jcc = new JColorChooser()
[/code]

With JButton, the creation is instant. With JCC as above, the creation is as
bad as before.

OK, the technical rationale I'm looking for was probably:

1. Even the construction of the no-argument JColorChooser() is much more
complex than the creation of a JTabbedPane with 20 other widgets. Possibly,
because the JCC is quite complex. But the question is: Is a default
realization of JCC created even with a no-arg constructor. My profiling
shows that JCC baulks in updateUI() called from JCC constructor I think.

2. When does the AWT lock come into play ? If the code stops in the JCC
constructor *after* clicking on a JButton, does it mean that the lock has
already been acquired By AWT ? Or, is there something deep within the
innards of JCC that still plays truant with getting the lock ?

Anyways, except for the JCC, I haven't encountered a situation with
dynamically instantiating Swing widgets on Swing's EDT. Which is why I'm
intrigued about the JCC. But rather than play around with FrameCycleTime, in
this particular case, I've found it more convenient to pre-create the JCCs.
But because the GUI start-up time is (very) crucial, the rest of the GUI is
still better instantiated dynamically.

BTW, one of the recent bugs (fixed now) about the FrameCycleTime was
actually prompted by me. Check the JDC bugbase. This had to do with my
strategy to optimize resources for CPU intensive numerics by temporarily
compromising on rendering speed by doing the following:

setMinimumFrameCycleTime(very_long_time)
do_numerically_intensive_comps
make_live_BG
setMinimumFrameCycleTime(old_default_time)

The problem, IIRC, was that the BG didn't show up immediately even after the
cycle time was reset.

--Vaidya
---
[Message sent by forum member 'NVaidya' (N. Vaidya)]

http://www.javadesktop.org/forums/thread.jspa?messageID=23212&#23212

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

aces
Offline
Joined: 2003-07-17

:D a FPS debate :D
I guess he speaks 25FPS because cinema movies uses 24 frames per second, and TV (NTSC/Pal) uses ~30FPS interlaced (first all even then all odd lines).
For games & 3D ~30 FPS is the minimun acceptable. For 3D visualization it is enought for many applications.
Video refresh at 60Hz give me big headache in a few minutes, but I can play my favorite game for hours at 30-45fps @85Hz (1024x768).

Swing & Java3D runs better on Linux. I guess this is due how the threads can works independently, with fewer wait states, and without DirectX ;).
I've found a post about slow responses on Swing GUIs :
http://forums.java.sun.com/thread.jspa?threadID=476074&messageID=2214088

Seems disabling DirectX solves it :
[b]
-Dsun.java2d.ddoffscreen=false -Dsun.java2d.d3d=false -Dsun.java2d.noddraw=true
[/b]
maybe it help you...

Florin Herinean

Actually it is a bug. The java3d renderer should have a .yield() call inside
the rendering loop to allow other threads to act even in a tight loop.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Dienstag, 17. August 2004 14:16
An: interest@java3d.dev.java.net
Betreff: RE: [JAVA3D-INTEREST] Re: Issue: JFileChooser, JColorChooser &
WakeupOnElapsedFrames

Using the test case that you posted I can confirm the problem. On WinXP,
J2SDK 1.4.2_03, J3D 1.3.2-build4 clicking the button causes a 8 - 10 second
pause before the dialog opens.

HOWEVER, you are constructing a non-passive behavior. This is causing the
renderer to run continuously, which as Kevin pointed out, requires grabbing
the AWT lock which will significantly slow down any other AWT/Swing
operation.

By adding:
u.getViewer().getView().setMinimumFrameCycleTime(1000);
the performance of the chooser is as expected. I presume that making the
behavior passive will have the same effect.

I do not believe this is a bug, but rather a performance and synchronization
issue. AWT will definitely slow down if the renderer is swapping buffers as
quickly as possible.

-mike

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Tuesday, August 17, 2004 5:05 AM
To: interest@java3d.dev.java.net
Subject: [JAVA3D-INTEREST] Re: Issue: JFileChooser, JColorChooser &
WakeupOnElapsedFrames

NO !!! if by J3D event thread you mean instantiating the JColorChooser from
the processStimulus method of a Behavior, then I don't do that. The Dialog
is created in Swing's EDT while the isolated behavior is enabled and
running.

Here is a testcase, dated May 31 2004, that I sent to the java3d-interest
forum:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0405&L=java3d-interest&P=R...
5&D=1&H=0&I=-3&O=D&T=1&m=42097

--Vaidya
---
[Message sent by forum member 'NVaidya' (N. Vaidya)]

http://www.javadesktop.org/forums/thread.jspa?messageID=23124&#23124

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

nikolai
Offline
Joined: 2003-06-10

> a live WakeupOnElapsedFames [...] instantiating a
> JColorChooser or JFileChooser takes ages.

You are not suppossed to show a dialog from the J3D event thread. That is clearly an error if you do that. You must make the Swing calls only from the AWT event thread unless you are building a GUI which is not yet live. Calls to .show() and similar must be called using

javax.swing.SwingUtilities.invokeAndWait()
or
javax.swing.SwingUtilities.invokeLater()

I'll almost bet this solves your problem, if you did not use these calls.

Regards
Nikolai

nvaidya
Offline
Joined: 2004-08-03

NO !!! if by J3D event thread you mean instantiating the JColorChooser from the processStimulus method of a Behavior, then I don't do that. The Dialog is created in Swing's EDT while the isolated behavior is enabled and running.

Here is a testcase, dated May 31 2004, that I sent to the java3d-interest forum:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0405&L=java3d-interest&P=R...

--Vaidya

Mike Pilone

Using the test case that you posted I can confirm the problem. On WinXP,
J2SDK 1.4.2_03, J3D 1.3.2-build4 clicking the button causes a 8 - 10 second
pause before the dialog opens.

HOWEVER, you are constructing a non-passive behavior. This is causing the
renderer to run continuously, which as Kevin pointed out, requires grabbing
the AWT lock which will significantly slow down any other AWT/Swing
operation.

By adding:
u.getViewer().getView().setMinimumFrameCycleTime(1000);
the performance of the chooser is as expected. I presume that making the
behavior passive will have the same effect.

I do not believe this is a bug, but rather a performance and synchronization
issue. AWT will definitely slow down if the renderer is swapping buffers as
quickly as possible.

-mike

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Tuesday, August 17, 2004 5:05 AM
To: interest@java3d.dev.java.net
Subject: [JAVA3D-INTEREST] Re: Issue: JFileChooser, JColorChooser &
WakeupOnElapsedFrames

NO !!! if by J3D event thread you mean instantiating the JColorChooser from
the processStimulus method of a Behavior, then I don't do that. The Dialog
is created in Swing's EDT while the isolated behavior is enabled and
running.

Here is a testcase, dated May 31 2004, that I sent to the java3d-interest
forum:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0405&L=java3d-interest&P=R...
5&D=1&H=0&I=-3&O=D&T=1&m=42097

--Vaidya
---
[Message sent by forum member 'NVaidya' (N. Vaidya)]

http://www.javadesktop.org/forums/thread.jspa?messageID=23124&#23124

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

nvaidya
Offline
Joined: 2004-08-03

Well, whatever you had to say about passive/non-passive behavior, I had already mentioned them in the same thread corresponding to my link above - the test, BTW, is called NonPassiveTest.java !

FWIW, here's the summary:

1. The problem isn't with the creation of *any* Swing widget - see the title of this thread and my mention of a complex JTabbedPane above.

2. If AWT has an attitude toward grabbing its lock, then the attitude seem to be directed only to JColorChooser(JCC). For example, in the testcase completely comment out the showDialog for JCC with:
[code]
JButton button = new JButton();
[/code]

Or, if you think that showing the Dialog is what is causing the problem, replace everything in the anonymous listener with:
[code]
JColorChooser jcc = new JColorChooser()
[/code]

With JButton, the creation is instant. With JCC as above, the creation is as bad as before.

OK, the technical rationale I'm looking for was probably:

1. Even the construction of the no-argument JColorChooser() is much more complex than the creation of a JTabbedPane with 20 other widgets. Possibly, because the JCC is quite complex. But the question is: Is a default realization of JCC created even with a no-arg constructor. My profiling shows that JCC baulks in updateUI() called from JCC constructor I think.

2. When does the AWT lock come into play ? If the code stops in the JCC constructor *after* clicking on a JButton, does it mean that the lock has already been acquired By AWT ? Or, is there something deep within the innards of JCC that still plays truant with getting the lock ?

Anyways, except for the JCC, I haven't encountered a situation with dynamically instantiating Swing widgets on Swing's EDT. Which is why I'm intrigued about the JCC. But rather than play around with FrameCycleTime, in this particular case, I've found it more convenient to pre-create the JCCs. But because the GUI start-up time is (very) crucial, the rest of the GUI is still better instantiated dynamically.

BTW, one of the recent bugs (fixed now) about the FrameCycleTime was actually prompted by me. Check the JDC bugbase. This had to do with my strategy to optimize resources for CPU intensive numerics by temporarily compromising on rendering speed by doing the following:

setMinimumFrameCycleTime(very_long_time)
do_numerically_intensive_comps
make_live_BG
setMinimumFrameCycleTime(old_default_time)

The problem, IIRC, was that the BG didn't show up immediately even after the cycle time was reset.

--Vaidya

Mike Pilone

I'm not an expert on AWT nor its synchronization mechanisms, but one reason
that you maybe seeing this with the JCC and not JButton is that JCC uses a
Dialog, which is a heavyweight AWT component (I believe). This would require
AWT to get any locks it needs to access the video card/underlying window
system.

JButton is a lightweight Swing container that can draw and update without
requiring access to the underlying window system.

I am not saying that this is definitely the case, but it would make sense.
Try instantiating and showing other heavy weight components (other
dialogs/frames) and see if you get the same delay. You may just be seeing a
heavyweight vs. lightweight difference when the system is forced to
synchronize so much.

Note that your monitor will only refresh so often, so letting J3D render as
fast as possible doesn't make sense. Setting the cycle time to 100 - 200
frames should be more than adequate and allow CPU cycles for AWT. Of course,
you can always fall back on the fact that the human eye can only see about
25 FPS! :)

-mike

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Tuesday, August 17, 2004 1:24 PM
To: interest@java3d.dev.java.net
Subject: Re: RE: [JAVA3D-INTEREST] Re: Issue: JFileChooser, JColorChooser &
WakeupOnElapsedFrames

Well, whatever you had to say about passive/non-passive behavior, I had
already mentioned them in the same thread corresponding to my link above -
the test, BTW, is called NonPassiveTest.java !

FWIW, here's the summary:

1. The problem isn't with the creation of *any* Swing widget - see the title
of this thread and my mention of a complex JTabbedPane above.

2. If AWT has an attitude toward grabbing its lock, then the attitude seem
to be directed only to JColorChooser(JCC). For example, in the testcase
completely comment out the showDialog for JCC with:
[code]
JButton button = new JButton();
[/code]

Or, if you think that showing the Dialog is what is causing the problem,
replace everything in the anonymous listener with:
[code]
JColorChooser jcc = new JColorChooser()
[/code]

With JButton, the creation is instant. With JCC as above, the creation is as
bad as before.

OK, the technical rationale I'm looking for was probably:

1. Even the construction of the no-argument JColorChooser() is much more
complex than the creation of a JTabbedPane with 20 other widgets. Possibly,
because the JCC is quite complex. But the question is: Is a default
realization of JCC created even with a no-arg constructor. My profiling
shows that JCC baulks in updateUI() called from JCC constructor I think.

2. When does the AWT lock come into play ? If the code stops in the JCC
constructor *after* clicking on a JButton, does it mean that the lock has
already been acquired By AWT ? Or, is there something deep within the
innards of JCC that still plays truant with getting the lock ?

Anyways, except for the JCC, I haven't encountered a situation with
dynamically instantiating Swing widgets on Swing's EDT. Which is why I'm
intrigued about the JCC. But rather than play around with FrameCycleTime, in
this particular case, I've found it more convenient to pre-create the JCCs.
But because the GUI start-up time is (very) crucial, the rest of the GUI is
still better instantiated dynamically.

BTW, one of the recent bugs (fixed now) about the FrameCycleTime was
actually prompted by me. Check the JDC bugbase. This had to do with my
strategy to optimize resources for CPU intensive numerics by temporarily
compromising on rendering speed by doing the following:

setMinimumFrameCycleTime(very_long_time)
do_numerically_intensive_comps
make_live_BG
setMinimumFrameCycleTime(old_default_time)

The problem, IIRC, was that the BG didn't show up immediately even after the
cycle time was reset.

--Vaidya
---
[Message sent by forum member 'NVaidya' (N. Vaidya)]

http://www.javadesktop.org/forums/thread.jspa?messageID=23212&#23212

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

nvaidya
Offline
Joined: 2004-08-03

Mike,

Thanks for the response.

I'm not an expert on AWT either :)!

About the Dialog issue, in the modified testcase where I'm simply setting:
[code]
JColorChooser jcc = new JColorChooser();
[/code]
there is no Dialog involved - unless, of course, even the no-arg constructor creates a default one, which I'd hope is not the case. And, even for this case there is a significant slowdown.

25 FPS ! Wow ! I'd call that sheer luxury for some of the work that I do. If you read my thread on OffScreenCanvas3D, I get 3-5 FPS. 10 FPS would be heavenly and quite decent for my application. But, even at 3 FPS, the JCC shows a slowdown (but there could be a different rationale for it).

If Kevin has to decide between investigating the JCC issue and speeding up the OffScreenCanvas3D issue, well, you know what my request would be for !

--Vaidya

bayblade
Offline
Joined: 2006-02-17

If you're just looking for a quick and dirty solution I'd reccomend trying to avoid lazy instantiation altogether for these two widgets (Bloch discusses how in Java lazy instatiation is inherently unsafe and should only be applied where there's sound reasoning and need for it; in his "Effective Java" book--more here http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)

The even dirtier (and less quick solution) would be to wrap the constructor in its own Thread (spawned from your behavior) and have it assign the widget when its done, so any blocking inside the constructor occurs out of J3D's hair.

Just a couple of thoughts :)

Matt

nvaidya
Offline
Joined: 2004-08-03

I think the cause here could be that those 2 widgets are modal. And, yes, just as I do for my JFileChooser, I also pre-create the JColorChoosers. But wouldn't want to do that for the whole GUI, because the start-up time is also a significant consideration.

Kevin Rushforth

> With an empty Canvas, a live WakeupOnElapsedFames set to anything
> from 0-10000, instantiating a JColorChooser or JFileChooser takes
> ages. Initially, I thought it was a Swing + WinXP issue but was
> told by the Swing Team that it wasn't.

Is the Canvas3D visible and not iconified? If so, it will render as fast
as possible, which for an empty scene will be in the 1000+ frames/second
range. The rendering for each frame (during the swap buffers) will grab
the global AWT lock. Maybe the JColorChooser also needs to grab that
lock. Try setting View.setMinimumCycleTime to, say 10 milliseconds,
which will limit the rendering to 100Hz.

-- Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

nvaidya
Offline
Joined: 2004-08-03

Aha ! the 1000FPS is a good point.

OK ! I'm doing the test on a low-end system to best illustrate the issue - GeForce2 MX200, 1.6GHz (sadistic am I not ?).

With an empty canvas size of ~64x64 I get 800FPS.
With a size of ~1000x800 I get about 80FPS.
The time taken to instantiate the JColorChooser is still about the same - 8-10 seconds.

In my actual app., the problem is with instantiating those 2 widgets only. For example, at runtime, I dynamically instantiate a JTabbedPane consisting of about 20 widgets (JButtons, JComboBoxes, JCheckBoxes, JSliders etc.). No, problems whatsoever in instantly instantiating the entire Pane (without JColorChoosers).

The whole problem started because I had about 16 JTabbedPanes of the above kind in my app., each with an instance of JColorChooser *initially*. And things started getting really slow everytime I tried to instantiate such a Pane. If I comment out the JColorChooser creation, everything works fine. Also, in the case of JFileChooser, if I cache it and then invoke it subsequently, then the invocations are fast (even with the behavior set to wakeup every frame).

I do increase the FrameCycleTime anytime I enable the behavior. Probably I should increase it even more.