Java & Double Buffering

[rock]

I just wrote an Applet for a client, but whenever you move a slider, and the main canvas updates, it's flashy -- and they don't like that.

I know what I need is Double Buffering, and I read that Swing will do this for you.

Great, so I convert the whole Applet to a JApplet, using Swing components everywhere. Then, all my JPanels are created like:
paneltop = new javax.swing.JPanel(true);
where the boolean in the constructor sets "isDoubleBuffered".

My main panel actually extends JPanel, but I was sure to include this constructor, and I call it the same way:
public JJPanel(boolean isDoubleBuffered) {
super(isDoubleBuffered);
}

I must be missing something, because it's still flashing. Any ideas?

[Grizzly]

My Java's a little weak, as in I've only been studying it for 3 weeks...but one thing I question is if your variable "paneltop" in your example is actually being instantiated through your childclass "JJPanel".

When I see your instantiation statement:
paneltop = new javax.swing.JPanel(true);

I think...paneltop is a new variable of the Jpanel class, but makes no mention of your subclass "JJPanel", and therefore never executes your JJPanel single param constructor.

Shouldn't you be instantiating this variable as:
JJPanel paneltop = new javax.swing.JPanel(true);

??
I could be way off target here...if so, please ignore me, and good luck with it buddy http://www.sharkyforums.com/ubb/biggrin.gif

[rock]

Sorry for the confusion, but I was trying to cover all the bases. Above, "paneltop" is a JPanel. My subclass constructor was just included to indicate that I'm also extending JPanel in what I think is a correct way.

Thus, more explicitly, I have code like:

paneltop = new javax.swing.JPanel(true);
panel2 = new JJPanel(true);

[bryce777]

What do you have that is flashing?

Swing components or an image?



------------------
system specs:
Voodoo 5 5500 agp
tyan 1834d tiger 133 dual 800eb 133mhz FSB
via chipset 133 via apollo pro (don't make this mistake)
256 MB RAM
2 maxtor 60gig ata100 drives
promise ata100 controller
liteon 52 truex cdrom
Linksys ethernet 10/100
Soundblaster Live! (what's so exciting about it??) value edition
300watt power supply (inwin)
about 7 pounds of fans (I'm not kidding)
Suse 7.1(god gnome is crappy compared to CDE)/win2000 based system

[rock]

Well, it's an Object that has a paint() method. The object does contain an Image object, and that's what's flashing.

I can't be too specific for a couple reasons: 1) this is a new, unreleased product with a price point about an order of magnitude higher than what I bring home every month. And 2) I'm too scrupulous to turn this into an advertisement.

UPDATE:
I've split things up so I now have a create() method and an update() method. The create() does all the hard work once, then the update() does much less work. Without create a new Object each time now, the overall flashing is gone! Yeah! Kind of... Now it's still slow to respond.

I put prints at the start and end of each method, and when I click a JScrollBar, the stdout flashes along and all the prints show up immediately. Then, the panel is redrawn -- so I can't track down what's taking so long... Argh.

[This message has been edited by rock (edited September 21, 2001).]

[bryce777]

Ok. The reason I asked is that the double buffering will control the components but not its contents.

If you have an image you need to basically draw to a background image, then draw that image to the screen. You also have to change the paint and update methods but it looks like you have a handle on that.

Originally posted by rock:
Well, it's an Object that has a paint() method. The object does contain an Image object, and that's what's flashing.

I can't be too specific for a couple reasons: 1) this is a new, unreleased product with a price point about an order of magnitude higher than what I bring home every month. And 2) I'm too scrupulous to turn this into an advertisement.

UPDATE:
I've split things up so I now have a create() method and an update() method. The create() does all the hard work once, then the update() does much less work. Without create a new Object each time now, the overall flashing is gone! Yeah! Kind of... Now it's still slow to respond.

I put prints at the start and end of each method, and when I click a JScrollBar, the stdout flashes along and all the prints show up immediately. Then, the panel is redrawn -- so I can't track down what's taking so long... Argh.

[This message has been edited by rock (edited September 21, 2001).]



------------------
system specs:
Voodoo 5 5500 agp
tyan 1834d tiger 133 dual 800eb 133mhz FSB
via chipset 133 via apollo pro (don't make this mistake)
256 MB RAM
2 maxtor 60gig ata100 drives
promise ata100 controller
liteon 52 truex cdrom
Linksys ethernet 10/100
Soundblaster Live! (what's so exciting about it??) value edition
300watt power supply (inwin)
about 7 pounds of fans (I'm not kidding)
Suse 7.1(god gnome is crappy compared to CDE)/win2000 based system

[rock]

Thanks - I guess my want for double-buffering to work was grabbing the low apple.

I've done some more investigation into the source code, adding prints and trying to gauge where time is spent -- and the slow part is redrawing the Background object. It just does a rectangular fill like this:

int screenViewport[] = getScreenViewport();
draw.startFill();
draw.fillRectangle(screenViewport[0], screenViewport[2],
screenViewport[1]-screenViewport[0]+1,
screenViewport[3]-screenViewport[2]+1);
draw.endFill();

Anyone have an idea why this is so darn slow?

[bryce777]

the point of having double buffering, besides eliminated flashes is so you don't have to draw and redraw all the time.

Draw that part once into a seperate image, and copy the image onto the working image, then do any other drawing on that image. This way you can draw things using native code instead of interpreted code.

That make sense?

One image for drawing on, one for display, n that have the objects you are drawing onto it.

The only time you need to break this is when you are doing transformations like rotation or shearing to the object too.

Originally posted by rock:
Thanks - I guess my want for double-buffering to work was grabbing the low apple.

I've done some more investigation into the source code, adding prints and trying to gauge where time is spent -- and the slow part is redrawing the Background object. It just does a rectangular fill like this:

int screenViewport[] = getScreenViewport();
draw.startFill();
draw.fillRectangle(screenViewport[0], screenViewport[2],
screenViewport[1]-screenViewport[0]+1,
screenViewport[3]-screenViewport[2]+1);
draw.endFill();

Anyone have an idea why this is so darn slow?



------------------
system specs:
Voodoo 5 5500 agp
tyan 1834d tiger 133 dual 800eb 133mhz FSB
via chipset 133 via apollo pro (don't make this mistake)
256 MB RAM
2 maxtor 60gig ata100 drives
promise ata100 controller
liteon 52 truex cdrom
Linksys ethernet 10/100
Soundblaster Live! (what's so exciting about it??) value edition
300watt power supply (inwin)
about 7 pounds of fans (I'm not kidding)
Suse 7.1(god gnome is crappy compared to CDE)/win2000 based system

[Barracuda]

I am not 100% sure that this works in an Applet, though it does work with Swing. If you are extending JApplet instead of Applet then it will work. Have never tried this with an Applet as I've never done a lot of work with them.

Add this method to your class that extends Applet or JApplet to override the built in method (which returns false):


public boolean isDoubleBuffered()
{
return true;
}

[rock]

Barracuda, I'm not too sure what that code would do. I've implemented the double buffering in my extended JPanel by adding the appropriate constructors as shown in my original post:

public JJPanel(boolean isDoubleBuffered) {
super(isDoubleBuffered);
}

Anyway, after further investigations of the code, I've got the speed to be reasonable as long as I don't set a background color. This way, as a user slides a slider, the image is updated at a decent rate. If I try to include a background, its paint method takes long enough the the image updates get too choppy. This happens whether or not DoubleBuffering is enabled.