My game engine is drawing a tiled map on a Canvas inside a JFrame. I am using a Bufferstrategy to get smoother rendering and tried to boost the performance at several points inside the program and end up with ca. 120 frames per second to fill a 1920 * 1080 Window with a black color and draw some isometric 512 * 256 tiles on top. When moveing the map around there are small black lines in between the tiles and . I assume that they occur because some tiles have already been moved to the new position, but the image isn´t done yet, when put on the sreen. But I don´t really have a solution to that and I´m also not sure if I´m right.
I should probably metnion that I´m using two threads in my program, one thread calls update and render methods, the other one is currently just getting user input to move the camera position. Also in some lauches everything works smoothly and in others it flickers very bad.
Here is some code of the window creation and rendering:
private final void createWindow(){
frame = new JFrame(title);
frame.setMinimumSize(size);
frame.setMaximumSize(size);
frame.setPreferredSize(size);
display = new Canvas();
display.setMinimumSize(size);
display.setMaximumSize(size);
display.setPreferredSize(size);
image = ImageLoader.boostPerformance(new BufferedImage((int)size.getWidth(), (int)size.getHeight(), BufferedImage.TYPE_INT_RGB));
graphics = (Graphics2D) image.getGraphics();
frame.add(display);
frame.pack();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
frame.requestFocusInWindow();
}
public final void renderToScreen(){
BufferStrategy bs = display.getBufferStrategy();
if(bs==null){
display.createBufferStrategy(bufferCount);
return;
}
graphicsToScreen = (Graphics2D) bs.getDrawGraphics();
graphicsToScreen.drawImage(image, 0, 0, display.getWidth(), display.getHeight(), null);
graphicsToScreen.dispose();
bs.show();
}
I use the Graphics2D graphics object in other classes to draw the tiles.
public void render(Graphics2D g) {
g.setColor(Color.black);
g.fillRect(0, 0, getWidth(), getHeight());
tilemap.render(g);
g.setColor(Color.red);
g.drawString(String.valueOf(Main.actualFps), 30, 30);
}
Above is the render method in another class using the graphics object I mentioned.
And here you can see the tile map render method:
private final void renderIsometric(Graphics2D g){
for(int x = 0; x < 4; x++){
for(int y = 3; y >= 0; y--){
if(x > tilesX - 1|| y > tilesY - 1)break;
if(x < 0 || y < 0)continue;
if(map[x][y] == null)continue;
g.drawImage(map[x][y].getImage(), (int)orthoToIso(x, y).x - cameraPosX, (int)orthoToIso(x, y).y - cameraPosY, null);
}
}
}
Finally here is the main loop to ensure that the fps counter is working and the value of 120 fps is correct:
while(running){
long now = System.nanoTime();
double ns = 1000000000.0 / preferredUps;
delta += (now - lastTime) / ns;
lastTime = now;
while(delta >= 1){
//call the update method
update();
updates++;
delta--;
}
//call the render method
render();
frames++;
//refresh the actualUps and actualFps once every second
if(System.currentTimeMillis() - timer > 1000){
timer+=1000;
actualUps = updates;
actualFps = frames;
updates = 0;
frames = 0;
}
}
How can I get rid of these tiny lags and flicker problems? And additionally I have been wondering if it would give better results to use OpenGL via LWJGL instead of Java2D?
Thanks for your help!
What you see there is most likely not flickering strickly speaking. Its tearing and weaving artifacts. Its a natural consequence of updating the screen without synchronizing to the vertical synchronization of screen refresh.
Windowing systems are in general not made to honor v-sync (they favor performance, as those effects are not grossly perceptible - or important - in a normal UI). As far as I know there is no way of synchronizing with a (J)Frame (you could probably hack something with JNI, asking the OS to tell you when the raster beam is at the top of the frame, but thats beside the point).
Also rendering at 120fps may actually make the problem worse, unless the display device also refreshes at 120hz - when you render more frames than the device actually displays you force the device to display graphics from more than one frame (e.g. frame 1 in the top half of screen, frame 2 in the bottom half). This will always result in perciptible artifacts with moving objects.
There is one way around it in pure java, and thats fullscreen mode (that will wait for v-sync, as a result your rendering rate is limited to and controlled by the refresh rate of the display device).
You can try openGL, but I have no idea if it will synchronize when rendering in windowed mode.
A first step to improve things would be to not render faster than the display devices displays (e.g. max. 60 fps for a 60hz screen).
In case your application is not time critical, you can resolve flickering by using a double-buffering strategy.
Essentially, the image you are compositing is copied to a secondary off-screen image buffer, which is not rendered this frame, but next frame. There are some tricks you can use to have Swing components double buffer automatically for you, see also:
https://gamedev.stackexchange.com/questions/30921/thread-safe-double-buffering
Double buffered image example in Jpanel
The downside of double buffering is that you introduce one frame of latency, which means your input is only going to result in visible changes one frame later than it would without double buffering. At 120hz this is probably not going to be a big issue, but just for completeness sake..
Related
A LinearGradientPaint object from java.awt may appear nice once painted, but there's a problem I'm having with it for painting an animated background in some kind of game model that's taking me long to build.
I want to paint an animated rainbow gradient on the background using the Graphics2D paint object, except that when I do so, I notice a lot of lag in repainting the panel. It should repaint itself at least 30 frames per second, which is only possible if the Paint object the graphics object uses is not a rainbow gradient.
Even running it as a separate thread will not do the trick. Below is the code for what I am trying to do at the end of each frame:
gamePanel.executor.execute(new Runnable(){
public void run()
{
while(true)
{
if (Background.selectedBackgroundIndex >= Background.SKY_HORIZON_GRADIENT_PAINT &&
Background.selectedBackgroundIndex < Background.SPACE_PAINT)
{
float displacementValue = 1.0f;
if (Background.backgroundShape.y < ((-2990.0f) + CannonShooterModel.gamePanel.getSize().height) && gamePanel.horizonGoingDown)
gamePanel.horizonGoingDown = false;
else if (Background.backgroundShape.y > (-10.0f) && !gamePanel.horizonGoingDown)
gamePanel.horizonGoingDown = true;
Point2D.Double startPoint = (Point2D.Double)(((LinearGradientPaint)Background.background).getStartPoint()),
endPoint = (Point2D.Double)(((LinearGradientPaint)Background.background).getEndPoint());
if (gamePanel.horizonGoingDown)
Background.backgroundShape.y -= displacementValue;
else
Background.backgroundShape.y += displacementValue;
startPoint.setLocation(0, Background.backgroundShape.y);
endPoint.setLocation(0, Background.horizonGradientPaintHeight + Background.backgroundShape.y);
// Should be done in another thread, particularly in arithmetic calculations.
Background.background = new LinearGradientPaint(startPoint, endPoint,
((LinearGradientPaint)Background.background).getFractions(),
((LinearGradientPaint)Background.background).getColors());
}
for (int a = 0; a < PlayerUnit.weapon.bullets.length; a++)
{
if (PlayerUnit.weapon.bullets[a] != null)
{
if (PlayerUnit.weapon instanceof Pistol &&
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).x + ((Pistol)PlayerUnit.weapon).bulletWidth >= 0 &&
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).x <= CannonShooterModel.gamePanel.getSize().width &&
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).y + ((Pistol)PlayerUnit.weapon).bulletWidth >= 0)
{
if (PlayerUnit.weapon.weaponAngles[a] >= 0)
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).x +=
PlayerUnit.weapon.bulletSpeed * Math.cos(PlayerUnit.weapon.weaponAngles[a]);
else
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).x -=
PlayerUnit.weapon.bulletSpeed * Math.cos(PlayerUnit.weapon.weaponAngles[a]);
if (PlayerUnit.weapon.weaponAngles[a] >= 0)
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).y -=
PlayerUnit.weapon.bulletSpeed * Math.sin(PlayerUnit.weapon.weaponAngles[a]);
else
((Ellipse2D.Float)PlayerUnit.weapon.bullets[a]).y +=
PlayerUnit.weapon.bulletSpeed * Math.sin(PlayerUnit.weapon.weaponAngles[a]);
}
else
PlayerUnit.weapon.bullets[a] = null;
}
}
//System.out.println(Background.backgroundShape.y);
repaint();
try
{
Thread.sleep(1000 / 60);
}
catch (InterruptedException ex)
{
}
}
}
});
The classes Background, PlayerUnit, and CannonShooterModel are important to my game model. It's an upright shooting game supposed to be designed with various weapons and enemies.
This rainbow gradient I have uses an array of eight different Color objects. For every frame passed through, I change the y-coordinate for both Point2D.Float objects required for the gradient paint as desired. In order for the animation to work, I have to actually instantiate another object of LinearGradientPaint again, with some of the previous properties from the previous object, and have it be referenced by the variable background of type Paint.
Problem is, LinearGradientPaint does not have a method to where you can do a translate on the two end points, and the get methods do not return the actual object that LinearGradientPaint object contains. (what I mean is, the get methods return a new object of Point2D with the same values as those part of the LinearGradientPaint object.)
For every frame passed, I have to change not only the y-coordinate property of the shape that's associated with the gradient, but also set the locations of the two Point2D objects that are needed to instantiate LinearGradientPaint once again.
I would love to re-explain this much simpler, because I can have trouble with some knowledge of English, even though this is my primary language. Please let me know if you need re-explanation.
There are a couple of solutions you might try.
Instead of filling the entire paintable area, you could create a BufferedImage whose width is 1 pixel and height equal to the area you want to fill (assuming you are fill vertically). You would then apply the LinearGradientPaint to this BufferedImage's Graphics2D and fill it (don't forget to dispose of the Graphics context when your done).
Then, you would simply use Graphics#drawImage(Image, x, y, width, height, ImageObserver) to actually paint the image. Generally speaking, it appears that it's faster to rescale an image then it is to fill it with a LinearGradientPaint, especially when you consider you are only stretching the image horizontally.
The other choice would be to generate a basic BufferedImage which had the LinearGradientPaint already applied and you would simply paint this offset as required. This would probably require you to paint it at least twice to allow it to "stitch" toegther...
If you are just making the background gradient move up and down, could you write it to an image at initialization and then move and wrap the image vertically?
I am a relative newbie in game programming. I know how to draw pixels to a BufferedImage using setPixel(). It is horribly slow on larger formats so I moved on and found VolatileImage (took me a week or so). It is fairly easy to draw lines, strings, rects, etc but I can't draw individual pixels. I already tried using drawLine(x,y,x,y) but I get 3-4 FPS on an 800x600 image.
The fact that java didn't include setPixel() or setRGB() in the VolatileImage makes me pretty angry and confused.
I have 4 questions:
Is there a way to draw individual pixels on a VolatileImage? (on 1440x900 formats with FPS > 40)
Can I draw pixels in a BufferedImage with a faster method? (same 1440x900, FPS > 40)
Is there any other way to draw pixels fast enough for 3D games?
Can I make my BufferedImage hardware accelerated( tried using setAccelerationPriority(1F) but it doesn't work)
Please if you have any idea tell me. I can't continue making my game wihout this information. I already made 3D rendering algorithms but i need to be able to draw fast pixels. I have got a good feeling about this game.
Here's the code if it can help you help me:
public static void drawImageRendered (int x, int y, int w, int h) { // This is just a method to test the performance
int a[] = new int[3]; // The array containing R, G and B value for each pixel
bImg = Launcher.contObj.getGraphicsConfiguration().createCompatibleImage(800, 600); // Creates a compatible image for the JPanel object i am working with (800x600)
bImg.setAccelerationPriority(1F); // I am trying to get this image accelerated
WritableRaster wr = bImg.getRaster(); // The image's writable raster
for (int i = 0; i < bImg.getWidth(); i++) {
for (int j = 0; j < bImg.getHeight(); j++) {
a[0] = i % 256;
a[2] = j % 256;
a[1] = (j * i) % 256;
wr.setPixel(i, j, a); // Sets the pixels (You get a nice pattern)
}
}
g.drawImage(bImg, x, y, w, h, null);
}
I would much prefer not using OpenGL or any other external libraries, just plain Java.
Well you're basically drawing one pixel after the other using the CPU. There's no way that this can be accelerated, thus such a method does simply not make any sense for a VolatileImage. The low FPS you get suggest that this even causes a significant overhead, as each pixel drawing operation is sent to the graphics card (with information such as location & colour), which takes longer than to modify 3 or 4 bytes of RAM.
I suggest to either stop drawing each pixel separately or to figure out a way to make your drawing algorithm run directly on the graphics card (which most likely requires another language than Java).
It's been over 4 years since this post got an answer. I was looking for an answer to this question as well and stumbled on this post. After some more searching, I got it to work. Below I'll post the source to rendering pixels with a VolatileImage.
It seems Java hides our ability to plot pixels directly to a VolatileImage, but we can draw buffered images to it. For good reason. Using the software to plot a pixel doesn't really help with acceleration(in Java it seems). If you can plot pixels to a BufferedImage, and then render it on a VolatileImage, you may get a speed bonus since it's hardware accelerated from that point.
The source down below is a self-contained example. You can copy-pasta practically all of it to your project and run it.
https://github.com/Miekpeeps/JavaSnippets-repo/blob/master/src/graphics_rendering/pixels_03/PlottingVolatile.java
In the constructor I save the Graphics environment of the app/game.
private GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
private GraphicsConfiguration gc = ge.getDefaultScreenDevice().getDefaultConfiguration();
Then, when I call a method to enable hardware we create a buffer. I set the transparency to Opaque. In my little engine, I deal with transparency/alpha blending on another thread in the pipeline.
public void setHardwareAcceleration(Boolean hw)
{
useHW = hw;
if (hw)
{
vbuffer = gc.createCompatibleVolatileImage(width, height, Transparency.OPAQUE);
System.setProperty("sun.java2d.opengl", hw.toString()); // may not be needed.
}
}
For each frame I update, I get the Graphics from the VolatileImage and render my buffer there. Nothing gets rendered if I dont flush().
#Override
public void paintComponent(Graphics g)
{
if(useHW)
{
g = vbuffer.getGraphics();
g.drawImage(buffer, 0, 0, null);
vbuffer.flush();
}
else
{
g.drawImage(buffer, 0, 0, null);
buffer.flush();
}
}
There is still a little bit of overhead when calling to plot a pixel on the BufferedImage writable raster. But when we update the screen, we get a speed boost when using the Volatile image instead of using the Buffered image.
Hope this helps some folks out. Cheers.
I have a live wallpaper that is running a looped animation by drawing each frame to the canvas. I have one single image, sized to the exact dimensions of the screen. I have a set of 400 frames sized exactly to fit about the bottom third of the screen; this is where the animation occurs. Here is the code that displays them:
public void updateBG() {
mHandler.removeCallbacks(mUpdateDisplay);
if (mVisible) {
mHandler.postDelayed(mUpdateDisplay, 40);
}
if (imagesLoaded < totalFrames) {
ShowLoadingProgress();
} else {
SurfaceHolder holder = getSurfaceHolder();
Canvas c = null;
try {
c = holder.lockCanvas();
if (c != null) {
Paint p = new Paint();
p.setAntiAlias(true);
c.drawRect(0, 0, c.getWidth(), c.getHeight(), p);
Rect destinationRect = new Rect();
destinationRect.set(0, 0, canvasWidth, canvasHeight);
if (animStartX > 0 || animEndX > 0 || animStartY > 0 || animEndY > 0) {
c.drawBitmap(BitmapFactory.decodeByteArray(bitmapArray[totalFrames], 0, bitmapArray[totalFrames].length), null, destinationRect, p);
Rect destinationRectAnim = new Rect();
destinationRectAnim.set(animX, animY, animX+animWidth, animY+animHeight);
c.drawBitmap(BitmapFactory.decodeByteArray(bitmapArray[bgcycle], 0, bitmapArray[bgcycle].length), null, destinationRectAnim, p);
} else {
c.drawBitmap(BitmapFactory.decodeByteArray(bitmapArray[bgcycle], 0, bitmapArray[bgcycle].length), null, destinationRect, p);
}
}
} finally {
if (c != null)
holder.unlockCanvasAndPost(c);
}
bgcycle++;
}
}
This code is running at approximately 10-12 FPS on an Xperia Ion (dual-core 1.5 GHz cpu) and worse on older devices. It was going much better when I saved entire frames at half the screen resolution. It actually got worse when I started using full frames at the screen resolution (which should have eliminated the need to interpolate on each frame). It then got even worse when I started using this code, which writes two bitmaps (presumably because it can't save the top half of the canvas from the last run).
How can I optimize this? I'd rather not save full frames as just saving the animated part for each frame really reduces memory usage. Something feels really wrong here, especially given that this is running with 3GHz of power behind it. I used to watch movies on a 450 MHz Pentium III. Is there something obvious that I'm doing wrong? Is the phone still trying to interpolate the images even though they are sized correctly?
You are decoding your bitmap on every frame, it's expensive and it will generate garbage that will trigger GCs. You are also rendering using software rendering. Here are your solutions, in order:
Don't re-decode the bitmaps on every frame
Reuse bitmap objects (see BitmapFactory.Options.inBitmap)
Use hardware acceleration (render directly into a View instead of a SurfaceView.) Software interpolation is very expensive.
I am making a 2D platform in Java, and I'm using a Swing timer, it is set at 5 milliseconds interval. However, sometimes it is smooth movement at a good speed, but then randomly it will become super fast and sometimes super slow. What could be the reason for this?
Code:
public Board() {
addKeyListener(new KeyListener());
setFocusable(true);
setBackground(new Color(204,250,255));
//draws the object off the screen in memory, then brings it in
setDoubleBuffered(true);
...(other code not relevant)...
timer = new Timer(5, this);
timer.start();
}
public void paint(Graphics g) {
super.paint(g);
Graphics2D g2d = (Graphics2D) g;
//draw platform
for(int i = 0; i < platform.length; i++) {
//g2d.setColor(new Color(0,0,0));
//g2d.drawRect(platform[i].getX(), platform[i].getY(), platform[i].getWidth(), platform[i].getHeight());
g2d.drawImage(platform[i].getImage(), platform[i].getX(), platform[i].getY(), this);
}
//draw guy
g2d.drawImage(guy.getImage(), guy.getX(), guy.getY(), this);
//destroy unneeded process
Toolkit.getDefaultToolkit().sync();
g.dispose();
}
Basically, the cycle function decides whether the character needs to move or not, and moves it if it does.
It is hard to make Java work as a real-time systems…. because of unknown factors like when the OS will schedule your process to run and GC. Since you are trying to update the game at 200 fps (if my math is correct) you might want to try the following approach. To make the game smoother I would try to find the time between the current event fired and the last event fired, now theoretically that might be 5ms but sometimes it will be 7ms (going super slow) and sometimes it will be 3ms (going super fast). Ones you have the time between the two event I would calculate where the animation should be, so if the time is 3ms then the animation will be a bit before the 5ms time. Lets take a simple example where your are trying to update the X position of a image 5 px every 5ms.
//your current code
newX = X + 5px
//new code
//this wont always be 5ms
timeDiff = currentEventTime – lastEventTime;
newX = X + 5px (timeDiff/5ms)
I have made a custom component (derived from JComponent) which represents
a draggable Bezier-curve.
(looks like a hanging cable, someone might know it
from Bender or Cubase)
My problem is: The curve may become really long,
let's say from top left to bottom right corners of the desktop.
This makes Swing's repaint functionality inefficient:
The area of the curve is perhaps few hundred pixels, but the area of
the component (being mostly 'transparent') is millions of pixels big.
My subjection impression is:
The longer the curve, the more flicker I get when dragging it.
I hope I made myself clear about the problem.
Perhaps it would help when I somehow could choose by myself, which regions
of the component needs repainting at all.
EDIT:
Such a mess! I'm profiling the application using Netbeans, which helps to
find inefficient code normally, but this Swing framework is making hundreds
of nested calls! I just can't figure out, what is slow and why.
By the way, disabling super.paint(...) or super.paintComponent(...) doesn't help.
Check out Filthy Rich Clients by Chet Haase and Romain Guy. They address these very optimizations among others along the way to producing responsive and graphically impressive UI.
Doing all of your bezier mathematics on the paint thread everytime the component is refreshed is (as you've gathered) a bad idea. Does your curve change often? If not then why not paint it to a BufferedImage as and when it changes, and change your paint() code to simply draw the buffered image to the component instead.
class CurveComponent extends JComponent {
private BufferedImage image;
#Override
public void paintComponent( Graphics g ) {
if ( image == null ) {
return;
}
g.drawImage( image, 0, 0, this );
}
private void updateCurve() {
image = new BufferedImage( getWidth(), getHeight(), BufferedImage.ARGB );
Graphics g = image.getGraphics();
// draw the curve onto image using g.
g.dispose();
}
}
Only call updateCurve() when you need to and all that expensive mathematics won't be needlessly repeated. Painting should be pretty responsive, even for a fullscreen window. drawImage() will be doing a straightforward memory copy and should be lightning fast.
Try writing a tiny test app, which consists of nothing except what you need to reproduce this problem. This will make profiling easier. Then post that app here, so we can take a look at possible solutions.
I found your question interesting so I wrote a test app myself. This draws a Bezier curve which is continually resized as you drag. I created a gradient background to ensure this works well with a nasty background. I get good performance and low flicker, although I use top-notch machine.
It pays to read "Filthy Rich Clients" to learn all the tricks of writing custom Swing components that perform really well.
import javax.swing.*;
import java.awt.*;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import java.awt.geom.CubicCurve2D;
import java.awt.geom.Point2D;
public class CustomComponent extends JComponent {
private Point2D start = new Point2D.Double(0, 0);
private Point2D end = new Point2D.Double(300, 200);
private CustomComponent() {
this.setOpaque(true);
final MouseAdapter mouseAdapter = new MouseAdapter() {
#Override
public void mouseDragged(MouseEvent e) {
setEnd(e.getPoint());
}
};
this.addMouseListener(mouseAdapter);
this.addMouseMotionListener(mouseAdapter);
}
public void setStart(Point2D start) {
this.start = start;
repaint();
}
public void setEnd(Point2D end) {
this.end = end;
repaint();
}
#Override
protected void paintComponent(Graphics g) {
final Graphics2D g2 = (Graphics2D) g;
g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
// draw gradient background
final int width = getWidth();
final int height = getHeight();
g2.setPaint(new GradientPaint(0, 0, Color.WHITE, width, height, Color.YELLOW));
g2.fillRect(0, 0, width, height);
// draw Bezier curve
final Shape shape = new CubicCurve2D.Double(start.getX(), start.getY(), start.getX(), end.getY(), end.getX(), start.getY(), end.getX(), end.getY());
g2.setColor(Color.BLACK);
g2.draw(shape);
g2.drawString("Click and drag to test for flickering", 100, 20);
}
public static void main(String[] args) {
final CustomComponent component = new CustomComponent();
final Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
final Dimension size = new Dimension(screenSize.width - 20, screenSize.height - 100);
component.setPreferredSize(size);
final JFrame frame = new JFrame();
frame.add(component);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setVisible(true);
}
}
Some things to note:
only overwrite paintComponent(Graphics g), not the other paintXXX() methods
set custom component to opaque if possible
only use repaint() to request repainting. Never directly order a repaint directly in your code. This lets Swing handle it well.
There is no efficient way to create lots of small clip rectangles for a diagonal structure which leaves you with two strategies to avoid flickering:
Double buffering. This needs an enormous amount of memory but the memory copy is very fast (it usually happens in the time the "electron beam" goes back from lower right to upper left ... if there was still a beam in your LCD).
Don't call super.paint() (which draws or "erases" the background) and draw the curve a second time with the background color to erase it.
For more details, see this document.
[EDIT] If fillRect() wasn't abstract, you could set a break point :) Set a break point in paint(), check who calls it and whether the background got cleared at that time. It should be since rendering would be completely wrong. Then set break points further up in the call chain.
You can redraw a smaller portion of the screen using repaint(Rectangle r)
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JComponent.html#repaint(java.awt.Rectangle)
Then you mention flicker. Since you are using swing, which uses double buffering your flickering must be coming from something else. Are you clearing the screen in paintComponent(...)? I.e. call to fillRect(...)? Don't do that, it's not needed (IIRC).
Which method do yo use to paint your curve? paint or paintComponent?
My solution was a partial re-design:
Now I don't represent each "cable"-element by a component.
Now, cables are just dummy objects (with no involved JComponent).
The repaint takes place "globally", on the content pane of the parent JFrame.
Now it's efficient, and flickers less.
just use getVisibleRect(); inside paintComponent(Graphics g) to get the area you actually need to redraw