JDK-8149768 : JavaFX Application Performance Issue
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u66,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2016-02-12
  • Updated: 2017-01-25
  • Resolved: 2016-03-04
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.
8u102Fixed 9Fixed
Related Reports
Relates :  
JavaFX loads web page so slowly the Java application appears hung.

A web page ("visitor") containing JavaScript that allows a user to share their browser's view with another user ("agent") who is using a JavaFX-based browser.

The agent's viewing application appears to hang when the visitor's page has a background-color specified on a page with "iframe" that opens/closes. The specific background color is unimportant; it may be because the "flyout" background has opacity and this causes a problem when the main page has a background-color.
Changeset: de87459ed168 Author: arajkumar Date: 2016-03-04 09:08 -0800 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/de87459ed168 8149768: JavaFX Application Performance Issue Reviewed-by: kcr

+1 from me, too.

Here is the patch proposed by Anton and authored by Arunprasad: diff --git a/modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp b/modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp --- a/modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp +++ b/modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp @@ -852,6 +852,8 @@ settings.setLoadsImagesAutomatically(true); settings.setMinimumFontSize(0); settings.setMinimumLogicalFontSize(5); + // FIXME(arunprsad): Will be addressed in JDK-8148129. + settings.setAcceleratedCompositingEnabled(false); settings.setScriptEnabled(true); settings.setJavaScriptCanOpenWindowsAutomatically(true); settings.setPluginsEnabled(usePlugins);

+1 to apply the workaround as for now.

It was defined that enabling "prism-sw" pipeline with JVM option "-Dprism.order=sw" allows to workaround the hang during the 1st expanding (flying out) of the window on the test cases web page, but this leads to consumption of big amount of physical memory (> 800 MB) by Java process, so folding of the expanded window always leads to throwing of "java.lang.OutOfMemoryError: Java heap space" exception and immediate JVM crash with HS error log. Thus this JVM option cannot be considered as a workaround for the issue.

By suggestion from Arunprasad Rajkumar a possibility that the temporary fix for the bug JDK-8148129, which was created and integrated by Arunprasad in JavaFX 9 sandbox repository, resolves this bug was checked. It was practically proven that this temporary fix disabling accelerated composition resolves this bug in "9-dev" and "8u-dev" JavaFX repositories.

The following WebKit builds for OS X platform were used for checking the test case on OS X 10.9.5 without any involvement of Java and JavaFX and the issue itself could not be reproduced or any indication of increasing of memory consumption by WebKit could not be observed with any of them: - (02/25/2014) http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r164615.dmg - (11/21/2014) http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r176455.dmg - (06/11/2015) http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r185444.dmg Therefore it was concluded that it is impossible to reproduce the issue without involvement of JavaFX and identify which change in public WebKit could influence or resolve the issue in sandbox JavaFX 9. Currently debugging, tracing JavaFX 9 compiled from "9-dev" repository and sandbox JavaFX 9 to identify differences in their behavior with the test case.

It was verified that the third version of the fix (webrev.02) for the bug JDK-8149537 does not allow to resolve this issue in "openjfx/8u-dev". Currently trying to define which changes in the public version of WebKit resolved this issue.

It was defined that the issue is not reproducible with JRE 9 b106 or JRE 9 b95, which are manually combined with the latest sandbox build of JavaFX 9 containing the latest version of WebKit.

The issue was reproduced using the user's test case on 64-bit MS Windows 7 OS with 32-bit Chrome browser (48.0.2564.116), with: - JavaFX 8 compiled from the latest version of development source code. - JavaFX 9 from JRE 9 b106. Was able to observe that, if the solution (removal of CSS style assigning a background color to the web page) described by the user is applied, the issue is not reproducible on the same host with specified in previous passage JavaFX 8, JavaFX 9. Debugging showed that during the hang numerous identical exceptions "java.lang.NullPointerException" occur, certain texture objects cannot be created in the method "com.sun.prism.d3d.D3DResourceFactory.createRTTexture", because of memory lack. Call stack of the NPE is listed below. java.lang.NullPointerException at com.sun.javafx.webkit.prism.RTImage.getTexture(RTImage.java:81) at com.sun.javafx.webkit.prism.RTImage.getGraphics(RTImage.java:69) at com.sun.javafx.webkit.prism.WCBufferedContext.getGraphics(WCBufferedContext.java:64) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite.paint(WCGraphicsPrismContext.java:1485) at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.fillRect(WCGraphicsPrismContext.java:528) at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:107) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:93) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:108) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:115) at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:340) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:93) at com.sun.webkit.WebPage.paint2GC(WebPage.java:698) at com.sun.webkit.WebPage.paint(WebPage.java:665) at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:96) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330) at com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:134) 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) It was defined that the following measures did not allow to work around the issue: - Increasing Java heap size to (1 GB) using JVM option "-Xmx1g". - Increasing the maximum size of JavaFX native resource pool from the default 512 MB to 2 GB by means of the JVM option "-Dprism.maxvram=2G". It was defined that permanent consumption of 20% of CPU time during the hang is caused by Garbage Collector (GC) through numerous calls to "System.gc()", which are attempts to free memory in Java heap for creation of texture objects; and it was practically proven that removal of calls to "System.gc()" before attempts to create the requested textures removes the hang effect completely.