Skip to main content

Swing unusable inside applets?

7 replies [Last post]
mmo18
Offline
Joined: 2008-07-20
Points: 0

This Swing refresh business is getting totally out of hand!

As I already described in thread http://forums.java.net/jive/thread.jspa?threadID=74483&tstart=0 I have a java applet that does not get painted initially.
I always need to first click into the gray area to get the screen updated and see the applet's content.

And now things start getting worse and worse! Among other elements the applet has two Swing JSplitPanes and now their contents does not get refreshed any more until I slightly move the separating slider.
In an experimental version I added repaints() all over the place but these seem to have absolutely no effect! Why does Swing not properly repaint updated JPanels?

And what's most annoying: this "Swing update-refusal" is only happening when running as a real applet inside a browser (I tested with IE8 and FF3.5). When running my program as application or testing it in AppletViewer then things are always working perfectly!

What could cause this? Is there some thread in AWT/Swing that can hang or somehow be blocked or what is the reason that applets don't properly refresh???
No wonder the entire world goes Flash and AJAX and what not just to avoid this Applet refresh craze!

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.
flar
Offline
Joined: 2003-06-10
Points: 0

Overriding paint just to do a println() should be safe as long as you delegate back to super.

I would point out that you probably need to do the same with update() if you want to track all calls to the painting code. paint() is called when there is screen damage from another source (like the window becoming visible on the screen or dragging another window over it), but update() is called in response to calls to repaint() so if you don't override update() then you may miss a lot of Swing's repainting work.

If you read the first article I pointed out then you can get a better idea of how Swing uses both paint() and update() in its paint cycles.

mmo18
Offline
Joined: 2008-07-20
Points: 0

Seems I have to take that on my back! I violated the Swing single thread policy. I had thought, that I had fully obeyed that rule, but had missed a case where via a listener I created Swing calls that did not originate from the AWT event thread and obviously those "bad" calls were the culprit.

Thanks to AspectJ which made it simple to finally pinpoint these errors!

M.

flar
Offline
Joined: 2003-06-10
Points: 0

First, I wanted to ask a quick question. Your other thread talks a lot about the paint() method - but Swing applications should avoid that method. If you override it or call it then you will seriously disrupt Swing's painting mechanisms. You should be focusing on paintComponent() instead and leave paint() and update() alone.

Here are some additional useful resources:

An article on debugging painting problems:

http://java.sun.com/docs/books/tutorial/uiswing/painting/problems.html

An article on the paint/update architecture of AWT and Swing:

http://java.sun.com/products/jfc/tsc/articles/painting/

(Note that the second article goes over the AWT model first which talks a lot about paint()/update() but if you are writing a Swing application then you want to treat that as "background information" and focus instead on the Swing section of the article which will tell you to use paintComponent(). Unfortunately the article was written a long time ago and fails to stress the need to avoid paint() and update() in Swing applications as much as it should...)

mmo18
Offline
Joined: 2008-07-20
Points: 0

> First, I wanted to ask a quick question. Your other
> thread talks a lot about the paint() method - but
> Swing applications should avoid that method. If you
> override it or call it then you will seriously
> disrupt Swing's painting mechanisms. You should be
> focusing on paintComponent() instead and leave
> paint() and update() alone.

I only had overwritten paint(...) of a few components to add a System.out.println() and then forwarded to super.paint(...). This was just to figure out, if and when paint(...) gets called. Functionality-wise I didn't fiddle with that at all.

> Here are some additional useful resources:

Thanks! I will work through them and see what may be applicable to my problem.

M.

Message was edited by: mmo18

claudeabb
Offline
Joined: 2006-08-09
Points: 0

Hi,

Do you use any api such as JXTransform or other thinks like that which handle the elements displaying and which may responsible of this issue?

I have rencently made some tests with an application I have modified to work as an applet. This one uses some swing components such as JScrollpane, JCombobox, JList, JTable without having noticed any problem.
All the elements appear immediately without needing to click on the applet.
All the refreshing work well too.

The java version I have is also the 1.16.017

Have you a link which could allows to test your applet, maybe the issue is due to a computer configuration issue.

Claude

claudeabb
Offline
Joined: 2006-08-09
Points: 0

Hi,

Strange that you have encountered such issues.
I had already noticed some artefact issues but that was due to the using of Applet class rather than JAPPLET.

Have you already tried to use java web start rather the applet approach?

The fact that you have to click on the applet the first time to make its content visible is maybe due to a security rules matter.
Have you already tried to use certificate within your applet?

Could you show us some part of your lines code especially concerning the first initialization steps?

By the way the main element root such as JPanel, JSlider , etc. has to be added by the method this.getContentPane().add(....)

Regards

Claude

mmo18
Offline
Joined: 2008-07-20
Points: 0

Hi Claude,
thanks giving a few hints.

> I had already noticed some artefact issues but that
> was due to the using of Applet class rather than
> JAPPLET.

I *am* indeed using a JApplet. I used "Applet" only as generic term.

> Have you already tried to use java web start rather
> the applet approach?

Alas that's not an option in my case. The app should run in any, unmodified browser (that has a somewhat new Java installed as only req').

> The fact that you have to click on the applet the
> first time to make its content visible is maybe due
> to a security rules matter.
> Have you already tried to use certificate within your
> applet?

The applet IS signed, i.e. it comes with a valid certificate.

> By the way the main element root such as JPanel,
> JSlider , etc. has to be added by the method
> this.getContentPane().add(....)

According to the Javadocs that's redirected automatically (i.e. JApplet overrides add() and forwards .add(...) to .getContentPane().add(...).

Michael