JDK-8239589 : JavaFX UI will not repaint after reconnecting via Remote Desktop
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: openjfx13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2020-02-20
  • Updated: 2021-05-10
  • Resolved: 2021-03-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8u291Fixed openjfx11.0.12Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
This is similar to issue JDK-8229394 but with a few key differences.

When you start a JavaFX application remotely via Remote Desktop and then you disconnect (not logoff) the remote session while the app is still running and then reconnecting, the running app will not be able to repaint.

The key difference from JDK-8229394 is: That issue mentions the app was started locally and then was accessed remotely, in this case, the app was started via remote session.

The other key difference is: This seems to only be an issue when the remote machine is running Windows 10.
I've also tested this against Windows 8.1, Windows Server 2012, and Windows Server 2016 and it works fine.
It is ONLY an issue with Windows 10.

There is no workaround aside from restarting the app.

FREQUENCY : always

Changeset: 73e70fe9 Author: Kevin Rushforth <kcr@openjdk.org> Date: 2021-03-23 20:27:23 +0000 URL: https://git.openjdk.java.net/jfx/commit/73e70fe9

I have fixed most of the outstanding issues now, and updated the WIP pull request with this comment: https://github.com/openjdk/jfx/pull/403#issuecomment-798767691 Of the remaining issues, most will be addressed by filing follow-on bugs. Only the 3D shapes problem is a "must fix" prior to starting the formal code review.

I have fixed the memory leak and done some additional stress testing. It wasn't related to the `resourceFreed` assertion failure, although in the stress testing I've done, there are no rendering problems associated with that assertion. I still want to explore it a bit further, but if not, I think we can live with it. Other than that, there are only a few remaining cleanup issues.

Ad noted in the PR here: https://github.com/openjdk/jfx/pull/403#issuecomment-786866103 stress testing has revealed a memory and resource leak that much be addressed before this is ready. It may or may not be related to the `resourceFreed` assertion failure, but I'll look at both at the same time.

I can reproduce the media issue using the software pipeline, so it is a separate problem. I will file a new bug for that case.

As noted in the WIP PR, almost everything is working now, including reconnecting to a device that isn't immediately ready. The only remaining issues I know of are: 1. If media is playing when you disconnect from RDP, it won't continue playing you reconnect (this one doesn't fail when simulating it, so might be something in DirectShow, which is used by jfxmedia on Windows). 2. When the device is destroyed and recreated, the resourceFreed method occasionally finds an attempt to free an unmanaged resource. As noted in the description, this is was changed from an error to a warning. I see it occasionally after reinitializing the device, both on the real system and when simulating device removal. This may or may not be an important issue, but I won't know until after I root cause it.

Here is a preliminary WIP PR that I created for initial testing: https://github.com/openjdk/jfx/pull/403 Once the remaining issues are debugged and addressed, I will close it and open the real PR.

I have an initial working version. I took the patch from https://git.openjdk.java.net/jfx/pull/315 as a starting point and fixed it up to not recreate the GraphicsPipeline object, but instead reinitialize it. I had to add a dispose method in D3DContext and implement the one in D3DResourceFactory. One impact of recreating the underlying D3D device and the resource factory is that all textures need to be recreated, even those marked as permanent. A few of them, notably the gradient cache, assumed they didn't need to check for a lost surface. I fixed that and now most things work.