Develop Reference

Java JFrame Graphics Update

I am playing around with graphics in Java using JFrames and am trying to completely understand when Graphics changes actually occur.
Let's say I have a timer running every second, and every second the graphics change. The tick method, for example, will run every second...
public void tick(Graphics g) {
g.fillRect(0,0,10,10);
//Do Some Computations
g.fillRect(0,0,someComputedWidth,someComputedHeight);
}
Are the graphics instantly updated on the computers display? When the first fillRect method is called, is that rectangle instantly created?
I want to be able to draw all my graphics, and then make them have their effect at the same exact time. I want the tick method to buffer all updates, and then execute them all at once. How do I accomplish this?

To buffer your updates you can use BufferedImage:
#Override
public void paintComponent(Graphics g){
BufferedImage image = new BufferedImage(this.size.width, this.size.height, BufferedImage.TYPE_INT_RGB);
Graphics bgr = image.getGraphics();
for(Tile t : this.tiles){
t.draw(bgr);
}
super(bgr);
g.drawImage(image, 0, 0, null);
bgr.dispose();
image = null;
}
I used this method in one of my school projects. It draws to an off-screen image and then draws the image to display.
With few drawable objects being drawn, and no, or little animation, updating directly to the display does not always have noticable effects, however with more complex tasks the image "flickers" and double buffering is a perfect cure for that.

Double Buffering in Java

I found this code of double buffering on internet but it has no explaination. I am a little confused in this code.
Why is the Image "i" used? What is its use if it is to be used once?
Why are we assigning changing color to Foreground color,when we already have set color?
What is g.drawImage() method doing?
Here is the code:
public void update(Graphics g)
{
if(i==null)
{
i=createImage(getWidth(), getHeight());
graph=i.getGraphics();
}
graph.setColor(getBackground());
graph.fillRect(0, 0, getWidth(),getHeight());
graph.setColor(getForeground());
paint(graph);
g.drawImage(i,0,0,this);
}
Regards

The basic idea of Double Buffering is to create the image off screen then display it all at once.
From the java tutorials found here
The code you have there first creates an image on first way through to be your "Back Buffer" with this bit, i is likely a field such as
private Image i;
private Graphics graph;
if(i==null)
{
i=createImage(getWidth(), getHeight());
graph=i.getGraphics();
}
Then Paints the background color onto the image with this
graph.setColor(getBackground());
graph.fillRect(0, 0, getWidth(),getHeight());
Then sets the front ready for drawing.
graph.setColor(getForeground());
paint(graph); /draws
Finally drawing the back Buffer over to the primary surface.
g.drawImage(i,0,0,this);

The graphics operations are all performed on a Graphics obtained from i, which is a bitmap in memory.
When they're finished, the bitmap is drawn onto the "real" (screen) Graphics object g. So the user will never see half-finished drawing, which eliminates flicker.
The field i is allocated the first time and then reused, so it is not only used once.

Low fps in low computation java paintcomponent

I am making a game where for the purpose of this question i have a a class that extends JFrame that adds a class that extends JPanel(GamePanel). in GamePanel i have a run method that has two functions update(); and repaint(); and then a Thread.sleep(20). The update function takes about 1-2ms. I have all my drawing stuff in paintComponent(Graphics g) which seems to correctly get called when i use repaint() since stuff shows up on screen.
My problem is that it is increeedibly laggy. When i didn't have Thread.sleep(20) it was unplayable with like 2fps. I read that this was because repaint() wasnt given enough time to finish or something so i added a delay before next loop. anything above or under 20ms seems to make it more laggy.
I've tried using graphics configuration stuff, double buffering and more but it stays laggy. On my home pc, which is an intel i5, quad core, 3.2GHz i'm only getting around 100fps, and on a school computer i get around 15fps (ok pc, like amd dual core i believe). The paintComponent loop is Super lightweight! just drawmap with offset depending on player position, then draw player in middle of screen! I am using a map that is 2000x2000, 0.8mb. Tried switching to 1000x1000 0.4mb and no difference.
Here is the code:
#Override
public void paintComponent(Graphics g) {
//Rendering settings and stuff
super.paintComponent(g);
Graphics2D g2d = (Graphics2D) g;
g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON);
//Draw map gameMap.gameMap is a bufferedImage
g2d.drawImage(gameMap.gameMap, gameMap.x, gameMap.y, null);
//Draw health bar
g2d.setColor(healthBarColor);
g2d.setComposite(alphaHealthBarBackground);
g2d.fillRect(100, 19, 200, 23);
g2d.setFont(font);
g2d.setComposite(alphaNormal);
g2d.setColor(healthBarColor);
g2d.drawString("HP: ", 20, 40);
g2d.fillRect(100, 19, player.health * 2, 23);
//Draw player player.playerImage is a BufferedImage
rotatePlayer.setToRotation(rotation, rotationAnchor.x, rotationAnchor.y);
rotatePlayer.translate(xResolution / 2, yResolution / 2);
g2d.drawImage(player.playerImage, rotatePlayer, this);
g2d.setColor(Color.white);
}
This results in 100fps on relatively awesome computer and 15fps on descent computer!

