0

I'm working on a simple drawing program where the user draws lines on the screen using the mouse.

When running the program, it eventually gets very 'laggy' when the drawing area gets filled with more and more lines.

I asked about it in SO and also done some research on Google. I understood that 'double buffering' might be the way to go to solve my problem.

I would like to explain my program, explain my idea of implementing double buffering in this program, and then ask two questions.

My program:

The program runs in an update loop that runs 25 times per second.

Each update cycle, the program checks if the mouse is pressed or not.

If it is pressed: A new Line object is created, composed of the point where the mouse was at the last update-cycle, and the point where the mouse is at the current update cycle. This very short Line is added to a List named lines.

Every update-cycle the drawing area (a JPanel) is repainted. Every repaint, it draws everything inside lines.

The fact that the more the user has drawn, the more the program has to display every update-cycle, is what causes the lagging.

How I'm thinking of implementing double buffering:

Instead of drawing all of the lines each update-cycle, I will do this:

Each update loop, I will paint only the new lines created by the user this update cycle - to a BufferedImage.

Every update-cycle, the drawing area will repaint, but will only display this BufferedImage.

My questions:

  1. Is this considered 'double buffering'?

  2. Will I also need to repaint the BufferedImage every update cycle? If the answer is 'yes', than this cancels the entire point of the double-buffering in this case - which is to spare the program constantly drawing each object in a large list.

Thanks

Aviv Cohn
  • 15,543
  • 25
  • 68
  • 131
  • That sounds like a very reasonable approach, and yes, blitting the buffer containing previously drawn lines should be faster than redrawing them, or at least, more consistently fast and independent of the number of lines. – Ben Voigt Feb 16 '14 at 18:02
  • @BenVoigt Thanks for your comment. So that means that it **will** be necessary to call `repaint()` on the `BufferedImage` every update-step - in order to add new lines to it? If so, than the only way of doing that is **constantly drawing the *entire* list of lines to the BufferedImage**, which is exactly what I'm trying to avoid, since at least with a JPanel it causes lags. – Aviv Cohn Feb 16 '14 at 18:07
  • No, you'll have the result of drawing all prior lines rendered as a bitmap. Blitting a bitmap depends on its size, but not on the complexity of the data used to generate it. And you can render more lines on top without needed to regenerate the old ones. – Ben Voigt Feb 16 '14 at 18:10
  • Using the BufferedImage is double buffering, but double buffering isn't necessary to implement incremental drawing. The key is not clearing the image before drawing new lines. Most likely you'll only need to actually redraw all lines when the window dimensions change. – Ben Voigt Feb 16 '14 at 18:11
  • @BenVoigt Okay, please say if I understand correctly: When drawing new things to a **`JPanel`**: In order for it to display it's new graphic content it has to get **repainted**. But - when drawing new things to a **`BufferedImage`**: It is **unnecessary to repaint** it in order for it to display it's new content. True? – Aviv Cohn Feb 16 '14 at 18:18
  • That is true in general. I'm not sure exactly what function calls your Java classes provide to accomplish it. – Ben Voigt Feb 16 '14 at 18:23
  • @BenVoigt Could you give me an example of when a `BufferedImage` will display it's new graphic content without calling repaint(), and when it won't? – Aviv Cohn Feb 16 '14 at 18:27

0 Answers0