FULL PRODUCT VERSION :
JDK 8u60
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 64

A DESCRIPTION OF THE PROBLEM :
Additional findings for JDK-8088279 on Windows 7.

Note this is different case than originally reported JDK-8088279 on Mac, because the original submitter sample runs on Windows without problem. This looks more like a regression on Windows somewhere between 7u79 and 8u60.

Simplest animation below runs well under Windows 7 on JRE 7u79 but is terrible jerky on JRE 8u60.

JRE 7:
i7, GTX 750 - smooth as silk
Intel NUC dn2820fykh - very smooth except major disruptions every 5-10 seconds

JDK 8u60:
On wide range of tested PC and laptops it is jerky.
i7, GTX 750 - disrupted every few seconds
Intel NUC dn2820fykh - just terrible, not usable

For JDK 8 it is just not usable on any machine I tested. However, it does not seem as rendering problem, see my findings below.

(btw. for JDK 7 there is no reason it would not run on NUC with Intel HD graphics without ANY disruptions, if it is able to run smooth for 10 seconds. Similar C++ D3D sample or other programs run without any disruptions there, so it is not driver problem. But it is not as terrible as on JDK 8).

The app runs with -Xms512M -Xmx512M -verbose:gc and there is no gc log output.

 
Animation code:

Pane screen = new Pane();
Scene scene = new Scene(screen, 1280, 720, true/*,
SceneAntialiasing.BALANCED*/);

Pane root = new Pane();

root.setPrefSize(1280, 720);
screen.getChildren().add(root);

Image imagebuf = new Image("https://upload.wikimedia.org/wikipedia/commons/b/b9/Javafx_logo_color.png", false);
final ImageView image = new ImageView(imagebuf);
image.setCache(true);
image.setCacheHint(CacheHint.SPEED);
image.setManaged(false);
image.setVisible(true);
root.getChildren().add(image);

        TranslateTransition transition = new TranslateTransition(Duration.seconds(5));
        transition.setFromX(image.getImage().getWidth());
        transition.setFromX(-imagebuf.getWidth());
        transition.setToX(1280);
        transition.setNode(image);
        transition.setCycleCount(Animation.INDEFINITE);
        transition.setInterpolator(Interpolator.LINEAR);
        transition.play();

-------------
I tried to check what happens

If I use Timeline I get the same jerky movement on 8.
If I position manually using AnimationTimer with delta from animation start to 'now' (or System.nanoTime delta) it produces exactly the same jerky movement as built-in animations on JRE 8.
Both approaches run relatively smooth on JRE 7.

When I collect animation timer 'now' delta stats on JRE 7, almost all frames are ~16ms.
However, on JRE 8 there are once in a while weird sequences like 16.001595, 29.018011, 2.977756, 30.503049, 1.519597, 15.987516, 15.999547, 32.034423, 15.970107.

Now the interesing part. One may think it delays or skips frames on rendering. Not exactly.

If AnimationTimer movement is not based on time delta but just adds a constant offset ignoring time difference, image moves pretty smooth on all machines including Celeron NUC.

This may suggest there is some problem with pulse call sync / timing and probably not an issue on D3D level.

What is really weird is that multiple resizing as I described in JDK-8133843 sometimes fixes the animaiton but not always and less on weak devices.

Additional info/issue that may be useful - video playing on Intel NUC is way less smooth with JavaFX 8 than with JavaFX 7 (quite jerky, barely usable). Given that both use DirectShow on Windows 7, it also suggests there is some timing, sync or threading problem related to pulse rather than D3D problem. Looks like there is common issue related both to animations and video timing.

(JRE 7 plays video much better, but on intel NUC even 7 play clearly less smooth than Media Player Classic Home Cinema which also uses DirectShow).

Please contact me fedor.losev@gmail.com for any additional details if the issue is not reproducible.

I see the animation problem on wide range of machines so it is not clear why others don't experience the same and how this issue is low priority.

-------------------------------------------
Prism output (same program same machine)

Java 7:

Prism pipeline init order: d3d j2d
Using t2k for text rasterization
Using dirty region optimizations
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.d3d.D3DPipeline
Loading D3D native library ...
succeeded.
Direct3D initialization succeeded
(X) Got class = class com.sun.prism.d3d.D3DPipeline
Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline
Maximum supported texture size: 16384
Maximum texture size clamped to 4096
OS Information:
Windows 7 build 7601
D3D Driver Information:
NVIDIA GeForce GTX 750
\\.\DISPLAY1
Driver nvd3dumx.dll, version 10.18.13.5560
Pixel Shader version 3.0
Device : ven_10DE, dev_1381, subsys_362E1458

Java 8:

Prism pipeline init order: d3d sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.d3d.D3DPipeline
Loading D3D native library ...
succeeded.
D3DPipelineManager: Created D3D9Ex device
Direct3D initialization succeeded
(X) Got class = class com.sun.prism.d3d.D3DPipeline
Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline
Maximum supported texture size: 16384
Maximum texture size clamped to 4096
OS Information:
Windows 7 build 7601
D3D Driver Information:
NVIDIA GeForce GTX 750
\\.\DISPLAY1
Driver nvd3dumx.dll, version 10.18.13.5560
Pixel Shader version 3.0
Device : ven_10DE, dev_1381, subsys_362E1458
Max Multisamples supported: 4
 vsync: true vpipe: true


 On NUC etc both outputs look similar as well.

REGRESSION. Last worked in version 7u79

ADDITIONAL REGRESSION INFORMATION:
Problematic
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Working
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)


REPRODUCIBILITY :
This bug can be reproduced always.