Not pretending to be ultimate solution, just some tips:
Make sure your buffered images are have same color model as default of GraphicsDevice on which they drawn. The method GraphicsConfiguration.createCompatibleImage could create such images.
If it is possible, try to split whole huge map to tiles and skip rendering off-screen (out of game view) parts.
It seems you use passive rendering, as you mentioned calling of repaint(). Event Dispatch Thread used for many things in Swing and AWT, and it can't guarantee acceptable timing for actively rendered games. Maybe it worth to redesign rendering part of game to use Active Rendering. Tutorial and example can be found here.

Well, for game development I donot think drawing a huge image in a Swing paintComponent is ever going to win any speed records. 100 FPS is still amazing (and about 40 FPS more than the refresh rate of most LCD displays).
For more speed it is essential that the drawing primitives you are using are accelerated. On your school PC's they may simply lack a decent graphics card that provides the 2D acceleration needed (how do these PC's feel doing normal 2D operations in say browsers and paint programs?)
You may want to look into a framework that uses OpenGL instead, like JOGL. Another option is to try out JavaFX 2 -- it may have a better rendering pipeline.

I am also developing a Java game and have done many things the same as you (extending JPanel and calling repaint()). One difference is that I am using a javax.swing.Timer to call an ActionPerformed(ActionEvent e) method to update my game every 5ms. At the end of the method it calls repaint() to do the rendering.
Also if you are using Graphics2D to do your rendering you can use RenderingHints to guide the computer on how you want your game to be rendered (Eg, speed or quality, stuff like that).
I haven't measured the FPS exactly but I get no lag on my Ubuntu 12.10 system and JUST a bit slower on Windows 8.
I apologize if my response isn't exactly what you wanted but this is what has worked for me so far without problems.

How can you produce sharp paint results when rotating a BufferedImage?

One attempted approach was to use TexturePaint and g.fillRect() to paint the image. This however requires you to create a new TexturePaint and Rectangle2D object each time you paint an image, which isn't ideal - and doesn't help anyway.
When I use g.drawImage(BufferedImage,...), the rotated images appear to be blurred/soft.
I'm familiar with RenderingHints and double-buffering (which is what I'm doing, I think), I just find it difficult to believe that you can't easily and efficiently rotate an image in Java that produces sharp results.
Code for using TexturePaint looks something like this.
Grahics2D g2d = (Graphics2D)g;
g2d.setPaint(new TexturePaint(bufferedImage, new Rectangle2D.Float(0,0,50,50)));
g2d.fillRect(0,0,50,50);
I'm using AffineTransform to rotate a hand of cards into a fan.
What would be the best approach to paint good-looking images quickly?
Here is a screenshot:
The 9 is crisp but the rest of the cards are definitely not as sharp.
It could be possible that the problem lies in when I create each card image and store it in an array.
Here's how I'm doing it at the moment:
// i from 0 to 52, card codes.
...
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice gs = ge.getDefaultScreenDevice();
GraphicsConfiguration gc = gs.getDefaultConfiguration();
BufferedImage img = gc.createCompatibleImage(86, 126, Transparency.TRANSLUCENT);
Graphics2D g = img.createGraphics();
setRenderingHints(g);
g.drawImage(shadow, 0, 0, 86, 126, null);
g.drawImage(white, 3, 3, 80, 120, null);
g.drawImage(suit, 3, 3, 80, 120, null);
g.drawImage(value, 3, 3, 80, 120, null);
g.dispose();
cardImages[i] = img;
}
private void setRenderingHints(Graphics2D g){
g.setRenderingHint(KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);
g.setRenderingHint(KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
g.setRenderingHint(KEY_ANTIALIASING, VALUE_ANTIALIAS_ON);
}
How should I approach this differently?
Thanks.
Edit:
Without RenderingHints
Setting AA hints made no difference. Also, setting RenderingHints when creating the images makes no difference either. It's only when they are being rotated with AffineTransform and painted using g.drawImage(...) that they seem to blur. The image above shows the difference between default (nearest neighbor) and bilinear interpolation.
Here is how I'm currently painting them (much faster than TexturePaint):
// GamePanel.java
private void paintCard(Graphics2D g, int code, int x, int y){
g.drawImage(imageLoader.getCard(code), x, y, 86, 126, null);
}
// ImageLoader.java
public BufferedImage getCard(int code){
return cardImages[code];
}
All my cards are 80x120 and the shadow .png is 86x126, so as to leave 3px semi-transparent shadow around the card. It's not a realistic shadow I know, but it looks okay.
And so the question becomes... How can you produce sharp paint results when rotating a BufferedImage?
Reference to a previous question also regarding a fanned card hand:
How can you detect a mouse-click event on an Image object in Java?
Bounty-Edit:
Okay so after much discussion I made a few test .svg cards to see how SVG Salamander would go about rendering them. Unfortunately, the performance is terrible. My implementation is clean enough, seeing as with double-buffered BufferedImage's the painting was incredibly fast. Which means I have come full circle and I'm back to my original problem.
I'll give the 50 bounty to whoever can give me a solution to get sharp BufferedImage rotations. Suggestions have been to make the images bigger than they need to be and downscale before painting, and to use bicubic interpolation. If these are the only possible solutions, then I really don't know where to go from here and I may just have to deal with the blurred rotations - because both of those impose performance setbacks.
I can finish my game if I can find a way to do this well.
Thanks to everyone. :)

