JDK-8093884 : [Canvas] Gui is getting slow, Controls are not redrawn
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2014-04-10
  • Updated: 2015-06-12
  • Resolved: 2014-09-17
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
8u40Resolved
Related Reports
Relates :  
Description
After opening and closing new windows and drawing to different canvas the complete GUI in all open java windows are not updated/redrawn correctly anymore.

Buttons disappear and are getting redrawn only when the mouse cursor is above the "invisible" control. Same for Tabs, TextField, custom controls,.....

Complete code is to big to be posted here. If necessary i can try to produce a simple test application.
Comments
This was likely fixed by any of: RT-37300: Canvas needs a fast rectangular clip capability RT-37793: Performance issues on Canvas clearing temp and clip buffers RT-30107: NGCanvas should take advantage of new 1-step clipping support Those were the major issues fixed in 8u40 (particular the first 2) which would have the most potential to improve performance for applications. In any case the original submitters no longer see a problem in 8u40 so I'll close as "not an issue".
17-09-2014

It seems that we can close as not an issue now.
17-09-2014

Should we close this bug then?
16-09-2014

8u40 rocks :-) Thanks for this tip :-)
29-08-2014

Just run a test with the latest 8u40 early access release and it seems like the problem got solved. Also general drawing performance improved dramatically. Under certain circumstances who also provoke the problem it feels like 50times faster compared to 8u20
28-08-2014

I was running into the same problem with my application and was about to check the reason with a simple GUI build with Scene Builder. Structure is: AnchorPane->BorderPane->TabPane with 12 Tabs and each contains a canvas. If I open each canvas (e.g. going down in the left Document-Hierarchy accordion in Scene Builder with the keyboard KeyDown and KeyLeft) the Scene Builder also hangs after short time... The FXML file is on pastebin: http://pastebin.com/EJ5B6Ug5 Btw: Using -Dprism.order=sw "solves" my original problem, but the speed is not funny... ;-) My System is on java version "1.8.0_20-ea" on MacOS 10.10 (Develop version / Yosemite) Exception in my application was: Prism pipeline init order: es2 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.es2.ES2Pipeline Loading ES2 native library ... prism_es2 succeeded. GLFactory using com.sun.prism.es2.MacGLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline Non power of two texture support = true Graphics Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce GT 650M OpenGL Engine Version: 2.1 NVIDIA-10.0.38 310.41.05b22 Maximum supported texture size: 16384 Maximum texture size clamped to 4096 vsync: true vpipe: true ��� Loading Prism common native library ... succeeded. java.lang.NullPointerException at com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:202) at com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:615) at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:578) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:474) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:327) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.lang.Thread.run(Thread.java:745) ERROR: unexpected fbo is bound! Expected 1, but found 2
28-08-2014

You may be using more texture resources than the standard budget allows for. If dirty opts solves the problem then that could be an indicator that you are causing the outstanding textures to be flushed constantly (which causes us to lose the back buffer on Mac currently per RT-36790). If you increase the standard allocations of vram then that could fix both the repaint problems (until we fix RT-36790) and improve performance. -Dprism.maxvram=###m to set the maximum useable vram to that number of megabytes -Dprism.targetbram=###m is the target we try to stay under, the default is 3/4 of the max, but you can play with that as well independently (though it must be less than the max) (Edited to correct the bug number I was referencing as a possible root cause...)
25-04-2014

Note that if you increase the vram limits and you no longer need dirtyopts=false then that is a clear indicator that you are running into RT-36790. (Edited to correct the bug I was referencing as a possible root cause here...)
25-04-2014

That moment when it dropped from 200m used to 26m used was one of the dramatic purges which likely freed the back buffer. This will only happen with more than one open stage since typically the back buffer is locked during the rendering of a single stage so you should only lose one stage's back buffer while another stage triggers the low-vram condition. Our current texture management heuristics are fairly simplistic and we plan to revisit them soon under RT-36566. RT-36790 should fix the "losing the back buffer" issue even earlier than that - we may still lose the back buffer then, but it won't cause repaint issues. Another issue that could be affecting you is why you grew to 150 "resources contain interesting data". My first guess for that would be that you are using a lot of images over time - which would grow the number of textures in the image->texture cache. Currently those are last on the list of "things to dump" even if they haven't been used in many, many frames - so by the time we decide to dump those, nearly everything else in the system that isn't tied down gets dumped as well (including the back buffer currently). More sophisticated heuristics under RT-36566 will help to get rid of cached "image textures" earlier and keep the vram churn on a lighter note.
25-04-2014

