swing - Weird bug involving background images in java -

my problem when run program white screen , text earlier build instead of background image that's suppose displayed. i've deleted code associated build.

i've looked around , threads i've seen write code how i've set up. don't understand displayed background coming from.

here relivent code:

package tactics;  import java.awt.*; import java.awt.image.bufferedimage; import java.io.ioexception; import javax.swing.jframe;  public class tactics2 extends jframe{     private screen s;     private bufferedimage bg;     private bufferedimage template;     private boolean loaded = false;      public static void main(string[] args) throws ioexception{           displaymode dm = new displaymode(1024, 768, 16, displaymode.refresh_rate_unknown);         tactics2 t = new tactics2();         t.run(dm);     }      //run method     public void run(displaymode dm) throws ioexception{         loadpics();          s = new screen();          try{             s.setfullscreen(dm, this);             try{                 thread.sleep(5000);             }catch(interruptedexception ex){}         }finally{             s.restorescreen();         }     }      public void loadpics() throws ioexception{         bg = new bufferedimage(1024, 768, bufferedimage.type_int_rgb);         template = new bufferedimage(1024, 768, bufferedimage.type_int_rgb);         chaosback cb = new chaosback();         bg = cb.chaosback(bg, template);         loaded = true;         repaint();     }      @override     public void paint(graphics g){         if(loaded){             g.drawimage(bg, 0, 0, null);         }     } } 

you've broken paint chain

@override public void paint(graphics g){     if(loaded){         g.drawimage(bg, 0, 0, null);     } } 

basically, you've failed call super.paint. graphics shared resource, is, painted given paint cycle uses same graphics context.

part of job of paint chain prepare painting clearing graphics context.

you should avoid overriding paint of top level container number reasons. it's not double buffered, may flicker it's updated , doesn't take consideration frame decorations, meaning can end painting underneath borders of frame, instead within viewable area.

you'd better of creating custom component, extending jpanel , overriding it's paintcomponent method (making sure call super.paintcomponent)

thread.sleep(5000); bad idea within swing application. it's possible stop application cold , stop been updated/painted or respond user interaction.

swing not thread safe. means changes ui must made within context of event dispatching thread.

take at:

• performing custom painting
• painting in awt , swing
• concurrency in swing
• initial threads
• how use swing timers

for details , ideas