Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / February 2005

Tip: Looking for answers? Try searching our database.

Flickering as paint continually recalled due to setFont call

Thread view: 
mflll@wiu.edu - 28 Feb 2005 04:25 GMT
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.

As indicated by my debugging, the paint method of my class inheriting
from JFrame is continually called.

My Java version on Windows is JAVA version "1.4.2_05"

My Java version on Linux using VNC is 1.5.0_01 although I also tested
on earlier versions of Java on Linux and it did not flicker on those
versions.

Note, the application does not interact with the user--it just displays
some straightforward graphics.

Dr. Laurence Leff  Western Illinois University, Macomb IL 61455 ||(309)
298-1315
Stipes 447 Assoc. Prof. of Computer Sci. Pager: 309-367-0787 FAX:
309-298-2302
Secretary: eContracts Technical Committee OASIS Legal XML Member
Section
_________________________________________________________________

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.io.*;

public class GR {
 static PrintWriter debug;
 static class MyFrame extends JFrame {
   public void paint (Graphics g) {
     super.paint(g);
     debug.println ("paint");debug.flush();
     /*g.setColor ( new Color(0,0,255));*/
     setFont (new Font ("SansSerif",Font.BOLD, 28));
     g.drawString ("BlueRectangle",50,100);
   }
 }

 static MyFrame frame;

 public static void main (String[] args) throws IOException {
    frame = new MyFrame ();
      Dimension Size = new Dimension (400,200);
    debug = new PrintWriter (new FileOutputStream ("debug.out"));

    frame.setSize(Size);
    frame.setVisible(true);
    frame.pack();
 }
}
Thomas Weidenfeller - 28 Feb 2005 09:37 GMT
> 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



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.