When you rotate a rasterized image (such as a BufferedImage), you lose data. The best solution is to save your images larger than you'll need them, and downscale on the fly when you paint them. I've found that 1.5x the size you need is a good starting point.
Then, when you're painting the image, resize on the fly:
g.drawImage(bufferedImage, x, y, desiredWidth, desiredHeight, observer);
Rotations using bilinear interpolation is recommended.
Credit for suggestion goes to guido.

This advice is probably a little late in your design, but may be worth mentioning.
Rasterized images is probably the wrong technology to use if a lot of rotations and animations are a part of your UI; especially with complicated images with lots of curves. Just wait until you try and scale your canvass. I might suggest looking at a vector based graphical library. They will render the sorts of effects you want with less potential for artifacts.
http://xmlgraphics.apache.org/batik/using/swing.htm

Setting the interpolation type, as well as anti-aliasing value, in an AffineTransformOp may offer some improvement. Type TYPE_BICUBIC, while slower, is typically the best quality; an example is outlined here. Note that you can supply multiple RenderingHints. Another pitfall arises from failing to apply the hints each time the image is rendered. You may also need to adjust the transparency of the background, as suggested here. Finally, consider creating an sscce that includes one of your actual images.

What's the difference between Graphics.clearRect and Graphics.drawRect?

I found a rendering bug in some code and have found a workaround, but I would like to know why I am getting different behaviour. In the old code, the background would (sometimes) be rendered as white, despite while debugging getBackground() would return the correct colour.
Old code:
#Override
public void paint(Graphics g) {
// Stuff
g.setColor(getBackground());
g.clearRect(0, 0, width, height); // Obviously wrong.
// More stuff
}
New code:
#Override
public void paint(Graphics g) {
// Stuff
g.setColor(getBackground());
g.drawRect(0, 0, width, height); // Correct usage with 'setColor' call.
// More stuff
}
As I put in the code, it is obvious that setColor(getBackground()) has no effect on the clearRect(...) call. Yet I would assume that calling clearRect(...) and calling setColor(getBackground()) followed by drawRect(...) would be semantically the same.
I have also considered the opaqueness property, but the parent lightweight components and ancestor heavyweight component all use the same background colour, and it is quite obvious that this component is the one with the incorrect behaviour (it is one of 8 of the same type of component owned by its parent - yet only the ones that get to this section of code have a problem).
I am using JDK 1.6.0_07 (for business reasons of course) if that helps.

Here's the information from the JavaDocs -
Clears the specified rectangle by filling it with the background color of the current drawing surface. This operation does not use the current paint mode.
Beginning with Java 1.1, the background color of offscreen images may be system dependent. Applications should use setColor followed by fillRect to ensure that an offscreen image is cleared to a specific color.
As this implies, clearRect is system dependent and the value of getBackground() is not taken into account.

The difference is this :
if you use the graphics method fillRect() you can't erase the color by using drawRect() over the same recatngle specified in pixels.
but if you use the graphics method fillRect() then clear it with clearRect() and after that drawRect(); you reach a satisfaction and a conclusion.