JDK-8091385 : PresentingPainter and UploadingPainter disregarding dirty clip rect
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.1
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-03-14
  • 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
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
The PresentingPainter's run method has a call to presentable.prepare in which it passes a null. This ends up taking an enormous amount of time. Passing the clip makes this much faster. I don't think that passing the clip is the only thing that needs to be done here (it is so slow, measuring > 100ms, that it implies that whenever the entire scene has been redrawn that we will see sub <10fps performance which is unacceptable).

Nevertheless, this patch seems to fix the issue for FishSim.


diff -r 022ed295ff86 -r be94eec3b5b2 javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PresentingPainter.java
--- a/javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PresentingPainter.java    Wed Mar 14 04:36:56 2012 +0100
+++ b/javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PresentingPainter.java    Wed Mar 14 04:37:14 2012 +0100
@@ -73,7 +73,7 @@
                     paintImpl(g);
                 }

-                if (!presentable.prepare(null)) {
+                if (!presentable.prepare((g == null ? null : g.getClipRect())) {
                     disposePresentable();
                     scene.entireSceneNeedsRepaint();
                     return;

Comments
Priority should be P3.
01-10-2013

We need to look again when the back-buffer is preserved between frames (right now, its not).
30-05-2013

The patch is not useful.
15-05-2013

I tried this patch today on the PI and it didn't make any impact on performance (but did cause rendering problems). Will need much deeper analysis.
15-05-2013

Kevin, I believe you meant RT-24168 in the above comment. Note that it's only required for UploadingPainer. The PresentingPainter does not call uploadPixels(), and thus doesn't depend on RT-24168.
31-08-2012

Doing this for the UploadingPainter will require RT-21468 to be implemented.
10-08-2012

Is this really a critical issue? If so, do we have a plan to address it?
19-05-2012

Both PresentingPainter and UploadingPainter are ignoring the clip rect value created from the dirty rect culling operation. In the PresentingPainter case passing null to prepare causes the whole back buffer to be swapped each time. In the UploadingPainter case we create Pixels at the underlying view size for upload without taking into account the clip rect (this is seen in http://javafx-jira.kenai.com/browse/RT-19897).
16-03-2012

The patch as shown is incorrect (or incomplete) since it causes incorrect clipping. A real solution will need to be found.
16-03-2012

Performance issues of this magnitude will be marked as critical for 2.2
14-03-2012