JDK-8090283 : [D3D] Ensemble application flickers during resize
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 7u6,8,9
  • Priority: P3
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2012-04-27
  • 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
Duplicate :  
JDK-8139117 - Undecorated stage flickers on resize
Duplicate :  
JDK-8093776 - [Stage] Undecorated stage flickers
Relates :  
JDK-8089313 - Transparent stage resize flickers on Mac
Relates :  
JDK-8118274 - The app flickers during resize and even can be catched with everything in black
Relates :  
JDK-8114867 - REGRESSION: JavaFX application starts to flicker on mouse move and actions after locking the screen
Relates :  
JDK-8127874 - SceneBuilder is out of sync with the native OS window size while resizing.
Description
When I resize Ensemble application on my windows 7 machine there are frames when the whole Ensemble screen is painted in black/gray.

That looks really weird.
Comments
Retargeted to tbd_major as not a regression in 8u/9 and introduced in 8 GA or earlier. However might be fixed in 9 in positive case on time resources
11-07-2016
JDK-8139117 has another simple test case which shows flickering on resize.
11-11-2015
SQE is ok to defer from 8u40.
18-11-2014
I would like to defer this bug from 8u20 to 9, this is very likely windows/d3d issue with no visible workarounds.
20-05-2014
It seems like a bug in Windows related to quick succession of releasing/creating swap chains. Apparently even a simple native test case (from the thread in Mozilla's bugzilla) suffers from it. I tried many different workarounds and nothing actually works. HelloBlinking for some reason blinks more rarely with decorated frame, but still blinks. The native test has clear distinction whether DWM is enabled or not (Windows Classic theme disables it), although I don't see much difference in HelloBlinking.
11-11-2013
On windows with a certain gpu. I could reproduce on ATI and Kevin could reproduce on only one of his two GPUs. (Intel I think) Every thing else is all ready described. I look into the possibility that d3d is less tolerant than es2. I.e. if you try to blit/stretch rect outside of destination surface. In that case d3d would draw black. I did not see any indication that we are doing that any more, however device drivers it self probably is during swap of back buffer.
05-11-2013
Thor, what were the conditions that cause black flashing in D3D? I remember you told them to me once.
05-11-2013
Yes, I can see occasional blinking with HelloBlinking with various hardware. I've thought that I was able to capture the problem in the PIX, but I was wrong, it's PIX's problem itself.
05-11-2013
Can you recreate the problem then or not? It was not clear to me whether you see it and have something that you can work on.
05-11-2013
I've tried capturing full d3d stream with PIX with no luck, apparently PIX is not working good with additional swap chains.
05-11-2013
Here is what I am seeing running the latest FX, Windows 7 under VMWare Fusion 4.0: Ensemble2 - flashes on resize Ensemble2 [-Dquantum.multithreaded=false] - does not flash on resize EnsembleApp - flashes on resize EnsembleApp [-Dquantum.multithreaded=false] - flashes on resize For me, the flag fixes the Ensemble2 native resize handles case. I am running under VMWare. The next step for me is to run on a real machine.
21-10-2013
Here is the patch that enables operating system resize handles for Ensemble2: diff --git a/ga-samples/Ensemble/src/ensemble/Ensemble2.java b/ga-samples/Ensemble/src/ensemble/Ensemble2.java --- a/ga-samples/Ensemble/src/ensemble/Ensemble2.java +++ b/ga-samples/Ensemble/src/ensemble/Ensemble2.java @@ -139,7 +139,7 @@ isApplet = false; } if (!isApplet) { - stage.initStyle(StageStyle.UNDECORATED); + //stage.initStyle(StageStyle.UNDECORATED); // create window resize button windowResizeButton = new WindowResizeButton(stage, 1020,700); // create root
21-10-2013
Thanks for checking this. There is nothing earlier than about b50, but that goes back more than a year, so it seems that the information about quantum.multithreaded=false ever fixing it was mistaken for this specific issue.
21-10-2013
I've tested b50, b60, b70, b80 and b90. In each case the problem is reproducible and quantum.multithreaded=false does not fix the issue. I cannot find earlier builds.
21-10-2013
I am running under VMWare and at some point in time, both Kevin and I saw the problem fixed with -Dquantum.multithreaded=false. This means that it should be possible to bisect and find the build and then the change that made the flag stop working. At this point, we would know that the bug "could be fixed" because we would have a working state.
18-10-2013
I can reproduce this when I switch to using my Intel HD GPU (I was using NVIDIA). I can confirm that both Ensemble and HelloBlinking occasionally show this problem. I can also confirm that -Dquantum.multithreaded=false has no effect (although it used to be a viable workaround).
18-10-2013
I have found that Firefox suffers from the same issue: https://bugzilla.mozilla.org/show_bug.cgi?id=672885 A short summary of the thread: 1. This is likely a bug in MS Windows. 2. There are a couple of possible workarounds, but all of them are not reliable. 3. MS support does not say anything about this issue. 4. I could not reproduce it in FF, but the issue is still open.
18-10-2013
I ran mine on Windows 7 with an NVIDIA chipset. I first ran the original Ensemble2 app, which uses an undecorated stage, but when that didn't reproduce the problem for me, I modified it locally to use a decorated stage. Now that I think about it, it's been a while since I've seen this.
17-10-2013
Windows 7. I am running EnsembleApp and resizing the bottom right corner like mad. Eventually the whole thing flashes black, then draws but not every time.
17-10-2013
It is not reproducible with the modified Ensemble. It's only reproducible with the original Ensemble2 with an undecorated stage. Do you run it on Win7 or 8? We were running it on different machines with different graphics cards, so it's not hardware specific.
17-10-2013
I no longer see the problem even without the flag. I tried both a modified Ensemble (using a decorated window) and the HelloBlinking test program. Since it is an intermittent failure, I may just not have run it for long enough.
17-10-2013
The property doesn't work for me either. At one point it did. Kevin and I confirmed it. We may have multiple problems here.
17-10-2013
Some more interesting results: if I switch windows to the classic theme (DWM is switched off) the issue disappears. This looks very similar to the following JDK bug: https://bugs.openjdk.java.net/browse/JDK-6600226
17-10-2013
Just tried the property. It does not fix the problem neither for Ensemble2 nor for my little example.
17-10-2013
Not sure why I can't find the original JIRA. The property that fixed it was -Dquantum.multithreaded=false. Please recreate the flash in EnsembleApp and verify that the property fixes it.
17-10-2013
I am running EnsembleApp that uses naive resize trim and it also flashes for me. I remember that Ensemble2 did not use native resizing trim from the work I did to implement live resizing. Thanks for attaching the app. There is a property whose name escapes me that has to do with making the UI thread wait until the Render thread is done before going to the next frame. This property fixed the issue. I will look for it and get back to this JIRA.
17-10-2013
I have narrowed the problem a little bit. It occurs because Ensemble2 is an undecorated stage and it's resized using Stage.setWidth/Height. I've attached a little application which could be used to reproduce the issue without using Ensemble. It blinks rarely and the concrete numbers of nodes/sleep time might be different for different machines.
17-10-2013
Ok, Thor is on this bug. Since Vadim fixed a low level D3D bug in the past, he may have a few ideas.
16-10-2013
Vadim, at one point, Thor told me that black flashing happens in D3D when there is a size mismatch on the surface where you are drawing. I'll add Thor if not here already and get his input.
16-10-2013
Couldn't check other pipelines, because they are extremely slow.
16-10-2013
I can see the flickering on my machine too. On Mac it's not reproducible, so it's platform-specific. It's also not reproducible with the smaller apps (smth from toys).
16-10-2013
Sorry Artem, I just got the latest code from mercurial and ran it under Windows. I run EnsembleApp and grab the bottom right corner and resize back and forth. After about 30 seconds, every once in a while, the window flashes black and then draws correctly.
11-10-2013
Not reproducible with the current (~b110) FX 8 build. Most likely it's the same issue as described in RT-24926.
11-10-2013
Still reproducible with javafx-sdk8.0.0-ea-b58
04-10-2012
Ensemble is used as a prime example and customer demo. It would be good to fix this in the next release. SQE / OK
19-07-2012