Bug ID: JDK-8094789 [D3D, WebView] Accelerated compositing goes black upon returning from screen lock or Clrt+Alt+Del

I think closing them as a duplicate, but making sure that they are linked in (not just referring to the bug in a comment, but use the "Link" feature) gives us the ability to know which bugs depended on the use of D3D9ex if we ever need to revert. Hopefully we can retire the non-ex code soon and then the issues will be both practically and theoretically historical... RT-23312 is probably a dup, but it also points out that we still have a problem with animating canvases on orphan scenes. We should probably open a new bug for that...
09-05-2014
I would note that the same logic applies to RT-23312 as well: Enabling D3D9Ex has made the issue go away. Another bug in the same camp is RT-32823 which I just verified no longer happens. In all three cases enabling D3D9Ex has resolved the problems, leaving us nothing more to do unless something goes wrong such that we have to revert it. We should handle all three bugs in the same manner, either by: 1) resolving them as a duplicate of RT-36571 2) resolving them as "Won't fix", indicating that the problem no longer occurs after the fix for RT-36571 (and that we don't plan to fix it independently of that). 3) leave them open, lower them to P5, and move them to the backlog (aka FX 9) I could be talked into any of the three, but have a preference for 2 (or even 1) over 3 -- we can always reopen them if we have to "roll-back" D3D9Ex again -- but that isn't a strong preference as long as we handle all three bugs consistently.
09-05-2014
Technically, the switch is also still there in some small part to acknowledge that we haven't had enough field testing with ex to rely on it. At what point do we decide that the switch is no longer "in case we need to revert" and is fully vestigial? Probably post 8u20 ship? Maybe 9?
08-05-2014
Jim has a valid point about it not really being a duplicate. However, I still do not think this bug needs to be fixed unless / until there is a good reason for us to do it (e.g., if there were a supported platform / case where D3D9Ex failed to initialize). The fact that there is an unsupported system property that a developer could set to cause this problem is not sufficient reason to fix this. So we could reopen and then close the bug as "Won't fix", but I don't see a good reason to reopen it and leave it open.
08-05-2014
Yes, isVolatile returns false with D3D9Ex enabled. And I agree that we should implement something like Canvas did and read back pixels and save them. Alternatively, could we save the commands stream used for painting?
08-05-2014
Until we remove the runtime flag to disable D3D9ex, then this isn't really fixed so closing it as a dup of the bug that simply made D3D9ex the default isn't really appropriate until we fully commit to D3D9ex as the only option. The Canvas code still protects against device lost conditions because they can still be enabled...
08-05-2014
FYI - permanent simply meant that the ManagedResource system would not voluntarily release it to free up space, it did not prevent platform-based system loss which is why the isVolatile() method exists and why Canvas had to save the pixels even though it also marked the texture as permanent. D3D9ex now means that the platform will no longer delete textures either so isVolatile() should now return false in all cases. Also, the D3D9ex runtime flag still exists so if anyone ever runs JavaFX with that flag set to disable D3D9ex, then we can still lose textures on device lost...
08-05-2014
Sounds reasonable to me. So close as a duplicate of RT-36571.
07-05-2014
Can we just close this bug? It seems fixed to me other than the hypothetical case that Vadim describes. We can reopen should a customer hit the case.
07-05-2014
I don't think it's supported case, but it seems that it's possible to install old (XPDM) video driver in Vista+, and in this case D3D9Ex will be unavailable.
07-05-2014
Yes, this is no longer reproducible with D3D9Ex enabled since there are no device lost events happening and render targets remain valid.
07-05-2014
If you can confirm my findings that this bug no longer happens with D3D9Ex enabled (that is, after the fix for RT-36571) then we can lower the priority of the bug (to P5) and targeted for FX 9.
07-05-2014
The problem here is that WebView doesn't re-render Canvas objects after device lost event. The tests from RT-36192 (http://people.iola.dk/olau/flot/examples/graph-types.html) and CanvasTest's FullTutorial are much more reliable than solar system since it has rendering problems by itself. As Jim noted in the RT-32845: "The reason the Canvas backbuffer is marked permanent is that we have absolutely no way to reconstruct it since the commands used to render it were lost after we ran them. We plan to eventually introduce API for developers to listen for texture-loss events and repair them, but until we have such an API, we mark them permanent." Apparently marking render target permanent doesn't prevent it from being released when the device is lost.
07-05-2014
Thanks for confirming. Are there any supported cases where attempting to create a D3D9Ex device will fail? (note that Windows/XP is not supported)
07-05-2014
I just ran the same tests with the proposed fix for RT-36571 and the problem is gone. So once that fix goes in we may not have to fix this case (it would only be important if D3D9Ex is not available on the platform for some reason, and since Java 8 does not support Winndows/XP this should never happen).
02-05-2014
Note that is WebView only. Other apps including Ensemble8 are fine. So either WebView has a bug, or it exposes a bug in Prism.
02-05-2014
Tried the following web sites: FAILS: http://people.iola.dk/olau/flot/examples/graph-types.html (from RT-36192) http://yahoo.com/ (but comes back if I resize it) WORKS: http://oracle.com/
02-05-2014
See RT-36192 for another test case for this bug.
20-03-2014
Note: the bug described in this JIRA is Windows-specific and something that I believe we can defer. However, there are some very serious rendering problems that are platform-independent and are a regression from 2.x. We have filed a separate bug, RT-34443, to track this as a separate issue.
21-11-2013
I think we need to fix this if at all possible.
20-11-2013
I just ran this and it's pretty bad. Note that it depends on RT-32845 being fixed, since the application gets errors relating to texture resources even before I go into screen lock.
16-11-2013
Is it a regression? What is the behaviour on FX 2 ? Need justification for deferral.
15-11-2013

Blocks :	JDK-8123125 - WebView keeps permanent back buffers for HTML pages and Canvas objects, can cause NPE
Duplicate :	JDK-8095319 - JavaFX webview issue with Hardware Acceleration ON
Duplicate :	JDK-8094123 - WebView with HTML Canvas content fails to render after lock workstation or RDP
Duplicate :	JDK-8093950 - [D3D] Re-enable DirectX 9Ex to avoid losing textures when surface lost
Relates :	JDK-8097381 - [WebView] solar system web page is slow, has rendering problems and throws exceptions
Relates :	JDK-8101730 - Implement and enable accelerated compositing to improve WebView rendering performance
Relates :	JDK-8093950 - [D3D] Re-enable DirectX 9Ex to avoid losing textures when surface lost