FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux filesrv 3.11.10-21-desktop #1 SMP PREEMPT Mon Jul 21 15:28:46 UTC 2014 (9a9565d) x86_64 x86_64 x86_64 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
Tried this on multiple systems with different graphics cards. Same result.

A DESCRIPTION OF THE PROBLEM :
When using animations, they are sluggish on Java 8. They were fluent on Java 7. I found out that this has to do with the Blit type used. Java 8 uses a different Blit (from the xr package). The root cause is a change in X11GraphicsEnvironment.java:

                    boolean xRenderRequested = true;

This boolean was false in Java 7. According to the source history, this is related to bug JDK-7077423: xrender is enabled by default.

Disabling xrender using -Dsun.java2d.xrender=false reverts Java 8 to the fluent animations Java 7 has, but I think xrender is now default because it is supposed to give a better performance, so that is not a solution.

Please check out this video I made: left you see a simple bouncing ball animation using -Dsun.java2d.xrender=false, right you see the same bouncing ball using -Dsun.java2d.xrender=true. With xrender on, the ui is not updated very often, so the animation is not fluent, unless actively moving around the mouse in that window.

https://www.youtube.com/watch?v=DEO6ZppjuzQ




REGRESSION. Last worked in version 7u51

ADDITIONAL REGRESSION INFORMATION:
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

This was working in Java 7, because of the change I found in X11GraphicsConfiguration: the boolean is now default true:

                    boolean xRenderRequested = true;

In the C-code (without xrender) Blit uses Xsync to send each change to the display. I didn't see this happen in the xrender version, but I don't know whether Xsync can be added there, due to the different architecture of xrender, which is unknown to me.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Save the source code Animation.java and run it with or without -Dsun.java2d.xrender=false. So:

This is sluggish on Java 8:

java -cp . Animation

or

java -cp . -Dsun.java2d.xrender=true Animation

This runs fluently:

java -cp . -Dsun.java2d.xrender=false Animation



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Fluent animation with xrender as well.
ACTUAL -
Sluggish animation.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.Color;
import java.awt.Graphics;
import java.util.Timer;
import java.util.TimerTask;

import javax.swing.JFrame;
import javax.swing.JPanel;

public class Animation extends JPanel {
private static int DELAY = 10;

int position = 0;

public void paint(Graphics g) {
super.paint(g);
g.setColor(Color.RED);

int objectWidth = 50;
int objectHeight = 50;
int arcWidth = objectWidth;
int arcHeight = objectHeight;

int xspace = getWidth()-objectWidth;
int x = calcPosition(xspace);
int yspace = getHeight()-objectHeight;
int y = calcPosition(yspace);

g.fillRoundRect(x, y, objectWidth, objectHeight, arcWidth, arcHeight);
g.setColor(Color.BLACK);
g.drawString("Position " + position, 10, 10);
}

private int calcPosition(int space) {
return space - Math.abs(space - (position % (space*2)));
}


public void go() {
TimerTask task = new TimerTask() {
public void run() {
position++;
repaint();
}
};
Timer timer = new Timer();
timer.schedule(task, 0, DELAY);
}

public static void main(String args[]) {
Animation panel = new Animation();
JFrame f = new JFrame();
f.setSize(400, 300);
f.setTitle("sun.java2d.xrender=" + System.getProperty("sun.java2d.xrender"));
f.setContentPane(panel);
f.setVisible(true);
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
panel.setDoubleBuffered(true);
panel.go();
}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Starting Java with -Dsun.java2d.xrender=false

But as I said, xrender probably is the future for Java 2D, so this problem should be solved.