> The Windows implementation of the Java virtual machine is causing my
> application
> to flicker and continually repaint the screen. From elimination, I
> found
> the problem to be the setFont call. After I boil down my problem,
> I have the following sample application which flickers uncontrollably.
Constantly? That is interesting. In fact, there are a couple of
interesting things to observer, however, non might be the reason for
your problem. Especially because I didn't run the program on Windows.
> My Java version on Windows is JAVA version "1.4.2_05"
I tried it with 1.5 on Solaris, and there the string is not painted. In
fact, the paint() method is not called.
I went back to 1.4.2 on Solaris. There it worked, and I couldn't
observer any continuous flickering. Just the normal flickering of
multiple repaints.
A couple of observations:
It is really not a good idea to override JFrame.paint(). Instead,
consider to use a JPanel and override paintComponent(). Sun apparently
has changed the JFrame 1.5 implementation for Solaris and there is
either a new bug or feature with the way JFrame paints.
> static class MyFrame extends JFrame {
> public void paint (Graphics g) {
> super.paint(g);
JFrame is a heavyweight, so this clears the drawing ares. This might be
the start of your flickering problems. You clear the screen here, and
then it takes a while to create the new font object and draw the new string.
> debug.println ("paint");debug.flush();
This delays the actual painting even more.
> /*g.setColor ( new Color(0,0,255));*/
I of course did uncomment this.
> setFont (new Font ("SansSerif",Font.BOLD, 28));
(a) You set the font on the wrong object! you should set it on the
Graphics g object, not the JFrame component. The g's font is initialized
from the JFrames font, so you will only see your font change the second
time your paint() method is called. In fact, when I removed the previous
super.paint() from your program, I could clearly observe this.
The following is highly speculative, but because you change a property
of JFrame with that wrong setFont() call, the windows implementation of
JFrame's peer might find it necessary to repaint the whole JFrame, so it
triggers a (re)paint(). So every execution of paint() triggers another
paint(). The Linux JFrame's peer might not care about the font change
until some other time, and might not trigger a new paint().
(b) Constructing the new Font object might take a lot of time, depending
on how the VM manages fonts. This is VM implementation-dependent, so
might well explain the difference between windows and Linux behavior.
And, if it takes some time, it might delay the painting of the string
even more.
> frame.setSize(Size);
> frame.setVisible(true);
> frame.pack();
(a) If you set a fixed size, you should not use pack(), but just
validate() instead.
(b) you should pack() or validate() before you call setVisible(true),
not after.
/Thomas

Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq