Bug ID: JDK-8091556 Improve performance of rendering a TRANSPARENT stage on Windows 7

Type: Enhancement
Component: javafx
Sub-Component: graphics
Affected Version: fx2.0

Priority: P3
Status: Open
Resolution: Unresolved

Submitted: 2011-10-19
Updated: 2018-09-05

Other
tbdUnresolved

Rendering to a Stage created with StageStyle.TRANSPARENT is slower and takes more CPU resources than rendering to a DECORATED or UNDECORATED Stage.

We should consider improving the performance of rendering to transparent stages.

I can also say that we are experiencing similar issues. In my case I do not have high cpu usage, my gpu load spikes through the roof. up to 100% (consistant) usage at times. To the point where I can physically hear it churning on even the slightest interaction with the stage. My uneducated guess is that there are probably some shader issues at the core of the problem. This is my -prism.verbose printout: Prism pipeline init order: d3d sw Using platform text rasterizer Using native-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D native library ... succeeded. D3DPipelineManager: Created D3D9Ex device Direct3D initialization succeeded (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline Maximum supported texture size: 16384 Maximum texture size clamped to 4096 OS Information: Windows 7 build 7601 D3D Driver Information: NVIDIA GeForce GTX 760 \\.\DISPLAY1 Driver nvd3dumx.dll, version 9.18.13.4709 Pixel Shader version 3.0 Device : ven_10DE, dev_1187, subsys_098410DE Max Multisamples supported: 4 vsync: true vpipe: true
11-02-2015
Using 1.8.0_40 ea b22, 64-bit o Win 8.1 64-bit, two screens, both beynd Full-HD: The issue you posted seems similar, although i don have high memory issues, just CPU load. I have AMD 4-core 3.4GHz. When i create a transparent stage spanning both screens (the screen number isnt an issue, the problem clearly scales with resolution), adding up to 4480x2440px = 6.5Mpx, even just moving the nodes (using mouse drag events) within the scene laggs a lot. FPS for the whole application basically drops to about 10. If I make transparent stage for just 2560x1440, the FPS goes up a notch. Using UNDECORATED stage instead completely gets rid of the issue. Mu CPU load for the dual screen mode is 55% with transparent and 3% with undecorated stage and 0% for both when no dynamic content (like animations and other movements) is active. Memory consumption in TaskManager is 380MB for transparent stage and 260MB for undecorated. Also, it was mentioned in the posted issue that the performance/memory drops even when the stage is not manipulated with, it happens even when only scene content changes. I can confirm this. At one moment the whole application is static with only single slider control being animated (bound to MediaPlayer position) and CPU load is about 20%, if i pause the playback, the CPU load drops to 0. Naturally, the playback is not causing the cpu load (it takes about 4% load to play some more compressed songs). This happens even when node functioning as window is not transparent - meaning the content that changes is layed out on opaque bgr. Using 32bit java: cpu load went down 10% to 40% for transparent stage, and FPS went up a tiny bit still maybe around 15. Memory consumption went down to 160 for transparent and 120 for undecorated stage. Still completely unusable. So, it really seems (from my point of view - pow of a clueless developer) that there is some problem with stage being redrawn ineffectively, quite possibly whole or majority of it (due to opacity mask?) on every pulse. With transparent stage sizes up FullHD resolution the problem isnt very noticable, but then it gets blown out of proportions very quickly (well, as we know, the thing with resolutions is that they scale O(n^2)...) I dont want to think that 5k resolution is something that needs to be taken very seriously, not in 2015, and particularly when undecorated stage works fluidly, in fact i was pleasantly surprised at the scene performance at that resolution (my single stage solution for multiple in-stage windows implemented as nodes), despite being used to great javaFX gui performance.
31-01-2015
@David: what version of JDK / FX are you running? If you are still running 8u31 or earlier, then you are likely hitting RT-34467. If you are running 8u40-ea then you may be hitting this issue or a different performance issue.
30-01-2015
I just came to face this problem as well. The performance of my app that performs just fine with normal stage drops drastically. My application requires an overlay layer, which can not be implemented with Node inside window. In addition i have multiple windows, which need to share this overlay. Using transparent Stage above them is not an option because it consumes the mouse events. I ended up implementing the windows as Nodes within a single TRANSPARENT Stage spanning whole screen (multiple of them in fact). But this solution performs so bad, the application is unusable. If i use UNDECORATED style, the performance is amazing and all window operations are blazing fast, but needless to say - there is white covering the rest of the screen. Isnt there something i could do, like making undecorated stage transparent, or some other workaround?
30-01-2015
The only update on this is that we have fixed a problem with memory thrashing in 8u40 that would occur with complex scene in a transparent stage. See RT-34467. I recommend you download an early access build of 8u40 and try it. As for the issue of reducing the per-frame overhead of copying the back buffer to the window, which is what this issue is tracking, the work is not yet planned or scoped to any release.
21-11-2014
Any updates on this one? I have quite a complex Scene, and as soon as I pass the TRANSPARENT flag, the app becomes completely unusable. The issue appears to be related to the complexity of the Scene.
21-11-2014
This is unplanned for FX 8.
02-08-2013
Any progress on this? In JFX8 b99 there is still a huge noticable difference between using a transparent and non-transparent stage (even if the transparent stage is not truly transparent, but only part of the time). I'm not a fan of the hacky work-around of moving a Scene from one type of stage to another depending on the transparentness of its fill property. mainStage = new Stage(StageStyle.UNDECORATED); transparentStage = new Stage(StageStyle.TRANSPARENT); private void display() { Paint paint = scene.getFill(); if(paint instanceof Color && ((Color)paint).getOpacity() == 1.0) { System.out.println(">>> Switching to normal stage"); displayOnStage(mainStage, transparentStage); } else { System.out.println(">>> Switching to transparent stage"); displayOnStage(transparentStage, mainStage); } } private void displayOnStage(Stage newStage, Stage oldStage) { oldStage.setScene(null); newStage.setScene(scene); newStage.show(); setupStageLocation(newStage); newStage.toFront(); oldStage.hide(); }
27-07-2013
http://xboxforums.create.msdn.com/forums/p/109006/644025.aspx#644025
13-11-2012
My thread on MSDN (un-answered) : http://social.msdn.microsoft.com/Forums/ru-RU/windowssdk/thread/e4a90d84-62f0-4726-a8c5-71bd466b74ee
24-09-2012
This is unlikely to happen for Linux, but will be targeted to 3.0 for Windows platforms since we stop running the HW-accelerated pipeline on Windows XP.
10-07-2012
We also need this feature in Linux.
06-07-2012
It is about to use D3D9Ex (Visdows 7 feature) to provide better dataflow for rendering transparent surfaces on windows
20-03-2012

Duplicate :	JDK-8101000 - CPU usage increases heavily when using StageStyle TRANSPARENT
Relates :	JDK-8095722 - Win: Huge Memory Consumption for Transparent Stage
Relates :	JDK-8092162 - Improve performance of rendering a TRANSPARENT stage on Linux
Relates :	JDK-8093950 - [D3D] Re-enable DirectX 9Ex to avoid losing textures when surface lost