Swing using lots of CPU when calling repaint in a minimized RDP session

Question

I'm observing some weird behavior with Java 8 (several versions, in particular 1.8.0_111) when running a Swing app in a VM. The VM is a Windows 10 machine running in VMware that I am remote-desktoping into. I have not tried to do this with an actual desktop, rather than a VM, but am planning to ASAP to potentially remove an extra failure point.

I've managed to reproduce it with this minimal program:

public static void main(String[] args) {
    SwingUtilities.invokeLater(() -> {
        JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        JPanel panel = new JPanel();
        for (int i = 0; i < 3; i++) {
            JPanel subpanel = new JPanel();
            JComboBox<?> box = new JComboBox<>();
            subpanel.add(box);
            panel.add(subpanel);
        }
        frame.add(panel);
        frame.pack();
        frame.setVisible(true);

        Timer timer = new Timer(1000, e -> {
            frame.repaint();
        });
        timer.setRepeats(true);
        timer.start();
    });
}

Now if I just start it normally, it repaints, no problems at all, just a frame with 3 empty combo boxes, as expected. The problem appears if I minimize the RDP session window. If that happens (and the frame was not iconified), then Swing starts eating up unhealthy amounts of CPU until I open the RDP window again.

I have tried minimizing the code example further, however reducing the combo-box count to 2, removing the subpanel or setting a single-fire timer (rather than repeating, even if the repaint would happen while the RDP is minimized) all prevented the bug from happening.

Here's the CPU utilization graph:
http://i67.tinypic.com/23rwglx.png

I've tried profiling the application during these spikes to try and see what the hell is happening. Here's the result from the profiler in JVisualVM:
http://i68.tinypic.com/apdwed.png

And the sampler (after removing the package filter):
http://i67.tinypic.com/2071735.png

I couldn't readily see what could be eating up the CPU in ProcessingRunnable. Does anyone have any experience with what Swing does when it suddenly has no screen to draw onto?

Answer 1

I have posted this as a bug report to Oracle. I'll update this answer as any details emerge (it's accepted or rejected) with the link.

A couple of similar bugs were already posted with "Cannot reproduce" as the resolution, however they do not involve VMs, only RDP sessions (I have not been able to trigger this bug by RDPing to my work desktop, rather than a VM).

I did find a workaround - apparently switching away from D3D stack and forcing OpenGL stack (-Dsun.java2d.d3d=false option when launching) prevents this from happening. I've now added some code to check whether the app is being started on a VM and set the options accordingly.

EDIT
The bug report has been accepted, although is in "Cannot reproduce" for the moment. http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8191018