Skip to main content

(J)Applet.start() not called by event thread - violating Swing's policy?

1 reply [Last post]
mmo18
Offline
Joined: 2008-07-20

Alas, I still have issues with my applet's screen refreshes.

As I had to learn I had a few places where I violated Swing's single thread policy and updated GUI components from threads other than the AWT event thread.

But now I just detected, that also the (J)Applet's start()-method is NOT called by the event thread. That would mean, that all GUI initialization code that I have in that method also violates that single thread policy. Or ist the start() method an exception to that rule?

The problem that I am observing is, that I have a split-pane, where one split's content gets updated depending on selections in the other split. However, when I select something, the other split either remains unchanged (even though the corresponding listener gets called and updates the component - I verified that!) or - even stranger: it get's cleared (i.e. contains no content all all).

But only when I subsequently leave the panel with the mouse or when I pull the split-pane divider, the split suddenly get's painted. Why is that update delayed and the display not fully refreshed immediately?

Again: all those refreshes work perfectly when running as a java application. Only when running as an Applet I witness these weirdoes...

Michael

Message was edited by: mmo18

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mmo18
Offline
Joined: 2008-07-20

FWIW - maybe for someone else's benefit - I am answering to my own thread:

Turned out that the reason for my severe update problems were a couple of .removeAll() method calls, that I was issuing before adding new content to those containers.

For whatever reason, these removeAll() calls sometimes took up to 40 (!) seconds and those delays must have spoiled Swing's entire screen update scheme.

I have no clue, why these updates sometimes took sooooo long (the container's contents wasn't particularly "big" nor complex and esp. why this effect hit only when the code was running as an applet inside a browser (as I wrote: there were never any issues with it, when running as application or in the applet-viewer) but after I noticed these odd delays and - trying to pinpoint the exact location eventually sandwich-ing each and every Swing-call in one of my methods with timing measurements it turned out that all the time was spent in this single method call.

Setting the containers invisible before removing their children and back visible again afterwards) immediately solved this odd and buggy behavior!

Michael