JDK-8087971 : Spinning progress indicator overlapping an image plays havoc with RDP
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 7u6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-01-29
  • Updated: 2018-09-05
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8092310 - SWPresentable.prepare: dirty region support
Relates :  
JDK-8091385 - PresentingPainter and UploadingPainter disregarding dirty clip rect
Description
I have a program that displays a pane of photo tiles, and I'm running it on Windows XP over a Remote Desktop Protocol (RDP) connection.  While I'm preparing the pane, I show a ProgressIndicator(-1); when I'm ready, I call setVisible(false) on the indicator.  When the indicator was the only thing on the display, the RDP bandwidth usage was minimal (maybe 1 KB/sec).  When the photo tiles are showing, even though the progress indicator is invisible, the bandwidth usage skyrockets.  I've seen as high as 3 MB/sec (yes, MB, not KB).  

As it turns out, the bandwidth usage is essentially the same whether I set the visibility true or false.  So there are at least a couple of things going wrong here.

Removing the progress indicator from the scene, rather than merely setting it invisible, results in normal bandwidth usage.

I'll attach a test case.
Comments
Thanks, Kevin. Some further notes: It���s a slightly complicated test case, since I was trying to discover what factors affected the bad interaction with the progress indicator. The test case puts up a spinning progress indicator for 5 seconds (so you can see the baseline bandwidth usage), then populates the pane behind it with a 5x5 array of something (controlled by command-line argument). If the something is simple color blocks, nothing bad happens. But if they���re images, it���s bad. 25 distinct images is worse than 25 copies of the same image. Rich images (photos) are worse than simple images, such as icons. The other thing that���s curious is that the problem only seems to occur when the progress indicator is part of a larger component, hence my class called LoadingSpinner. If you replace ���new LoadingSpinner()��� with ���new ProgressIndicator(-1)���, the problem does not occur.
01-02-2013
Attached test case on behalf of the bug submitter.
31-01-2013
As Jonathan indicates, this seems like a dirty region problem, which is likely a caused by RT-27374 (which is related to RT-20356) since JavaFX will use the SW pipeline when running via Remote Desktop. There seems to be additional problem here in that if nothing changes (which should be the case with your invisible progress indicator), then we shouldn't draw anything at all. As to "where did the attach button go", it had to be temporarily disabled due to some server issues that have not yet been resolved. If you e-mail me the attachment, I will attach it for you.
30-01-2013
Sounds more like a dirty regions issue, but it may also be crossing over into simply a failing in RDP to optimally determine the dirty regions and transmitting the whole desktop image. Assigning to Kevin to triage, but this I won't be surprised if this becomes an even lower-level issue.
29-01-2013
Well, I thought I was going to attach a test case. Where did the attach button go?
29-01-2013