My 2D code runs so impossibly slow...

Java 2D
#1

Here it is:



[imports...]

public class Main extends JApplet implements Runnable
{
    
    Random R = new Random();
    Image img;
    BufferedImage back;
    
    public void paint(Graphics g)
    {
        int height = this.getSize().height;
        int width = this.getSize().width;
        Graphics2D g2d = (Graphics2D) g;
        back = (BufferedImage) createImage(width, height);
        Graphics2D back2d = (Graphics2D) back.getGraphics();
        back2d.fillRect(0, 0, width, height);
        for(int i = 0; i < 100; i++)
             back2d.drawImage(img, R.nextInt(width), R.nextInt(height), null);
        g2d.drawImage(back, 0, 0, null);
    }
    
    public void init()
    {
        try 
        {
            img = ImageIO.read(new URL(getCodeBase(), "ff.png"));
            Thread t = new Thread(this);
            t.start();
        } 
        catch (MalformedURLException ex) 
        {
            ex.printStackTrace();
        } 
        catch (IOException ex) 
        {
            ex.printStackTrace();
        }
    }
    
    public void run()
    {
        while(true)
        {
            repaint();
            try {
                Thread.sleep(10);
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
        }
    }
    
}

Any reason why?

#2

because you create a brand new image on each frame…


back = (BufferedImage) createImage(width, height);

you only need to create the back image once

#3

Will that result in a noticeable speed improvement?

Anyway, the reason I do it each frame is because I am putting this in an applet, wherein the browser might be resized. Is that the main slowdown, though?

Rye

#4

Try it out. :slight_smile:

Get your hands on a profiler. It will save you a lot of try and error. It might be a bit difficult to get used to it at first, but its worth the time.

#5

1.) Rendering to a BufferedImage means Software-Rendering
2.) Painting a BufferedImage you’ve just recently painted to means RAM->VRAM copying which is slow.
3.) Allocating a BufferedImage each paint will preassure the Garbage-Collector a lot.

I don’t know what you want to archive, but if you would like to double-buffer better use BufferStrategy.

lg Clemens

#6

[…]the reason I do it each frame is because I am putting this in an applet, wherein the browser might be resized.

Store width and height and only recreate then buffer if there was a change. This makes lots of sense and it will greatly improve things, because resizing happens rarely.

However, with percentages it won’t work with the appletviewer anymore. Also if you don’t intend to properly cope with different dimensions, you shouldn’t do that. The vast majority of applets use a fixed size.

I would use a fixed size and BufferStrategy. I also wouldn’t start with Applets, because they are somewhat annoying to do. It’s certainly nicer to do a stand-alone application and wrapping it up. That means that you get some kind of hybrid with 2 entry points.

#7

Just try to use the MediaTracker, because it allows you to safely control loading while you intend to paint the image. Som’thin like this: (but please give attention to scaling sizes! c.f. Java Documentation))