Hi, setting the vram limit to a higher value improves the situation. It takes longer until the Not Redraw problem occurs, but it doesnt eliminate it. Even 7000mb does not resolve the problem completely. There are no more canvas objects used. I think the problem occurs in the moment when you clean up the vram. Here is a vram status report: ES2 Vram Pool: 200.165.744 used (74,6%), 200.165.744 managed (74,6%), 268.435.456 total 156 total resources being managed average resource age is 65.4 frames 0 resources at maximum supported age (0,000000) 6 resources marked permanent (3,800000) 0 resources have had mismatched locks (0,000000) 0 resources locked (0,000000) 151 resources contain interesting data (96,800000) 0 resources disappeared (0,000000) ES2 Vram Pool: 200.703.160 used (74,8%), 200.703.160 managed (74,8%), 268.435.456 total 163 total resources being managed average resource age is 63.5 frames 0 resources at maximum supported age (0,000000) 6 resources marked permanent (3,700000) 0 resources have had mismatched locks (0,000000) 0 resources locked (0,000000) 151 resources contain interesting data (92,600000) 0 resources disappeared (0,000000) /*********************************************************** ----> from here on controls are not beeing redrawn /*********************************************************** ES2 Vram Pool: 26.024.304 used (9,7%), 26.024.304 managed (9,7%), 268.435.456 total 17 total resources being managed average resource age is 0.6 frames 0 resources at maximum supported age (0,000000) 6 resources marked permanent (35,300000) 0 resources have had mismatched locks (0,000000) 0 resources locked (0,000000) 11 resources contain interesting data (64,700000) 0 resources disappeared (0,000000) 59400 [AppKit Thread] DEBUG de.srm.srmx.chart.singleLine.SingleLineChart - repaint 59400 [AppKit Thread] DEBUG de.srm.srmx.chart.ChartPane - paint ChartPane
25-04-2014

-Dprism.dirtyopts=false resolves the problem. However i see a big degradation in performance. My special case is a couple of path and line nodes beeing partly overlayed by a half transparent pane. When maximizing the window to 2560x1440 and dynamically changing the size of the pane the performance is very poor. Performance and appearance of the problem are independent of the node count. Its the same behavior with less than 25 as with around 4000; Canvas objects are completely eliminated from the project now.
24-04-2014

It is only similar to RT-36603 if you are getting errors. If you are simply seeing items not being redrawn, and if they redraw correctly with "-Dprism.dirtyopts=false", then it is likely more related to RT-36790 which is where we lose the back buffer due to resource drains coming from excessive texture use (and Canvas objects use persistent textures so they can have a high cost for our vram resource usage). Also, setting larger vram limits may help with the issues listed in RT-36603 - "-Dprism.maxvram=###m", "-Dprism.targetvram=###m" where ### are larger than the defaults of max=256m and target=192m.
23-04-2014

Problem only occurs with hardware renderer. When forcing the sw renderer via -Dprism.order=sw, no problem. However its substantialy slower. Problem occurs either by heavy node adding/removing from the scene graph or by maximizing, minimizing a window a couple of times and adding/removing the nodes to the window during resizing. Here are the prism status messages for sw and hw renderer: SW: Prism pipeline init order: 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 *** Fallback to Prism SW pipeline Prism pipeline name = com.sun.prism.sw.SWPipeline (X) Got class = class com.sun.prism.sw.SWPipeline Initialized prism pipeline: com.sun.prism.sw.SWPipeline vsync: true vpipe: false HW:Prism pipeline init order: es2 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.es2.ES2Pipeline Loading ES2 native library ... prism_es2 succeeded. GLFactory using com.sun.prism.es2.MacGLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline Non power of two texture support = true Maximum supported texture size: 16384 Maximum texture size clamped to 4096 Graphics Vendor: Intel Inc. Renderer: Intel HD Graphics 4000 OpenGL Engine Version: 2.1 INTEL-8.24.11 vsync: true vpipe: true
23-04-2014

This is almost certainly a graphics issue relating to Canvas.
11-04-2014

The window itself is visible, but all kind of child nodes are not drawn. For me it seems related to RT-36603 So far i can reproduce the problem when i open a child window with a tabpane and each tab contains a couple of canvas bound to the size of the tab. As soon as the window has a height >1200pixel and i changed the tabs a couple if times the problem starts. See Description above. As far as i can see there are no exceptions thrown. I am using a Mac Display with 2560x1440 resolution. The affected software can be downloaded here: http://update.srm.de/srmmacv2.0RC1.dmg
11-04-2014

Can you clarify what you see when the gui isn't updated or redrawn? Is the window black?
10-04-2014