From chien.yang at oracle.com Tue Nov 1 03:37:18 2016 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 31 Oct 2016 20:37:18 -0700 Subject: [9] Code Review Request For 8168616: -Xcheck:jni indicates there are missing exception checks in Font Message-ID: <58180DEE.5060008@oracle.com> Hi Phil, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8168616 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8168616/webrev.00/ Thanks, - Chien From mike.ennen at gmail.com Tue Nov 1 23:56:17 2016 From: mike.ennen at gmail.com (Michael Ennen) Date: Tue, 1 Nov 2016 16:56:17 -0700 Subject: Occasional Canvas Error (stacktrace) Message-ID: I have implemented a "candle stick chart" using the JavaFX canvas API. I have transitioned from using the charts API because after experimenting heavily with the chart API I came to the conclusion that for a (auto)-zooming, scrolling, and dynamically updated chart with various graphical indicators with *precise* control the canvas API better fit my needs. My implementation relies on the following canvas API methods: beginPath, clip, clearRect, closePath, fill, lineTo, moveTo, restore, rect, save, setFont, setFill, setStroke, setLineWidth, stroke, strokeRect, and strokeText. Sometimes I run into the following exception when the chart is being rendered, but a second attempt at rendering (which is triggered by, for example, scrolling or zooming the chart) always makes it work again. This exception is seen only rarely and I have not been able to come up with a simplified test case that exhibits the error in a deterministic fashion, unfortunately. I realize that the likelihood of being able to fix the error with only the stack trace is slim, but I thought I may as well give a report of it just in case (and was encouraged by the fact that the entire code-path starts and stays inside the JavaFX code base (i.e. none of my code is actually present in the stack trace). Here is the full stack trace: java.nio.BufferOverflowException at com.sun.javafx.sg.prism.GrowableDataBuffer.ensureReadCapacity(GrowableDataBuffer.java:317) at com.sun.javafx.sg.prism.GrowableDataBuffer.getInt(GrowableDataBuffer.java:527) at com.sun.javafx.sg.prism.GrowableDataBuffer.getFloat(GrowableDataBuffer.java:563) at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:957) at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:606) 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.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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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: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:323) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) 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) java.lang.InternalError: Unrecognized PGCanvas token: 67 at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1157) at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:606) 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.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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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: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:323) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) 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) java.lang.InternalError: Unrecognized PGCanvas token: 107 at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1157) at com.sun.javafx.sg.prism.NGCanvas.renderForcedContent(NGCanvas.java:626) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:332) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) 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) java.lang.ClassCastException: com.sun.prism.paint.Color cannot be cast to com.sun.javafx.font.PGFont at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1000) at com.sun.javafx.sg.prism.NGCanvas.renderForcedContent(NGCanvas.java:626) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:332) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) 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) java.lang.ClassCastException: com.sun.javafx.font.PrismFont cannot be cast to java.lang.String at com.sun.javafx.sg.prism.NGCanvas.handleRenderOp(NGCanvas.java:1361) at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1097) at com.sun.javafx.sg.prism.NGCanvas.renderForcedContent(NGCanvas.java:626) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:332) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) 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) java.lang.ClassCastException: com.sun.prism.paint.Color cannot be cast to java.lang.String at com.sun.javafx.sg.prism.NGCanvas.handleRenderOp(NGCanvas.java:1361) at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1097) at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:606) 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.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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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:2294) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) 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: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.PresentingPainter.run(PresentingPainter.java:91) 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) Thanks very much, and sorry for not being able to provide a replicable test case. -- Michael Ennen From dave at jfree.org Wed Nov 2 07:18:40 2016 From: dave at jfree.org (David Gilbert) Date: Wed, 2 Nov 2016 08:18:40 +0100 Subject: Occasional Canvas Error (stacktrace) In-Reply-To: References: Message-ID: <482BE071-C1DC-45BF-839C-B6368EB6CDC8@jfree.org> I had something similar reported for JFreeChart running on JavaFX - see this thread: http://www.jfree.org/forum/viewtopic.php?f=3&t=117577 In the end it seems to have been caused by UI calls coming from another thread, so you should check if your code is doing this. Best regards, David Gilbert http://www.jfree.org/ > On 2 Nov 2016, at 00:56, Michael Ennen wrote: > > I have implemented a "candle stick chart" using the JavaFX canvas API. I > have transitioned from using the charts API because after experimenting > heavily with the chart API I came to the conclusion that for a > (auto)-zooming, scrolling, and dynamically updated chart with various > graphical indicators with *precise* control the canvas API better fit my > needs. My implementation relies on the following canvas API methods: > > beginPath, clip, clearRect, closePath, fill, lineTo, moveTo, restore, rect, > save, setFont, setFill, setStroke, setLineWidth, stroke, strokeRect, and > strokeText. > > Sometimes I run into the following exception when the chart is being > rendered, but a second attempt at rendering (which is triggered by, for > example, scrolling or zooming the chart) always makes it work again. This > exception is seen only rarely and I have not been able to come up with a > simplified test case that exhibits the error in a deterministic fashion, > unfortunately. > > I realize that the likelihood of being able to fix the error with only the > stack trace is slim, but I thought I may as well give a report of it just > in case (and was encouraged by the fact that the entire code-path starts > and stays inside the JavaFX code base (i.e. none of my code is actually > present in the stack trace). > > Here is the full stack trace: > > java.nio.BufferOverflowException > at > com.sun.javafx.sg.prism.GrowableDataBuffer.ensureReadCapacity(GrowableDataBuffer.java:317) > at > com.sun.javafx.sg.prism.GrowableDataBuffer.getInt(GrowableDataBuffer.java:527) > at > com.sun.javafx.sg.prism.GrowableDataBuffer.getFloat(GrowableDataBuffer.java:563) > at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:957) > at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:606) > 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.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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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: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:323) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > 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) > java.lang.InternalError: Unrecognized PGCanvas token: 67 > at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1157) > at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:606) > 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.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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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: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:323) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > 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) > java.lang.InternalError: Unrecognized PGCanvas token: 107 > at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1157) > at > com.sun.javafx.sg.prism.NGCanvas.renderForcedContent(NGCanvas.java:626) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:332) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > 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) > java.lang.ClassCastException: com.sun.prism.paint.Color cannot be cast to > com.sun.javafx.font.PGFont > at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1000) > at > com.sun.javafx.sg.prism.NGCanvas.renderForcedContent(NGCanvas.java:626) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:332) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > 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) > java.lang.ClassCastException: com.sun.javafx.font.PrismFont cannot be cast > to java.lang.String > at > com.sun.javafx.sg.prism.NGCanvas.handleRenderOp(NGCanvas.java:1361) > at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1097) > at > com.sun.javafx.sg.prism.NGCanvas.renderForcedContent(NGCanvas.java:626) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.sg.prism.NGGroup.renderForcedContent(NGGroup.java:198) > at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:332) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > 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) > java.lang.ClassCastException: com.sun.prism.paint.Color cannot be cast to > java.lang.String > at > com.sun.javafx.sg.prism.NGCanvas.handleRenderOp(NGCanvas.java:1361) > at com.sun.javafx.sg.prism.NGCanvas.renderStream(NGCanvas.java:1097) > at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:606) > 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.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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2053) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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:2294) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2188) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2214) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2047) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) > 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: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.PresentingPainter.run(PresentingPainter.java:91) > 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) > > Thanks very much, and sorry for not being able to provide a replicable test > case. > > -- > Michael Ennen From hastebrot at gmail.com Wed Nov 2 16:31:37 2016 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 2 Nov 2016 17:31:37 +0100 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() Message-ID: Hey! Are there plans to expose this API [1] in JavaFX 9? // NOTE: Add the following if we decide to expose it publicly // public static void runAndWait(Runnable runnable) { // PlatformImpl.runAndWait(runnable); // } [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/ application/Platform.java#l148 --Benjamin From kevin.rushforth at oracle.com Wed Nov 2 16:36:58 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Nov 2016 09:36:58 -0700 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: References: Message-ID: <581A162A.9010305@oracle.com> No. This isn't something we will do for JDK 9, which is feature complete (with an exception process for critical requests, especially relating to Jigsaw). I note in this case that it isn't clear whether we want to do this one at all. -- Kevin Benjamin Gudehus wrote: > Hey! > > Are there plans to expose this API [1] in JavaFX 9? > > // NOTE: Add the following if we decide to expose it publicly > // public static void runAndWait(Runnable runnable) { > // PlatformImpl.runAndWait(runnable); > // } > > [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ > 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/ > application/Platform.java#l148 > > --Benjamin > From hastebrot at gmail.com Wed Nov 2 16:50:43 2016 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 2 Nov 2016 17:50:43 +0100 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: <581A162A.9010305@oracle.com> References: <581A162A.9010305@oracle.com> Message-ID: Hi, Kevin. Thanks for the info! On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth wrote: > No. This isn't something we will do for JDK 9, which is feature complete > (with an exception process for critical requests, especially relating to > Jigsaw). I note in this case that it isn't clear whether we want to do this > one at all. > > -- Kevin > > > > Benjamin Gudehus wrote: > >> Hey! >> >> Are there plans to expose this API [1] in JavaFX 9? >> >> // NOTE: Add the following if we decide to expose it publicly >> // public static void runAndWait(Runnable runnable) { >> // PlatformImpl.runAndWait(runnable); >> // } >> >> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ >> 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/ >> application/Platform.java#l148 >> >> --Benjamin >> >> > From David.Hill at Oracle.com Wed Nov 2 16:55:49 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 02 Nov 2016 12:55:49 -0400 Subject: Review: Switch to Jigsaw-aware boot JDK for compiling FX 9 Message-ID: <581A1A95.7050109@Oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8161704 Webrev: http://cr.openjdk.java.net/~ddhill/8161704/ Kevin, Chien, Vadim, There is a lot of change in this webrev, but there are a lot of common patterns (or sets of changes) ./apps - the majority of the change is altering the NB project files to use rt/build/compile.args and run.args via a relative path. This is a replacement action for using jfxrt.jar (and something I will address in a follow on email) Also, a new pattern for apps that need --add-exports lines to run properly (like Robot), we have added a file: || *apps/tests/HelloTest/addExports *that will used as an @argfile with the run command. This allows greater visibility into the added command than hiding them in the project.properties files. Under ./modules/ there is two classes of renames /module-info/module-info.java --> / *java/module-info.java * /test/java/com --> / *shims/java/com *Module-info.java is needed by javac, and so moving into the "main" set makes sense. It does mean however that IDEs may get upset because this is JDK9 syntax. The "shim" classes were mixed in with the general test classes. No more. Now they are in the "shim" set to allow us to build them as part of a rebuild of the main module classes to create a shim-ed module for testing. It also means we don't have to play include/exclude games when building. Under packager, there is a different class of move/renames, creating " *src/antplugin". *These sources are used to build a separate jar for use with ant. We needed to move these out of the main set because the would cause javac failure - but gained an additional benefit of a clear separation of sources. What is left is changes related to: ripping out build/sdk adding in a modular build creating rt/build/*.args argfiles to ease development. A big notes: we had to change the build target to 1.9 javac.source=1.9 javac.target=1.9 because in many of the places javac would baulk at using the JDK9 commands without it. It is expected that the current IDEs may not like that. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From philip.race at oracle.com Wed Nov 2 17:01:44 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 2 Nov 2016 10:01:44 -0700 Subject: Review: Switch to Jigsaw-aware boot JDK for compiling FX 9 In-Reply-To: <581A1A95.7050109@Oracle.com> References: <581A1A95.7050109@Oracle.com> Message-ID: David, I generally make the following request of "large" reviews : One thing that would help a lot here is if the "important" files were at the top rather than buried due to lexical sorting by path name. In particular files like build.gradle and so on .. people then get a sense of what it is about rather than first wading through the noise. -phil. On 11/2/2016 9:55 AM, David Hill wrote: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8161704 > Webrev: http://cr.openjdk.java.net/~ddhill/8161704/ > > Kevin, Chien, Vadim, > > There is a lot of change in this webrev, but there are a lot of common > patterns (or sets of changes) > > ./apps - the majority of the change is altering the NB project files > to use rt/build/compile.args and run.args via a relative path. This is > a replacement action for using jfxrt.jar (and something I will address > in a follow on email) > > Also, a new pattern for apps that need --add-exports lines to run > properly (like Robot), we have added a file: > || *apps/tests/HelloTest/addExports > *that will used as an @argfile with the run command. This allows > greater visibility into the added command than hiding them in the > project.properties files. > > Under ./modules/ there is two classes of renames > /module-info/module-info.java --> / *java/module-info.java > * /test/java/com --> / *shims/java/com > *Module-info.java is needed by javac, and so moving into the "main" > set makes sense. It does mean however that IDEs may get upset because > this is JDK9 syntax. > > The "shim" classes were mixed in with the general test classes. No > more. Now they are in the "shim" set to allow us to build them as part > of a rebuild of the main module classes to create a shim-ed module for > testing. It also means we don't have to play include/exclude games > when building. > > Under packager, there is a different class of move/renames, creating > " *src/antplugin". *These sources are used to build a separate jar for > use with ant. We needed to move these out of the main set because the > would cause javac failure - but gained an additional benefit of a > clear separation of sources. > > What is left is changes related to: > ripping out build/sdk > adding in a modular build > creating rt/build/*.args argfiles to ease development. > > A big notes: we had to change the build target to 1.9 > javac.source=1.9 > javac.target=1.9 > because in many of the places javac would baulk at using the JDK9 > commands without it. It is expected that the current IDEs may not like > that. > From David.Hill at Oracle.com Wed Nov 2 17:35:48 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 02 Nov 2016 13:35:48 -0400 Subject: Review: Switch to Jigsaw-aware boot JDK for compiling FX 9 In-Reply-To: References: <581A1A95.7050109@Oracle.com> Message-ID: <581A23F4.1080201@Oracle.com> On 11/2/16, 1:01 PM, Phil Race wrote: Updated with your suggestion, moved the obvious hot spots to the top. > David, > > I generally make the following request of "large" reviews : > One thing that would help a lot here is if the "important" files were at the top rather > than buried due to lexical sorting by path name. > > In particular files like build.gradle and so on .. people then get a sense of what it is > about rather than first wading through the noise. > > -phil. > > On 11/2/2016 9:55 AM, David Hill wrote: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8161704 >> Webrev: http://cr.openjdk.java.net/~ddhill/8161704/ >> >> Kevin, Chien, Vadim, >> >> There is a lot of change in this webrev, but there are a lot of common patterns (or sets of changes) >> >> ./apps - the majority of the change is altering the NB project files to use rt/build/compile.args and run.args via a relative path. This is a replacement action for using jfxrt.jar (and something I will address in a follow on email) >> >> Also, a new pattern for apps that need --add-exports lines to run properly (like Robot), we have added a file: >> || *apps/tests/HelloTest/addExports >> *that will used as an @argfile with the run command. This allows greater visibility into the added command than hiding them in the project.properties files. >> >> Under ./modules/ there is two classes of renames >> /module-info/module-info.java --> / *java/module-info.java >> * /test/java/com --> / *shims/java/com >> *Module-info.java is needed by javac, and so moving into the "main" set makes sense. It does mean however that IDEs may get upset because this is JDK9 syntax. >> >> The "shim" classes were mixed in with the general test classes. No more. Now they are in the "shim" set to allow us to build them as part of a rebuild of the main module classes to create a shim-ed module for testing. It also means we don't have to play include/exclude games when building. >> >> Under packager, there is a different class of move/renames, creating " *src/antplugin". *These sources are used to build a separate jar for use with ant. We needed to move these out of the main set because the would cause javac failure - but gained an additional benefit of a clear separation of sources. >> >> What is left is changes related to: >> ripping out build/sdk >> adding in a modular build >> creating rt/build/*.args argfiles to ease development. >> >> A big notes: we had to change the build target to 1.9 >> javac.source=1.9 >> javac.target=1.9 >> because in many of the places javac would baulk at using the JDK9 commands without it. It is expected that the current IDEs may not like that. >> > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From snfuchs at gmx.de Wed Nov 2 20:02:17 2016 From: snfuchs at gmx.de (Stefan Fuchs) Date: Wed, 2 Nov 2016 21:02:17 +0100 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: References: <581A162A.9010305@oracle.com> Message-ID: <12a79d60-995b-2590-3160-5e6abfacae35@gmx.de> Hi, in my experience blocking your working thread for the JavaFX application thread is almost always a sign of bad application design. You can easily deadlock your application. In our quite complex JavaFX Application, we could eliminate almost all of its uses. However, in one case it is still needed: In a thread we sequentially prepare several images in the background, create a snapshot and save them as jpegs. Here we use java.util.concurrent.CountDownLatch to simulate PlatformImpl.runAndWait. final WritableImage image = new WritableImage((int) targetWidth, (int) targetHeight); final CountDownLatch countDownLatch = new CountDownLatch(1); Platform.runLater(() -> { /* render and snapshot image */ countDownLatch.countDown(); }); boolean released = countDownLatch.await(10, TimeUnit.SECONDS); if (!released) { Logger.getLogger(getClass()).error("Timeout reached, while waiting for snapshot"); return null; } return image; What I would like to see implemented is a method, we call runNowOrLater. That is, if I'm on the JavaFX ApplicationThread execute the Runnable immediately, if not call Platform.runLater(). With this method I have not to worry, if I'm on the JavaFX Application thread or not and I avoid flooding the event queue with calls to Platform.runLater, that could have been executed directly. So basically: public static void runNowOrLater(final Runnable runnable) { if (Platform.isFxApplicationThread()) { runnable.run(); } else { Platform.runLater(runnable); } } -- Stefan > Hi, Kevin. Thanks for the info! > > On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth > wrote: > >> No. This isn't something we will do for JDK 9, which is feature complete >> (with an exception process for critical requests, especially relating to >> Jigsaw). I note in this case that it isn't clear whether we want to do this >> one at all. >> >> -- Kevin >> >> >> >> Benjamin Gudehus wrote: >> >>> Hey! >>> >>> Are there plans to expose this API [1] in JavaFX 9? >>> >>> // NOTE: Add the following if we decide to expose it publicly >>> // public static void runAndWait(Runnable runnable) { >>> // PlatformImpl.runAndWait(runnable); >>> // } >>> >>> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ >>> 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/ >>> application/Platform.java#l148 >>> >>> --Benjamin >>> >>> From hastebrot at gmail.com Wed Nov 2 20:55:48 2016 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 2 Nov 2016 21:55:48 +0100 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: <12a79d60-995b-2590-3160-5e6abfacae35@gmx.de> References: <581A162A.9010305@oracle.com> <12a79d60-995b-2590-3160-5e6abfacae35@gmx.de> Message-ID: I wonder, if it is possible to test JavaFX applications without blocking the main thread. User interactions could be completely simulated by using Event.fireEvent(...) and we could enqueue assertions in the JavaFX application thread, in which case the assertion library needs to support asynchronous assertions. On Wed, Nov 2, 2016 at 9:02 PM, Stefan Fuchs wrote: > Hi, > > in my experience blocking your working thread for the JavaFX application > thread is almost always a sign of bad application design. > You can easily deadlock your application. In our quite complex JavaFX > Application, we could eliminate almost all of its uses. > > However, in one case it is still needed: In a thread we sequentially > prepare several images in the background, create a snapshot and save them > as jpegs. > Here we use java.util.concurrent.CountDownLatch to simulate > PlatformImpl.runAndWait. > > final WritableImage image = new WritableImage((int) targetWidth, > (int) targetHeight); > final CountDownLatch countDownLatch = new CountDownLatch(1); > Platform.runLater(() -> { > > /* render and snapshot image */ > > countDownLatch.countDown(); > }); > > boolean released = countDownLatch.await(10, TimeUnit.SECONDS); > if (!released) { > Logger.getLogger(getClass()).error("Timeout reached, while > waiting for snapshot"); > return null; > } > > return image; > > > > What I would like to see implemented is a method, we call runNowOrLater. > > That is, if I'm on the JavaFX ApplicationThread execute the Runnable > immediately, if not call Platform.runLater(). > With this method I have not to worry, if I'm on the JavaFX Application > thread or not and I avoid flooding the event queue with calls to > Platform.runLater, that could have been executed directly. > > So basically: > > public static void runNowOrLater(final Runnable runnable) { > if (Platform.isFxApplicationThread()) { > runnable.run(); > } else { > Platform.runLater(runnable); > } > } > > -- Stefan > > > > > Hi, Kevin. Thanks for the info! >> >> On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> >> wrote: >> >> No. This isn't something we will do for JDK 9, which is feature complete >>> (with an exception process for critical requests, especially relating to >>> Jigsaw). I note in this case that it isn't clear whether we want to do >>> this >>> one at all. >>> >>> -- Kevin >>> >>> >>> >>> Benjamin Gudehus wrote: >>> >>> Hey! >>>> >>>> Are there plans to expose this API [1] in JavaFX 9? >>>> >>>> // NOTE: Add the following if we decide to expose it publicly >>>> // public static void runAndWait(Runnable runnable) { >>>> // PlatformImpl.runAndWait(runnable); >>>> // } >>>> >>>> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ >>>> 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/ >>>> application/Platform.java#l148 >>>> >>>> --Benjamin >>>> >>>> >>>> > From kevin.rushforth at oracle.com Wed Nov 2 21:13:37 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Nov 2016 14:13:37 -0700 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: References: <581A162A.9010305@oracle.com> <12a79d60-995b-2590-3160-5e6abfacae35@gmx.de> Message-ID: <581A5701.6040702@oracle.com> We use runAndWait (using a CountDownLatch) in many of our unit tests. You might take a look at: tests/system/src/test/java/test/util/Util.java Its runAndWait method also handles propagating runtime exceptions and errors (e.g., assertion failures) from the body of the runAndWait back to the caller. -- Kevin Benjamin Gudehus wrote: > I wonder, if it is possible to test JavaFX applications without > blocking the main thread. User interactions could be completely > simulated by using Event.fireEvent(...) and we could enqueue > assertions in the JavaFX application thread, in which case the > assertion library needs to support asynchronous assertions. > > On Wed, Nov 2, 2016 at 9:02 PM, Stefan Fuchs > wrote: > > Hi, > > in my experience blocking your working thread for the JavaFX > application thread is almost always a sign of bad application design. > You can easily deadlock your application. In our quite complex > JavaFX Application, we could eliminate almost all of its uses. > > However, in one case it is still needed: In a thread we > sequentially prepare several images in the background, create a > snapshot and save them as jpegs. > Here we use java.util.concurrent.CountDownLatch to simulate > PlatformImpl.runAndWait. > > final WritableImage image = new WritableImage((int) > targetWidth, (int) targetHeight); > final CountDownLatch countDownLatch = new CountDownLatch(1); > Platform.runLater(() -> { > > /* render and snapshot image */ > > countDownLatch.countDown(); > }); > > boolean released = countDownLatch.await(10, TimeUnit.SECONDS); > if (!released) { > Logger.getLogger(getClass()).error("Timeout reached, > while waiting for snapshot"); > return null; > } > > return image; > > > > What I would like to see implemented is a method, we call > runNowOrLater. > > That is, if I'm on the JavaFX ApplicationThread execute the > Runnable immediately, if not call Platform.runLater(). > With this method I have not to worry, if I'm on the JavaFX > Application thread or not and I avoid flooding the event queue > with calls to Platform.runLater, that could have been executed > directly. > > So basically: > > public static void runNowOrLater(final Runnable runnable) { > if (Platform.isFxApplicationThread()) { > runnable.run(); > } else { > Platform.runLater(runnable); > } > } > > -- Stefan > > > > > Hi, Kevin. Thanks for the info! > > On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth > > > wrote: > > No. This isn't something we will do for JDK 9, which is > feature complete > (with an exception process for critical requests, > especially relating to > Jigsaw). I note in this case that it isn't clear whether > we want to do this > one at all. > > -- Kevin > > > > Benjamin Gudehus wrote: > > Hey! > > Are there plans to expose this API [1] in JavaFX 9? > > // NOTE: Add the following if we decide to expose it > publicly > // public static void runAndWait(Runnable runnable) { > // PlatformImpl.runAndWait(runnable); > // } > > [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ > > 6edd0c3c01f4/modules/javafx.gr > aphics/src/main/java/javafx/ > application/Platform.java#l148 > > --Benjamin > > > > From bourges.laurent at gmail.com Wed Nov 2 21:54:11 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 2 Nov 2016 22:54:11 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> Message-ID: Jim, Here is an updated patch for MarlinFX: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ I made big improvements: MarlinFX is now "feature-complete": - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new methods on AlphaConsumer and common methods between AA & noAA renderers - Renderer: fixed cubic dec/inc lengths (like openpisces) + use optimized copyAlphas from MarlinAlphaConsumer (with block flag optimization derived from former MarlinCache) - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) - Dasher & Stroker: backported changes from openpisces (small dash phase & refined cubic / quad mitters) - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin renderer as a JavaFX ShapeRasterizer and implement the MarlinAlphaConsumer efficiently (mimics former MarlinCache ie support the block flag optimization); MarlinPrismUtils performs properly NaN / Infinity coordinates filtering and use the same pipeline stages (delta / invDelta transformers for Dasher/Stroker) like in the MarlinRenderingEngine - Thread safety: MarlinRasterizer completely thread-safe (for future multi-threaded rendering) using ReentrantContext... - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of the OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable Marlin-FX) - Fixed Path2D growing algorithm (like java2d) So MarlinFX is 13K LOC (few unused classes could be removed soon) and only few lines are added in ShapeUtil to switch MarlinFX ON: if (PrismSettings.doNativePisces) { shapeRasterizer = new NativePiscesRasterizer(); } else { * // TODO: move that new setting into PrismSettings: // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if (MarlinProperties.isMarlinEnabled()) { System.out.println("Marlin-FX[" + Version.getVersion() + "] enabled."); shapeRasterizer = new MarlinRasterizer(); } else {* shapeRasterizer = new OpenPiscesRasterizer(); * }* } So the OpenPisces classes are totally left unchanged and MarlinFX is just added as another rasterizer and is enabled with the following settings: -Dsun.javafx.marlin=true and -Dprism.nativepisces=false Of course, we could adapt these few lines to satisfy your requirements (system properties ...); please tell me what you prefer. I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and everything is working fine. Does it look acceptable as a low risk RFE ? Finally what do you prefer for OpenJDK9 integration ? - as a new javafx rasterizer (like the provided marlinFX patch) - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? I wonder if it would be better to create another JavaFX ShapeRasterizer that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication but it will add some complexity in the marlin renderer (itself) to introduce the AlphaConsumer interface... I can make separate patches for all these changes concerning jfx Path2D or Marlin changes for OpenJDK9 first, then MarlinFX. PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I will synchronize both branches to provide soon MarlinFX9 patches closer to OpenJDK9's Marlin renderer if we are going to work on its integration. PS2: I will also work on another MarlinFX variant not using Unsafe but only plain arrays to evaluate the performance loss (small) that could simplify the integration with Jigsaw ... So I made a big step forward, and I am looking forward your feedback, Cheers, Laurent From herve.girod at gmail.com Wed Nov 2 23:23:30 2016 From: herve.girod at gmail.com (Herve Girod) Date: Thu, 3 Nov 2016 00:23:30 +0100 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: <581A5701.6040702@oracle.com> References: <581A162A.9010305@oracle.com> <12a79d60-995b-2590-3160-5e6abfacae35@gmx.de> <581A5701.6040702@oracle.com> Message-ID: We have a use case where we receive a LOT of processing orders in one Thread in a TCP socket and we have to perform the drawing in the JavaFX Thread, but also we must wait until the effective drawing has finished before ordering a new drawing (because otherwise some parameters could have changed in the middle of the drawing so the rsulting image could be inconsistent). We use Platform.runLater with a future in our case like: FutureTask future = new FutureTask<>(runnable, null); Platform.runLater(future); try { future.get(); return true; } catch... I don't know if this is a valid pattern. Of course the Thread which handle this code has to be different from the Thread which handle the socket reception in our case. Herv? 2016-11-02 22:13 GMT+01:00 Kevin Rushforth : > We use runAndWait (using a CountDownLatch) in many of our unit tests. You > might take a look at: > > tests/system/src/test/java/test/util/Util.java > > Its runAndWait method also handles propagating runtime exceptions and > errors (e.g., assertion failures) from the body of the runAndWait back to > the caller. > > -- Kevin > > > Benjamin Gudehus wrote: > >> I wonder, if it is possible to test JavaFX applications without blocking >> the main thread. User interactions could be completely simulated by using >> Event.fireEvent(...) and we could enqueue assertions in the JavaFX >> application thread, in which case the assertion library needs to support >> asynchronous assertions. >> >> On Wed, Nov 2, 2016 at 9:02 PM, Stefan Fuchs > snfuchs at gmx.de>> wrote: >> >> Hi, >> >> in my experience blocking your working thread for the JavaFX >> application thread is almost always a sign of bad application design. >> You can easily deadlock your application. In our quite complex >> JavaFX Application, we could eliminate almost all of its uses. >> >> However, in one case it is still needed: In a thread we >> sequentially prepare several images in the background, create a >> snapshot and save them as jpegs. >> Here we use java.util.concurrent.CountDownLatch to simulate >> PlatformImpl.runAndWait. >> >> final WritableImage image = new WritableImage((int) >> targetWidth, (int) targetHeight); >> final CountDownLatch countDownLatch = new CountDownLatch(1); >> Platform.runLater(() -> { >> >> /* render and snapshot image */ >> >> countDownLatch.countDown(); >> }); >> >> boolean released = countDownLatch.await(10, TimeUnit.SECONDS); >> if (!released) { >> Logger.getLogger(getClass()).error("Timeout reached, >> while waiting for snapshot"); >> return null; >> } >> >> return image; >> >> >> >> What I would like to see implemented is a method, we call >> runNowOrLater. >> >> That is, if I'm on the JavaFX ApplicationThread execute the >> Runnable immediately, if not call Platform.runLater(). >> With this method I have not to worry, if I'm on the JavaFX >> Application thread or not and I avoid flooding the event queue >> with calls to Platform.runLater, that could have been executed >> directly. >> >> So basically: >> >> public static void runNowOrLater(final Runnable runnable) { >> if (Platform.isFxApplicationThread()) { >> runnable.run(); >> } else { >> Platform.runLater(runnable); >> } >> } >> >> -- Stefan >> >> >> >> >> Hi, Kevin. Thanks for the info! >> >> On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth >> > >> wrote: >> >> No. This isn't something we will do for JDK 9, which is >> feature complete >> (with an exception process for critical requests, >> especially relating to >> Jigsaw). I note in this case that it isn't clear whether >> we want to do this >> one at all. >> >> -- Kevin >> >> >> >> Benjamin Gudehus wrote: >> >> Hey! >> >> Are there plans to expose this API [1] in JavaFX 9? >> >> // NOTE: Add the following if we decide to expose it >> publicly >> // public static void runAndWait(Runnable runnable) { >> // PlatformImpl.runAndWait(runnable); >> // } >> >> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ >> >> 6edd0c3c01f4/modules/javafx.gr >> aphics/src/main/java/javafx/ >> application/Platform.java#l148 >> >> --Benjamin >> >> >> >> >> From tom.schindl at bestsolution.at Wed Nov 2 23:41:23 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 3 Nov 2016 00:41:23 +0100 Subject: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait() In-Reply-To: References: <581A162A.9010305@oracle.com> <12a79d60-995b-2590-3160-5e6abfacae35@gmx.de> <581A5701.6040702@oracle.com> Message-ID: e(fx)clipse also uses FutureTask - we initially used CountDownLatch but it escapes my mind what was the reason for that change. BTW: We have many other clever util methods in this area - see - http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.ui.workbench.fx/src/org/eclipse/fx/ui/workbench/fx/internal/UISynchronizeImpl.java - http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.core/src/org/eclipse/fx/core/ThreadSynchronize.java Tom Von meinem iPhone gesendet > Am 03.11.2016 um 00:23 schrieb Herve Girod : > > We have a use case where we receive a LOT of processing orders in one > Thread in a TCP socket and we have to perform the drawing in the JavaFX > Thread, but also we must wait until the effective drawing has finished > before ordering a new drawing (because otherwise some parameters could have > changed in the middle of the drawing so the rsulting image could be > inconsistent). We use Platform.runLater with a future in our case like: > FutureTask future = new FutureTask<>(runnable, null); > Platform.runLater(future); > try { > future.get(); > return true; > } catch... > > I don't know if this is a valid pattern. Of course the Thread which handle > this code has to be different from the Thread which handle the socket > reception in our case. > > Herv? > > 2016-11-02 22:13 GMT+01:00 Kevin Rushforth : > >> We use runAndWait (using a CountDownLatch) in many of our unit tests. You >> might take a look at: >> >> tests/system/src/test/java/test/util/Util.java >> >> Its runAndWait method also handles propagating runtime exceptions and >> errors (e.g., assertion failures) from the body of the runAndWait back to >> the caller. >> >> -- Kevin >> >> >> Benjamin Gudehus wrote: >> >>> I wonder, if it is possible to test JavaFX applications without blocking >>> the main thread. User interactions could be completely simulated by using >>> Event.fireEvent(...) and we could enqueue assertions in the JavaFX >>> application thread, in which case the assertion library needs to support >>> asynchronous assertions. >>> >>> On Wed, Nov 2, 2016 at 9:02 PM, Stefan Fuchs >> snfuchs at gmx.de>> wrote: >>> >>> Hi, >>> >>> in my experience blocking your working thread for the JavaFX >>> application thread is almost always a sign of bad application design. >>> You can easily deadlock your application. In our quite complex >>> JavaFX Application, we could eliminate almost all of its uses. >>> >>> However, in one case it is still needed: In a thread we >>> sequentially prepare several images in the background, create a >>> snapshot and save them as jpegs. >>> Here we use java.util.concurrent.CountDownLatch to simulate >>> PlatformImpl.runAndWait. >>> >>> final WritableImage image = new WritableImage((int) >>> targetWidth, (int) targetHeight); >>> final CountDownLatch countDownLatch = new CountDownLatch(1); >>> Platform.runLater(() -> { >>> >>> /* render and snapshot image */ >>> >>> countDownLatch.countDown(); >>> }); >>> >>> boolean released = countDownLatch.await(10, TimeUnit.SECONDS); >>> if (!released) { >>> Logger.getLogger(getClass()).error("Timeout reached, >>> while waiting for snapshot"); >>> return null; >>> } >>> >>> return image; >>> >>> >>> >>> What I would like to see implemented is a method, we call >>> runNowOrLater. >>> >>> That is, if I'm on the JavaFX ApplicationThread execute the >>> Runnable immediately, if not call Platform.runLater(). >>> With this method I have not to worry, if I'm on the JavaFX >>> Application thread or not and I avoid flooding the event queue >>> with calls to Platform.runLater, that could have been executed >>> directly. >>> >>> So basically: >>> >>> public static void runNowOrLater(final Runnable runnable) { >>> if (Platform.isFxApplicationThread()) { >>> runnable.run(); >>> } else { >>> Platform.runLater(runnable); >>> } >>> } >>> >>> -- Stefan >>> >>> >>> >>> >>> Hi, Kevin. Thanks for the info! >>> >>> On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth >>> > >>> wrote: >>> >>> No. This isn't something we will do for JDK 9, which is >>> feature complete >>> (with an exception process for critical requests, >>> especially relating to >>> Jigsaw). I note in this case that it isn't clear whether >>> we want to do this >>> one at all. >>> >>> -- Kevin >>> >>> >>> >>> Benjamin Gudehus wrote: >>> >>> Hey! >>> >>> Are there plans to expose this API [1] in JavaFX 9? >>> >>> // NOTE: Add the following if we decide to expose it >>> publicly >>> // public static void runAndWait(Runnable runnable) { >>> // PlatformImpl.runAndWait(runnable); >>> // } >>> >>> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/ >>> >>> 6edd0c3c01f4/modules/javafx.gr >>> aphics/src/main/java/javafx/ >>> application/Platform.java#l148 >>> >>> --Benjamin >>> >>> >>> >>> >>> From Sergey.Bylokhov at oracle.com Thu Nov 3 00:27:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 3 Nov 2016 03:27:42 +0300 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> Message-ID: <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> Probably the logging should be enabled only if we pass the upper case "True" to "-Dsun.javafx.marlin=True". I do not know is it correct to write to the system output unconditionally, can this affect application? And instead of "sun." can we use something different like "jdk." I guess the same question can be applied to jdk? On 03.11.16 0:54, Laurent Bourg?s wrote: > Jim, > > Here is an updated patch for MarlinFX: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ > > I made big improvements: MarlinFX is now "feature-complete": > - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new > methods on AlphaConsumer and common methods between AA & noAA renderers > - Renderer: fixed cubic dec/inc lengths (like openpisces) + use optimized > copyAlphas from MarlinAlphaConsumer (with block flag optimization derived > from former MarlinCache) > - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) > - Dasher & Stroker: backported changes from openpisces (small dash phase & > refined cubic / quad mitters) > - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin > renderer as a JavaFX ShapeRasterizer and implement the MarlinAlphaConsumer > efficiently (mimics former MarlinCache ie support the block flag > optimization); MarlinPrismUtils performs properly NaN / Infinity > coordinates filtering and use the same pipeline stages (delta / invDelta > transformers for Dasher/Stroker) like in the MarlinRenderingEngine > - Thread safety: MarlinRasterizer completely thread-safe (for future > multi-threaded rendering) using ReentrantContext... > - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of the > OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable > Marlin-FX) > - Fixed Path2D growing algorithm (like java2d) > > So MarlinFX is 13K LOC (few unused classes could be removed soon) and only > few lines are added in ShapeUtil to switch MarlinFX ON: > > if (PrismSettings.doNativePisces) { > shapeRasterizer = new NativePiscesRasterizer(); > } else { > > > > > > > * // TODO: move that new setting into PrismSettings: > // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if > (MarlinProperties.isMarlinEnabled()) { > System.out.println("Marlin-FX[" + Version.getVersion() + "] > enabled."); shapeRasterizer = new > MarlinRasterizer(); } else {* shapeRasterizer = > new OpenPiscesRasterizer(); > > * }* } > > So the OpenPisces classes are totally left unchanged and MarlinFX is just > added as another rasterizer and is enabled with the following settings: > -Dsun.javafx.marlin=true and -Dprism.nativepisces=false > > Of course, we could adapt these few lines to satisfy your requirements > (system properties ...); please tell me what you prefer. > > I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and > everything is working fine. > > > Does it look acceptable as a low risk RFE ? > > Finally what do you prefer for OpenJDK9 integration ? > - as a new javafx rasterizer (like the provided marlinFX patch) > - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? > I wonder if it would be better to create another JavaFX ShapeRasterizer > that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication but it > will add some complexity in the marlin renderer (itself) to introduce the > AlphaConsumer interface... > > > I can make separate patches for all these changes concerning jfx Path2D or > Marlin changes for OpenJDK9 first, then MarlinFX. > > PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit > different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I > will synchronize both branches to provide soon MarlinFX9 patches closer to > OpenJDK9's Marlin renderer if we are going to work on its integration. > > PS2: I will also work on another MarlinFX variant not using Unsafe but only > plain arrays to evaluate the performance loss (small) that could simplify > the integration with Jigsaw ... > > So I made a big step forward, and I am looking forward your feedback, > > Cheers, > Laurent > -- Best regards, Sergey. From alexander.matveev at oracle.com Thu Nov 3 02:14:16 2016 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 2 Nov 2016 19:14:16 -0700 Subject: [9] Review request for 8167175: JFX MediaPlayer Leaks Native Memory in Windows Message-ID: <64dbe489-e502-04e7-0b0c-ad9ced5d87d9@oracle.com> Hi David, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8167175 Fixed several memory leaks. Thanks, Alexander From kevin.rushforth at oracle.com Thu Nov 3 12:11:19 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 03 Nov 2016 05:11:19 -0700 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> Message-ID: <581B2967.1070409@oracle.com> Hi Laurent, Great progress. I agree with Sergey about avoiding unconditional logging, and about wanting a different name for the property (work with Jim on the property name). To answer a couple other questions: > Does it look acceptable as a low risk RFE ? I would need to see the final diff against FX 9-dev, but if the only change to the current control flow in the existing logic is the additional "if" test for the existence of the new property, and if the Marlin code base itself is basically a copy of what is in Java2D, then I think it is low-risk enough to propose it. I can't guarantee that it will be accepted. > Finally what do you prefer for OpenJDK9 integration ? > - as a new javafx rasterizer (like the provided marlinFX patch) > - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? The former. It will add risk and complexity to wrap the version of Marlin in Java2D for JDK 9. > I can make separate patches for all these changes concerning jfx > Path2D or > Marlin changes for OpenJDK9 first, then MarlinFX. Please do file a new JBS bug for Path2D and let's fix that separately. As a bug fix it will not need to go through the feature request extension process. > PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit > different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I > will synchronize both branches to provide soon MarlinFX9 patches > closer to > OpenJDK9's Marlin renderer if we are going to work on its integration. We will need a patch based on FX 9 before we can propose this for 9, so this sounds like a good plan. > PS2: I will also work on another MarlinFX variant not using Unsafe but > only > plain arrays to evaluate the performance loss (small) that could simplify > the integration with Jigsaw ... I recommend whatever is easiest to get to a patch that will apply to FX 9-dev and build using JDK 9. -- Kevin Sergey Bylokhov wrote: > Probably the logging should be enabled only if we pass the upper case > "True" to "-Dsun.javafx.marlin=True". I do not know is it correct to > write to the system output unconditionally, can this affect > application? And instead of "sun." can we use something different like > "jdk." I guess the same question can be applied to jdk? > > On 03.11.16 0:54, Laurent Bourg?s wrote: >> Jim, >> >> Here is an updated patch for MarlinFX: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ >> >> I made big improvements: MarlinFX is now "feature-complete": >> - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new >> methods on AlphaConsumer and common methods between AA & noAA renderers >> - Renderer: fixed cubic dec/inc lengths (like openpisces) + use >> optimized >> copyAlphas from MarlinAlphaConsumer (with block flag optimization >> derived >> from former MarlinCache) >> - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) >> - Dasher & Stroker: backported changes from openpisces (small dash >> phase & >> refined cubic / quad mitters) >> - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin >> renderer as a JavaFX ShapeRasterizer and implement the >> MarlinAlphaConsumer >> efficiently (mimics former MarlinCache ie support the block flag >> optimization); MarlinPrismUtils performs properly NaN / Infinity >> coordinates filtering and use the same pipeline stages (delta / invDelta >> transformers for Dasher/Stroker) like in the MarlinRenderingEngine >> - Thread safety: MarlinRasterizer completely thread-safe (for future >> multi-threaded rendering) using ReentrantContext... >> - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of >> the >> OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable >> Marlin-FX) >> - Fixed Path2D growing algorithm (like java2d) >> >> So MarlinFX is 13K LOC (few unused classes could be removed soon) and >> only >> few lines are added in ShapeUtil to switch MarlinFX ON: >> >> if (PrismSettings.doNativePisces) { >> shapeRasterizer = new NativePiscesRasterizer(); >> } else { >> >> >> >> >> >> >> * // TODO: move that new setting into PrismSettings: >> // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if >> (MarlinProperties.isMarlinEnabled()) { >> System.out.println("Marlin-FX[" + Version.getVersion() + "] >> enabled."); shapeRasterizer = new >> MarlinRasterizer(); } else {* >> shapeRasterizer = >> new OpenPiscesRasterizer(); >> >> * }* } >> >> So the OpenPisces classes are totally left unchanged and MarlinFX is >> just >> added as another rasterizer and is enabled with the following settings: >> -Dsun.javafx.marlin=true and -Dprism.nativepisces=false >> >> Of course, we could adapt these few lines to satisfy your requirements >> (system properties ...); please tell me what you prefer. >> >> I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and >> everything is working fine. >> >> >> Does it look acceptable as a low risk RFE ? >> >> Finally what do you prefer for OpenJDK9 integration ? >> - as a new javafx rasterizer (like the provided marlinFX patch) >> - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? >> I wonder if it would be better to create another JavaFX ShapeRasterizer >> that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication >> but it >> will add some complexity in the marlin renderer (itself) to introduce >> the >> AlphaConsumer interface... >> >> >> I can make separate patches for all these changes concerning jfx >> Path2D or >> Marlin changes for OpenJDK9 first, then MarlinFX. >> >> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit >> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I >> will synchronize both branches to provide soon MarlinFX9 patches >> closer to >> OpenJDK9's Marlin renderer if we are going to work on its integration. >> >> PS2: I will also work on another MarlinFX variant not using Unsafe >> but only >> plain arrays to evaluate the performance loss (small) that could >> simplify >> the integration with Jigsaw ... >> >> So I made a big step forward, and I am looking forward your feedback, >> >> Cheers, >> Laurent >> > > From james.graham at oracle.com Thu Nov 3 21:40:51 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 3 Nov 2016 14:40:51 -0700 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> Message-ID: <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> We currently control the configuration logging with prism.verbose, and we already have a place in PrismSettings where we dump out the configuration including which rasterizer we're using (native or java-based) if verbose is set. We should probably consolidate this along with the TODO to move the setting to PrismSettings. With 3 choices it might make sense to use a "prism.rasterizerorder" type of property like we use for the general pipeline (es2 d3d sw), but for the sake of keeping the changes fairly localized, I'd recommend: prism.marlinrasterizer=true|false (overrides prism.nativepisces=true|false) (It might seem natural to use "useMarlin" or something like that, but most of the other prism.* settings in that file are of the form "mechanism=true/false" to mean "useMechanism"...) If set to true, use Marlin regardless of "nativepisces" value. If not set to true, consult nativepisces or use the default as the code already does. Also, change the print statement in the "verbose" block in that same method to indicate we are using Marlin, printing out one of the following: "Using java-based Pisces rasterizer" "Using native-based Pisces rasterizer" "Using Marlin rasterizer" I also noticed that the SWContext also chooses a rasterizer for its use using a copy of the decision logic in ShapeUtils. We should probably add a ShapeUtil.getRasterizer() method to return the one that was determined by its algorithm rather than repeat the selection algorithm in SWContext. In MarlinProperties we should probably use prism.marlin.* as the prefix for these settings to keep them isolated from the java2d settings...? ...jim On 11/2/2016 5:27 PM, Sergey Bylokhov wrote: > Probably the logging should be enabled only if we pass the upper case > "True" to "-Dsun.javafx.marlin=True". I do not know is it correct to > write to the system output unconditionally, can this affect application? > And instead of "sun." can we use something different like "jdk." I guess > the same question can be applied to jdk? > > On 03.11.16 0:54, Laurent Bourg?s wrote: >> Jim, >> >> Here is an updated patch for MarlinFX: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ >> >> I made big improvements: MarlinFX is now "feature-complete": >> - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new >> methods on AlphaConsumer and common methods between AA & noAA renderers >> - Renderer: fixed cubic dec/inc lengths (like openpisces) + use optimized >> copyAlphas from MarlinAlphaConsumer (with block flag optimization derived >> from former MarlinCache) >> - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) >> - Dasher & Stroker: backported changes from openpisces (small dash >> phase & >> refined cubic / quad mitters) >> - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin >> renderer as a JavaFX ShapeRasterizer and implement the >> MarlinAlphaConsumer >> efficiently (mimics former MarlinCache ie support the block flag >> optimization); MarlinPrismUtils performs properly NaN / Infinity >> coordinates filtering and use the same pipeline stages (delta / invDelta >> transformers for Dasher/Stroker) like in the MarlinRenderingEngine >> - Thread safety: MarlinRasterizer completely thread-safe (for future >> multi-threaded rendering) using ReentrantContext... >> - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of the >> OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable >> Marlin-FX) >> - Fixed Path2D growing algorithm (like java2d) >> >> So MarlinFX is 13K LOC (few unused classes could be removed soon) and >> only >> few lines are added in ShapeUtil to switch MarlinFX ON: >> >> if (PrismSettings.doNativePisces) { >> shapeRasterizer = new NativePiscesRasterizer(); >> } else { >> >> >> >> >> >> >> * // TODO: move that new setting into PrismSettings: >> // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if >> (MarlinProperties.isMarlinEnabled()) { >> System.out.println("Marlin-FX[" + Version.getVersion() + "] >> enabled."); shapeRasterizer = new >> MarlinRasterizer(); } else {* shapeRasterizer = >> new OpenPiscesRasterizer(); >> >> * }* } >> >> So the OpenPisces classes are totally left unchanged and MarlinFX is just >> added as another rasterizer and is enabled with the following settings: >> -Dsun.javafx.marlin=true and -Dprism.nativepisces=false >> >> Of course, we could adapt these few lines to satisfy your requirements >> (system properties ...); please tell me what you prefer. >> >> I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and >> everything is working fine. >> >> >> Does it look acceptable as a low risk RFE ? >> >> Finally what do you prefer for OpenJDK9 integration ? >> - as a new javafx rasterizer (like the provided marlinFX patch) >> - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? >> I wonder if it would be better to create another JavaFX ShapeRasterizer >> that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication >> but it >> will add some complexity in the marlin renderer (itself) to introduce the >> AlphaConsumer interface... >> >> >> I can make separate patches for all these changes concerning jfx >> Path2D or >> Marlin changes for OpenJDK9 first, then MarlinFX. >> >> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit >> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I >> will synchronize both branches to provide soon MarlinFX9 patches >> closer to >> OpenJDK9's Marlin renderer if we are going to work on its integration. >> >> PS2: I will also work on another MarlinFX variant not using Unsafe but >> only >> plain arrays to evaluate the performance loss (small) that could simplify >> the integration with Jigsaw ... >> >> So I made a big step forward, and I am looking forward your feedback, >> >> Cheers, >> Laurent >> > > From james.graham at oracle.com Fri Nov 4 01:17:38 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 3 Nov 2016 18:17:38 -0700 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> Message-ID: <0991be17-ce78-8807-8836-a31f132b573f@oracle.com> There are basically 2 isolated changes to the existing code base and then a set of added source files. The first change is to use Marlin if the appropriate property is specified, and those changes are very localized and easy to verify that they won't hurt anything. The second change is to modify the growth pattern of Path2D. While these changes are live in AWT already and have already been code reviewed, it would probably be better to submit them as a separate FX fix if they are only performance oriented and not strictly required for Marlin to function. That way we compartmentalize anything that could possibly result in a regression into a separate bugid so we don't have to pull everything if someone complains that the new growth pattern is having negative consequences for their app. I doubt that will happen, but it is simple enough to break them into 2 separate fixes so it couldn't hurt to do that. After that, this just boils down to adding a bunch of code that has already been vetted elsewhere and a small and simple change to use it only optionally and conditionally, which is a very low risk fix. That would take this change from "no obvious drawbacks" to "obviously no drawbacks" (or, more precisely, one "obviously no drawbacks" fix and one related "no obvious drawbacks" fix)... ...jim On 11/2/2016 2:54 PM, Laurent Bourg?s wrote: > Jim, > > Here is an updated patch for MarlinFX: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ > > I made big improvements: MarlinFX is now "feature-complete": > - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new > methods on AlphaConsumer and common methods between AA & noAA renderers > - Renderer: fixed cubic dec/inc lengths (like openpisces) + use optimized > copyAlphas from MarlinAlphaConsumer (with block flag optimization derived > from former MarlinCache) > - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) > - Dasher & Stroker: backported changes from openpisces (small dash phase & > refined cubic / quad mitters) > - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin > renderer as a JavaFX ShapeRasterizer and implement the MarlinAlphaConsumer > efficiently (mimics former MarlinCache ie support the block flag > optimization); MarlinPrismUtils performs properly NaN / Infinity > coordinates filtering and use the same pipeline stages (delta / invDelta > transformers for Dasher/Stroker) like in the MarlinRenderingEngine > - Thread safety: MarlinRasterizer completely thread-safe (for future > multi-threaded rendering) using ReentrantContext... > - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of the > OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable > Marlin-FX) > - Fixed Path2D growing algorithm (like java2d) > > So MarlinFX is 13K LOC (few unused classes could be removed soon) and only > few lines are added in ShapeUtil to switch MarlinFX ON: > > if (PrismSettings.doNativePisces) { > shapeRasterizer = new NativePiscesRasterizer(); > } else { > > > > > > > * // TODO: move that new setting into PrismSettings: > // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if > (MarlinProperties.isMarlinEnabled()) { > System.out.println("Marlin-FX[" + Version.getVersion() + "] > enabled."); shapeRasterizer = new > MarlinRasterizer(); } else {* shapeRasterizer = > new OpenPiscesRasterizer(); > > * }* } > > So the OpenPisces classes are totally left unchanged and MarlinFX is just > added as another rasterizer and is enabled with the following settings: > -Dsun.javafx.marlin=true and -Dprism.nativepisces=false > > Of course, we could adapt these few lines to satisfy your requirements > (system properties ...); please tell me what you prefer. > > I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and > everything is working fine. > > > Does it look acceptable as a low risk RFE ? > > Finally what do you prefer for OpenJDK9 integration ? > - as a new javafx rasterizer (like the provided marlinFX patch) > - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? > I wonder if it would be better to create another JavaFX ShapeRasterizer > that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication but it > will add some complexity in the marlin renderer (itself) to introduce the > AlphaConsumer interface... > > > I can make separate patches for all these changes concerning jfx Path2D or > Marlin changes for OpenJDK9 first, then MarlinFX. > > PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit > different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I > will synchronize both branches to provide soon MarlinFX9 patches closer to > OpenJDK9's Marlin renderer if we are going to work on its integration. > > PS2: I will also work on another MarlinFX variant not using Unsafe but only > plain arrays to evaluate the performance loss (small) that could simplify > the integration with Jigsaw ... > > So I made a big step forward, and I am looking forward your feedback, > > Cheers, > Laurent > From murali.billa at oracle.com Fri Nov 4 09:33:13 2016 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 4 Nov 2016 02:33:13 -0700 (PDT) Subject: [9] Review request for 8169204: Need to document JSObject Call and setSlot APIs to use weak references In-Reply-To: References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> Message-ID: <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8169204 Webrev: http://cr.openjdk.java.net/~mbilla/8169204/webrev.00/ ? Thanks, Murali From kevin.rushforth at oracle.com Fri Nov 4 15:21:02 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Nov 2016 08:21:02 -0700 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <0991be17-ce78-8807-8836-a31f132b573f@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <0991be17-ce78-8807-8836-a31f132b573f@oracle.com> Message-ID: <581CA75E.60400@oracle.com> Hi Jim, Thanks for the summary. We should proceed as you outlined. Can you file a new RFE (Enhancement) to integrate Marlin into JavaFX as an optional rasterizer (disabled by default) so we have a clean JBS issue to use for the JDK 9 feature extension request, rather than using JDK-8092373? You can assign the RFE to Laurent. It can be linked to the Java2D/Marlin JEP and to JDK-8092373. Laurent: Since there are multiple reasons for submitting the Path2D fix as a separate bug fix, please file a new bug for this, linking it to the equivalent Java2D bug and also to the new RFE that Jim will file. Thanks. -- Kevin Jim Graham wrote: > There are basically 2 isolated changes to the existing code base and > then a set of added source files. > > The first change is to use Marlin if the appropriate property is > specified, and those changes are very localized and easy to verify > that they won't hurt anything. > > The second change is to modify the growth pattern of Path2D. While > these changes are live in AWT already and have already been code > reviewed, it would probably be better to submit them as a separate FX > fix if they are only performance oriented and not strictly required > for Marlin to function. That way we compartmentalize anything that > could possibly result in a regression into a separate bugid so we > don't have to pull everything if someone complains that the new growth > pattern is having negative consequences for their app. I doubt that > will happen, but it is simple enough to break them into 2 separate > fixes so it couldn't hurt to do that. > > After that, this just boils down to adding a bunch of code that has > already been vetted elsewhere and a small and simple change to use it > only optionally and conditionally, which is a very low risk fix. > > That would take this change from "no obvious drawbacks" to "obviously > no drawbacks" (or, more precisely, one "obviously no drawbacks" fix > and one related "no obvious drawbacks" fix)... > > ...jim > > On 11/2/2016 2:54 PM, Laurent Bourg?s wrote: >> Jim, >> >> Here is an updated patch for MarlinFX: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ >> >> I made big improvements: MarlinFX is now "feature-complete": >> - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new >> methods on AlphaConsumer and common methods between AA & noAA renderers >> - Renderer: fixed cubic dec/inc lengths (like openpisces) + use >> optimized >> copyAlphas from MarlinAlphaConsumer (with block flag optimization >> derived >> from former MarlinCache) >> - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) >> - Dasher & Stroker: backported changes from openpisces (small dash >> phase & >> refined cubic / quad mitters) >> - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin >> renderer as a JavaFX ShapeRasterizer and implement the >> MarlinAlphaConsumer >> efficiently (mimics former MarlinCache ie support the block flag >> optimization); MarlinPrismUtils performs properly NaN / Infinity >> coordinates filtering and use the same pipeline stages (delta / invDelta >> transformers for Dasher/Stroker) like in the MarlinRenderingEngine >> - Thread safety: MarlinRasterizer completely thread-safe (for future >> multi-threaded rendering) using ReentrantContext... >> - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of >> the >> OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable >> Marlin-FX) >> - Fixed Path2D growing algorithm (like java2d) >> >> So MarlinFX is 13K LOC (few unused classes could be removed soon) and >> only >> few lines are added in ShapeUtil to switch MarlinFX ON: >> >> if (PrismSettings.doNativePisces) { >> shapeRasterizer = new NativePiscesRasterizer(); >> } else { >> >> >> >> >> >> >> * // TODO: move that new setting into PrismSettings: >> // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if >> (MarlinProperties.isMarlinEnabled()) { >> System.out.println("Marlin-FX[" + Version.getVersion() + "] >> enabled."); shapeRasterizer = new >> MarlinRasterizer(); } else {* >> shapeRasterizer = >> new OpenPiscesRasterizer(); >> >> * }* } >> >> So the OpenPisces classes are totally left unchanged and MarlinFX is >> just >> added as another rasterizer and is enabled with the following settings: >> -Dsun.javafx.marlin=true and -Dprism.nativepisces=false >> >> Of course, we could adapt these few lines to satisfy your requirements >> (system properties ...); please tell me what you prefer. >> >> I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and >> everything is working fine. >> >> >> Does it look acceptable as a low risk RFE ? >> >> Finally what do you prefer for OpenJDK9 integration ? >> - as a new javafx rasterizer (like the provided marlinFX patch) >> - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? >> I wonder if it would be better to create another JavaFX ShapeRasterizer >> that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication >> but it >> will add some complexity in the marlin renderer (itself) to introduce >> the >> AlphaConsumer interface... >> >> >> I can make separate patches for all these changes concerning jfx >> Path2D or >> Marlin changes for OpenJDK9 first, then MarlinFX. >> >> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit >> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I >> will synchronize both branches to provide soon MarlinFX9 patches >> closer to >> OpenJDK9's Marlin renderer if we are going to work on its integration. >> >> PS2: I will also work on another MarlinFX variant not using Unsafe >> but only >> plain arrays to evaluate the performance loss (small) that could >> simplify >> the integration with Jigsaw ... >> >> So I made a big step forward, and I am looking forward your feedback, >> >> Cheers, >> Laurent >> From bourges.laurent at gmail.com Fri Nov 4 18:33:48 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 4 Nov 2016 19:33:48 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> Message-ID: Jim, I agree your proposals on ShapeUtil and prism settings. Will do it in next webrev after cleanup and OpenJDK9 synchro, certainly happening during this week end. > I also noticed that the SWContext also chooses a rasterizer for its use using a copy of the decision logic in ShapeUtils. We should probably add a ShapeUtil.getRasterizer() method to return the one that was determined by its algorithm rather than repeat the selection algorithm in SWContext. For SWContext, I figured out that only openpisces.* classes were used directly via imports (hardcoded) so I left it unchanged. So you propose to generalize use of marlin or native pisces ? As I extended the AlphaConsumer to add two specialized methods (clearAlphas and block flag opt fill) for MarlinRenderer we should discuss how to adapt the DirectSWAlphaConsumer with Marlin: it is possible to use a SWRenderer interface (renamed new MarlinRenderer interface) and change all consumers to implement the two new methods in the SW Consumer. Of course it will increase the risk so I propose to create an adaptor in marlin to implement the MarlinAlphaConsumer methods and redirect to the former AlphaConsumer. Looking forward your answers on the several interleaved posts on this thread. Laurent From james.graham at oracle.com Fri Nov 4 18:55:19 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 4 Nov 2016 11:55:19 -0700 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> Message-ID: On 11/4/2016 11:33 AM, Laurent Bourg?s wrote: > For SWContext, I figured out that only openpisces.* classes were used > directly via imports (hardcoded) so I left it unchanged. So you propose > to generalize use of marlin or native pisces ? I didn't notice that, I was just searching on the use of "doNativePisces". We can look at that separately, and Kevin would know how frequently we end up in the SW pipeline these days... ...jim From james.graham at oracle.com Fri Nov 4 19:15:33 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 4 Nov 2016 12:15:33 -0700 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <581CA75E.60400@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <0991be17-ce78-8807-8836-a31f132b573f@oracle.com> <581CA75E.60400@oracle.com> Message-ID: FX enhancement: https://bugs.openjdk.java.net/browse/JDK-8169270 ...jim On 11/4/2016 8:21 AM, Kevin Rushforth wrote: > Hi Jim, > > Thanks for the summary. We should proceed as you outlined. Can you file > a new RFE (Enhancement) to integrate Marlin into JavaFX as an optional > rasterizer (disabled by default) so we have a clean JBS issue to use for > the JDK 9 feature extension request, rather than using JDK-8092373? You > can assign the RFE to Laurent. It can be linked to the Java2D/Marlin JEP > and to JDK-8092373. > > Laurent: Since there are multiple reasons for submitting the Path2D fix > as a separate bug fix, please file a new bug for this, linking it to the > equivalent Java2D bug and also to the new RFE that Jim will file. > > Thanks. > > -- Kevin > > > Jim Graham wrote: >> There are basically 2 isolated changes to the existing code base and >> then a set of added source files. >> >> The first change is to use Marlin if the appropriate property is >> specified, and those changes are very localized and easy to verify >> that they won't hurt anything. >> >> The second change is to modify the growth pattern of Path2D. While >> these changes are live in AWT already and have already been code >> reviewed, it would probably be better to submit them as a separate FX >> fix if they are only performance oriented and not strictly required >> for Marlin to function. That way we compartmentalize anything that >> could possibly result in a regression into a separate bugid so we >> don't have to pull everything if someone complains that the new growth >> pattern is having negative consequences for their app. I doubt that >> will happen, but it is simple enough to break them into 2 separate >> fixes so it couldn't hurt to do that. >> >> After that, this just boils down to adding a bunch of code that has >> already been vetted elsewhere and a small and simple change to use it >> only optionally and conditionally, which is a very low risk fix. >> >> That would take this change from "no obvious drawbacks" to "obviously >> no drawbacks" (or, more precisely, one "obviously no drawbacks" fix >> and one related "no obvious drawbacks" fix)... >> >> ...jim >> >> On 11/2/2016 2:54 PM, Laurent Bourg?s wrote: >>> Jim, >>> >>> Here is an updated patch for MarlinFX: >>> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9/ >>> >>> I made big improvements: MarlinFX is now "feature-complete": >>> - Added MarlinAlphaConsumer & MarlinRenderer interfaces to define new >>> methods on AlphaConsumer and common methods between AA & noAA renderers >>> - Renderer: fixed cubic dec/inc lengths (like openpisces) + use >>> optimized >>> copyAlphas from MarlinAlphaConsumer (with block flag optimization >>> derived >>> from former MarlinCache) >>> - RendererNoAA: optimized Renderer for non-antialiasing (tested OK) >>> - Dasher & Stroker: backported changes from openpisces (small dash >>> phase & >>> refined cubic / quad mitters) >>> - Added MarlinPrismUtils & MarlinRasterizer classes to wrap the Marlin >>> renderer as a JavaFX ShapeRasterizer and implement the >>> MarlinAlphaConsumer >>> efficiently (mimics former MarlinCache ie support the block flag >>> optimization); MarlinPrismUtils performs properly NaN / Infinity >>> coordinates filtering and use the same pipeline stages (delta / invDelta >>> transformers for Dasher/Stroker) like in the MarlinRenderingEngine >>> - Thread safety: MarlinRasterizer completely thread-safe (for future >>> multi-threaded rendering) using ReentrantContext... >>> - Modified (OpenJFX) ShapeUtil to use the MarlinRasterizer instead of >>> the >>> OpenPiscesRasterizer class (use -Dsun.javafx.marlin=true to enable >>> Marlin-FX) >>> - Fixed Path2D growing algorithm (like java2d) >>> >>> So MarlinFX is 13K LOC (few unused classes could be removed soon) and >>> only >>> few lines are added in ShapeUtil to switch MarlinFX ON: >>> >>> if (PrismSettings.doNativePisces) { >>> shapeRasterizer = new NativePiscesRasterizer(); >>> } else { >>> >>> >>> >>> >>> >>> >>> * // TODO: move that new setting into PrismSettings: >>> // Enable Marlin-FX by setting -Dsun.javafx.marlin=true if >>> (MarlinProperties.isMarlinEnabled()) { >>> System.out.println("Marlin-FX[" + Version.getVersion() + "] >>> enabled."); shapeRasterizer = new >>> MarlinRasterizer(); } else {* >>> shapeRasterizer = >>> new OpenPiscesRasterizer(); >>> >>> * }* } >>> >>> So the OpenPisces classes are totally left unchanged and MarlinFX is >>> just >>> added as another rasterizer and is enabled with the following settings: >>> -Dsun.javafx.marlin=true and -Dprism.nativepisces=false >>> >>> Of course, we could adapt these few lines to satisfy your requirements >>> (system properties ...); please tell me what you prefer. >>> >>> I tested this new release with DemoFX, Guimark HTML5, Ensemble8 and >>> everything is working fine. >>> >>> >>> Does it look acceptable as a low risk RFE ? >>> >>> Finally what do you prefer for OpenJDK9 integration ? >>> - as a new javafx rasterizer (like the provided marlinFX patch) >>> - or as a javafx wrapper using OpenJDK9's marlin renderer (java2d) ? >>> I wonder if it would be better to create another JavaFX ShapeRasterizer >>> that wraps OpenJDK9 Marlin (java2d) to minimize the code duplication >>> but it >>> will add some complexity in the marlin renderer (itself) to introduce >>> the >>> AlphaConsumer interface... >>> >>> >>> I can make separate patches for all these changes concerning jfx >>> Path2D or >>> Marlin changes for OpenJDK9 first, then MarlinFX. >>> >>> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit >>> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I >>> will synchronize both branches to provide soon MarlinFX9 patches >>> closer to >>> OpenJDK9's Marlin renderer if we are going to work on its integration. >>> >>> PS2: I will also work on another MarlinFX variant not using Unsafe >>> but only >>> plain arrays to evaluate the performance loss (small) that could >>> simplify >>> the integration with Jigsaw ... >>> >>> So I made a big step forward, and I am looking forward your feedback, >>> >>> Cheers, >>> Laurent >>> From bourges.laurent at gmail.com Fri Nov 4 19:48:10 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 4 Nov 2016 20:48:10 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <581CA75E.60400@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <0991be17-ce78-8807-8836-a31f132b573f@oracle.com> <581CA75E.60400@oracle.com> Message-ID: Hi Kevin & Jim, this plan looks good for me. > Thanks for the summary. We should proceed as you outlined. Can you file a > new RFE (Enhancement) to integrate Marlin into JavaFX as an optional > rasterizer (disabled by default) so we have a clean JBS issue to use for > the JDK 9 feature extension request, rather than using JDK-8092373? You can > assign the RFE to Laurent. It can be linked to the Java2D/Marlin JEP and to > JDK-8092373. > Thanks, I got it. > Laurent: Since there are multiple reasons for submitting the Path2D fix as > a separate bug fix, please file a new bug for this, linking it to the > equivalent Java2D bug and also to the new RFE that Jim will file. > Will create the bug tomorrow and propose a specific webrev asap. Thanks, Laurent From dgr at libertysurf.fr Sat Nov 5 16:15:46 2016 From: dgr at libertysurf.fr (dgr at libertysurf.fr) Date: Sat, 5 Nov 2016 17:15:46 +0100 (CET) Subject: [Alpine Linux][amd64][JDK8] Build :graphics:compileDecoraNativeShadersLinux FAILED In-Reply-To: <59256390.292091100.1478361374042.JavaMail.root@zimbra65-e11.priv.proxad.net> Message-ID: <2027434438.292147778.1478362546415.JavaMail.root@zimbra65-e11.priv.proxad.net> Hi all, I'm trying to build JavaFX 8 taken from mercurial repo with Gradle 1.8 (as explained in https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) for alpine linux amd64 and face the following error : bash-4.3# gradle ... OS_NAME: linux OS_ARCH: amd64 JAVA_HOME: /usr/lib/jvm/java-1.8-openjdk JDK_HOME: /usr/lib/jvm/java-1.8-openjdk java.runtime.version: 1.8.0_92-internal-alpine-r1-b14 java version: 1.8.0_92 java build number: 14 jdk.runtime.version: 1.8.0_92-internal-alpine-r1-b14 jdk version: 1.8.0_92 jdk build number: 14 minimum java build number: 26 CONF: Debug NUM_COMPILE_THREADS: 8 COMPILE_TARGETS: linux COMPILE_FLAGS_FILES: buildSrc/linux.gradle HUDSON_JOB_NAME: not_hudson HUDSON_BUILD_NUMBER: 0000 PROMOTED_BUILD_NUMBER: 00 PRODUCT_NAME: OpenJFX RAW_VERSION: 8.0.132 RELEASE_NAME: 8u132 RELEASE_MILESTONE: ea UPDATE_STUB_CACHE: false The CompileOptions.useAnt property has been deprecated and is scheduled to be removed in Gradle 2.0. There is no replacement for this property. :checkJfxrtJar ... :graphics:compileDecoraNativeShadersLinux gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory :graphics:compileDecoraNativeShadersLinux FAILED ... We can notice there are 33 "gcc: error: : No such file or directory" Build with --stacktrace does not give more hints : * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':graphics:compileDecoraNativeShadersLinux'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) ... at org.gradle.launcher.GradleMain.main(GradleMain.java:23) Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':graphics:compileDecoraNativeShadersLinux' at org.gradle.util.JavaMethod.invoke(JavaMethod.java:69) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:527) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:510) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) ... 49 more Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished with non-zero exit value 1 at java_util_concurrent_Future$get.call(Unknown Source) at NativeCompileTask$_compile_closure6.doCall(NativeCompileTask.groovy:161) at NativeCompileTask.compile(NativeCompileTask.groovy:161) at org.gradle.util.JavaMethod.invoke(JavaMethod.java:62) ... 56 more Caused by: org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished with non-zero exit value 1 at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:361) at org.gradle.process.internal.DefaultExecAction.execute(DefaultExecAction.java:36) at org.gradle.api.internal.file.DefaultFileOperations.exec(DefaultFileOperations.java:179) at org.gradle.api.internal.project.AbstractProject.exec(AbstractProject.java:836) at org.gradle.api.internal.ProcessOperations$exec$5.call(Unknown Source) at CCTask.doCompile(CCTask.groovy:52) at NativeCompileTask.this$dist$invoke$3(NativeCompileTask.groovy) at NativeCompileTask$1.methodMissing(NativeCompileTask.groovy) at NativeCompileTask$1.run(NativeCompileTask.groovy:150) If I compile by myself the 33 files (from --debug output) : Compiling native files: [/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPerspectiveTransformPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_REDPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_ATOPPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEColorAdjustPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SCREENPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSESepiaTonePeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SOFT_LIGHTPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_GREENPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_BLUEPeer.cc, /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxShadowPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_BURNPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_DISTANTPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_OVERLAYPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEDisplacementMapPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DARKENPeer.cc, /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEUtils.cc, /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolveShadowPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEInvertMaskPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_SPOTPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DIFFERENCEPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_POINTPeer.cc, /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxBlurPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_EXCLUSIONPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_MULTIPLYPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_HARD_LIGHTPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_DODGEPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBrightpassPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OUTPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_ADDPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_LIGHTENPeer.cc, /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolvePeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_INPeer.cc, /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OVERPeer.cc] with the same command as gradle uses : gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -W -Wall -Wno-unused -Wno-parentheses -Werror=implicit-function-declaration -I/usr/lib/jvm/java-1.8-openjdk/include -I/usr/lib/jvm/java-1.8-openjdk/include/linux -c -O2 -DNDEBUG -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/atk-1.0 -pthread -ffast-math -I/tmp/javafx/rt/modules/graphics/build/generated-src/headers/jsl-decora -I/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora -I/tmp/javafx/rt/modules/graphics/src/main/native-decora -o /tmp/javafx/rt/modules/graphics/build/native/jsl-decora/linux/file.obj /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/file.cc the 33 files compiles without error ... I have also tested by setting NUM_COMPILE_THREADS to 1, without change. Any thoughts about what's happening ? Thx From kevin.rushforth at oracle.com Sat Nov 5 16:29:05 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 05 Nov 2016 09:29:05 -0700 Subject: [Alpine Linux][amd64][JDK8] Build :graphics:compileDecoraNativeShadersLinux FAILED In-Reply-To: <2027434438.292147778.1478362546415.JavaMail.root@zimbra65-e11.priv.proxad.net> References: <2027434438.292147778.1478362546415.JavaMail.root@zimbra65-e11.priv.proxad.net> Message-ID: <581E08D1.4090208@oracle.com> Did you install any new packages after the first time you got a build failure? If so, you might try manually doing: rm -rf build This will cause the various properties files in build to be recreated. -- Kevin dgr at libertysurf.fr wrote: > Hi all, > > I'm trying to build JavaFX 8 taken from mercurial repo with Gradle 1.8 (as explained in https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) for alpine linux amd64 and face the following error : > > > bash-4.3# gradle > ... > OS_NAME: linux > OS_ARCH: amd64 > JAVA_HOME: /usr/lib/jvm/java-1.8-openjdk > JDK_HOME: /usr/lib/jvm/java-1.8-openjdk > java.runtime.version: 1.8.0_92-internal-alpine-r1-b14 > java version: 1.8.0_92 > java build number: 14 > jdk.runtime.version: 1.8.0_92-internal-alpine-r1-b14 > jdk version: 1.8.0_92 > jdk build number: 14 > minimum java build number: 26 > CONF: Debug > NUM_COMPILE_THREADS: 8 > COMPILE_TARGETS: linux > COMPILE_FLAGS_FILES: buildSrc/linux.gradle > HUDSON_JOB_NAME: not_hudson > HUDSON_BUILD_NUMBER: 0000 > PROMOTED_BUILD_NUMBER: 00 > PRODUCT_NAME: OpenJFX > RAW_VERSION: 8.0.132 > RELEASE_NAME: 8u132 > RELEASE_MILESTONE: ea > UPDATE_STUB_CACHE: false > The CompileOptions.useAnt property has been deprecated and is scheduled to be > removed in Gradle 2.0. There is no replacement for this property. > :checkJfxrtJar > ... > :graphics:compileDecoraNativeShadersLinux > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > gcc: error: : No such file or directory > :graphics:compileDecoraNativeShadersLinux FAILED > ... > > We can notice there are 33 "gcc: error: : No such file or directory" > > Build with --stacktrace does not give more hints : > > * Exception is: > org.gradle.api.tasks.TaskExecutionException: Execution failed for task > ':graphics:compileDecoraNativeShadersLinux'. > at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) > at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) > ... > at org.gradle.launcher.GradleMain.main(GradleMain.java:23) > Caused by: org.gradle.api.GradleException: Could not call NativeCompileTask.compile() on task ':graphics:compileDecoraNativeShadersLinux' > at org.gradle.util.JavaMethod.invoke(JavaMethod.java:69) > at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219) > at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212) > at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201) > at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:527) > at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:510) > at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) > at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) > ... 49 more > Caused by: java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished with non-zero exit value 1 > at java_util_concurrent_Future$get.call(Unknown Source) > at NativeCompileTask$_compile_closure6.doCall(NativeCompileTask.groovy:161) > at NativeCompileTask.compile(NativeCompileTask.groovy:161) > at org.gradle.util.JavaMethod.invoke(JavaMethod.java:62) > ... 56 more > Caused by: org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished with non-zero exit value 1 > at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:361) > at org.gradle.process.internal.DefaultExecAction.execute(DefaultExecAction.java:36) > at org.gradle.api.internal.file.DefaultFileOperations.exec(DefaultFileOperations.java:179) > at org.gradle.api.internal.project.AbstractProject.exec(AbstractProject.java:836) at org.gradle.api.internal.ProcessOperations$exec$5.call(Unknown Source) > at CCTask.doCompile(CCTask.groovy:52) > at NativeCompileTask.this$dist$invoke$3(NativeCompileTask.groovy) > at NativeCompileTask$1.methodMissing(NativeCompileTask.groovy) > at NativeCompileTask$1.run(NativeCompileTask.groovy:150) > > If I compile by myself the 33 files (from --debug output) : > > Compiling native files: > [/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPerspectiveTransformPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_REDPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_ATOPPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEColorAdjustPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SCREENPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSESepiaTonePeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SOFT_LIGHTPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_GREENPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_BLUEPeer.cc, > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxShadowPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_BURNPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_DISTANTPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_OVERLAYPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEDisplacementMapPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DARKENPeer.cc, > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEUtils.cc, > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolveShadowPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEInvertMaskPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_SPOTPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DIFFERENCEPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_POINTPeer.cc, > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxBlurPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_EXCLUSIONPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_MULTIPLYPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_HARD_LIGHTPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_DODGEPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBrightpassPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OUTPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_ADDPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_LIGHTENPeer.cc, > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolvePeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_INPeer.cc, > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OVERPeer.cc] > > with the same command as gradle uses : > > gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -W -Wall -Wno-unused > -Wno-parentheses -Werror=implicit-function-declaration > -I/usr/lib/jvm/java-1.8-openjdk/include > -I/usr/lib/jvm/java-1.8-openjdk/include/linux -c -O2 -DNDEBUG > -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo > -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 > -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/atk-1.0 > -pthread -ffast-math > -I/tmp/javafx/rt/modules/graphics/build/generated-src/headers/jsl-decora > -I/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora > -I/tmp/javafx/rt/modules/graphics/src/main/native-decora -o > /tmp/javafx/rt/modules/graphics/build/native/jsl-decora/linux/file.obj > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/file.cc > > the 33 files compiles without error ... > > > I have also tested by setting NUM_COMPILE_THREADS to 1, without change. > Any thoughts about what's happening ? > > > Thx > From dgr at libertysurf.fr Sat Nov 5 16:49:15 2016 From: dgr at libertysurf.fr (dgr at libertysurf.fr) Date: Sat, 5 Nov 2016 17:49:15 +0100 (CET) Subject: [Alpine Linux][amd64][JDK8] Build :graphics:compileDecoraNativeShadersLinux FAILED In-Reply-To: <581E08D1.4090208@oracle.com> Message-ID: <709519544.292242097.1478364555275.JavaMail.root@zimbra65-e11.priv.proxad.net> No, I did not install any new packages after the first build failure. In fact, I am building the javafx in a docker container restarting from the beginning at each test ! Looking at the long output of the build, I noticed this : ... :buildSrc:generateGrammarSource error(10): internal error: Can't get property indirectDelegates using method get/isIndirectDelegates from org.antlr.tool.Grammar instance : java.lang.NullPointerException java.util.Objects.requireNonNull(Objects.java:203) java.util.ArrayList.removeAll(ArrayList.java:689) org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222) org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563) org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514) org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416) org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java:351) org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136) org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEvaluator.java:216) org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.codegen.CodeGenerator.write(CodeGenerator.java:1278) org.antlr.codegen.Target.genRecognizerFile(Target.java:94) org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:463) org.antlr.Tool.generateRecognizer(Tool.java:607) org.antlr.Tool.process(Tool.java:429) org.antlr.Tool.main(Tool.java:91) :buildSrc:compileJava ... May be there is a relationship between this and the final error ? Didier ----- Mail original ----- > Did you install any new packages after the first time you got a build > failure? If so, you might try manually doing: > > rm -rf build > > This will cause the various properties files in build to be > recreated. > > -- Kevin > > > > dgr at libertysurf.fr wrote: > > Hi all, > > > > I'm trying to build JavaFX 8 taken from mercurial repo with Gradle > > 1.8 (as explained in > > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) > > for alpine linux amd64 and face the following error : > > > > > > bash-4.3# gradle > > ... > > OS_NAME: linux > > OS_ARCH: amd64 > > JAVA_HOME: /usr/lib/jvm/java-1.8-openjdk > > JDK_HOME: /usr/lib/jvm/java-1.8-openjdk > > java.runtime.version: 1.8.0_92-internal-alpine-r1-b14 > > java version: 1.8.0_92 > > java build number: 14 > > jdk.runtime.version: 1.8.0_92-internal-alpine-r1-b14 > > jdk version: 1.8.0_92 > > jdk build number: 14 > > minimum java build number: 26 > > CONF: Debug > > NUM_COMPILE_THREADS: 8 > > COMPILE_TARGETS: linux > > COMPILE_FLAGS_FILES: buildSrc/linux.gradle > > HUDSON_JOB_NAME: not_hudson > > HUDSON_BUILD_NUMBER: 0000 > > PROMOTED_BUILD_NUMBER: 00 > > PRODUCT_NAME: OpenJFX > > RAW_VERSION: 8.0.132 > > RELEASE_NAME: 8u132 > > RELEASE_MILESTONE: ea > > UPDATE_STUB_CACHE: false > > The CompileOptions.useAnt property has been deprecated and is > > scheduled to be > > removed in Gradle 2.0. There is no replacement for this property. > > :checkJfxrtJar > > ... > > :graphics:compileDecoraNativeShadersLinux > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > gcc: error: : No such file or directory > > :graphics:compileDecoraNativeShadersLinux FAILED > > ... > > > > We can notice there are 33 "gcc: error: : No such file or > > directory" > > > > Build with --stacktrace does not give more hints : > > > > * Exception is: > > org.gradle.api.tasks.TaskExecutionException: Execution failed for > > task > > ':graphics:compileDecoraNativeShadersLinux'. > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) > > ... > > at org.gradle.launcher.GradleMain.main(GradleMain.java:23) > > Caused by: org.gradle.api.GradleException: Could not call > > NativeCompileTask.compile() on task > > ':graphics:compileDecoraNativeShadersLinux' > > at org.gradle.util.JavaMethod.invoke(JavaMethod.java:69) > > at > > org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219) > > at > > org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212) > > at > > org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201) > > at > > org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:527) > > at > > org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:510) > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) > > ... 49 more > > Caused by: java.util.concurrent.ExecutionException: > > org.gradle.process.internal.ExecException: Process 'command 'gcc'' > > finished with non-zero exit value 1 > > at java_util_concurrent_Future$get.call(Unknown Source) > > at > > NativeCompileTask$_compile_closure6.doCall(NativeCompileTask.groovy:161) > > at NativeCompileTask.compile(NativeCompileTask.groovy:161) > > at org.gradle.util.JavaMethod.invoke(JavaMethod.java:62) > > ... 56 more > > Caused by: org.gradle.process.internal.ExecException: Process > > 'command 'gcc'' finished with non-zero exit value 1 > > at > > org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:361) > > at > > org.gradle.process.internal.DefaultExecAction.execute(DefaultExecAction.java:36) > > at > > org.gradle.api.internal.file.DefaultFileOperations.exec(DefaultFileOperations.java:179) > > at > > org.gradle.api.internal.project.AbstractProject.exec(AbstractProject.java:836) > > at > > org.gradle.api.internal.ProcessOperations$exec$5.call(Unknown > > Source) > > at CCTask.doCompile(CCTask.groovy:52) > > at > > NativeCompileTask.this$dist$invoke$3(NativeCompileTask.groovy) > > at > > NativeCompileTask$1.methodMissing(NativeCompileTask.groovy) > > at NativeCompileTask$1.run(NativeCompileTask.groovy:150) > > > > If I compile by myself the 33 files (from --debug output) : > > > > Compiling native files: > > [/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPerspectiveTransformPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_REDPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_ATOPPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEColorAdjustPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SCREENPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSESepiaTonePeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SOFT_LIGHTPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_GREENPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_BLUEPeer.cc, > > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxShadowPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_BURNPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_DISTANTPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_OVERLAYPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEDisplacementMapPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DARKENPeer.cc, > > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEUtils.cc, > > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolveShadowPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEInvertMaskPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_SPOTPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DIFFERENCEPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_POINTPeer.cc, > > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxBlurPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_EXCLUSIONPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_MULTIPLYPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_HARD_LIGHTPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_DODGEPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBrightpassPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OUTPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_ADDPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_LIGHTENPeer.cc, > > /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolvePeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_INPeer.cc, > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OVERPeer.cc] > > > > with the same command as gradle uses : > > > > gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -W -Wall > > -Wno-unused > > -Wno-parentheses -Werror=implicit-function-declaration > > -I/usr/lib/jvm/java-1.8-openjdk/include > > -I/usr/lib/jvm/java-1.8-openjdk/include/linux -c -O2 -DNDEBUG > > -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include > > -I/usr/include/pango-1.0 > > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > > -I/usr/include/cairo > > -I/usr/include/pixman-1 -I/usr/include/freetype2 > > -I/usr/include/libpng16 > > -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 > > -I/usr/include/atk-1.0 > > -pthread -ffast-math > > -I/tmp/javafx/rt/modules/graphics/build/generated-src/headers/jsl-decora > > -I/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora > > -I/tmp/javafx/rt/modules/graphics/src/main/native-decora -o > > /tmp/javafx/rt/modules/graphics/build/native/jsl-decora/linux/file.obj > > /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/file.cc > > > > the 33 files compiles without error ... > > > > > > I have also tested by setting NUM_COMPILE_THREADS to 1, without > > change. > > Any thoughts about what's happening ? > > > > > > Thx > > > From bourges.laurent at gmail.com Sun Nov 6 21:01:43 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sun, 6 Nov 2016 22:01:43 +0100 Subject: Review request for 8169294: Message-ID: Hi, Please review this Path2D fix improving its storage growth algorithm as done in java2d: JBS: https://bugs.openjdk.java.net/browse/JDK-8169294 Webrev: http://cr.openjdk.java.net/~lbourges/fx/path2D/ PS: I converted the former jtreg test to JUnit test for OpenJFX. I hope it is correct, as I was not able to run this test within gradle (but it works in netbeans) Best regards, Laurent From semyon.sadetsky at oracle.com Mon Nov 7 15:45:47 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 7 Nov 2016 18:45:47 +0300 Subject: [9] Review request for 8169309: Migrate SwingNode to the new float API of JLightweightFrame Message-ID: <7080c18d-9fb5-31ee-8838-80f5f9a3dcb9@oracle.com> Hello Kevin & Jim, Please review the fix for jfx9: webrev: http://cr.openjdk.java.net/~ssadetsky/8169309/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8153522 --Semyon From kevin.rushforth at oracle.com Mon Nov 7 16:10:15 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Nov 2016 08:10:15 -0800 Subject: [Alpine Linux][amd64][JDK8] Build :graphics:compileDecoraNativeShadersLinux FAILED In-Reply-To: <709519544.292242097.1478364555275.JavaMail.root@zimbra65-e11.priv.proxad.net> References: <709519544.292242097.1478364555275.JavaMail.root@zimbra65-e11.priv.proxad.net> Message-ID: <5820A767.2070803@oracle.com> The NPE is a known issue with antlr that happens on all platforms and is unrelated to your gcc error. -- Kevin dgr at libertysurf.fr wrote: > No, I did not install any new packages after the first build failure. In fact, I am building the javafx in a docker container restarting from the beginning at each test ! > > Looking at the long output of the build, I noticed this : > > ... > :buildSrc:generateGrammarSource > error(10): internal error: Can't get property indirectDelegates using method get/isIndirectDelegates from org.antlr.tool.Grammar instance : java.lang.NullPointerException > java.util.Objects.requireNonNull(Objects.java:203) > java.util.ArrayList.removeAll(ArrayList.java:689) > org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222) > org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:498) > org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563) > org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514) > org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416) > org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java:351) > org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136) > org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEvaluator.java:216) > org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126) > org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) > org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) > org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) > org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) > org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) > org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) > org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) > org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) > org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) > org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86) > org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) > org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) > org.antlr.codegen.CodeGenerator.write(CodeGenerator.java:1278) > org.antlr.codegen.Target.genRecognizerFile(Target.java:94) > org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:463) > org.antlr.Tool.generateRecognizer(Tool.java:607) > org.antlr.Tool.process(Tool.java:429) > org.antlr.Tool.main(Tool.java:91) > :buildSrc:compileJava > ... > > May be there is a relationship between this and the final error ? > > Didier > > ----- Mail original ----- > >> Did you install any new packages after the first time you got a build >> failure? If so, you might try manually doing: >> >> rm -rf build >> >> This will cause the various properties files in build to be >> recreated. >> >> -- Kevin >> >> >> >> dgr at libertysurf.fr wrote: >> >>> Hi all, >>> >>> I'm trying to build JavaFX 8 taken from mercurial repo with Gradle >>> 1.8 (as explained in >>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) >>> for alpine linux amd64 and face the following error : >>> >>> >>> bash-4.3# gradle >>> ... >>> OS_NAME: linux >>> OS_ARCH: amd64 >>> JAVA_HOME: /usr/lib/jvm/java-1.8-openjdk >>> JDK_HOME: /usr/lib/jvm/java-1.8-openjdk >>> java.runtime.version: 1.8.0_92-internal-alpine-r1-b14 >>> java version: 1.8.0_92 >>> java build number: 14 >>> jdk.runtime.version: 1.8.0_92-internal-alpine-r1-b14 >>> jdk version: 1.8.0_92 >>> jdk build number: 14 >>> minimum java build number: 26 >>> CONF: Debug >>> NUM_COMPILE_THREADS: 8 >>> COMPILE_TARGETS: linux >>> COMPILE_FLAGS_FILES: buildSrc/linux.gradle >>> HUDSON_JOB_NAME: not_hudson >>> HUDSON_BUILD_NUMBER: 0000 >>> PROMOTED_BUILD_NUMBER: 00 >>> PRODUCT_NAME: OpenJFX >>> RAW_VERSION: 8.0.132 >>> RELEASE_NAME: 8u132 >>> RELEASE_MILESTONE: ea >>> UPDATE_STUB_CACHE: false >>> The CompileOptions.useAnt property has been deprecated and is >>> scheduled to be >>> removed in Gradle 2.0. There is no replacement for this property. >>> :checkJfxrtJar >>> ... >>> :graphics:compileDecoraNativeShadersLinux >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> gcc: error: : No such file or directory >>> :graphics:compileDecoraNativeShadersLinux FAILED >>> ... >>> >>> We can notice there are 33 "gcc: error: : No such file or >>> directory" >>> >>> Build with --stacktrace does not give more hints : >>> >>> * Exception is: >>> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>> task >>> ':graphics:compileDecoraNativeShadersLinux'. >>> at >>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) >>> at >>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) >>> ... >>> at org.gradle.launcher.GradleMain.main(GradleMain.java:23) >>> Caused by: org.gradle.api.GradleException: Could not call >>> NativeCompileTask.compile() on task >>> ':graphics:compileDecoraNativeShadersLinux' >>> at org.gradle.util.JavaMethod.invoke(JavaMethod.java:69) >>> at >>> org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219) >>> at >>> org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212) >>> at >>> org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201) >>> at >>> org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:527) >>> at >>> org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:510) >>> at >>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) >>> at >>> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) >>> ... 49 more >>> Caused by: java.util.concurrent.ExecutionException: >>> org.gradle.process.internal.ExecException: Process 'command 'gcc'' >>> finished with non-zero exit value 1 >>> at java_util_concurrent_Future$get.call(Unknown Source) >>> at >>> NativeCompileTask$_compile_closure6.doCall(NativeCompileTask.groovy:161) >>> at NativeCompileTask.compile(NativeCompileTask.groovy:161) >>> at org.gradle.util.JavaMethod.invoke(JavaMethod.java:62) >>> ... 56 more >>> Caused by: org.gradle.process.internal.ExecException: Process >>> 'command 'gcc'' finished with non-zero exit value 1 >>> at >>> org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:361) >>> at >>> org.gradle.process.internal.DefaultExecAction.execute(DefaultExecAction.java:36) >>> at >>> org.gradle.api.internal.file.DefaultFileOperations.exec(DefaultFileOperations.java:179) >>> at >>> org.gradle.api.internal.project.AbstractProject.exec(AbstractProject.java:836) >>> at >>> org.gradle.api.internal.ProcessOperations$exec$5.call(Unknown >>> Source) >>> at CCTask.doCompile(CCTask.groovy:52) >>> at >>> NativeCompileTask.this$dist$invoke$3(NativeCompileTask.groovy) >>> at >>> NativeCompileTask$1.methodMissing(NativeCompileTask.groovy) >>> at NativeCompileTask$1.run(NativeCompileTask.groovy:150) >>> >>> If I compile by myself the 33 files (from --debug output) : >>> >>> Compiling native files: >>> [/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPerspectiveTransformPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_REDPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_ATOPPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEColorAdjustPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SCREENPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSESepiaTonePeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SOFT_LIGHTPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_GREENPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_BLUEPeer.cc, >>> /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxShadowPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_BURNPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_DISTANTPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_OVERLAYPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEDisplacementMapPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DARKENPeer.cc, >>> /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEUtils.cc, >>> /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolveShadowPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEInvertMaskPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_SPOTPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_DIFFERENCEPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEPhongLighting_POINTPeer.cc, >>> /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSEBoxBlurPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_EXCLUSIONPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_MULTIPLYPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_HARD_LIGHTPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_COLOR_DODGEPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBrightpassPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OUTPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_ADDPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_LIGHTENPeer.cc, >>> /tmp/javafx/rt/modules/graphics/src/main/native-decora/SSELinearConvolvePeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_INPeer.cc, >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/SSEBlend_SRC_OVERPeer.cc] >>> >>> with the same command as gradle uses : >>> >>> gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -W -Wall >>> -Wno-unused >>> -Wno-parentheses -Werror=implicit-function-declaration >>> -I/usr/lib/jvm/java-1.8-openjdk/include >>> -I/usr/lib/jvm/java-1.8-openjdk/include/linux -c -O2 -DNDEBUG >>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include >>> -I/usr/include/pango-1.0 >>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >>> -I/usr/include/cairo >>> -I/usr/include/pixman-1 -I/usr/include/freetype2 >>> -I/usr/include/libpng16 >>> -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 >>> -I/usr/include/atk-1.0 >>> -pthread -ffast-math >>> -I/tmp/javafx/rt/modules/graphics/build/generated-src/headers/jsl-decora >>> -I/tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora >>> -I/tmp/javafx/rt/modules/graphics/src/main/native-decora -o >>> /tmp/javafx/rt/modules/graphics/build/native/jsl-decora/linux/file.obj >>> /tmp/javafx/rt/modules/graphics/build/generated-src/jsl-decora/file.cc >>> >>> the 33 files compiles without error ... >>> >>> >>> I have also tested by setting NUM_COMPILE_THREADS to 1, without >>> change. >>> Any thoughts about what's happening ? >>> >>> >>> Thx >>> >>> From David.Hill at Oracle.com Mon Nov 7 16:13:32 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 07 Nov 2016 11:13:32 -0500 Subject: Heads up: Modular build is close..... Message-ID: <5820A82C.8040102@Oracle.com> The new modular build is close... ! The plan is for me to push the change set around 10 EST (7PST) on Tuesday. This way we have much of the week to respond to disruptions. Unlike one of my previous changes, there should be less disruption (less moved files, did not change buildSrc). BUT ... there is some things I have mentioned, that I will mention again. This build checks for versions of gradle and the JDK. We are sensitive to ant versions. * Gradle 3.1 [1] * JDK 9 ea build 142+ [2] * ANT 1.8.2 [3] Before pulling in the Tuesday changesets, it is very good practice to either run: gradle clean or hg purge --all to tidy up your repo (or both :-) [1] https://gradle.org/gradle-download/ [2] https://jdk9.java.net/download/ [3] https://ant.apache.org/bindownload.cgi -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From arunprasad.rajkumar at oracle.com Mon Nov 7 16:50:18 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 7 Nov 2016 22:20:18 +0530 Subject: [webkit] [9] Review request for 8088205: [Mac] WebView renders icons instead of letters on some sites In-Reply-To: <0863B2AC-2B17-4EA9-91F3-92FDC8E2C073@oracle.com> References: <0863B2AC-2B17-4EA9-91F3-92FDC8E2C073@oracle.com> Message-ID: <1E2E10C4-70CC-4331-A8BF-E4FB6C7AFE8C@oracle.com> Hello Kevin, Phil, I have incorporated review comments, Please take a look. http://cr.openjdk.java.net/~arajkumar/8088205/webrev.01/ Thanks, Arun > On 04-Oct-2016, at 12:15 AM, Arunprasad Rajkumar wrote: > > Hello Kevin, Phil, Guru > > Please review the following fix. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8088205 > > Webrev: http://cr.openjdk.java.net/~arajkumar/8088205/webrev.00 > > Analysis: Some Web Fonts(like Thin.ttf, refer the attachment) doesn?t have valid entry in the TTF Naming Table. Due to missing entry, ?CTFontCreateWithName? is not returning correct font reference. > > Solution: Use ?CGFontCreateWithDataProvider?, it takes font path as a parameter and creates a CGFontRef, then create a CTFontRef using CGFontRef. > ?CGFontCreateWithDataProvider? doesn?t support TTC font type, so use ?CTFontCreateWithName? as a fallback if CGFontRef creation fails. > > Test - 1: Load http://www.cnet.com with HelloWebView > > Test - 2: Try simple fx application present in https://bugs.openjdk.java.net/secure/attachment/62649/CustomFontApp.tar.bz2 > > Regards, > Arun > > > From john at status6.com Mon Nov 7 17:55:06 2016 From: john at status6.com (John Neffenger) Date: Mon, 7 Nov 2016 09:55:06 -0800 Subject: Issues porting to Monocle EPD platform Message-ID: <55937ce0-446a-61a9-7e6d-8ca1bbda2d1f@status6.com> While porting OpenJFX to devices with an electronic paper display, I resolved three issues in the graphics module that I thought I should pass along. The following merge request on GitLab lists the issues and my minor changes. See the Commits and Changes tabs in the middle of the page for details. WIP: Patches to OpenJFX https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1 Did I understand the code correctly? I would appreciate any feedback. As a brief summary, the first issue, "QuantumRenderer modifies buffer in use by JavaFX Application Thread," may be of general interest because it occurs on the Monocle Headless and VNC platforms. The second issue, "zForce touchscreen input device fails when closed and immediately reopened," might affect only my platform, or maybe just the older Linux kernel and device driver I'm forced to use, but I couldn't find a good workaround without duplicating the entire LinuxInputDevice class. The third issue, "Get two bytes for the Linux input event type, not four," doesn't seem to cause any problems, but may still be worth fixing. Thank you, John From David.Hill at Oracle.com Mon Nov 7 18:07:13 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 07 Nov 2016 13:07:13 -0500 Subject: Issues porting to Monocle EPD platform In-Reply-To: <55937ce0-446a-61a9-7e6d-8ca1bbda2d1f@status6.com> References: <55937ce0-446a-61a9-7e6d-8ca1bbda2d1f@status6.com> Message-ID: <5820C2D1.4010102@Oracle.com> On 11/7/16, 12:55 PM, John Neffenger wrote: Hi John, I am probably the guy that will be looking over these, but I am in the middle of a big push. Feel free to ping me offline if I don't get back to you by early next week. Dave > While porting OpenJFX to devices with an electronic paper display, I resolved three issues in the graphics module that I thought I should pass along. The following merge request on GitLab lists the issues and my minor changes. See the Commits and Changes tabs in the middle of the page for details. > > WIP: Patches to OpenJFX > https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1 > > Did I understand the code correctly? I would appreciate any feedback. > > As a brief summary, the first issue, "QuantumRenderer modifies buffer in use by JavaFX Application Thread," may be of general interest because it occurs on the Monocle Headless and VNC platforms. > > The second issue, "zForce touchscreen input device fails when closed and immediately reopened," might affect only my platform, or maybe just the older Linux kernel and device driver I'm forced to use, but I couldn't find a good workaround without duplicating the entire LinuxInputDevice class. > > The third issue, "Get two bytes for the Linux input event type, not four," doesn't seem to cause any problems, but may still be worth fixing. > > Thank you, > John -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Mon Nov 7 20:05:12 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 7 Nov 2016 12:05:12 -0800 Subject: Review request for 8169294: In-Reply-To: References: Message-ID: <63cd0995-b637-4e07-7353-d8c55c50a41b@oracle.com> I'd like to see Kevin review the test as I'm not the best expert on our JUnit framework. It looks like it is mostly just going to emit some printouts about performance (using echo() and log()) and verify that we don't get any ArrayBounds related exceptions (or worse, OOME)? The only difference in Path2D.java I noted is that the Java2D version has an EXPAND_MIN which is 10, but you re-use INIT_SIZE, which is 20, here for the same purpose. I think that's fine, but wanted to point it out so you could comment... ...jim On 11/6/2016 1:01 PM, Laurent Bourg?s wrote: > Hi, > > Please review this Path2D fix improving its storage growth algorithm as > done in java2d: > JBS: https://bugs.openjdk.java.net/browse/JDK-8169294 > Webrev: http://cr.openjdk.java.net/~lbourges/fx/path2D/ > > PS: I converted the former jtreg test to JUnit test for OpenJFX. I hope > it is correct, as I was not able to run this test within gradle (but it > works in netbeans) > > Best regards, > Laurent From bourges.laurent at gmail.com Mon Nov 7 21:14:53 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 7 Nov 2016 22:14:53 +0100 Subject: Review request for 8169294: In-Reply-To: <63cd0995-b637-4e07-7353-d8c55c50a41b@oracle.com> References: <63cd0995-b637-4e07-7353-d8c55c50a41b@oracle.com> Message-ID: Jim, 2016-11-07 21:05 GMT+01:00 Jim Graham : > I'd like to see Kevin review the test as I'm not the best expert on our > JUnit framework. > I just added @Test annotations and kept the jtreg tags in header (for information). I could add asserts but JUnit does intercept any thrown exception and reports a test failure in such case. I managed to undestand how to run my test with gradle: gradle :graphics:test --tests test.com.sun.javafx.geom.Path2DGrowTest It is passing and the reports indicates that the 2 new tests are OK (report in modules/javafx.graphics/build/reports/tests/index.html) > > It looks like it is mostly just going to emit some printouts about > performance (using echo() and log()) and verify that we don't get any > ArrayBounds related exceptions (or worse, OOME)? > Exactly, it is passing as there is no runtime exception and the performance issue is fixed as indicated by the few logged lines. > > The only difference in Path2D.java I noted is that the Java2D version has > an EXPAND_MIN which is 10, but you re-use INIT_SIZE, which is 20, here for > the same purpose. > You're right; I think I didn't want to add an extra constant but if you prefer being more consistent, I can prepare another webrev. Laurent From philip.race at oracle.com Mon Nov 7 22:23:25 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 7 Nov 2016 14:23:25 -0800 Subject: RFR: 8088325 & 8169339 : Provide internal JDK API to JavaFX to locate JDK fonts Message-ID: Hi, Two bug ids, two webrevs and a cross-post since JDK needs to provide a qualified export to JavaFX so it can access any fonts that may be provided with the JDK. FX bug: https://bugs.openjdk.java.net/browse/JDK-8088325 FX fix : http://cr.openjdk.java.net/~prr/8088325/ JDK bug : https://bugs.openjdk.java.net/browse/JDK-8169339 JDK fix : http://cr.openjdk.java.net/~prr/8169339/ -phil. From kevin.rushforth at oracle.com Mon Nov 7 22:50:12 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Nov 2016 14:50:12 -0800 Subject: Review request for 8169294: In-Reply-To: References: <63cd0995-b637-4e07-7353-d8c55c50a41b@oracle.com> Message-ID: <58210524.2090309@oracle.com> I'll review the test tomorrow (I'm a little backed up on my code reviews given the impending change to build with jigsaw JDK). -- Kevin Laurent Bourg?s wrote: > Jim, > > 2016-11-07 21:05 GMT+01:00 Jim Graham >: > > I'd like to see Kevin review the test as I'm not the best expert > on our JUnit framework. > > > I just added @Test annotations and kept the jtreg tags in header (for > information). > I could add asserts but JUnit does intercept any thrown exception and > reports a test failure in such case. > > I managed to undestand how to run my test with gradle: > gradle :graphics:test --tests test.com.sun.javafx.geom.Path2DGrowTest > > It is passing and the reports indicates that the 2 new tests are OK > (report in modules/javafx.graphics/build/reports/tests/index.html) > > > > It looks like it is mostly just going to emit some printouts about > performance (using echo() and log()) and verify that we don't get > any ArrayBounds related exceptions (or worse, OOME)? > > > Exactly, it is passing as there is no runtime exception and the > performance issue is fixed as indicated by the few logged lines. > > > > The only difference in Path2D.java I noted is that the Java2D > version has an EXPAND_MIN which is 10, but you re-use INIT_SIZE, > which is 20, here for the same purpose. > > > You're right; I think I didn't want to add an extra constant but if > you prefer being more consistent, I can prepare another webrev. > > Laurent From bourges.laurent at gmail.com Mon Nov 7 22:55:02 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 7 Nov 2016 23:55:02 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> Message-ID: Jim, Here is the new patch: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/ Changes: - cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner) - modified PrismSettings as recommended and renamed all Marlin properties to use the prefix 'prism.marlin' - SWContext: added Marlin SW support: I had to tweak the processed range[x; pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does not handle properly the bbox so it processes many extra pixels on the left side (empty coverage) = to be discussed as it can be fixed in the native prism-sw code ... See my comment in the code: + @Override+ public void setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+ final int pix_from, final int pix_to)+ {+ // use x instead of pix_from as it cause artefacts:+ // note: it would be more efficient to skip all those empty pixels [x to pix_from[+ // but the native implementation must be fixed too.+// pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from, pix_to, rowNum);+ pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, x, pix_to, rowNum); I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143 (xpatch.args) with Ensemble8 + DemoFX. Maybe it is time to start the review for the FX enhancement ? https://bugs.openjdk.java.net/browse/JDK-8169270 Cheers, Laurent 2016-11-04 19:55 GMT+01:00 Jim Graham : > On 11/4/2016 11:33 AM, Laurent Bourg?s wrote: > >> For SWContext, I figured out that only openpisces.* classes were used >> directly via imports (hardcoded) so I left it unchanged. So you propose >> to generalize use of marlin or native pisces ? >> > > I didn't notice that, I was just searching on the use of > "doNativePisces". We can look at that separately, and Kevin would know how > frequently we end up in the SW pipeline these days... From james.graham at oracle.com Tue Nov 8 02:08:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 7 Nov 2016 18:08:48 -0800 Subject: Review request for 8169294: In-Reply-To: References: <63cd0995-b637-4e07-7353-d8c55c50a41b@oracle.com> Message-ID: On 11/7/2016 1:14 PM, Laurent Bourg?s wrote: >> The only difference in Path2D.java I noted is that the Java2D version has >> an EXPAND_MIN which is 10, but you re-use INIT_SIZE, which is 20, here for >> the same purpose. > > You're right; I think I didn't want to add an extra constant but if you > prefer being more consistent, I can prepare another webrev. In looking at it again, I don't think it matters since it would only ever be triggered if they created a path that intentionally had fewer than the default number of entries, so it makes more sense to always grow by at least the INIT_SIZE rather than a smaller number. I think I like the new policy better than the one in Java2D... ...jim From derijcke.erik at gmail.com Tue Nov 8 08:49:25 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Tue, 8 Nov 2016 09:49:25 +0100 Subject: Issues porting to Monocle EPD platform In-Reply-To: <5820C2D1.4010102@Oracle.com> References: <55937ce0-446a-61a9-7e6d-8ca1bbda2d1f@status6.com> <5820C2D1.4010102@Oracle.com> Message-ID: Hi John, In regard to your input issue. If it's a possibility, I'd recommend looking at 'libinput'. It's an generic input abstraction library. It might be more up to date and provide quirk fixes for (all kind of) input hardware. https://wayland.freedesktop.org/libinput/doc/latest/ It's already the default input library used by X.org and Wayland compositors but is in no way dependend on them. regards, Erik On Mon, Nov 7, 2016 at 7:07 PM, David Hill wrote: > On 11/7/16, 12:55 PM, John Neffenger wrote: > > Hi John, > I am probably the guy that will be looking over these, but I am in the > middle of a big push. Feel free to ping me offline if I don't get back to > you by early next week. > > Dave > > While porting OpenJFX to devices with an electronic paper display, I >> resolved three issues in the graphics module that I thought I should pass >> along. The following merge request on GitLab lists the issues and my minor >> changes. See the Commits and Changes tabs in the middle of the page for >> details. >> >> WIP: Patches to OpenJFX >> https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1 >> >> Did I understand the code correctly? I would appreciate any feedback. >> >> As a brief summary, the first issue, "QuantumRenderer modifies buffer in >> use by JavaFX Application Thread," may be of general interest because it >> occurs on the Monocle Headless and VNC platforms. >> >> The second issue, "zForce touchscreen input device fails when closed and >> immediately reopened," might affect only my platform, or maybe just the >> older Linux kernel and device driver I'm forced to use, but I couldn't find >> a good workaround without duplicating the entire LinuxInputDevice class. >> >> The third issue, "Get two bytes for the Linux input event type, not >> four," doesn't seem to cause any problems, but may still be worth fixing. >> >> Thank you, >> John >> > > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey > the world." > -- George Santayana (1863 - 1952) > > From bourges.laurent at gmail.com Tue Nov 8 08:50:37 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 8 Nov 2016 09:50:37 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> Message-ID: Hi, I think we should wait for OpenJFX9 Jigsaw build patch that is coming and rebase / test again the proposed patch Marlin for JavaFX. Maybe jdk.internal.Cleaner or Unsafe.allocateDirect methods will be then available to the javafx.graphics module or that may be acceptable to export such jdk API to OpenJFX. Finally I will have a look at the native prism sw code to see if I can fix the forementioned method by adding 1 integer to give the output_minx coordinate and only process pixels where the alpha coverage != 0. Please give me your opinions. Cheers, Laurent Le 7 nov. 2016 23:55, "Laurent Bourg?s" a ?crit : > Jim, > > Here is the new patch: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/ > > Changes: > - cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner) > - modified PrismSettings as recommended and renamed all Marlin properties > to use the prefix 'prism.marlin' > - SWContext: added Marlin SW support: I had to tweak the processed > range[x; pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does > not handle properly the bbox so it processes many extra pixels on the left > side (empty coverage) = to be discussed as it can be fixed in the native > prism-sw code ... See my comment in the code: > > + @Override+ public void setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+ final int pix_from, final int pix_to)+ {+ // use x instead of pix_from as it cause artefacts:+ // note: it would be more efficient to skip all those empty pixels [x to pix_from[+ // but the native implementation must be fixed too.+// pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from, pix_to, rowNum);+ pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, x, pix_to, rowNum); > > I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143 > (xpatch.args) with Ensemble8 + DemoFX. > > Maybe it is time to start the review for the FX enhancement ? > https://bugs.openjdk.java.net/browse/JDK-8169270 > > Cheers, > Laurent > > > 2016-11-04 19:55 GMT+01:00 Jim Graham : > >> On 11/4/2016 11:33 AM, Laurent Bourg?s wrote: >> >>> For SWContext, I figured out that only openpisces.* classes were used >>> directly via imports (hardcoded) so I left it unchanged. So you propose >>> to generalize use of marlin or native pisces ? >>> >> >> I didn't notice that, I was just searching on the use of >> "doNativePisces". We can look at that separately, and Kevin would know how >> frequently we end up in the SW pipeline these days... > > From Sergey.Bylokhov at oracle.com Tue Nov 8 10:43:46 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 8 Nov 2016 13:43:46 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8088325 & 8169339 : Provide internal JDK API to JavaFX to locate JDK fonts In-Reply-To: References: Message-ID: <0b21b1d3-904e-a013-b7a3-f2c418488ab4@oracle.com> jdk part looks fine. ps: We also can think about customizing this location for custom jdk via the "public api" in jdk-dir/conf/font.properties On 08.11.16 1:23, Phil Race wrote: > Hi, > Two bug ids, two webrevs and a cross-post since JDK needs to provide a > qualified export to JavaFX so it can access any fonts that may be provided > with the JDK. > > FX bug: https://bugs.openjdk.java.net/browse/JDK-8088325 > FX fix : http://cr.openjdk.java.net/~prr/8088325/ > > JDK bug : https://bugs.openjdk.java.net/browse/JDK-8169339 > JDK fix : http://cr.openjdk.java.net/~prr/8169339/ > > > -phil. -- Best regards, Sergey. From David.Hill at Oracle.com Tue Nov 8 14:42:32 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 08 Nov 2016 09:42:32 -0500 Subject: ACTION - JavaFX modular build is here Message-ID: <5821E458.7000009@Oracle.com> The new modular build has been committed to 9-dev !!! To ensure a continued happy development, please consider the following advice :-) Clean up your old repository before syncing. gradle clean consider (but not required) hg purge --all unset JIGSAW_HOME # this enviroment variable is no longer used in 9-dev Download, install and verify you have the version you think you have. Gradle 3.1+ [1] JDK 9 build 142+ [2] Ant 1.8.2 (note, that there are known issue with 1.9.x) [3] Remember, if you still need to work with older workspaces like 8, keep gradle 2.11 around, as Gradle 3.1 will NOT work. To help with this, I set to environment variables: GRADLE2_HOME=__path_to_gradle_2 GRADLE3_HOME=__path_to_gradle_3 and then now add $GRADLE3_HOME/bin to my path as this is the default I use. But this allows me to use $GRADLE2_HOME/bin/gradle in older repositories. At this point, sync in the new changes and build it ! export JDK_HOME=_path_to_jdk_9_ea_142+ $GRADLE3_HOME/bin/gradle clean sdk [1] https://gradle.org/gradle-download/ [2] https://jdk9.java.net/download/ [3] https://ant.apache.org/bindownload.cgi -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Tue Nov 8 14:47:20 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 08 Nov 2016 09:47:20 -0500 Subject: FX Modular build - FIVE Shocking things you need to know about the new build.... Message-ID: <5821E578.2040608@Oracle.com> What do you need to know about the new modular build (or how does this affect me ?) I have covered the need for a new Gradle 3.1+, JDK 9 build 142+ already, so moving beyond that.... FIVE Shocking things you need to know about the new build.... !!!!!!! :-) FIRST: There is NO jfxrt.jar anymore. This quite a change, but the new practice has already been talked about before. The build produces: rt/build/run.args rt/build/compile.args (Note: run.args was renamed from xpatch.args as the java command line arguments changed) These are "argfiles" which is a way of batching up command line option for ease of use. Fyi, argfiles work with javac in JDK8, and were added to the java command in JDK9. Assuming you have reset JDK_HOME to point to JDK 9 ea build 142+, then building an running an FX application from the command lines would look like this: $JDK_HOME/bin/javac @_path_to_/compile.args -d build src/mytest/MyTestApp.java $JDK_HOME/bin/java @_path_to_/run.args -cp build mytest.MyTestApp Please note that these arg files contain absolute paths to your repository artifacts. If you want to copy the artifacts (rt/build/modular-sdk) to another location, then there is a script (rt/tools/scripts/make_runargs.sh) to generate a new run.args file There is a corresponding set of argfiles that contain the test "shim" classes as well as the full modules. These are testrun.args and testcompile.args. Because the test modules modules contain a module-info.class (it is filtered out when we copy to rt/build/modular-sdk) it is quite likely that you will see one or more: WARNING: module-info.class not allowed in patch: (path to the module) These are annoying and harmless, and there is nothing we can do to suppress them. SECOND: The FX built class files are "target=1.9". This is required by javac when we are building modules. If you have an existing netbeans project, you may need to edit it to update the value. This also means that any application like an IDE that parses class files may have a problem with the newer version. THIRD: Module test classes are now split apart. Before we had the "shim" classes and the unit test classes all in one hierarchy. This does not work so well with the modular build, and so the shim classes have been separated into a new hierarchy. before: modules/javafx.base/src/test/... now: unit tests in modules/javafx.base/src/test/... shims in modules/javafx.base/src/shims/java/ For unit tests, we rebuild the modules that needs shims again, but this time add in the shim sources. The resulting module is then passed into the unit test run using -patch-module. FOURTH: In the past we often used jfxrt.jar via a bootclasspath. One side effect of this was "all permissions" for the FX classes, which matched how the bundled FX classes are treated in the JDK. This does not work with JDK9 and -patch-module. If you run into security issues with a test application, then you will need to use a java.security.manager, and a policy file that starts with the one we generate during the test task of our build: rt/build/test.java.policy (again, one that contains absolute paths). It is reasonably easy to add to an ant file an action that will start with this file, and add in any test application specific additions, and the resulting file can then be used for the application run. FIFTH: There are early access editions of IDEs. Let us know if you find ways to get these to work :-) Netbeans: http://wiki.netbeans.org/JDK9Support Intellij: https://confluence.jetbrains.com/display/IDEADEV/EAP -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From david.dehaven at oracle.com Tue Nov 8 19:04:57 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 8 Nov 2016 11:04:57 -0800 Subject: ACTION - JavaFX modular build is here In-Reply-To: <5821E458.7000009@Oracle.com> References: <5821E458.7000009@Oracle.com> Message-ID: > The new modular build has been committed to 9-dev !!! And you've just made my job about 100x easier! Huge thanks! -DrD- From David.Hill at Oracle.com Tue Nov 8 19:30:47 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 08 Nov 2016 14:30:47 -0500 Subject: Modular build: understanding addExports Message-ID: <582227E7.40209@Oracle.com> There are times when you just have to break the rules.... :-) And when it comes to module package internals visibility, we have to at least bend the rules a bit, particularly for testing. In comes the 'addExports" file. These files in the FX tree are actually 'argfiles' passed to javac and/or the java command. Lets look at an example.... apps/tests/Robot This test application uses non public/internal FX API, but is valuable to visually test that functionality. To get around the visibility issue, we use --add-exports arguments to explicitly allow access. Looking at the file we see: $ cat apps/tests/Robot/addExports --add-exports=javafx.graphics/com.sun.glass.events=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED As the Robots.jar is an "un-named" automatic module, we export to the magic ALL-UNNAMED. Nothing in the tool chain knows about this addExports file, so we do a small amount of Ant magic in nbproject/project.properties to add it to the compile and run paths. All of this means that 'ant clean run' just works :-) (But of course manually launching Robot.jar does not unless we add to the command line). There are other uses worth mentioning. Most of our unit tests have cases that need special access. These are handled in modules/*/src/test/addExports, and might need to be touched if you are adding a test case with new needs. Lastly there are some really special cases in build.gradle that don't quite fit the pattern. The Decora build for example has the --add-exports explicitly in build.gradle. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Wed Nov 9 00:11:13 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 08 Nov 2016 16:11:13 -0800 Subject: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles Message-ID: <582269A1.8010201@oracle.com> Hi, Please review the following fix to include jake-compatible versions of module-info.java with our input bundles: https://bugs.openjdk.java.net/browse/JDK-8169417 http://cr.openjdk.java.net/~kcr/8169417/webrev.00/ These new files end up in a new "modules_src_jake" subdirectory of modular-sdk, and are zipped up delivered to the JDK build as javafx-exports.zip along with the existing directories. The existing jdk9 build will not be affected. The jisgaw/jake build will take the modules_src_jake files in preference to modules_src. NOTE: for the files that have a jake-equivalent, we will need to keep them in sync going forward for as long as we need both. -- Kevin From mandy.chung at oracle.com Wed Nov 9 00:17:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Nov 2016 16:17:49 -0800 Subject: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles In-Reply-To: <582269A1.8010201@oracle.com> References: <582269A1.8010201@oracle.com> Message-ID: Looks good to me. Mandy > On Nov 8, 2016, at 4:11 PM, Kevin Rushforth wrote: > > Hi, > > Please review the following fix to include jake-compatible versions of module-info.java with our input bundles: > > https://bugs.openjdk.java.net/browse/JDK-8169417 > http://cr.openjdk.java.net/~kcr/8169417/webrev.00/ > > These new files end up in a new "modules_src_jake" subdirectory of modular-sdk, and are zipped up delivered to the JDK build as javafx-exports.zip along with the existing directories. The existing jdk9 build will not be affected. The jisgaw/jake build will take the modules_src_jake files in preference to modules_src. > > NOTE: for the files that have a jake-equivalent, we will need to keep them in sync going forward for as long as we need both. > > -- Kevin > From chris.bensen at oracle.com Wed Nov 9 01:08:26 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 8 Nov 2016 17:08:26 -0800 Subject: [9] Review request: DK-8169417: JavaFX to include jake-compatible versions of module-info.java with import bundles In-Reply-To: <582269A1.8010201@oracle.com> References: <582269A1.8010201@oracle.com> Message-ID: +1 I did a quick test on Mac and it worked for me. Chris > On Nov 8, 2016, at 4:11 PM, Kevin Rushforth wrote: > > Hi, > > Please review the following fix to include jake-compatible versions of module-info.java with our input bundles: > > https://bugs.openjdk.java.net/browse/JDK-8169417 > http://cr.openjdk.java.net/~kcr/8169417/webrev.00/ > > These new files end up in a new "modules_src_jake" subdirectory of modular-sdk, and are zipped up delivered to the JDK build as javafx-exports.zip along with the existing directories. The existing jdk9 build will not be affected. The jisgaw/jake build will take the modules_src_jake files in preference to modules_src. > > NOTE: for the files that have a jake-equivalent, we will need to keep them in sync going forward for as long as we need both. > > -- Kevin > From kevin.rushforth at oracle.com Wed Nov 9 02:57:33 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 08 Nov 2016 18:57:33 -0800 Subject: RFR: 8088325 & 8169339 : Provide internal JDK API to JavaFX to locate JDK fonts In-Reply-To: References: Message-ID: <5822909D.3030807@oracle.com> Changes look good to me. I verified that they can go in in either order. -- Kevin Phil Race wrote: > Hi, > Two bug ids, two webrevs and a cross-post since JDK needs to provide a > qualified export to JavaFX so it can access any fonts that may be > provided > with the JDK. > > FX bug: https://bugs.openjdk.java.net/browse/JDK-8088325 > FX fix : http://cr.openjdk.java.net/~prr/8088325/ > > JDK bug : https://bugs.openjdk.java.net/browse/JDK-8169339 > JDK fix : http://cr.openjdk.java.net/~prr/8169339/ > > > -phil. From bourges.laurent at gmail.com Wed Nov 9 09:30:08 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 9 Nov 2016 10:30:08 +0100 Subject: ACTION - JavaFX modular build is here In-Reply-To: <5821E458.7000009@Oracle.com> References: <5821E458.7000009@Oracle.com> Message-ID: Hi david, I am trying to build OpenJDK9 with OpenJFX9 (tip); I run the following scenario: - build OpenJFX9 with JDK9 EA 143: ok - build OpenJDK9 with --with-import-modules=_path_to_openjfx/9-dev/build/modular-sdk: ok - build OpenJFX9 with the built OpenJDK9: KO (gradle clean all) Apparently, the dependency on the commercial jdk.jfr module is required: :base:compileJava /home/graphics-rasterizer/client/openjfx9/modules/javafx.base/src/main/java/module-info.java:28: error: module not found: jdk.jfr requires jdk.jfr; ^ 1 error :base:compileJava FAILED Any workaround ? PS: as you recommended me for Marlin JavaFX, I am trying adding a dependencies on modules: openjfx9/dependencies/java.base/module-info.java.extra: 27d26 < exports jdk.internal.ref to javafx.graphics; What is the magic to make cross-references between OpenJDK / OpenJFX builds ? Thanks for your help, Laurent 2016-11-08 15:42 GMT+01:00 David Hill : > > The new modular build has been committed to 9-dev !!! From daniel.gloeckner at 360t.com Wed Nov 9 10:23:40 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Wed, 9 Nov 2016 10:23:40 +0000 Subject: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385540@EOFFICE-EX01.360t.com> Hi guys, We're facing an exception triggered from Parent.updateCachedBounds. I've pasted the stack trace below. This looks very similar to https://bugs.openjdk.java.net/browse/JDK-8163078. We have a few listeners to layoutBounds property, similar to the reporter of that issue. This seems to trigger the issue. For us it's hard to reproduce this issue in our application. If the bug shows up the result is quite disastrous though. The application freezes in this case. Has anyone observed this bug or is aware of a workaround? P4 suggests that it's a low priority issue with minor loss of functionality... really? Kind regards, Daniel ERROR [28.10.16 13:01:45.415] DefaultLogger uncaughtException() java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.elementData(Unknown Source) at java.util.ArrayList.get(Unknown Source) at com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:89) at com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:306) at javafx.scene.Parent.updateCachedBounds(Parent.java:1591) at javafx.scene.Parent.recomputeBounds(Parent.java:1535) at javafx.scene.Parent.impl_computeGeomBounds(Parent.java:1388) at javafx.scene.layout.Region.impl_computeGeomBounds(Region.java:3078) at javafx.scene.Node.updateGeomBounds(Node.java:3579) at javafx.scene.Node.getGeomBounds(Node.java:3532) at javafx.scene.Node.getLocalBounds(Node.java:3480) at javafx.scene.Node.updateTxBounds(Node.java:3643) at javafx.scene.Node.getTransformedBounds(Node.java:3426) at javafx.scene.Node.updateBounds(Node.java:559) at javafx.scene.Parent.updateBounds(Parent.java:1719) at javafx.scene.Parent.updateBounds(Parent.java:1717) at javafx.scene.Parent.updateBounds(Parent.java:1717) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2404) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolkit.java:319) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) at java.lang.Thread.run(Unknown Source) From arunprasad.rajkumar at oracle.com Wed Nov 9 12:36:44 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 9 Nov 2016 18:06:44 +0530 Subject: [webkit] [9] Review request for 8167675: Animated gifs are not working Message-ID: <396191ED-6572-4C75-9E89-0CE4CA19FB4F@oracle.com> Hello Kevin, Guru, Murali, Please review the below patch. JIRA: https://bugs.openjdk.java.net/browse/JDK-8167675 Webrev: http://cr.openjdk.java.net/~arajkumar/8167675/webrev Analysis: Image frame count is not updated properly after JDK-8153148 . Frame count is an important property which is needed while animating any GIF image. Solution: WCImageDecoderImpl.getFrameCount() method will be called just before rendering an Image, if we have full image data, then initiate a image decoding to get number of frames present in the image. Regards, Arun From kevin.rushforth at oracle.com Wed Nov 9 12:40:49 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 09 Nov 2016 04:40:49 -0800 Subject: ACTION - JavaFX modular build is here In-Reply-To: References: <5821E458.7000009@Oracle.com> Message-ID: <58231951.2040703@oracle.com> I will file a bug and fix this morning. I almost did yesterday as cleanup (we no longer use it even for the closed build). -- Kevin Laurent Bourg?s wrote: > Hi david, > > I am trying to build OpenJDK9 with OpenJFX9 (tip); I run the following > scenario: > - build OpenJFX9 with JDK9 EA 143: ok > - build OpenJDK9 with > --with-import-modules=_path_to_openjfx/9-dev/build/modular-sdk: > ok > - build OpenJFX9 with the built OpenJDK9: KO (gradle clean all) > > Apparently, the dependency on the commercial jdk.jfr module is required: > > :base:compileJava > /home/graphics-rasterizer/client/openjfx9/modules/javafx.base/src/main/java/module-info.java:28: > error: module not found: jdk.jfr > requires jdk.jfr; > ^ > 1 error > :base:compileJava FAILED > > Any workaround ? > > PS: as you recommended me for Marlin JavaFX, I am trying adding a > dependencies on modules: > openjfx9/dependencies/java.base/module-info.java.extra: > 27d26 > < exports jdk.internal.ref to javafx.graphics; > > What is the magic to make cross-references between OpenJDK / OpenJFX builds > ? > > > Thanks for your help, > Laurent > > 2016-11-08 15:42 GMT+01:00 David Hill : > > >> The new modular build has been committed to 9-dev !!! >> From kevin.rushforth at oracle.com Wed Nov 9 13:05:47 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 09 Nov 2016 05:05:47 -0800 Subject: [9] Review request: 8169500: Cannot build JavaFX with OpenJDK due to dependency on jdk.jfr Message-ID: <58231F2B.3070807@oracle.com> Dave, Please review: https://bugs.openjdk.java.net/browse/JDK-8169500 Diff is in the JBS issue. -- Kevin From David.Hill at Oracle.com Wed Nov 9 13:32:38 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 09 Nov 2016 08:32:38 -0500 Subject: ACTION - JavaFX modular build is here In-Reply-To: References: <5821E458.7000009@Oracle.com> Message-ID: <58232576.4050207@Oracle.com> On 11/9/16, 4:30 AM, Laurent Bourg?s wrote: Nice catch. Points out that I should have tried a fully open build path. I did try several times an open JFX build, but each time I was using a commercial JDK. Kevin will push a fix today. Dave > Hi david, > > I am trying to build OpenJDK9 with OpenJFX9 (tip); I run the following scenario: > - build OpenJFX9 with JDK9 EA 143: ok > - build OpenJDK9 with --with-import-modules=_path_to_openjfx/9-dev/build/modular-sdk: ok > - build OpenJFX9 with the built OpenJDK9: KO (gradle clean all) > > Apparently, the dependency on the commercial jdk.jfr module is required: > > :base:compileJava > /home/graphics-rasterizer/client/openjfx9/modules/javafx.base/src/main/java/module-info.java:28: error: module not found: jdk.jfr > requires jdk.jfr; > ^ > 1 error > :base:compileJava FAILED > > Any workaround ? > > PS: as you recommended me for Marlin JavaFX, I am trying adding a dependencies on modules: > openjfx9/dependencies/java.base/module-info.java.extra: > 27d26 > < exports jdk.internal.ref to javafx.graphics; > > What is the magic to make cross-references between OpenJDK / OpenJFX builds ? > > > Thanks for your help, > Laurent > > 2016-11-08 15:42 GMT+01:00 David Hill >: > > > The new modular build has been committed to 9-dev !!! > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Wed Nov 9 13:46:58 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 09 Nov 2016 08:46:58 -0500 Subject: ACTION - JavaFX modular build is here In-Reply-To: References: <5821E458.7000009@Oracle.com> Message-ID: <582328D2.7010704@Oracle.com> On 11/9/16, 4:30 AM, Laurent Bourg?s wrote: > Any workaround ? > > PS: as you recommended me for Marlin JavaFX, I am trying adding a dependencies on modules: > openjfx9/dependencies/java.base/module-info.java.extra: > 27d26 > < exports jdk.internal.ref to javafx.graphics; > > What is the magic to make cross-references between OpenJDK / OpenJFX builds ? I think this should work. Note that the real fix is to get the second part into a JDK, at which point the workaround part goes away. diff --git a/build.gradle b/build.gradle --- a/build.gradle +++ b/build.gradle @@ -1678,6 +1678,16 @@ } classes.dependsOn(compileFullJava) + + //Temporary workaround until this is part of the java.base module + compileJava.options.compilerArgs.addAll([ + "--add-exports=java.base/jdk.internal.ref=javafx.graphics", + ]) + compileFullJava.options.compilerArgs.addAll([ + "--add-exports=java.base/jdk.internal.ref=javafx.graphics", + ]) + //End workaround + // Create a single "native" task which will depend on all the individual native tasks for graphics project.ext.nativeAllTask = task("native", group: "Build", description: "Compiles and Builds all native libraries for Graphics"); project.ext.cleanNativeAllTask = task("cleanNative", group: "Build", description: "Clean all native libraries and objects for Graphics"); diff --git a/dependencies/java.base/module-info.java.extra b/dependencies/java.base/module-info.java.extra --- a/dependencies/java.base/module-info.java.extra +++ b/dependencies/java.base/module-info.java.extra @@ -24,6 +24,7 @@ */ exports jdk.internal.misc to javafx.graphics; +exports jdk.internal.ref to javafx.graphics; exports jdk.internal.ref to javafx.media; exports sun.net.www to javafx.web; exports sun.nio.ch to javafx.media; -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Wed Nov 9 13:51:14 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 09 Nov 2016 05:51:14 -0800 Subject: ACTION - JavaFX modular build is here In-Reply-To: <582328D2.7010704@Oracle.com> References: <5821E458.7000009@Oracle.com> <582328D2.7010704@Oracle.com> Message-ID: <582329D2.6030805@oracle.com> My recommendation would be to avoid this dependency if possible, but if not, then Dave's suggestion is the way to go. What is it that you need from jdk.internal.ref that you can't do using public API? -- Kevin David Hill wrote: > On 11/9/16, 4:30 AM, Laurent Bourg?s wrote: >> Any workaround ? >> >> PS: as you recommended me for Marlin JavaFX, I am trying adding a >> dependencies on modules: >> openjfx9/dependencies/java.base/module-info.java.extra: >> 27d26 >> < exports jdk.internal.ref to javafx.graphics; >> >> What is the magic to make cross-references between OpenJDK / OpenJFX >> builds ? > > I think this should work. Note that the real fix is to get the second > part into a JDK, at which point the workaround part goes away. > > diff --git a/build.gradle b/build.gradle > --- a/build.gradle > +++ b/build.gradle > @@ -1678,6 +1678,16 @@ > } > classes.dependsOn(compileFullJava) > > + > + //Temporary workaround until this is part of the java.base module > + compileJava.options.compilerArgs.addAll([ > + "--add-exports=java.base/jdk.internal.ref=javafx.graphics", > + ]) > + compileFullJava.options.compilerArgs.addAll([ > + "--add-exports=java.base/jdk.internal.ref=javafx.graphics", > + ]) > + //End workaround > + > // Create a single "native" task which will depend on all the > individual native tasks for graphics > project.ext.nativeAllTask = task("native", group: "Build", > description: "Compiles and Builds all native libraries for Graphics"); > project.ext.cleanNativeAllTask = task("cleanNative", group: > "Build", description: "Clean all native libraries and objects for > Graphics"); > diff --git a/dependencies/java.base/module-info.java.extra > b/dependencies/java.base/module-info.java.extra > --- a/dependencies/java.base/module-info.java.extra > +++ b/dependencies/java.base/module-info.java.extra > @@ -24,6 +24,7 @@ > */ > > exports jdk.internal.misc to javafx.graphics; > +exports jdk.internal.ref to javafx.graphics; > exports jdk.internal.ref to javafx.media; > exports sun.net.www to javafx.web; > exports sun.nio.ch to javafx.media; > > From bourges.laurent at gmail.com Wed Nov 9 14:25:52 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 9 Nov 2016 15:25:52 +0100 Subject: ACTION - JavaFX modular build is here In-Reply-To: <582329D2.6030805@oracle.com> References: <5821E458.7000009@Oracle.com> <582328D2.7010704@Oracle.com> <582329D2.6030805@oracle.com> Message-ID: Kevin & David, It seems tricky to add a module dependency ! 2016-11-09 14:51 GMT+01:00 Kevin Rushforth : > My recommendation would be to avoid this dependency if possible, but if > not, then Dave's suggestion is the way to go. What is it that you need from > jdk.internal.ref that you can't do using public API? > Marlin (OpenJDK) use jdk.internal.ref.CleanerFactory.cleaner() to get the java.base Cleaner instance (Thread). I agree for Marlin-FX, it will be easier to use the public Cleaner API but it will cost creating another thread. Here is the current fix : // JavaFX specific Cleaner for Marlin-FX: // Module issue with jdk.internal.ref.Cleaner private final static java.lang.ref.Cleaner cleaner = java.lang.ref.Cleaner.create(); static java.lang.ref.Cleaner getCleaner() { return cleaner; } instead of: /* static jdk.internal.ref.Cleaner getCleaner() { return jdk.internal.ref.CleanerFactory.cleaner(); } */ Regards, Laurent From kevin.rushforth at oracle.com Wed Nov 9 15:46:12 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 09 Nov 2016 07:46:12 -0800 Subject: ACTION - JavaFX modular build is here In-Reply-To: References: <5821E458.7000009@Oracle.com> <582328D2.7010704@Oracle.com> <582329D2.6030805@oracle.com> Message-ID: <582344C4.1060209@oracle.com> Yes, it is somewhat tricky to add a new qualified export. I would expect that to be rare. For JDK 9 let's go with the public API since it will be fewer moving parts. -- Kevin Laurent Bourg?s wrote: > Kevin & David, > > It seems tricky to add a module dependency ! > > 2016-11-09 14:51 GMT+01:00 Kevin Rushforth >: > > My recommendation would be to avoid this dependency if possible, > but if not, then Dave's suggestion is the way to go. What is it > that you need from jdk.internal.ref that you can't do using public > API? > > > Marlin (OpenJDK) use jdk.internal.ref.CleanerFactory.cleaner() to get > the java.base Cleaner instance (Thread). > > I agree for Marlin-FX, it will be easier to use the public Cleaner API > but it will cost creating another thread. > > Here is the current fix : > > // JavaFX specific Cleaner for Marlin-FX: > // Module issue with jdk.internal.ref.Cleaner > private final static java.lang.ref.Cleaner cleaner > = java.lang.ref.Cleaner.create(); > > static java.lang.ref.Cleaner getCleaner() { > return cleaner; > } > > instead of: > /* > static jdk.internal.ref.Cleaner getCleaner() { > return jdk.internal.ref.CleanerFactory.cleaner(); > } > */ > > Regards, > Laurent From snfuchs at gmx.de Wed Nov 9 18:59:23 2016 From: snfuchs at gmx.de (Stefan Fuchs) Date: Wed, 9 Nov 2016 19:59:23 +0100 Subject: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds In-Reply-To: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385540@EOFFICE-EX01.360t.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385540@EOFFICE-EX01.360t.com> Message-ID: Hi Daniel, are you registering or removing the listeners on a thread other than the JavaFX Application Thread? I think the Observables are not thread save. -- regards Stefan > Hi guys, > > We're facing an exception triggered from Parent.updateCachedBounds. I've pasted the stack trace below. > > This looks very similar to https://bugs.openjdk.java.net/browse/JDK-8163078. > > We have a few listeners to layoutBounds property, similar to the reporter of that issue. This seems to trigger the issue. > > For us it's hard to reproduce this issue in our application. If the bug shows up the result is quite disastrous though. The application freezes in this case. > > Has anyone observed this bug or is aware of a workaround? P4 suggests that it's a low priority issue with minor loss of functionality... really? > > Kind regards, > Daniel > > ERROR [28.10.16 13:01:45.415] DefaultLogger uncaughtException() > java.lang.ArrayIndexOutOfBoundsException: -1 > at java.util.ArrayList.elementData(Unknown Source) > at java.util.ArrayList.get(Unknown Source) > at com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:89) > at com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:306) > at javafx.scene.Parent.updateCachedBounds(Parent.java:1591) > at javafx.scene.Parent.recomputeBounds(Parent.java:1535) > at javafx.scene.Parent.impl_computeGeomBounds(Parent.java:1388) > at javafx.scene.layout.Region.impl_computeGeomBounds(Region.java:3078) > at javafx.scene.Node.updateGeomBounds(Node.java:3579) > at javafx.scene.Node.getGeomBounds(Node.java:3532) > at javafx.scene.Node.getLocalBounds(Node.java:3480) > at javafx.scene.Node.updateTxBounds(Node.java:3643) > at javafx.scene.Node.getTransformedBounds(Node.java:3426) > at javafx.scene.Node.updateBounds(Node.java:559) > at javafx.scene.Parent.updateBounds(Parent.java:1719) > at javafx.scene.Parent.updateBounds(Parent.java:1717) > at javafx.scene.Parent.updateBounds(Parent.java:1717) > at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2404) > at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) > at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) > at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolkit.java:319) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191) > at java.lang.Thread.run(Unknown Source) > From David.Hill at Oracle.com Wed Nov 9 20:34:37 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 09 Nov 2016 15:34:37 -0500 Subject: review: correct concatenation of dependencies/*/*.extra files Message-ID: <5823885D.7040507@Oracle.com> Kevin, if you would review.... JBS: https://bugs.openjdk.java.net/browse/JDK-8169511 diff inline. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Wed Nov 9 23:27:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 9 Nov 2016 15:27:48 -0800 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <5808B9D2.30909@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> Message-ID: <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> On 10/20/16 5:34 AM, Kevin Rushforth wrote: >> For now the OpenPiscesRasterizer class uses a static Renderer (single >> instance) so it is single-threaded. >> >> In MarlinFX I could prepare the multi-threading support by using 1 >> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >> >> However it seems a complex task to enable parallelization in the javafx >> pipeline but I could help there also... >> > > Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the > limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the > default OpenPisces path to be unaltered. Also, such a parallelization of the javafx pipelines would be a fairly large task. I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? ...jim From james.graham at oracle.com Wed Nov 9 23:30:29 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 9 Nov 2016 15:30:29 -0800 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> Message-ID: On 10/21/16 9:51 AM, Laurent Bourg?s wrote: > Jim, do you think possible to unify Marlin and MarlinFX for openjdk9 ? The > main difference relies in different Shape/PathConsumer classes and Fx uses > the AlphaConsumer + different initialization. > Did you have a look at the diffs ? One of the big hurdles here is that Java2DMarlin is in a very large module in the JDK and we currently run independently of it. We'd have to break Marlin out into a separate module shared by both and I think that is outside our scope right now...? ...jim From james.graham at oracle.com Wed Nov 9 23:39:07 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 9 Nov 2016 15:39:07 -0800 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> Message-ID: <0759bda9-7f3f-fecb-cb84-b64b575dcec6@oracle.com> Going forward perhaps we should refer to the version of Marlin in Java2D as Marlin2D? Then Marlin is your original plug-in version that is still being worked on. Marlin2D is what you integrated into OpenJDK/Java2D. MarlinFX is what you are planning for FX. That's just for conversational purposes, I'm not proposing that we formalize those into formal project names, but this will keep discussions smaller? On 11/2/16 2:54 PM, Laurent Bourg?s wrote: > PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit > different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I > will synchronize both branches to provide soon MarlinFX9 patches closer to > OpenJDK9's Marlin renderer if we are going to work on its integration. If I read this correctly, you have outstanding changes you've made to Marlin that you plan to propose for Marlin2D, but they haven't been proposed yet? And you based MarlinFX on the newer version of Marlin with those outstanding changes? Is your plan to propose a patch for Marlin2D soon? For now I'd like to keep the 2 versions of Marlin in the JDK in sync other than differences required for Java2D's rendering pipelines vs. the FX ones. That will simplify at least the intial proposal to integrate this if we can say it is "99% the same as the one in Java2D other than differences required by the pipelines" which should quiet any fears that might get in the way. Did I read that correctly? Does that sound reasonable? ...jim From james.graham at oracle.com Wed Nov 9 23:47:37 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 9 Nov 2016 15:47:37 -0800 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> Message-ID: <654d24fc-0b40-1be6-e5f2-28773a373f8f@oracle.com> Hi Laurent, Great job on creating a very obvious minimal impact! That should help streamline it through the approval process. Is MarlinProperties.isEnabled still used? (Searching patch file - no, I don't think so) Kevin and I had a long back and forth over the packaging of the Reentrant files and came up with "com.sun.util.reentrant" as we'd like to avoid "com.sun" as a terminal package. We should eventually move a few other common utilities into that new tree as well, but we can start with these classes. I still want to take a pass through the changes to the Marlin files themselves, but above is my review of the glue code and with that Kevin can pursue the internal processes. Before I pursue too far on reading the Marlin source changes, I'd like to hear back about how this version of Marlin(FX) differs from the OpenJDK version of Marlin(2D) - were they based on different versions of your Marlin project? Also, you mentioned waiting for the jigsaw build patch integration. I'm guessing you meant the build changes that happened yesterday, so we can proceed now? With respect to the changes to the native part of the SW pipeline that would trim the rendering - please continue to investigate them, but we should pursue those as a separate bug fix so as not to complicate this particular change. It sounds like you've adapted the new code in the SWContext wrapper class to not require that native change yet, so let's go with that for the first phase... ...jim On 11/7/16 2:55 PM, Laurent Bourg?s wrote: > Jim, > > Here is the new patch: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/ > > Changes: > - cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner) > - modified PrismSettings as recommended and renamed all Marlin properties > to use the prefix 'prism.marlin' > - SWContext: added Marlin SW support: I had to tweak the processed range[x; > pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does not handle > properly the bbox so it processes many extra pixels on the left side (empty > coverage) = to be discussed as it can be fixed in the native prism-sw code > ... See my comment in the code: > > + @Override+ public void > setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+ > final int pix_from, > final int pix_to)+ {+ // use x instead of > pix_from as it cause artefacts:+ // note: it would be > more efficient to skip all those empty pixels [x to pix_from[+ > // but the native implementation must be fixed too.+// > pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from, > pix_to, rowNum);+ pr.emitAndClearAlphaRow(alpha_map, > alphaDeltas, pix_y, x, pix_to, rowNum); > > I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143 > (xpatch.args) with Ensemble8 + DemoFX. > > Maybe it is time to start the review for the FX enhancement ? > https://bugs.openjdk.java.net/browse/JDK-8169270 > > Cheers, > Laurent > > > 2016-11-04 19:55 GMT+01:00 Jim Graham : > >> On 11/4/2016 11:33 AM, Laurent Bourg?s wrote: >> >>> For SWContext, I figured out that only openpisces.* classes were used >>> directly via imports (hardcoded) so I left it unchanged. So you propose >>> to generalize use of marlin or native pisces ? >>> >> >> I didn't notice that, I was just searching on the use of >> "doNativePisces". We can look at that separately, and Kevin would know how >> frequently we end up in the SW pipeline these days... From felix.bembrick at gmail.com Wed Nov 9 23:57:14 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 10 Nov 2016 10:57:14 +1100 Subject: Marlin-Renderer and JavaFX In-Reply-To: <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> Message-ID: > On 10 Nov. 2016, at 10:27, Jim Graham wrote: > > On 10/20/16 5:34 AM, Kevin Rushforth wrote: >>> For now the OpenPiscesRasterizer class uses a static Renderer (single >>> instance) so it is single-threaded. >>> >>> In MarlinFX I could prepare the multi-threading support by using 1 >>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >>> >>> However it seems a complex task to enable parallelization in the javafx >>> pipeline but I could help there also... >>> >> >> Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the >> limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the >> default OpenPisces path to be unaltered. > > Also, such a parallelization of the javafx pipelines would be a fairly large task. > > I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? > > ...jim From felix.bembrick at gmail.com Thu Nov 10 00:02:23 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 10 Nov 2016 11:02:23 +1100 Subject: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> Message-ID: If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me. If, of course, this email gets moderated... > On 10 Nov. 2016, at 10:57, Felix Bembrick wrote: > > > >> On 10 Nov. 2016, at 10:27, Jim Graham wrote: >> >> On 10/20/16 5:34 AM, Kevin Rushforth wrote: >>>> For now the OpenPiscesRasterizer class uses a static Renderer (single >>>> instance) so it is single-threaded. >>>> >>>> In MarlinFX I could prepare the multi-threading support by using 1 >>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >>>> >>>> However it seems a complex task to enable parallelization in the javafx >>>> pipeline but I could help there also... >>>> >>> >>> Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the >>> limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the >>> default OpenPisces path to be unaltered. >> >> Also, such a parallelization of the javafx pipelines would be a fairly large task. >> >> I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? >> >> ...jim From chien.yang at oracle.com Thu Nov 10 01:35:47 2016 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 09 Nov 2016 17:35:47 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background Message-ID: <5823CEF3.5040405@oracle.com> Hi Jim and Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ Thanks, - Chien From tom.schindl at bestsolution.at Thu Nov 10 05:35:50 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 10 Nov 2016 06:35:50 +0100 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: <5823CEF3.5040405@oracle.com> References: <5823CEF3.5040405@oracle.com> Message-ID: <671CC3D7-9BC0-422E-8473-C94C02B1CD1D@bestsolution.at> Hi, Might be dumb questions but Did you try that this doesn't interfere with stages who have been created with StageStyle.TRANSPARENT? What happens if i set the Scene.fill to an rgba value? Doesn't this lead to a different color than what you get today where the background stage background is always white? Tom Von meinem iPhone gesendet > Am 10.11.2016 um 02:35 schrieb Chien Yang : > > Hi Jim and Kevin, > > Please review the proposed fix: > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 > Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ > > Thanks, > - Chien From bley at jpro.io Thu Nov 10 07:35:09 2016 From: bley at jpro.io (Tobias Bley) Date: Thu, 10 Nov 2016 08:35:09 +0100 Subject: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> Message-ID: Do you have started any parallelization? > Am 10.11.2016 um 01:02 schrieb Felix Bembrick : > > If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me. > > If, of course, this email gets moderated... > >> On 10 Nov. 2016, at 10:57, Felix Bembrick wrote: >> >> >> >>> On 10 Nov. 2016, at 10:27, Jim Graham wrote: >>> >>> On 10/20/16 5:34 AM, Kevin Rushforth wrote: >>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single >>>>> instance) so it is single-threaded. >>>>> >>>>> In MarlinFX I could prepare the multi-threading support by using 1 >>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >>>>> >>>>> However it seems a complex task to enable parallelization in the javafx >>>>> pipeline but I could help there also... >>>>> >>>> >>>> Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the >>>> limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the >>>> default OpenPisces path to be unaltered. >>> >>> Also, such a parallelization of the javafx pipelines would be a fairly large task. >>> >>> I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? >>> >>> ...jim From daniel.gloeckner at 360t.com Thu Nov 10 08:28:33 2016 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Thu, 10 Nov 2016 08:28:33 +0000 Subject: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds In-Reply-To: References: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385540@EOFFICE-EX01.360t.com> Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385AF8@EOFFICE-EX01.360t.com> Hi Stefan, >From code review it seems that this is not the case. I'll ask my team mate to check this programmatically just to make sure... Note that JDK-8163078 contains a code example which reproduces the exception but adds and removes listeners on the JavaFX thread. Kind regards, Daniel > -----Original Message----- > From: Stefan Fuchs [mailto:snfuchs at gmx.de] > Sent: Wednesday, November 09, 2016 7:59 PM > To: Daniel Gl?ckner; openjfx-dev at openjdk.java.net > Subject: Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in > Parent.updateCachedBounds > > Hi Daniel, > > are you registering or removing the listeners on a thread other than the > JavaFX Application Thread? > I think the Observables are not thread save. > > > -- regards > Stefan > > > Hi guys, > > > > We're facing an exception triggered from Parent.updateCachedBounds. I've > pasted the stack trace below. > > > > This looks very similar to https://bugs.openjdk.java.net/browse/JDK- > 8163078. > > > > We have a few listeners to layoutBounds property, similar to the reporter of > that issue. This seems to trigger the issue. > > > > For us it's hard to reproduce this issue in our application. If the bug shows > up the result is quite disastrous though. The application freezes in this case. > > > > Has anyone observed this bug or is aware of a workaround? P4 suggests that > it's a low priority issue with minor loss of functionality... really? > > > > Kind regards, > > Daniel > > > > ERROR [28.10.16 13:01:45.415] DefaultLogger uncaughtException() > > java.lang.ArrayIndexOutOfBoundsException: -1 > > at java.util.ArrayList.elementData(Unknown Source) > > at java.util.ArrayList.get(Unknown Source) > > at > com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrappe > r.java:89) > > at > com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.ja > va:306) > > at javafx.scene.Parent.updateCachedBounds(Parent.java:1591) > > at javafx.scene.Parent.recomputeBounds(Parent.java:1535) > > at javafx.scene.Parent.impl_computeGeomBounds(Parent.java:1388) > > at > javafx.scene.layout.Region.impl_computeGeomBounds(Region.java:3078) > > at javafx.scene.Node.updateGeomBounds(Node.java:3579) > > at javafx.scene.Node.getGeomBounds(Node.java:3532) > > at javafx.scene.Node.getLocalBounds(Node.java:3480) > > at javafx.scene.Node.updateTxBounds(Node.java:3643) > > at javafx.scene.Node.getTransformedBounds(Node.java:3426) > > at javafx.scene.Node.updateBounds(Node.java:559) > > at javafx.scene.Parent.updateBounds(Parent.java:1719) > > at javafx.scene.Parent.updateBounds(Parent.java:1717) > > at javafx.scene.Parent.updateBounds(Parent.java:1717) > > at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2404) > > at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) > > at java.security.AccessController.doPrivileged(Native Method) > > at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) > > at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(Quantum > Toolkit.java:319) > > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.jav > a:95) > > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > > at > com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:19 > 1) > > at java.lang.Thread.run(Unknown Source) > > From cnewland at chrisnewland.com Thu Nov 10 08:38:04 2016 From: cnewland at chrisnewland.com (Chris Newland) Date: Thu, 10 Nov 2016 08:38:04 -0000 Subject: New JavaFX performance benchmark (DemoFX part III) Message-ID: <7eaf52661c521d9b35ea4055cab1ca15.squirrel@excalibur.xssl.net> Hi all, Hope not too off-topic but I've just released the 3rd version of my JavaFX performance benchmark "DemoFX". This time it exercises the PixelWriter (of Canvas and WriteableImage), the spectral analyser (thanks for adding this!), and some 3D as well as drawing on the Canvas. It does use MediaPlayer.impl_getLatestFrame() to grab raw frames for the chroma-key / green-screen effects so won't be compatible with JDK9 (I did file RFE JI-9038459 for this but realise it's low priority). The code is fairly unoptimised (but still runs 60fps on my 2011 iMac) but I'm going to spend a bit of time looking at what the JIT gets up to and come back with any suggestions. Code is here: https://github.com/chriswhocodes/DemoFX and a video here https://www.youtube.com/watch?v=9jztG_l8qrk Hopefully a useful showcase for JavaFX realtime graphics. Cheers, Chris @chriswhocodes on Twitter From bley at jpro.io Thu Nov 10 10:56:42 2016 From: bley at jpro.io (Tobias Bley) Date: Thu, 10 Nov 2016 11:56:42 +0100 Subject: Marlin-Renderer and JavaFX In-Reply-To: <935B6CA2-27D4-4F10-B7C0-26C64B38ECDF@gmail.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> <935B6CA2-27D4-4F10-B7C0-26C64B38ECDF@gmail.com> Message-ID: <55750905-8DE6-4F27-BD61-9E3C5621AECE@jpro.io> What about performance benchmark? Did you already tried to benchmark your prototype with DemoFX from Chris Newsland? https://github.com/chriswhocodes/DemoFX > Am 10.11.2016 um 08:40 schrieb Felix Bembrick : > > Started? I have a fully working prototype! > > And it's not just "parallelised" but it greatly improves the efficiency and utilisation of both the CPU (and cores) and the GPU(s). > >> On 10 Nov. 2016, at 18:35, Tobias Bley wrote: >> >> Do you have started any parallelization? >> >> >> >>> Am 10.11.2016 um 01:02 schrieb Felix Bembrick : >>> >>> If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me. >>> >>> If, of course, this email gets moderated... >>> >>>> On 10 Nov. 2016, at 10:57, Felix Bembrick wrote: >>>> >>>> >>>> >>>>> On 10 Nov. 2016, at 10:27, Jim Graham wrote: >>>>> >>>>> On 10/20/16 5:34 AM, Kevin Rushforth wrote: >>>>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single >>>>>>> instance) so it is single-threaded. >>>>>>> >>>>>>> In MarlinFX I could prepare the multi-threading support by using 1 >>>>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >>>>>>> >>>>>>> However it seems a complex task to enable parallelization in the javafx >>>>>>> pipeline but I could help there also... >>>>>>> >>>>>> >>>>>> Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the >>>>>> limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the >>>>>> default OpenPisces path to be unaltered. >>>>> >>>>> Also, such a parallelization of the javafx pipelines would be a fairly large task. >>>>> >>>>> I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? >>>>> >>>>> ...jim >> From bourges.laurent at gmail.com Thu Nov 10 11:15:50 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Nov 2016 12:15:50 +0100 Subject: Marlin-Renderer and JavaFX In-Reply-To: <55750905-8DE6-4F27-BD61-9E3C5621AECE@jpro.io> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> <935B6CA2-27D4-4F10-B7C0-26C64B38ECDF@gmail.com> <55750905-8DE6-4F27-BD61-9E3C5621AECE@jpro.io> Message-ID: Hi, First results with DemoFX (run.sh -e sierpinski) to compare a simple path scene with HW pipeline (es2): - native pisces: 138 fps - open pisces: 150 fps - marlin fx: 300 fps But it is too simple to evaluate Marlin improvements: the more complex the shape is, the more performance you get Laurent From felix.bembrick at gmail.com Thu Nov 10 07:40:59 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 10 Nov 2016 18:40:59 +1100 Subject: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> Message-ID: <935B6CA2-27D4-4F10-B7C0-26C64B38ECDF@gmail.com> Started? I have a fully working prototype! And it's not just "parallelised" but it greatly improves the efficiency and utilisation of both the CPU (and cores) and the GPU(s). > On 10 Nov. 2016, at 18:35, Tobias Bley wrote: > > Do you have started any parallelization? > > > >> Am 10.11.2016 um 01:02 schrieb Felix Bembrick : >> >> If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me. >> >> If, of course, this email gets moderated... >> >>> On 10 Nov. 2016, at 10:57, Felix Bembrick wrote: >>> >>> >>> >>>> On 10 Nov. 2016, at 10:27, Jim Graham wrote: >>>> >>>> On 10/20/16 5:34 AM, Kevin Rushforth wrote: >>>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single >>>>>> instance) so it is single-threaded. >>>>>> >>>>>> In MarlinFX I could prepare the multi-threading support by using 1 >>>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >>>>>> >>>>>> However it seems a complex task to enable parallelization in the javafx >>>>>> pipeline but I could help there also... >>>>>> >>>>> >>>>> Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the >>>>> limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the >>>>> default OpenPisces path to be unaltered. >>>> >>>> Also, such a parallelization of the javafx pipelines would be a fairly large task. >>>> >>>> I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? >>>> >>>> ...jim > From felix.bembrick at gmail.com Thu Nov 10 11:30:39 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 10 Nov 2016 22:30:39 +1100 Subject: Marlin-Renderer and JavaFX In-Reply-To: <55750905-8DE6-4F27-BD61-9E3C5621AECE@jpro.io> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> <935B6CA2-27D4-4F10-B7C0-26C64B38ECDF@gmail.com> <55750905-8DE6-4F27-BD61-9E3C5621AECE@jpro.io> Message-ID: If Oracle are interested in it (and permit me to be part of the JavaFX community on a level playing field), I would be more than happy to! (Such as not having to wait for every post to be moderated for example). > On 10 Nov. 2016, at 21:56, Tobias Bley wrote: > > What about performance benchmark? Did you already tried to benchmark your prototype with DemoFX from Chris Newsland? > > https://github.com/chriswhocodes/DemoFX > > > > > > >> Am 10.11.2016 um 08:40 schrieb Felix Bembrick : >> >> Started? I have a fully working prototype! >> >> And it's not just "parallelised" but it greatly improves the efficiency and utilisation of both the CPU (and cores) and the GPU(s). >> >>> On 10 Nov. 2016, at 18:35, Tobias Bley wrote: >>> >>> Do you have started any parallelization? >>> >>> >>> >>>> Am 10.11.2016 um 01:02 schrieb Felix Bembrick : >>>> >>>> If you want to know how to parallelise the JavaFX pipeline (or how it's already been done with amazing results) then talk to me. >>>> >>>> If, of course, this email gets moderated... >>>> >>>>> On 10 Nov. 2016, at 10:57, Felix Bembrick wrote: >>>>> >>>>> >>>>> >>>>>> On 10 Nov. 2016, at 10:27, Jim Graham wrote: >>>>>> >>>>>> On 10/20/16 5:34 AM, Kevin Rushforth wrote: >>>>>>>> For now the OpenPiscesRasterizer class uses a static Renderer (single >>>>>>>> instance) so it is single-threaded. >>>>>>>> >>>>>>>> In MarlinFX I could prepare the multi-threading support by using 1 >>>>>>>> RendererContext per thread (ThreadLocal) as I did in Marlin for java2d. >>>>>>>> >>>>>>>> However it seems a complex task to enable parallelization in the javafx >>>>>>>> pipeline but I could help there also... >>>>>>>> >>>>>>> >>>>>>> Enabling parallel rasterization seems like a good follow-on task, but is out of scope for the short term given the >>>>>>> limited amount of time. Also, the only way that MarlinFX even has a chance of getting approved for in JDK 9 is for the >>>>>>> default OpenPisces path to be unaltered. >>>>>> >>>>>> Also, such a parallelization of the javafx pipelines would be a fairly large task. >>>>>> >>>>>> I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the crossings and N threads to populate the alphas...? >>>>>> >>>>>> ...jim >>> > From kevin.rushforth at oracle.com Thu Nov 10 12:58:08 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Nov 2016 04:58:08 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: <671CC3D7-9BC0-422E-8473-C94C02B1CD1D@bestsolution.at> References: <5823CEF3.5040405@oracle.com> <671CC3D7-9BC0-422E-8473-C94C02B1CD1D@bestsolution.at> Message-ID: <58246EE0.6030706@oracle.com> Hi Tom, This is a good question, and will needs to be checked. If it is a problem, then one possibility would be to modify the fix to skip the call to setBackground if StageStyle == TRANSPARENT. -- Kevin Tom Schindl wrote: > Hi, > > Might be dumb questions but > > Did you try that this doesn't interfere with stages who have been created with StageStyle.TRANSPARENT? > > What happens if i set the Scene.fill to an rgba value? Doesn't this lead to a different color than what you get today where the background stage background is always white? > > Tom > > Von meinem iPhone gesendet > > >> Am 10.11.2016 um 02:35 schrieb Chien Yang : >> >> Hi Jim and Kevin, >> >> Please review the proposed fix: >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 >> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ >> >> Thanks, >> - Chien >> > > From bourges.laurent at gmail.com Thu Nov 10 13:04:47 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Nov 2016 14:04:47 +0100 Subject: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> <935B6CA2-27D4-4F10-B7C0-26C64B38ECDF@gmail.com> <55750905-8DE6-4F27-BD61-9E3C5621AECE@jpro.io> Message-ID: Felix & Tobias, Could you please start another thread to discuss the parallelization (multi-threading) in JavaFX Graphics ? I am a bit lost as there is 13 messages since 12 hours on several topics (marlin, MT ...) so I would like closing this topic soon by answering MarlinFX questions and participate to other threads. Thanks a lot, Laurent From bourges.laurent at gmail.com Thu Nov 10 13:13:20 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Nov 2016 14:13:20 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> Message-ID: Jim, > > I would think an effort to parallelize a single shape rasterization would > be much simpler in scope. Still outside the current JDK 9 timeline, but > definitely something that could help in future releases. I believe that > once we put the edges into the internal structures we could parallelize the > rasterization of individual scanlines and maybe break a tall shape up into > N horizontal bands for N threads. Other thoughts would be a thread to > generate the crossings and N threads to populate the alphas...? > Multithreaded rendering is a complex task that should be discussed in another thread as it is totally out of my current scope. My 2 cents: there is two approach: - render shapes in parallel (but it requires the JavaFX pipeline to be parallelized = tricky as caching mask, gpu need single thread communication ...) - render shape with several threads (as you proposed) but the scanline algorithm requires the previous scanline information like previous edges (so it becomes tricky to make it efficient) and this will only speed up large shapes (point clouds will remain slow !) Anyway the major issue concerns latency ie how to spread the workload on several threads when the scene contains shapes with various sizes or complexity (edge count): the latency corresponds to the slowest thread to complete its rendering task. => adaptive algorithm to make a sort of load balancing (work stealing approach) or small tasks (average same cpu cost). PS: I have some experience on parallelization, but please let's postpone this discussion or let's do it in another thread. Laurent From bourges.laurent at gmail.com Thu Nov 10 13:29:16 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Nov 2016 14:29:16 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <0759bda9-7f3f-fecb-cb84-b64b575dcec6@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <0759bda9-7f3f-fecb-cb84-b64b575dcec6@oracle.com> Message-ID: Jim, 2016-11-10 0:39 GMT+01:00 Jim Graham : > Going forward perhaps we should refer to the version of Marlin in Java2D > as Marlin2D? > > Then Marlin is your original plug-in version that is still being worked on. > Marlin2D is what you integrated into OpenJDK/Java2D. > MarlinFX is what you are planning for FX. > I agree your naming convention. > > That's just for conversational purposes, I'm not proposing that we > formalize those into formal project names, but this will keep discussions > smaller? > > On 11/2/16 2:54 PM, Laurent Bourg?s wrote: > >> PS: MarlinFX is based on my (internal) Marlin-renderer 0.7.5 (a bit >> different than OpenJDK9's Marlin as it is compatible with jdk 1.8) so I >> will synchronize both branches to provide soon MarlinFX9 patches closer to >> OpenJDK9's Marlin renderer if we are going to work on its integration. >> > > If I read this correctly, you have outstanding changes you've made to > Marlin that you plan to propose for Marlin2D, but they haven't been > proposed yet? > Exactly but I told you several times (in this thread): - I started optimizing tile filling in Marlin 0.7.5 (asymetric tiles W != H) and it is 10% faster for almost empty (0x00) / full tiles (0xFF) but also it speeds up larger tiles (128 x 32 ...) than usual (32 x 32) - I switched to Marlin-FX and found out that OpenPisces (Dasher / Stroker / Renderer cubic decimation thresholds) were changed compared to Pisces2D so I ported all these changes to Marlin-FX (first) - Very minor fixes in Renderer loop: block flag bug + fast exit loop on the right side - Increased array size for edge / crossings / polystack (as in 0.7.3) If you prefer, I can first upgrade Marlin2D then propose a new webrev for MarlinFX for its integration. Anyway Marlin changes are very small compared to Marlin2D or MarlinFX and are located in principal classes. > > And you based MarlinFX on the newer version of Marlin with those > outstanding changes? > Yes but MarlinFX do not have MarlinCache nor MarlinTileGenerator where are located changes for optimizing tile filling. To sum up, MarlinFX has small changes from Marlin to make it compliant with OpenPisces. > > Is your plan to propose a patch for Marlin2D soon? > Yes to make Marlin2D up-to-date and behave like OpenPisces / MarlinFX. > > For now I'd like to keep the 2 versions of Marlin in the JDK in sync other > than differences required for Java2D's rendering pipelines vs. the FX > ones. That will simplify at least the intial proposal to integrate this if > we can say it is "99% the same as the one in Java2D other than differences > required by the pipelines" which should quiet any fears that might get in > the way. > > Did I read that correctly? Does that sound reasonable? > MarlinFX is now ready and up-to-date to behave like OpenPisces. Finally I submitted yesterday a new webrev on JBS and expected it would have started a new review thread (as this one is too long !) Please have a look to my comment: https://bugs.openjdk.java.net/browse/JDK-8169270 " Please review the marlin-FX webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/ Reviewers: flar This webrev consist in Prism classes (ShapeUtil, SWContext) using the new Marlin renderer ported to JavaFX. The PrismSettings class has been modified to have the new prism.marlinrasterizer flag (disabled by default). Marlin-FX is slightly different than Marlin OpenJDK9 to: - use javafx classes instead of java2d classes - fix Dasher / Stroker as done in OpenPisces - support both AA and nonAA Renderer (see MarlinRenderer interface) - fix Renderer cubic decimation thresholds to match OpenPisces nonAA quality - the new MarlinAlphaConsumer supports optimized alpha copies (only valuable ranges) and the block flag optimized fills for the MarlinRasterizer only (not SWContext) Note: The SWContext.DirectRTPiscesMarlinAlphaConsumer relies on PiscesRenderer.emitAndClearAlphaRow() that is not optimal with the Marlin approach as it expects a complete row [x0, x1] although Marlin gives the span [xmin, xmax] where coverage != 0. The prism-native-sw (c code) could be improved to accept an extra offset to skip useless pixels [x0, xmin] and improve the blending performance. Will upgrade later OpenJDK9's Marlin renderer or if you prefer, I can do it first. " Best regards, Laurent From bourges.laurent at gmail.com Thu Nov 10 13:35:49 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Nov 2016 14:35:49 +0100 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: <654d24fc-0b40-1be6-e5f2-28773a373f8f@oracle.com> References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <9006b271-6c62-8e35-0a6d-c598f34f0f64@oracle.com> <6aa1946b-69b5-a0d9-9c41-c80cad1ee1a6@oracle.com> <654d24fc-0b40-1be6-e5f2-28773a373f8f@oracle.com> Message-ID: Jim, 2016-11-10 0:47 GMT+01:00 Jim Graham : > Hi Laurent, > > Great job on creating a very obvious minimal impact! That should help > streamline it through the approval process. > Thanks. > > Is MarlinProperties.isEnabled still used? (Searching patch file - no, I > don't think so) > Will fix and also remove all tile related properties. > > Kevin and I had a long back and forth over the packaging of the Reentrant > files and came up with "com.sun.util.reentrant" as we'd like to avoid > "com.sun" as a terminal package. We should eventually move a few other > common utilities into that new tree as well, but we can start with these > classes. > Agreed. > > I still want to take a pass through the changes to the Marlin files > themselves, but above is my review of the glue code and with that Kevin can > pursue the internal processes. > > Before I pursue too far on reading the Marlin source changes, I'd like to > hear back about how this version of Marlin(FX) differs from the OpenJDK > version of Marlin(2D) - were they based on different versions of your > Marlin project? Also, you mentioned waiting for the jigsaw build patch > integration. I'm guessing you meant the build changes that happened > yesterday, so we can proceed now? > About jigsaw integration: I made the latest patch (JBS) after testing a complete OpenJDK9+OpenJFX9 build and running DemoFX + Ensemble8. Yes, let's discuss the webrev on a dedicated thread: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/ > > With respect to the changes to the native part of the SW pipeline that > would trim the rendering - please continue to investigate them, but we > should pursue those as a separate bug fix so as not to complicate this > particular change. It sounds like you've adapted the new code in the > SWContext wrapper class to not require that native change yet, so let's go > with that for the first phase... > Agreed, let's postpone that effort later as it is not blocking. Laurent From David.Hill at Oracle.com Thu Nov 10 15:30:33 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 10 Nov 2016 10:30:33 -0500 Subject: review: fix old jar list in build.gradle Message-ID: <58249299.8050609@Oracle.com> Kevin, would you review: https://bugs.openjdk.java.net/browse/JDK-8169552 diff is inside the bug. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From bourges.laurent at gmail.com Thu Nov 10 15:53:01 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Nov 2016 16:53:01 +0100 Subject: Review request for JDK-8169270: Leverage new Java2D Marlin rasterizer for JavaFX Message-ID: Jim & Kevin, Sorry to announce this code review in late, I thought JBS would have sent such email from the comment. Please review the marlin-FX webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8169270.0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8169270 Reviewers: flar, kcr This webrev consist in Prism classes (ShapeUtil, SWContext) using the new Marlin renderer ported to JavaFX. The PrismSettings class has been modified to have the new prism.marlinrasterizer flag (disabled by default). Marlin-FX is slightly different than Marlin OpenJDK9 to: - use javafx classes instead of java2d classes - fix Dasher / Stroker as done in OpenPisces - support both AA and nonAA Renderer (see MarlinRenderer interface) - fix Renderer cubic decimation thresholds to match OpenPisces nonAA quality - the new MarlinAlphaConsumer supports optimized alpha copies (only valuable ranges) and the block flag optimized fills for the MarlinRasterizer only (not SWContext) Note: The SWContext.DirectRTPiscesMarlinAlphaConsumer relies on PiscesRenderer.emitAndClearAlphaRow() that is not optimal with the Marlin approach as it expects a complete row [x0, x1] although Marlin gives the span [xmin, xmax] where coverage != 0. The prism-native-sw (c code) could be improved to accept an extra offset to skip useless pixels [x0, xmin] and improve the blending performance. Will upgrade later OpenJDK9's Marlin renderer or if you prefer, I can do it first. PS: As you proposed in the previous thread, I will refactor reentrant classes to com.sun.util.reentrant and remove useless properties in MarlinProperties. Regards, Laurent From david.dehaven at oracle.com Thu Nov 10 17:27:32 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 10 Nov 2016 09:27:32 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method Message-ID: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> Please review the JavaFX changes needed for this issue: https://bugs.openjdk.java.net/browse/JDK-8169289 webrev: http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0 For reference, the OpenJDK changes needed are here: http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ These are being reviewed separately on core-libs-dev at openjdk.java.net I've tested the following cases so far: LM_CLASS_1 : -cp some.jar main.class LM_CLASS_2 : -cp path/to/loose/classes main.class LM_JAR_1 : -jar some.jar (Main-Class) LM_JAR_2 : -jar some.jar (Main-Class + JavaFX-Application-Class) <- JAC should take precedence LM_MODULE_1 : -m module/main.class LM_MODULE_2 : -m module (main class declared in module-info) and one more in progress: LM_JAR_3 : -jar some.jar (Main-Class + JavaFX-Class-Path) <- creates new ClassLoader I've tested all combinations of having changes (or not) to openjfx and openjdk and there are no unexpected results, the only cases that fail are the LM_MODULE launch modes which fail currently. This means the changes can be pushed in any order. I will create unit tests for this, but don't want to push it since this change is split between OpenJFX and OpenJDK (else LM_MODULE modes will just fail until everything is in sync). I'll file a separate issue to push the unit tests at the appropriate time. A couple other notes: - I brought over changes for handling diacritical marks on MacOS X [1], moved class loading to a new method - I assumed not having a default preloader for the -jar case was a bug, so I fixed it -DrD- [1] https://bugs.openjdk.java.net/browse/JDK-8017248 From felix.bembrick at gmail.com Thu Nov 10 18:11:21 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 11 Nov 2016 05:11:21 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline Message-ID: (Thanks to Kevin for lifting my "awaiting moderation" impasse). So, with all the recent discussions regarding the great contribution by Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be started to discuss parallelisation of the JavaFX rendering pipeline in general. As has been correctly pointed-out, converting or modifying the existing rendering pipeline into a fully multi-threaded and performant beast is indeed quite a complex task. But, that's exactly what myself and my colleagues have been working on for about 2 years. The result is what we call the Hyper Rendering Pipeline (HPR). Work on HPR started when we developed FXMark and were (bitterly) disappointed with the performance of the JavaFX scene graph. Many JavaFX developers have blogged about the need to dramatically minimise the number of nodes (especially on embedded devices) in order to achieve even "acceptable" performance. Often it is the case that most (if not all rendering) is eventually done in a single Canvas node. Now, as well already know, the JavaFX Canvas does perform very well and the recent awesome work (DemoFX) by Chris Newland, just for example, shows what can be done with this one node. But, the majority of the animation plumbing in JavaFX is related to the scene graph itself and is designed to make use of multiple nodes and node types. At the moment, the performance of this scene graph is the Achilles Heel of JavaFX (or at least one of them). Enter HPR. I personally have worked with a number of hardware-accelerated toolkits over the years and am astounded by just how sluggish the rendering pipeline for JavaFX is. When I am animating just a couple of hundred nodes using JavaFX and transitions, I am lucky to get more than about 30 FPS, but on the same (very powerful) machine, I can use other toolkits to render thousands of "objects" and achieve frame rates well over 1000 FPS. So, we refactored the entire scene graph rendering pipeline with the following goals and principles: 1. It is written using JavaFX 9 and Java 9 (but could theoretically be back-ported to JavaFX 8 though I see no reason to). 2. We analysed how other toolkits had optimised their own rendering pipelines (especially Qt which has made some significant advances in this area in recent years). We also analysed recent examples of multi-threaded rendering using the new Vulkan API. 3. We carefully analysed and determined which parts of the pipeline should best utilise the CPU and which parts should best utilise the GPU. 4. For those parts most suited to the CPU, we use the advanced concurrency features of Java 8/9 to maximise parallelisation and throughput by utilising multiple cores & threads in as an efficient manner as possible. 5. We devoted a large amount of time to optimising the "communication" between the CPU and GPU to be far less "chatty" and this alone led to some huge performance gains. 6. We also looked at the structure of the scene graph itself and after studying products such as OpenSceneGraph, we refactored the JavaFX scene graph in such a way that it lends itself to optimised rendering much more easily. 7. This is clearly not a "small" patch. In fact to refer to it as a "patch" is probably rather inappropriate. The end result is that we now have a fully-functional prototype of HPR and, already, we are seeing very significant performance improvements. At the minimum, scene graph rendering performance has improved by 500% and, with judicious and sometimes "tricky" use of caching, we have seen improvements in performance of 10x or more. And... we are only just *starting* with the performance optimisation phase. The potential for HPR is massive as it opens-up the possibility for the JavaFX scene graph and the animation/transition infrastructure to be used for a whole new class of applications including games, advanced visualisations etc., without having to rely on imperative programming of a single Canvas node. I believe that HPR, along with tremendous recent developments like JPro and the outstanding work by Gluon on mobiles and embedded devices, could position JavaFX to be the best graphics toolkit of any kind in any language and, be the ONLY *truly* cross-platform graphics technology available. WORA for graphics and UIs is finally within reach! Blessings, Felix From james.graham at oracle.com Thu Nov 10 18:22:40 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Nov 2016 10:22:40 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: <5823CEF3.5040405@oracle.com> References: <5823CEF3.5040405@oracle.com> Message-ID: I guess we'll punt on ImagePattern? Other than that the fix looks fine... ...jim On 11/9/16 5:35 PM, Chien Yang wrote: > Hi Jim and Kevin, > > Please review the proposed fix: > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 > Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ > > Thanks, > - Chien From james.graham at oracle.com Thu Nov 10 18:35:05 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Nov 2016 10:35:05 -0800 Subject: Fwd: Re: Marlin-Renderer and JavaFX In-Reply-To: References: <5807683A.8020400@oracle.com> <004601d22a1b$b88d3070$29a79150$@eu> <5808B9D2.30909@oracle.com> <86797bb6-5d55-fd31-66de-d7823e8b0d8c@oracle.com> Message-ID: <8481af24-3d14-33f1-0aa1-27b86642ab6c@oracle.com> Another thought on multi-threaded scan-line rasterization would be to pre-scan the node tree and pre-rasterize all shapes into masks before we run through and render them to the destination. Again, that would be outside the scope of 9, but it would be a change only to the rendering process (and dealing with the caching of alpha masks) that would leverage your ability to create multiple Marlin contexts without any changes to MarlinFX... ...jim On 11/10/16 5:13 AM, Laurent Bourg?s wrote: > Jim, > > > I would think an effort to parallelize a single shape rasterization would be much simpler in scope. Still outside > the current JDK 9 timeline, but definitely something that could help in future releases. I believe that once we put > the edges into the internal structures we could parallelize the rasterization of individual scanlines and maybe > break a tall shape up into N horizontal bands for N threads. Other thoughts would be a thread to generate the > crossings and N threads to populate the alphas...? > > > Multithreaded rendering is a complex task that should be discussed in another thread as it is totally out of my current > scope. > > My 2 cents: there is two approach: > - render shapes in parallel (but it requires the JavaFX pipeline to be parallelized = tricky as caching mask, gpu need > single thread communication ...) > - render shape with several threads (as you proposed) but the scanline algorithm requires the previous scanline > information like previous edges (so it becomes tricky to make it efficient) and this will only speed up large shapes > (point clouds will remain slow !) > > Anyway the major issue concerns latency ie how to spread the workload on several threads when the scene contains shapes > with various sizes or complexity (edge count): the latency corresponds to the slowest thread to complete its rendering task. > => adaptive algorithm to make a sort of load balancing (work stealing approach) or small tasks (average same cpu cost). > > PS: I have some experience on parallelization, but please let's postpone this discussion or let's do it in another thread. > > Laurent From snfuchs at gmx.de Thu Nov 10 19:17:32 2016 From: snfuchs at gmx.de (Stefan Fuchs) Date: Thu, 10 Nov 2016 20:17:32 +0100 Subject: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds In-Reply-To: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385AF8@EOFFICE-EX01.360t.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE98FF385540@EOFFICE-EX01.360t.com> <6D5AA6A29F1039459FDD3C00A9F5DE98FF385AF8@EOFFICE-EX01.360t.com> Message-ID: <34b1366b-0c0f-2fab-beb7-90741547716b@gmx.de> Hi Daniel, I mentioned it, because we got similar exceptions in our application, which stalled our application completely We moved the add of the listeners around. Luckily we could move most of the code,which added or removed listeners, to the application startup code. So the problem went away. As of JDK-8163078 I wonder, if the code below is correct, given that https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#layoutBoundsProperty says: ... "Because the computation of layoutBounds is often tied to a node's geometric variables, it is an error to bind any such variables to an expression that depends upon |layoutBounds|. For example, the x or y variables of a shape should never be bound to layoutBounds for the purpose of positioning the node. " DoubleBinding innerWidth = javafx.beans.binding.Bindings.createDoubleBinding( () -> g.layoutBoundsProperty().get().getWidth(), g.layoutBoundsProperty()); l.endXProperty().bind(innerWidth); -- Stefan > Hi Stefan, > > >From code review it seems that this is not the case. I'll ask my team mate to check this programmatically just to make sure... > > Note that JDK-8163078 contains a code example which reproduces the exception but adds and removes listeners on the JavaFX thread. > > Kind regards, > Daniel > >> -----Original Message----- >> From: Stefan Fuchs [mailto:snfuchs at gmx.de] >> Sent: Wednesday, November 09, 2016 7:59 PM >> To: Daniel Gl?ckner; openjfx-dev at openjdk.java.net >> Subject: Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in >> Parent.updateCachedBounds >> >> Hi Daniel, >> >> are you registering or removing the listeners on a thread other than the >> JavaFX Application Thread? >> I think the Observables are not thread save. >> >> >> -- regards >> Stefan >> >>> Hi guys, >>> >>> We're facing an exception triggered from Parent.updateCachedBounds. I've >> pasted the stack trace below. >>> This looks very similar to https://bugs.openjdk.java.net/browse/JDK- >> 8163078. >>> We have a few listeners to layoutBounds property, similar to the reporter of >> that issue. This seems to trigger the issue. >>> For us it's hard to reproduce this issue in our application. If the bug shows >> up the result is quite disastrous though. The application freezes in this case. >>> Has anyone observed this bug or is aware of a workaround? P4 suggests that >> it's a low priority issue with minor loss of functionality... really? >>> Kind regards, >>> Daniel >>> >>> ERROR [28.10.16 13:01:45.415] DefaultLogger uncaughtException() >>> java.lang.ArrayIndexOutOfBoundsException: -1 >>> at java.util.ArrayList.elementData(Unknown Source) >>> at java.util.ArrayList.get(Unknown Source) >>> at >> com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrappe >> r.java:89) >>> at >> com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.ja >> va:306) >>> at javafx.scene.Parent.updateCachedBounds(Parent.java:1591) >>> at javafx.scene.Parent.recomputeBounds(Parent.java:1535) >>> at javafx.scene.Parent.impl_computeGeomBounds(Parent.java:1388) >>> at >> javafx.scene.layout.Region.impl_computeGeomBounds(Region.java:3078) >>> at javafx.scene.Node.updateGeomBounds(Node.java:3579) >>> at javafx.scene.Node.getGeomBounds(Node.java:3532) >>> at javafx.scene.Node.getLocalBounds(Node.java:3480) >>> at javafx.scene.Node.updateTxBounds(Node.java:3643) >>> at javafx.scene.Node.getTransformedBounds(Node.java:3426) >>> at javafx.scene.Node.updateBounds(Node.java:559) >>> at javafx.scene.Parent.updateBounds(Parent.java:1719) >>> at javafx.scene.Parent.updateBounds(Parent.java:1717) >>> at javafx.scene.Parent.updateBounds(Parent.java:1717) >>> at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2404) >>> at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) >>> at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) >>> at >> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) >>> at >> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) >>> at >> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(Quantum >> Toolkit.java:319) >>> at >> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.jav >> a:95) >>> at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) >>> at >> com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:19 >> 1) >>> at java.lang.Thread.run(Unknown Source) >>> > From victor.drozdov at oracle.com Thu Nov 10 20:38:50 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Thu, 10 Nov 2016 23:38:50 +0300 Subject: [9] Review request: JDK-8162923 Error: Unknown Argument thrown by javpackager when argument values are passed with multiple words with in quotation Message-ID: Chris, Please review the changes about argument quotation for javapackager. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162923 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8162923/webrev.00/ --Victor From victor.drozdov at oracle.com Thu Nov 10 20:21:20 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Thu, 10 Nov 2016 23:21:20 +0300 Subject: [9] Review request: JDK-8165522 Remove #ifndef USE_JLI_LAUNCH from native launcher Message-ID: <49901868-853c-0d67-7434-f52e14ecf850@oracle.com> Chris, Please review the changes about removing native packager JNI code. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165522 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8165522/webrev.00/ --Victor From chien.yang at oracle.com Thu Nov 10 23:31:47 2016 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 10 Nov 2016 15:31:47 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: <58246EE0.6030706@oracle.com> References: <5823CEF3.5040405@oracle.com> <671CC3D7-9BC0-422E-8473-C94C02B1CD1D@bestsolution.at> <58246EE0.6030706@oracle.com> Message-ID: <58250363.5000608@oracle.com> I have tested with different StageStyle and Fill combinations, and all seems to work well with the proposed fix. No more white flashing if the Scene.fill is set with a color(with/without alpha). - Chien On 11/10/16, 4:58 AM, Kevin Rushforth wrote: > Hi Tom, > > This is a good question, and will needs to be checked. If it is a > problem, then one possibility would be to modify the fix to skip the > call to setBackground if StageStyle == TRANSPARENT. > > -- Kevin > > > Tom Schindl wrote: >> Hi, >> >> Might be dumb questions but >> >> Did you try that this doesn't interfere with stages who have been created with StageStyle.TRANSPARENT? >> >> What happens if i set the Scene.fill to an rgba value? Doesn't this lead to a different color than what you get today where the background stage background is always white? >> >> Tom >> >> Von meinem iPhone gesendet >> >> >>> Am 10.11.2016 um 02:35 schrieb Chien Yang: >>> >>> Hi Jim and Kevin, >>> >>> Please review the proposed fix: >>> >>> JIRA:https://bugs.openjdk.java.net/browse/JDK-8088179 >>> Webrev:http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ >>> >>> Thanks, >>> - Chien >>> >> >> From chien.yang at oracle.com Thu Nov 10 23:34:14 2016 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 10 Nov 2016 15:34:14 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: References: <5823CEF3.5040405@oracle.com> Message-ID: <582503F6.6020005@oracle.com> Yes, we decide to punt on ImagePattern as there isn't a trivial way to find a reasonable background color for it. - Chien On 11/10/16, 10:22 AM, Jim Graham wrote: > I guess we'll punt on ImagePattern? > > Other than that the fix looks fine... > > ...jim > > On 11/9/16 5:35 PM, Chien Yang wrote: >> Hi Jim and Kevin, >> >> Please review the proposed fix: >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 >> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ >> >> Thanks, >> - Chien From james.graham at oracle.com Thu Nov 10 23:35:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Nov 2016 15:35:04 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: <582503F6.6020005@oracle.com> References: <5823CEF3.5040405@oracle.com> <582503F6.6020005@oracle.com> Message-ID: <23d9d639-8b84-45ed-2a49-f09e8b1f1ee7@oracle.com> Not as trivial as the Gradient cases, true. +1 on the fix if we're happy with that limitation... ...jim On 11/10/16 3:34 PM, Chien Yang wrote: > Yes, we decide to punt on ImagePattern as there isn't a trivial way to find a reasonable background color for it. > > - Chien > > On 11/10/16, 10:22 AM, Jim Graham wrote: >> I guess we'll punt on ImagePattern? >> >> Other than that the fix looks fine... >> >> ...jim >> >> On 11/9/16 5:35 PM, Chien Yang wrote: >>> Hi Jim and Kevin, >>> >>> Please review the proposed fix: >>> >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 >>> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ >>> >>> Thanks, >>> - Chien From tobi at ultramixer.com Fri Nov 11 10:27:27 2016 From: tobi at ultramixer.com (Tobi) Date: Fri, 11 Nov 2016 11:27:27 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: Message-ID: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> Hi, thanks Felix, Laurent and Chris for sharing your stuff with the community! I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? So maybe there are other points than multithreading where we can boost the performance? 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? Best regards, Tobi > Am 10.11.2016 um 19:11 schrieb Felix Bembrick : > > (Thanks to Kevin for lifting my "awaiting moderation" impasse). > > So, with all the recent discussions regarding the great contribution by > Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be > started to discuss parallelisation of the JavaFX rendering pipeline in > general. > > As has been correctly pointed-out, converting or modifying the existing > rendering pipeline into a fully multi-threaded and performant beast is > indeed quite a complex task. > > But, that's exactly what myself and my colleagues have been working on for > about 2 years. > > The result is what we call the Hyper Rendering Pipeline (HPR). > > Work on HPR started when we developed FXMark and were (bitterly) > disappointed with the performance of the JavaFX scene graph. Many JavaFX > developers have blogged about the need to dramatically minimise the number > of nodes (especially on embedded devices) in order to achieve even > "acceptable" performance. Often it is the case that most (if not all > rendering) is eventually done in a single Canvas node. > > Now, as well already know, the JavaFX Canvas does perform very well and the > recent awesome work (DemoFX) by Chris Newland, just for example, shows what > can be done with this one node. > > But, the majority of the animation plumbing in JavaFX is related to the > scene graph itself and is designed to make use of multiple nodes and node > types. At the moment, the performance of this scene graph is the Achilles > Heel of JavaFX (or at least one of them). > > Enter HPR. > > I personally have worked with a number of hardware-accelerated toolkits > over the years and am astounded by just how sluggish the rendering pipeline > for JavaFX is. When I am animating just a couple of hundred nodes using > JavaFX and transitions, I am lucky to get more than about 30 FPS, but on > the same (very powerful) machine, I can use other toolkits to render > thousands of "objects" and achieve frame rates well over 1000 FPS. > > So, we refactored the entire scene graph rendering pipeline with the > following goals and principles: > > 1. It is written using JavaFX 9 and Java 9 (but could theoretically be > back-ported to JavaFX 8 though I see no reason to). > > 2. We analysed how other toolkits had optimised their own rendering > pipelines (especially Qt which has made some significant advances in this > area in recent years). We also analysed recent examples of multi-threaded > rendering using the new Vulkan API. > > 3. We carefully analysed and determined which parts of the pipeline should > best utilise the CPU and which parts should best utilise the GPU. > > 4. For those parts most suited to the CPU, we use the advanced concurrency > features of Java 8/9 to maximise parallelisation and throughput by > utilising multiple cores & threads in as an efficient manner as possible. > > 5. We devoted a large amount of time to optimising the "communication" > between the CPU and GPU to be far less "chatty" and this alone led to some > huge performance gains. > > 6. We also looked at the structure of the scene graph itself and after > studying products such as OpenSceneGraph, we refactored the JavaFX scene > graph in such a way that it lends itself to optimised rendering much more > easily. > > 7. This is clearly not a "small" patch. In fact to refer to it as a > "patch" is probably rather inappropriate. > > The end result is that we now have a fully-functional prototype of HPR and, > already, we are seeing very significant performance improvements. > > At the minimum, scene graph rendering performance has improved by 500% and, > with judicious and sometimes "tricky" use of caching, we have seen > improvements in performance of 10x or more. > > And... we are only just *starting* with the performance optimisation phase. > > The potential for HPR is massive as it opens-up the possibility for the > JavaFX scene graph and the animation/transition infrastructure to be used > for a whole new class of applications including games, advanced > visualisations etc., without having to rely on imperative programming of a > single Canvas node. > > I believe that HPR, along with tremendous recent developments like JPro and > the outstanding work by Gluon on mobiles and embedded devices, could > position JavaFX to be the best graphics toolkit of any kind in any language > and, be the ONLY *truly* cross-platform graphics technology available. > > WORA for graphics and UIs is finally within reach! > > Blessings, > > Felix From bourges.laurent at gmail.com Fri Nov 11 10:55:54 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 11 Nov 2016 11:55:54 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> Message-ID: Hi, To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. This approach is generic and could be applied in other critical places of the rendering pipelines. FYI here are my fosdem 2016 slides on the Marlin renderer: https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. However I would like getting sort of sponsoring for my potential contributions... Cheers, Laurent Le 11 nov. 2016 11:29, "Tobi" a ?crit : > > Hi, > > thanks Felix, Laurent and Chris for sharing your stuff with the community! > > I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. > > Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? > > So maybe there are other points than multithreading where we can boost the performance? > > 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? > > > Best regards, > Tobi > > > > Am 10.11.2016 um 19:11 schrieb Felix Bembrick : > > > > (Thanks to Kevin for lifting my "awaiting moderation" impasse). > > > > So, with all the recent discussions regarding the great contribution by > > Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be > > started to discuss parallelisation of the JavaFX rendering pipeline in > > general. > > > > As has been correctly pointed-out, converting or modifying the existing > > rendering pipeline into a fully multi-threaded and performant beast is > > indeed quite a complex task. > > > > But, that's exactly what myself and my colleagues have been working on for > > about 2 years. > > > > The result is what we call the Hyper Rendering Pipeline (HPR). > > > > Work on HPR started when we developed FXMark and were (bitterly) > > disappointed with the performance of the JavaFX scene graph. Many JavaFX > > developers have blogged about the need to dramatically minimise the number > > of nodes (especially on embedded devices) in order to achieve even > > "acceptable" performance. Often it is the case that most (if not all > > rendering) is eventually done in a single Canvas node. > > > > Now, as well already know, the JavaFX Canvas does perform very well and the > > recent awesome work (DemoFX) by Chris Newland, just for example, shows what > > can be done with this one node. > > > > But, the majority of the animation plumbing in JavaFX is related to the > > scene graph itself and is designed to make use of multiple nodes and node > > types. At the moment, the performance of this scene graph is the Achilles > > Heel of JavaFX (or at least one of them). > > > > Enter HPR. > > > > I personally have worked with a number of hardware-accelerated toolkits > > over the years and am astounded by just how sluggish the rendering pipeline > > for JavaFX is. When I am animating just a couple of hundred nodes using > > JavaFX and transitions, I am lucky to get more than about 30 FPS, but on > > the same (very powerful) machine, I can use other toolkits to render > > thousands of "objects" and achieve frame rates well over 1000 FPS. > > > > So, we refactored the entire scene graph rendering pipeline with the > > following goals and principles: > > > > 1. It is written using JavaFX 9 and Java 9 (but could theoretically be > > back-ported to JavaFX 8 though I see no reason to). > > > > 2. We analysed how other toolkits had optimised their own rendering > > pipelines (especially Qt which has made some significant advances in this > > area in recent years). We also analysed recent examples of multi-threaded > > rendering using the new Vulkan API. > > > > 3. We carefully analysed and determined which parts of the pipeline should > > best utilise the CPU and which parts should best utilise the GPU. > > > > 4. For those parts most suited to the CPU, we use the advanced concurrency > > features of Java 8/9 to maximise parallelisation and throughput by > > utilising multiple cores & threads in as an efficient manner as possible. > > > > 5. We devoted a large amount of time to optimising the "communication" > > between the CPU and GPU to be far less "chatty" and this alone led to some > > huge performance gains. > > > > 6. We also looked at the structure of the scene graph itself and after > > studying products such as OpenSceneGraph, we refactored the JavaFX scene > > graph in such a way that it lends itself to optimised rendering much more > > easily. > > > > 7. This is clearly not a "small" patch. In fact to refer to it as a > > "patch" is probably rather inappropriate. > > > > The end result is that we now have a fully-functional prototype of HPR and, > > already, we are seeing very significant performance improvements. > > > > At the minimum, scene graph rendering performance has improved by 500% and, > > with judicious and sometimes "tricky" use of caching, we have seen > > improvements in performance of 10x or more. > > > > And... we are only just *starting* with the performance optimisation phase. > > > > The potential for HPR is massive as it opens-up the possibility for the > > JavaFX scene graph and the animation/transition infrastructure to be used > > for a whole new class of applications including games, advanced > > visualisations etc., without having to rely on imperative programming of a > > single Canvas node. > > > > I believe that HPR, along with tremendous recent developments like JPro and > > the outstanding work by Gluon on mobiles and embedded devices, could > > position JavaFX to be the best graphics toolkit of any kind in any language > > and, be the ONLY *truly* cross-platform graphics technology available. > > > > WORA for graphics and UIs is finally within reach! > > > > Blessings, > > > > Felix > From felix.bembrick at gmail.com Fri Nov 11 11:01:23 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 11 Nov 2016 22:01:23 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> Message-ID: Hi Tobi, Thanks for the input. In answer to your first question, not all toolkits use as much parallelisation as HPR but are indeed more performant than JavaFX for a few reasons: 1. They are "closer to the metal". The more layers of architecture you add, there is almost an inevitable performance hit associated with them. There's an OpenGL toolkit named Visualization Library which is very low-level and the performance is outstanding (and is basically single threaded). 2. The structure of the scene graph. The more cumbersome or memory-hogging the scene graph along with the actual "scene graph model" used can seriously impair the ability to optimise the rendering pipeline. That's why it was necessary for us to restructure the JavaFX scene graph itself. 3. Significant performance improvements can be achieved (even in a single threaded pipeline) simply by batching GPU commands or using various forms of "caching" them on the GPU (as both OpenGL and Direct3D support). JavaFX is particularly poor in this area of CPU-to-GPU communication. Now, as for testing HPR with DemoFX, the answer is no. There are 2 main reasons: 1. HPR currently only works with Java/JavaFX 9 (and that is unlikely to change). 2. Given that DemoFX is mostly Canvas based (along with some 3D scene overlays), I doubt it would have much impact (although I expect the 3D parts would perform better). I hope these answers are helpful. Blessings, Felix > On 11 Nov. 2016, at 21:27, Tobi wrote: > > Hi, > > thanks Felix, Laurent and Chris for sharing your stuff with the community! > > I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. > > Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? > > So maybe there are other points than multithreading where we can boost the performance? > > 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? > > > Best regards, > Tobi > > >> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >> >> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >> >> So, with all the recent discussions regarding the great contribution by >> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >> started to discuss parallelisation of the JavaFX rendering pipeline in >> general. >> >> As has been correctly pointed-out, converting or modifying the existing >> rendering pipeline into a fully multi-threaded and performant beast is >> indeed quite a complex task. >> >> But, that's exactly what myself and my colleagues have been working on for >> about 2 years. >> >> The result is what we call the Hyper Rendering Pipeline (HPR). >> >> Work on HPR started when we developed FXMark and were (bitterly) >> disappointed with the performance of the JavaFX scene graph. Many JavaFX >> developers have blogged about the need to dramatically minimise the number >> of nodes (especially on embedded devices) in order to achieve even >> "acceptable" performance. Often it is the case that most (if not all >> rendering) is eventually done in a single Canvas node. >> >> Now, as well already know, the JavaFX Canvas does perform very well and the >> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >> can be done with this one node. >> >> But, the majority of the animation plumbing in JavaFX is related to the >> scene graph itself and is designed to make use of multiple nodes and node >> types. At the moment, the performance of this scene graph is the Achilles >> Heel of JavaFX (or at least one of them). >> >> Enter HPR. >> >> I personally have worked with a number of hardware-accelerated toolkits >> over the years and am astounded by just how sluggish the rendering pipeline >> for JavaFX is. When I am animating just a couple of hundred nodes using >> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >> the same (very powerful) machine, I can use other toolkits to render >> thousands of "objects" and achieve frame rates well over 1000 FPS. >> >> So, we refactored the entire scene graph rendering pipeline with the >> following goals and principles: >> >> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >> back-ported to JavaFX 8 though I see no reason to). >> >> 2. We analysed how other toolkits had optimised their own rendering >> pipelines (especially Qt which has made some significant advances in this >> area in recent years). We also analysed recent examples of multi-threaded >> rendering using the new Vulkan API. >> >> 3. We carefully analysed and determined which parts of the pipeline should >> best utilise the CPU and which parts should best utilise the GPU. >> >> 4. For those parts most suited to the CPU, we use the advanced concurrency >> features of Java 8/9 to maximise parallelisation and throughput by >> utilising multiple cores & threads in as an efficient manner as possible. >> >> 5. We devoted a large amount of time to optimising the "communication" >> between the CPU and GPU to be far less "chatty" and this alone led to some >> huge performance gains. >> >> 6. We also looked at the structure of the scene graph itself and after >> studying products such as OpenSceneGraph, we refactored the JavaFX scene >> graph in such a way that it lends itself to optimised rendering much more >> easily. >> >> 7. This is clearly not a "small" patch. In fact to refer to it as a >> "patch" is probably rather inappropriate. >> >> The end result is that we now have a fully-functional prototype of HPR and, >> already, we are seeing very significant performance improvements. >> >> At the minimum, scene graph rendering performance has improved by 500% and, >> with judicious and sometimes "tricky" use of caching, we have seen >> improvements in performance of 10x or more. >> >> And... we are only just *starting* with the performance optimisation phase. >> >> The potential for HPR is massive as it opens-up the possibility for the >> JavaFX scene graph and the animation/transition infrastructure to be used >> for a whole new class of applications including games, advanced >> visualisations etc., without having to rely on imperative programming of a >> single Canvas node. >> >> I believe that HPR, along with tremendous recent developments like JPro and >> the outstanding work by Gluon on mobiles and embedded devices, could >> position JavaFX to be the best graphics toolkit of any kind in any language >> and, be the ONLY *truly* cross-platform graphics technology available. >> >> WORA for graphics and UIs is finally within reach! >> >> Blessings, >> >> Felix > From felix.bembrick at gmail.com Fri Nov 11 11:08:35 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 11 Nov 2016 22:08:35 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> Message-ID: <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Thanks Laurent, That's another thing we discovered: using Java itself in the most performant way can help a lot. It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. Blessings, Felix > On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: > > Hi, > > To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. > > This approach is generic and could be applied in other critical places of the rendering pipelines. > > FYI here are my fosdem 2016 slides on the Marlin renderer: > https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf > > Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. > > However I would like getting sort of sponsoring for my potential contributions... > > Cheers, > Laurent > > Le 11 nov. 2016 11:29, "Tobi" a ?crit : > > > > Hi, > > > > thanks Felix, Laurent and Chris for sharing your stuff with the community! > > > > I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. > > > > Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? > > > > So maybe there are other points than multithreading where we can boost the performance? > > > > 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? > > > > > > Best regards, > > Tobi > > > > > > > Am 10.11.2016 um 19:11 schrieb Felix Bembrick : > > > > > > (Thanks to Kevin for lifting my "awaiting moderation" impasse). > > > > > > So, with all the recent discussions regarding the great contribution by > > > Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be > > > started to discuss parallelisation of the JavaFX rendering pipeline in > > > general. > > > > > > As has been correctly pointed-out, converting or modifying the existing > > > rendering pipeline into a fully multi-threaded and performant beast is > > > indeed quite a complex task. > > > > > > But, that's exactly what myself and my colleagues have been working on for > > > about 2 years. > > > > > > The result is what we call the Hyper Rendering Pipeline (HPR). > > > > > > Work on HPR started when we developed FXMark and were (bitterly) > > > disappointed with the performance of the JavaFX scene graph. Many JavaFX > > > developers have blogged about the need to dramatically minimise the number > > > of nodes (especially on embedded devices) in order to achieve even > > > "acceptable" performance. Often it is the case that most (if not all > > > rendering) is eventually done in a single Canvas node. > > > > > > Now, as well already know, the JavaFX Canvas does perform very well and the > > > recent awesome work (DemoFX) by Chris Newland, just for example, shows what > > > can be done with this one node. > > > > > > But, the majority of the animation plumbing in JavaFX is related to the > > > scene graph itself and is designed to make use of multiple nodes and node > > > types. At the moment, the performance of this scene graph is the Achilles > > > Heel of JavaFX (or at least one of them). > > > > > > Enter HPR. > > > > > > I personally have worked with a number of hardware-accelerated toolkits > > > over the years and am astounded by just how sluggish the rendering pipeline > > > for JavaFX is. When I am animating just a couple of hundred nodes using > > > JavaFX and transitions, I am lucky to get more than about 30 FPS, but on > > > the same (very powerful) machine, I can use other toolkits to render > > > thousands of "objects" and achieve frame rates well over 1000 FPS. > > > > > > So, we refactored the entire scene graph rendering pipeline with the > > > following goals and principles: > > > > > > 1. It is written using JavaFX 9 and Java 9 (but could theoretically be > > > back-ported to JavaFX 8 though I see no reason to). > > > > > > 2. We analysed how other toolkits had optimised their own rendering > > > pipelines (especially Qt which has made some significant advances in this > > > area in recent years). We also analysed recent examples of multi-threaded > > > rendering using the new Vulkan API. > > > > > > 3. We carefully analysed and determined which parts of the pipeline should > > > best utilise the CPU and which parts should best utilise the GPU. > > > > > > 4. For those parts most suited to the CPU, we use the advanced concurrency > > > features of Java 8/9 to maximise parallelisation and throughput by > > > utilising multiple cores & threads in as an efficient manner as possible. > > > > > > 5. We devoted a large amount of time to optimising the "communication" > > > between the CPU and GPU to be far less "chatty" and this alone led to some > > > huge performance gains. > > > > > > 6. We also looked at the structure of the scene graph itself and after > > > studying products such as OpenSceneGraph, we refactored the JavaFX scene > > > graph in such a way that it lends itself to optimised rendering much more > > > easily. > > > > > > 7. This is clearly not a "small" patch. In fact to refer to it as a > > > "patch" is probably rather inappropriate. > > > > > > The end result is that we now have a fully-functional prototype of HPR and, > > > already, we are seeing very significant performance improvements. > > > > > > At the minimum, scene graph rendering performance has improved by 500% and, > > > with judicious and sometimes "tricky" use of caching, we have seen > > > improvements in performance of 10x or more. > > > > > > And... we are only just *starting* with the performance optimisation phase. > > > > > > The potential for HPR is massive as it opens-up the possibility for the > > > JavaFX scene graph and the animation/transition infrastructure to be used > > > for a whole new class of applications including games, advanced > > > visualisations etc., without having to rely on imperative programming of a > > > single Canvas node. > > > > > > I believe that HPR, along with tremendous recent developments like JPro and > > > the outstanding work by Gluon on mobiles and embedded devices, could > > > position JavaFX to be the best graphics toolkit of any kind in any language > > > and, be the ONLY *truly* cross-platform graphics technology available. > > > > > > WORA for graphics and UIs is finally within reach! > > > > > > Blessings, > > > > > > Felix > > From alexander.zvegintsev at oracle.com Fri Nov 11 11:51:55 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 11 Nov 2016 14:51:55 +0300 Subject: [9] Review request for 8087498 [Mac] : Full screen mode fails for certain StageStyles In-Reply-To: References: Message-ID: <58ccbcff-6516-af9d-a646-b9c120b5d215@oracle.com> please see the updated webrev http://cr.openjdk.java.net/~azvegint/jdk/9/8087498/01/ Thanks, Alexander. On 8/4/16 3:40 AM, Alexander Zvegintsev wrote: > Hello, > > please review the fix > http://cr.openjdk.java.net/~azvegint/jdk/9/8087498/00 > for the issue > https://bugs.openjdk.java.net/browse/JDK-8087498 > From kevin.rushforth at oracle.com Fri Nov 11 14:16:55 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 11 Nov 2016 06:16:55 -0800 Subject: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background In-Reply-To: <23d9d639-8b84-45ed-2a49-f09e8b1f1ee7@oracle.com> References: <5823CEF3.5040405@oracle.com> <582503F6.6020005@oracle.com> <23d9d639-8b84-45ed-2a49-f09e8b1f1ee7@oracle.com> Message-ID: <5825D2D7.1000201@oracle.com> +1 from me, too. -- Kevin Jim Graham wrote: > Not as trivial as the Gradient cases, true. > > +1 on the fix if we're happy with that limitation... > > ...jim > > On 11/10/16 3:34 PM, Chien Yang wrote: >> Yes, we decide to punt on ImagePattern as there isn't a trivial way >> to find a reasonable background color for it. >> >> - Chien >> >> On 11/10/16, 10:22 AM, Jim Graham wrote: >>> I guess we'll punt on ImagePattern? >>> >>> Other than that the fix looks fine... >>> >>> ...jim >>> >>> On 11/9/16 5:35 PM, Chien Yang wrote: >>>> Hi Jim and Kevin, >>>> >>>> Please review the proposed fix: >>>> >>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179 >>>> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8088179/webrev.00/ >>>> >>>> Thanks, >>>> - Chien From victor.drozdov at oracle.com Fri Nov 11 18:55:48 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Fri, 11 Nov 2016 21:55:48 +0300 Subject: [9] Review request: JDK-8162693 javapackager returns null if com.oracle.tools.packager.windows.WinAppBundler called twice Message-ID: Chris, Please review the changes about WinAppBundler. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162693 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8162693/webrev.00/ --Victor From victor.drozdov at oracle.com Fri Nov 11 20:13:31 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Fri, 11 Nov 2016 23:13:31 +0300 Subject: [9] Review request: JDK-8162693 javapackager returns null if com.oracle.tools.packager.windows.WinAppBundler called twice In-Reply-To: References: Message-ID: Correct links: JIRA: https://bugs.openjdk.java.net/browse/JDK-8162693 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8162693/webrev.00/ --Victor > > Chris, > > Please review the changes about WinAppBundler. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8162693 > Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8162693/webrev.00/ > > --Victor > From david.dehaven at oracle.com Mon Nov 14 17:46:37 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 14 Nov 2016 09:46:37 -0800 Subject: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144 Message-ID: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> Kevin, David, please review this trivial change to bump the minimum JDK version to 9-ea+b144 which is now available on java.net. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8169271 The diff is in a comment in the JBS issue, no webrev. -DrD- From kevin.rushforth at oracle.com Mon Nov 14 17:51:09 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Nov 2016 09:51:09 -0800 Subject: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144 In-Reply-To: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> References: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> Message-ID: <5829F98D.1030307@oracle.com> +1 Note that this will need to wait until after the repo is "unlocked" at 1pm PT. -- Kevin David DeHaven wrote: > Kevin, David, please review this trivial change to bump the minimum JDK version to 9-ea+b144 which is now available on java.net. > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8169271 > > The diff is in a comment in the JBS issue, no webrev. > > -DrD- > > From david.dehaven at oracle.com Mon Nov 14 17:57:38 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 14 Nov 2016 09:57:38 -0800 Subject: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144 In-Reply-To: <5829F98D.1030307@oracle.com> References: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> <5829F98D.1030307@oracle.com> Message-ID: <6594BCF6-7093-48CB-BB01-7AAC79FDC7FE@oracle.com> That should be fine. I still want to do test builds with other things that are going on. -DrD- > +1 > > Note that this will need to wait until after the repo is "unlocked" at 1pm PT. > > -- Kevin > > > David DeHaven wrote: >> Kevin, David, please review this trivial change to bump the minimum JDK version to 9-ea+b144 which is now available on java.net. >> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8169271 >> >> The diff is in a comment in the JBS issue, no webrev. >> >> -DrD- >> >> From philip.race at oracle.com Mon Nov 14 18:09:54 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 14 Nov 2016 10:09:54 -0800 Subject: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144 In-Reply-To: <5829F98D.1030307@oracle.com> References: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> <5829F98D.1030307@oracle.com> Message-ID: <2d09432a-d8fa-01b3-570b-e8215bbd7f74@oracle.com> Is this going to be a weekly event ? -phil. On 11/14/2016 09:51 AM, Kevin Rushforth wrote: > +1 > > Note that this will need to wait until after the repo is "unlocked" at > 1pm PT. > > -- Kevin > > > David DeHaven wrote: >> Kevin, David, please review this trivial change to bump the minimum >> JDK version to 9-ea+b144 which is now available on java.net. >> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8169271 >> >> The diff is in a comment in the JBS issue, no webrev. >> >> -DrD- >> From david.dehaven at oracle.com Mon Nov 14 18:11:28 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 14 Nov 2016 10:11:28 -0800 Subject: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144 In-Reply-To: <2d09432a-d8fa-01b3-570b-e8215bbd7f74@oracle.com> References: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> <5829F98D.1030307@oracle.com> <2d09432a-d8fa-01b3-570b-e8215bbd7f74@oracle.com> Message-ID: No, this is a requirement for other, jigsaw related things. -DrD- > Is this going to be a weekly event ? > > -phil. > > On 11/14/2016 09:51 AM, Kevin Rushforth wrote: >> +1 >> >> Note that this will need to wait until after the repo is "unlocked" at 1pm PT. >> >> -- Kevin >> >> >> David DeHaven wrote: >>> Kevin, David, please review this trivial change to bump the minimum JDK version to 9-ea+b144 which is now available on java.net. >>> >>> JBS Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8169271 >>> >>> The diff is in a comment in the JBS issue, no webrev. >>> >>> -DrD- >>> > From kevin.rushforth at oracle.com Mon Nov 14 18:15:20 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Nov 2016 10:15:20 -0800 Subject: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144 In-Reply-To: References: <7F8BD451-C438-4AD5-8575-EA9031B18B65@oracle.com> <5829F98D.1030307@oracle.com> <2d09432a-d8fa-01b3-570b-e8215bbd7f74@oracle.com> Message-ID: <5829FF38.7060101@oracle.com> I hope this will be a rare change, but it will likely happen at least once more next month. -- Kevin David DeHaven wrote: > No, this is a requirement for other, jigsaw related things. > > -DrD- > > >> Is this going to be a weekly event ? >> >> -phil. >> >> On 11/14/2016 09:51 AM, Kevin Rushforth wrote: >> >>> +1 >>> >>> Note that this will need to wait until after the repo is "unlocked" at 1pm PT. >>> >>> -- Kevin >>> >>> >>> David DeHaven wrote: >>> >>>> Kevin, David, please review this trivial change to bump the minimum JDK version to 9-ea+b144 which is now available on java.net. >>>> >>>> JBS Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8169271 >>>> >>>> The diff is in a comment in the JBS issue, no webrev. >>>> >>>> -DrD- >>>> >>>> > > From David.Hill at Oracle.com Mon Nov 14 19:41:04 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 14 Nov 2016 14:41:04 -0500 Subject: Wikie Building OpenJFX has been update Message-ID: <582A1350.3020702@Oracle.com> I just reworked: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX to show the current 9-dev reality of a modular build. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Tue Nov 15 17:30:20 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Nov 2016 09:30:20 -0800 Subject: [9] Review request: 8169683: Incremental build of WebKit native library is broken Message-ID: <582B462C.4050206@oracle.com> Dave, Please review: https://bugs.openjdk.java.net/browse/JDK-8169683 The patch is in JBS. It is a simple one-line change to restore the behavior for native WebKit builds prior to the recent build changes to build with a Jigsaw-aware javac. -- Kevin From steve.hruda at hexagongeospatial.com Wed Nov 16 09:07:11 2016 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Wed, 16 Nov 2016 09:07:11 +0000 Subject: [WebView] Single page application - relative resource in a different jar Message-ID: Hi, short question from my side. I?ve submitted the following bug report which is fixed with 8u112. - [WebView] Icon font doesn't work if single page application will be loaded from jar https://bugs.openjdk.java.net/browse/JDK-8152420 I?ve tested it and I?ve found a new related one. A relative resources only works if the resource is located in the same jar as it?s root. E.g. I changed my test application so that the ?pic_mountain.jpg? is located at another jar but it is still relative to my index.html. Result: It can?t see the image. Is that expected? Best Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. From chris.bensen at oracle.com Wed Nov 16 16:11:50 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 16 Nov 2016 08:11:50 -0800 Subject: [9] Review request: JDK-8167508 ant-javafx.jar and jdk.packager runtime version check Message-ID: <7ED4D39D-887C-43CE-9A90-9C4465049214@oracle.com> Kevin, Please review this change to have ant-javafx.jar check the version of Java that is running it and match the version it was intended to run with by comparing against a version string that is stored in the jar file. JIRA: https://bugs.openjdk.java.net/browse/JDK-8167508 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8167508/webrev.01/ Chris From david.dehaven at oracle.com Wed Nov 16 23:42:57 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 16 Nov 2016 15:42:57 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> Message-ID: Ping? The OpenJDK portion is reviewed and ready to push. I'd prefer to push them at the same time so we don't have a bug that appears to be resolved when it isn't. -DrD- > Please review the JavaFX changes needed for this issue: > https://bugs.openjdk.java.net/browse/JDK-8169289 > > webrev: > http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0 > > For reference, the OpenJDK changes needed are here: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ > > These are being reviewed separately on core-libs-dev at openjdk.java.net > > > I've tested the following cases so far: > LM_CLASS_1 : -cp some.jar main.class > LM_CLASS_2 : -cp path/to/loose/classes main.class > LM_JAR_1 : -jar some.jar (Main-Class) > LM_JAR_2 : -jar some.jar (Main-Class + JavaFX-Application-Class) <- JAC should take precedence > LM_MODULE_1 : -m module/main.class > LM_MODULE_2 : -m module (main class declared in module-info) > > > and one more in progress: > LM_JAR_3 : -jar some.jar (Main-Class + JavaFX-Class-Path) <- creates new ClassLoader > > > I've tested all combinations of having changes (or not) to openjfx and openjdk and there are no unexpected results, the only cases that fail are the LM_MODULE launch modes which fail currently. This means the changes can be pushed in any order. > > I will create unit tests for this, but don't want to push it since this change is split between OpenJFX and OpenJDK (else LM_MODULE modes will just fail until everything is in sync). I'll file a separate issue to push the unit tests at the appropriate time. > > A couple other notes: > - I brought over changes for handling diacritical marks on MacOS X [1], moved class loading to a new method > - I assumed not having a default preloader for the -jar case was a bug, so I fixed it > > -DrD- > > [1] https://bugs.openjdk.java.net/browse/JDK-8017248 > From kevin.rushforth at oracle.com Thu Nov 17 02:17:06 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Nov 2016 18:17:06 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> Message-ID: <582D1322.5040700@oracle.com> Looks good with two minor comments: 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs is only ever called with "null". Did you intend it to be called with the application module in the case of LM_MODULE? 2) In the case of LM_JAR with no preloader attribute (i.e., JavaFX-Preloader-Class is not present in the jar file), the former behavior would then use the default preloader. The new behavior will look for the javafx.preloader system property in that case. I think this is a fine change, but I wanted to point it out. -- Kevin David DeHaven wrote: > Ping? The OpenJDK portion is reviewed and ready to push. I'd prefer to push them at the same time so we don't have a bug that appears to be resolved when it isn't. > > -DrD- > > >> Please review the JavaFX changes needed for this issue: >> https://bugs.openjdk.java.net/browse/JDK-8169289 >> >> webrev: >> http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0 >> >> For reference, the OpenJDK changes needed are here: >> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >> >> These are being reviewed separately on core-libs-dev at openjdk.java.net >> >> >> I've tested the following cases so far: >> LM_CLASS_1 : -cp some.jar main.class >> LM_CLASS_2 : -cp path/to/loose/classes main.class >> LM_JAR_1 : -jar some.jar (Main-Class) >> LM_JAR_2 : -jar some.jar (Main-Class + JavaFX-Application-Class) <- JAC should take precedence >> LM_MODULE_1 : -m module/main.class >> LM_MODULE_2 : -m module (main class declared in module-info) >> >> >> and one more in progress: >> LM_JAR_3 : -jar some.jar (Main-Class + JavaFX-Class-Path) <- creates new ClassLoader >> >> >> I've tested all combinations of having changes (or not) to openjfx and openjdk and there are no unexpected results, the only cases that fail are the LM_MODULE launch modes which fail currently. This means the changes can be pushed in any order. >> >> I will create unit tests for this, but don't want to push it since this change is split between OpenJFX and OpenJDK (else LM_MODULE modes will just fail until everything is in sync). I'll file a separate issue to push the unit tests at the appropriate time. >> >> A couple other notes: >> - I brought over changes for handling diacritical marks on MacOS X [1], moved class loading to a new method >> - I assumed not having a default preloader for the -jar case was a bug, so I fixed it >> >> -DrD- >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8017248 >> >> > > From David.Hill at Oracle.com Thu Nov 17 14:13:27 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 17 Nov 2016 09:13:27 -0500 Subject: review: javac @compile.args does not pick up changes in local build Message-ID: <582DBB07.1@Oracle.com> Kevin: https://bugs.openjdk.java.net/browse/JDK-8169747 http://cr.openjdk.java.net/~ddhill/8169747 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From david.dehaven at oracle.com Thu Nov 17 16:04:10 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 17 Nov 2016 08:04:10 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <582D1322.5040700@oracle.com> References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> <582D1322.5040700@oracle.com> Message-ID: > Looks good with two minor comments: > > 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs is only ever called with "null". Did you intend it to be called with the application module in the case of LM_MODULE? You're correct... I wonder how that happened. It seems I never finished that part, probably due to splitting the work over the weekend :/ That needs to be corrected. Shouldn't take long. -DrD- From Rony.Flatscher at wu.ac.at Thu Nov 17 16:34:01 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 17 Nov 2016 17:34:01 +0100 Subject: Question ad javax.script deployment scenarios ... Message-ID: <4f0286ea-77e4-68ff-4910-4ccddd2a9bf6@wu.ac.at> Not having found a documentation or references as how javax.script scripting languages get employed in JavaFX, I was wondering whether there is an up-to-date, current documentation of that support, if any at all? E.g. it seems that it is not possible to have different scripting engines execute event handlers for the same document (there seems to be no type-attribute or language-attribute available that denotes the scripting language to use to execute the code supplied in an event-attribute like onAction). Or, at least in JavaFX 8, the filename is not supplied for external files, although it could be supplied (and would be important for debugging) like the name the source-attribute of a fx:script element (e.g. ). [One would merely have to add an attribute to the ScriptContext.ENGINE_SCOPE Bindings under the key ScriptEngine.FILENAME, ie. "javax.script.filename".] There would be more, maybe interesting features that javax.script defines that could be taken advantage of (like defining arguments to supply in certain situations which would merely need to employ the key ScriptEngine.ARGV, ie. "javax.script.argv" for the Object array to store in the ScriptContext.ENGINE_SCOPE Bindings. ---rony From david.dehaven at oracle.com Thu Nov 17 17:48:28 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 17 Nov 2016 09:48:28 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> <582D1322.5040700@oracle.com> Message-ID: <9ADFDBD3-BEDA-4A25-A7EF-BBAC6C655E4F@oracle.com> >> Looks good with two minor comments: >> >> 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs is only ever called with "null". Did you intend it to be called with the application module in the case of LM_MODULE? > > You're correct... I wonder how that happened. It seems I never finished that part, probably due to splitting the work over the weekend :/ > > That needs to be corrected. Shouldn't take long. Updated webrev after this mornings dose of http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.1/ -DrD- From kevin.rushforth at oracle.com Thu Nov 17 18:35:32 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Nov 2016 10:35:32 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <9ADFDBD3-BEDA-4A25-A7EF-BBAC6C655E4F@oracle.com> References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> <582D1322.5040700@oracle.com> <9ADFDBD3-BEDA-4A25-A7EF-BBAC6C655E4F@oracle.com> Message-ID: <582DF874.8030105@oracle.com> I think you missed one place: + lawa.invoke(null, new Object[] {null, mainClassName, preloaderClassName, appArgs}); You will want to pass in mainModule as the first argument here, too. -- Kevin David DeHaven wrote: >>> Looks good with two minor comments: >>> >>> 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs is only ever called with "null". Did you intend it to be called with the application module in the case of LM_MODULE? >>> >> You're correct... I wonder how that happened. It seems I never finished that part, probably due to splitting the work over the weekend :/ >> >> That needs to be corrected. Shouldn't take long. >> > > Updated webrev after this mornings dose of > > http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.1/ > > -DrD- > > From david.dehaven at oracle.com Thu Nov 17 18:45:44 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 17 Nov 2016 10:45:44 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <582DF874.8030105@oracle.com> References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> <582D1322.5040700@oracle.com> <9ADFDBD3-BEDA-4A25-A7EF-BBAC6C655E4F@oracle.com> <582DF874.8030105@oracle.com> Message-ID: <31B16EC4-6D11-4415-9EC5-F66AF5ECAB53@oracle.com> There's no way to specify a ClassLoader when loading from a Module, so there's not much point in passing it. Also, the only case where appLoader will be non-null is LM_JAR with JavaFX-Class-Path, so mainModule and appLoader are mutually exclusive. -DrD- > I think you missed one place: > > + lawa.invoke(null, new Object[] {null, mainClassName, preloaderClassName, appArgs}); > > > You will want to pass in mainModule as the first argument here, too. > > -- Kevin > > > David DeHaven wrote: >>>> Looks good with two minor comments: >>>> >>>> 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs is only ever called with "null". Did you intend it to be called with the application module in the case of LM_MODULE? >>>> >>>> >>> You're correct... I wonder how that happened. It seems I never finished that part, probably due to splitting the work over the weekend :/ >>> >>> That needs to be corrected. Shouldn't take long. >>> >>> >> >> Updated webrev after this mornings dose of >> >> >> http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.1/ >> >> >> -DrD- >> >> >> From kevin.rushforth at oracle.com Thu Nov 17 18:52:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Nov 2016 10:52:01 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <31B16EC4-6D11-4415-9EC5-F66AF5ECAB53@oracle.com> References: <56EAC47E-FEA4-4E58-ADC9-81BABBE7AE01@oracle.com> <582D1322.5040700@oracle.com> <9ADFDBD3-BEDA-4A25-A7EF-BBAC6C655E4F@oracle.com> <582DF874.8030105@oracle.com> <31B16EC4-6D11-4415-9EC5-F66AF5ECAB53@oracle.com> Message-ID: <582DFC51.2000908@oracle.com> Thanks for the explanation. +1 -- Kevin David DeHaven wrote: > There's no way to specify a ClassLoader when loading from a Module, so there's not much point in passing it. Also, the only case where appLoader will be non-null is LM_JAR with JavaFX-Class-Path, so mainModule and appLoader are mutually exclusive. > > -DrD- > > >> I think you missed one place: >> >> + lawa.invoke(null, new Object[] {null, mainClassName, preloaderClassName, appArgs}); >> >> >> You will want to pass in mainModule as the first argument here, too. >> >> -- Kevin >> >> >> David DeHaven wrote: >> >>>>> Looks good with two minor comments: >>>>> >>>>> 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs is only ever called with "null". Did you intend it to be called with the application module in the case of LM_MODULE? >>>>> >>>>> >>>>> >>>> You're correct... I wonder how that happened. It seems I never finished that part, probably due to splitting the work over the weekend :/ >>>> >>>> That needs to be corrected. Shouldn't take long. >>>> >>>> >>>> >>> Updated webrev after this mornings dose of >>> >>> >>> http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.1/ >>> >>> >>> -DrD- >>> >>> >>> >>> > > From chien.yang at oracle.com Thu Nov 17 21:31:33 2016 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 17 Nov 2016 13:31:33 -0800 Subject: [9] Code Review Request For 8166932: Fix @Deprecated annotations for deprecated JavaFX methods Message-ID: <582E21B5.4000309@oracle.com> Hi Jim and Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8166932 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8166932/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Thu Nov 17 23:48:16 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Nov 2016 15:48:16 -0800 Subject: [9] Review request: Message-ID: <582E41C0.1060803@oracle.com> Please review the following change to include the sources for javafx.* modules into the JDK 9 src.zip. https://bugs.openjdk.java.net/browse/JDK-8169396 http://cr.openjdk.java.net/~kcr/8169396/webrev.00/ -- Kevin From kevin.rushforth at oracle.com Fri Nov 18 00:10:42 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Nov 2016 16:10:42 -0800 Subject: [9] Review request: 8169396: Include sources for javafx.* modules in src.zip In-Reply-To: <582E41C0.1060803@oracle.com> References: <582E41C0.1060803@oracle.com> Message-ID: <582E4702.6010900@oracle.com> corrected the subject line Kevin Rushforth wrote: > Please review the following change to include the sources for javafx.* > modules into the JDK 9 src.zip. > > https://bugs.openjdk.java.net/browse/JDK-8169396 > http://cr.openjdk.java.net/~kcr/8169396/webrev.00/ > > -- Kevin > From victor.drozdov at oracle.com Fri Nov 18 13:30:47 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Fri, 18 Nov 2016 16:30:47 +0300 Subject: [9] Review request: JDK-8168501 javapackager system wide installation is failed when bundled through ANT in windows operating system Message-ID: <8ffe8309-24df-59a9-aecb-33a01e8041e6@oracle.com> Chris, Please review the changes about system wide installation (bundled through ANT). JIRA: https://bugs.openjdk.java.net/browse/JDK-8168501 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8168501/webrev.00/ --Victor From guru.hb at oracle.com Sat Nov 19 04:25:20 2016 From: guru.hb at oracle.com (Guru Hb) Date: Sat, 19 Nov 2016 09:55:20 +0530 Subject: [WebView] Single page application - relative resource in a different jar In-Reply-To: References: Message-ID: <6B1BA6C3-C515-4AC5-A8EC-7C80C51218D0@oracle.com> Hi Steve, Could you please share the layout of jar file (two jars) so i can re-create the problem and let you know the failure reason. Thanks, Guru > On 16-Nov-2016, at 2:37 PM, Hruda, Steve wrote: > > Hi, > short question from my side. I?ve submitted the following bug report which is fixed with 8u112. > > > - [WebView] Icon font doesn't work if single page application will be loaded from jar > > https://bugs.openjdk.java.net/browse/JDK-8152420 > > I?ve tested it and I?ve found a new related one. > > A relative resources only works if the resource is located in the same jar as it?s root. > > E.g. I changed my test application so that the ?pic_mountain.jpg? is located at another jar but it is still relative to my index.html. > > Result: It can?t see the image. > > Is that expected? > > Best Regards, > Steve > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > > From jonathan.giles at oracle.com Mon Nov 21 07:09:26 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 21 Nov 2016 20:09:26 +1300 Subject: [Review request] 8169642: IndexOutOfBoundsException when sorting TreeTableView with multi-selection enabled Message-ID: Vadim, Please review the following issue: https://bugs.openjdk.java.net/browse/JDK-8169642 http://cr.openjdk.java.net/~jgiles/8169642/ Thanks! -- -- Jonathan From steve.hruda at hexagongeospatial.com Mon Nov 21 09:30:27 2016 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Mon, 21 Nov 2016 09:30:27 +0000 Subject: [WebView] Single page application - relative resource in a different jar In-Reply-To: <6B1BA6C3-C515-4AC5-A8EC-7C80C51218D0@oracle.com> References: <6B1BA6C3-C515-4AC5-A8EC-7C80C51218D0@oracle.com> Message-ID: Hi Guru, I only moved the Pic_mountain.jpg to another jar. So therefore the layout of my jar files look like: html1.jar -> webview.html -> css font-awesome.css -> fonts fontawesome-webfont.eot fontawesome-webfont.svg fontawesome-webfont.ttf fontawesome-webfont.woff fontawesome-webfont.woff2 FontAwesome.otf executeOnStart.js index.html html2.jar ->webview.html Pic_mountain.jpg I java code is still the same: https://github.com/shruda/jdk/tree/master/webview/singlepage Best Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Guru Hb [mailto:guru.hb at oracle.com] Sent: Saturday, November 19, 2016 5:25 AM To: Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: [WebView] Single page application - relative resource in a different jar Hi Steve, Could you please share the layout of jar file (two jars) so i can re-create the problem and let you know the failure reason. Thanks, Guru > On 16-Nov-2016, at 2:37 PM, Hruda, Steve wrote: > > Hi, > short question from my side. I?ve submitted the following bug report which is fixed with 8u112. > > > - [WebView] Icon font doesn't work if single page application will be loaded from jar > > https://bugs.openjdk.java.net/browse/JDK-8152420 > > I?ve tested it and I?ve found a new related one. > > A relative resources only works if the resource is located in the same jar as it?s root. > > E.g. I changed my test application so that the ?pic_mountain.jpg? is located at another jar but it is still relative to my index.html. > > Result: It can?t see the image. > > Is that expected? > > Best Regards, > Steve > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der > Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 > (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN > 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, > Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber Registered office and > Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. > +43 (1) 9610567-0 The company is recorded at the commercial court of > Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > > From David.Hill at Oracle.com Mon Nov 21 19:37:34 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 21 Nov 2016 14:37:34 -0500 Subject: initial webrev for review Message-ID: <58334CFE.5020708@Oracle.com> Kevin, Chien, Semyon, Here is the initial webrev for reworking libglass addressing GTK issues. I am calling it inital because I have not finished the large amount of testing it needs, plus I may need to rework a small number of entry points (6) to make them dynamic. I am asking my reviewers to give the change a try and feed me back results/comments ASAP, given the rather short timeline to get this in. https://bugs.openjdk.java.net/browse/JDK-8163496 initial webrev: http://cr.openjdk.java.net/~ddhill/8163496/ Known issues: GTK3 and popup windows, which seems to be an existing issue which I am chasing. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Mon Nov 21 21:04:41 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 21 Nov 2016 16:04:41 -0500 Subject: initial webrev for review In-Reply-To: <58334CFE.5020708@Oracle.com> References: <58334CFE.5020708@Oracle.com> Message-ID: <58336169.50508@Oracle.com> On 11/21/16, 2:37 PM, David Hill wrote: updated: http://cr.openjdk.java.net/~ddhill/8163496.1 This fixed the popup issue I was seeing. > Kevin, Chien, Semyon, > > Here is the initial webrev for reworking libglass addressing GTK issues. > > I am calling it inital because I have not finished the large amount of testing it needs, plus I may need to rework a small number of entry points (6) to make them dynamic. > > I am asking my reviewers to give the change a try and feed me back results/comments ASAP, given the rather short timeline to get this in. > > https://bugs.openjdk.java.net/browse/JDK-8163496 > initial webrev: http://cr.openjdk.java.net/~ddhill/8163496/ > > Known issues: GTK3 and popup windows, which seems to be an existing issue which I am chasing. > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From Rony.Flatscher at wu.ac.at Tue Nov 22 09:34:49 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 22 Nov 2016 10:34:49 +0100 Subject: Problem editing FXML documents with latest SceneBuilder 8.2.0 with a"${attrname}" text property Message-ID: Not sure whether this is the correct list, if not, please advise where to post such observations. The latest SceneBuilder 8.2.0 (in this case the 64-bit Windows-Version) seems to not be able to process 'text="${attrname}"' definitions, e.g. for a Label. Such an entry will not be displayed in the Properties section (the attribute "Text" is empty), the Label cannot be interactively resized or moved and is flagged with a superimposed warning icon in the Document Hierarchy. When saving a manually created FXML document after editing in the ScreenBuilder the entire text-attribute definition gets removed! How is one supposed to communicate such a bug in SceneBuilder? ---rony From Rony.Flatscher at wu.ac.at Tue Nov 22 09:42:30 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 22 Nov 2016 10:42:30 +0100 Subject: Problem editing FXML documents with latest SceneBuilder 8.2.0 with a"${attrname}" text property In-Reply-To: References: Message-ID: On 22.11.2016 10:34, Rony G. Flatscher wrote: > Not sure whether this is the correct list, if not, please advise where to post such observations. > > The latest SceneBuilder 8.2.0 (in this case the 64-bit Windows-Version) seems to not be able to > process 'text="${attrname}"' definitions, e.g. for a Label. Such an entry will not be displayed in > the Properties section (the attribute "Text" is empty), the Label cannot be interactively resized or > moved and is flagged with a superimposed warning icon in the Document Hierarchy. When saving a > manually created FXML document after editing in the ScreenBuilder the entire text-attribute > definition gets removed! > > How is one supposed to communicate such a bug in SceneBuilder? > > ---rony Actually the text-attribute that has a "$attrname" (without curly braces) gets removed when saving the FXML document. Everything else is still as reported if the text attribute has a "${attrname}" value (and eventually gets removed upon saving it, cannot recreate it as of yet, but observed that behaviour). ---rony From itaisha at gmail.com Tue Nov 22 09:44:30 2016 From: itaisha at gmail.com (Itai) Date: Tue, 22 Nov 2016 11:44:30 +0200 Subject: PopupWindow.AnchorLocation inconsistent with other location properties in RTL mode Message-ID: It seems the meaning of AnchorLocation is opposite to all other position/location parameters in JavaFX when using RTL orientation: in javafx.geometry.Pos, javafx.geometry.HPos LEFT always means "start", so in RTL orientation it aligns nodes to the right (i.e. start of read order). In AnchorLocation however, LEFT and RIGHT have absolute meanings, regardless of node orientation. The comment in [1] says this is how it should work, but considering this is opposite to how other parts of JavaFX operate and that in RTL orientation the default behavior should be anchoring to the right, I think it may be a problem. At the very least, perhaps clarify in the documentation of AnchorLocation that its meaning differs from Pos etc.? Thanks, Itai. [1] https://bugs.openjdk.java.net/browse/JDK-8125934?focusedCommentId=13767580&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13767580 From semyon.sadetsky at oracle.com Tue Nov 22 13:51:23 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 22 Nov 2016 16:51:23 +0300 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas Message-ID: Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8157002 webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK version cannot be detected using the check for the loaded native library version. The fix proposes a way to detect if GTK version of swt.jar library is available on the classpath and tries to get the GTK version from SWT lib internal java classes. --Semyon From alexander.zvegintsev at oracle.com Tue Nov 22 15:44:55 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 22 Nov 2016 18:44:55 +0300 Subject: [9] Review request for 8150175: Need replacement in FXDnD for DropTargetContext::addNotify, removeNotify Message-ID: <89d04077-af58-ce67-e329-0c515a5146df@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8150175/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8150175 -- Thanks, Alexander. From chris.bensen at oracle.com Wed Nov 23 00:12:35 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 22 Nov 2016 16:12:35 -0800 Subject: [9] Review request: 8170122: Packager Tests Message-ID: <4B6E1286-8DCE-4E66-AAF9-4F71884925F0@oracle.com> Kevin, Adding Java Packager examples/tests. JIRA: https://bugs.openjdk.java.net/browse/JDK-8170122 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170122/webrev.00/ Chris From doychin at dsoft-bg.com Wed Nov 23 07:15:26 2016 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Wed, 23 Nov 2016 09:15:26 +0200 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: References: Message-ID: Hi, I think this line is incorrect: if (ver < 2 && ver > 3) { It should be || instead of && On 22.11.2016 ?. 15:51 ?., Semyon Sadetsky wrote: > Hello Kevin & David, > > Please review the fix for jfx9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8157002 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ > > In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK > version cannot be detected using the check for the loaded native library > version. > > The fix proposes a way to detect if GTK version of swt.jar library is > available on the classpath and tries to get the GTK version from SWT lib > internal java classes. > > --Semyon > > -- Doychin Bondzhev dSoft-Bulgaria Ltd. PowerPro - billing & provisioning solution for Service providers PowerStor - Warehouse & POS http://www.dsoft-bg.com/ Mobile: +359888243116 From semyon.sadetsky at oracle.com Wed Nov 23 09:13:58 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 23 Nov 2016 12:13:58 +0300 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: References: Message-ID: <12a7880a-99e0-7ac7-d464-dcbdc1b6d13f@oracle.com> Thanks, Doychin. The webrev is updated: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.01/ --Semyon On 11/23/2016 10:15 AM, Doychin Bondzhev wrote: > Hi, > > I think this line is incorrect: > > if (ver < 2 && ver > 3) { > > It should be || instead of && > > On 22.11.2016 ?. 15:51 ?., Semyon Sadetsky wrote: >> Hello Kevin & David, >> >> Please review the fix for jfx9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >> >> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >> version cannot be detected using the check for the loaded native library >> version. >> >> The fix proposes a way to detect if GTK version of swt.jar library is >> available on the classpath and tries to get the GTK version from SWT lib >> internal java classes. >> >> --Semyon >> >> > > From tom.schindl at bestsolution.at Wed Nov 23 09:38:48 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 23 Nov 2016 10:38:48 +0100 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: References: Message-ID: >From looking at the code I doubt your fix will work reliably in a OSGi-Environment who is the Main deployment scenario for SWT and hence FXCanvas! For sure you won't find the SWT-Library on the SystemClassloader and whether you find it on the Thread-ContextClassloader is just gambling! The only area you for sure can detect the swt-library are the swt-fx.jar-Classes because those are guaranteed to be loaded with a classloader who can look up SWT-Libary classes like "org.eclipse.swt.internal.gtk.OS" BTW: Is the statement below really correct? .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... If you create an instance of FXCanvas SWT must have been loaded already (You need to pass a parent Composite) so the native gtk-libs are there already loaded. Tom On 22.11.16 14:51, Semyon Sadetsky wrote: > Hello Kevin & David, > > Please review the fix for jfx9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8157002 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ > > In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK > version cannot be detected using the check for the loaded native library > version. > > The fix proposes a way to detect if GTK version of swt.jar library is > available on the classpath and tries to get the GTK version from SWT lib > internal java classes. > > --Semyon > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From semyon.sadetsky at oracle.com Wed Nov 23 12:13:48 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 23 Nov 2016 15:13:48 +0300 Subject: [9] Review request for 8156491: Autodetect GTK version for JFX Message-ID: <69903ebc-4683-e4b8-f365-7c2817a1dff6@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8156491 webrev: http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.00/ The fix implements the autodetect feature which protects JFX Glass toolkit from the crash caused by loading dynamic libs from different GTK versions into the same process on Linux platform. --Semyon From semyon.sadetsky at oracle.com Wed Nov 23 12:32:41 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 23 Nov 2016 15:32:41 +0300 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: References: Message-ID: <2c13988f-70a9-6125-c0af-64b102010c5a@oracle.com> On 11/23/2016 12:38 PM, Tom Schindl wrote: > From looking at the code I doubt your fix will work reliably in a > OSGi-Environment who is the Main deployment scenario for SWT and hence > FXCanvas! > > For sure you won't find the SWT-Library on the SystemClassloader and > whether you find it on the Thread-ContextClassloader is just gambling! > > The only area you for sure can detect the swt-library are the > swt-fx.jar-Classes because those are guaranteed to be loaded with a > classloader who can look up SWT-Libary classes like > "org.eclipse.swt.internal.gtk.OS" What is swt-fx.jar? Maybe you meant javafx-swt.jar? > > BTW: Is the statement below really correct? > > .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... > > If you create an instance of FXCanvas SWT must have been loaded already > (You need to pass a parent Composite) so the native gtk-libs are there > already loaded. That's right concern. Actually the fix covers the scenario when swt.jar is on the classpath and may be potentially loaded in future with another GTK version (which will cause the process crash). The rest scenarios are covered by the 8156491 fix which I just posted for review. --Semyon > > Tom > > On 22.11.16 14:51, Semyon Sadetsky wrote: >> Hello Kevin & David, >> >> Please review the fix for jfx9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >> >> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >> version cannot be detected using the check for the loaded native library >> version. >> >> The fix proposes a way to detect if GTK version of swt.jar library is >> available on the classpath and tries to get the GTK version from SWT lib >> internal java classes. >> >> --Semyon >> > From kevin.rushforth at oracle.com Wed Nov 23 15:37:16 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Nov 2016 07:37:16 -0800 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: References: Message-ID: <5835B7AC.9000308@oracle.com> Hi Tom, Would you have time to help us test this? -- Kevin Tom Schindl wrote: > From looking at the code I doubt your fix will work reliably in a > OSGi-Environment who is the Main deployment scenario for SWT and hence > FXCanvas! > > For sure you won't find the SWT-Library on the SystemClassloader and > whether you find it on the Thread-ContextClassloader is just gambling! > > The only area you for sure can detect the swt-library are the > swt-fx.jar-Classes because those are guaranteed to be loaded with a > classloader who can look up SWT-Libary classes like > "org.eclipse.swt.internal.gtk.OS" > > BTW: Is the statement below really correct? > > .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... > > If you create an instance of FXCanvas SWT must have been loaded already > (You need to pass a parent Composite) so the native gtk-libs are there > already loaded. > > Tom > > On 22.11.16 14:51, Semyon Sadetsky wrote: > >> Hello Kevin & David, >> >> Please review the fix for jfx9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >> >> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >> version cannot be detected using the check for the loaded native library >> version. >> >> The fix proposes a way to detect if GTK version of swt.jar library is >> available on the classpath and tries to get the GTK version from SWT lib >> internal java classes. >> >> --Semyon >> >> > > > From tom.schindl at bestsolution.at Wed Nov 23 16:29:19 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 23 Nov 2016 17:29:19 +0100 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: <2c13988f-70a9-6125-c0af-64b102010c5a@oracle.com> References: <2c13988f-70a9-6125-c0af-64b102010c5a@oracle.com> Message-ID: Hi, Ok. I think I got it: a) if SWT is loaded first (which is th 99% case I guess) then you are finding out that you need to run with gtk2 or gtk3 by finding out what gtk libs are already loaded (webref http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.00/) b) if JavaFX is loaded before SWT but SWT is on the classpath then you try to findout what SWT will load and align with that (webref http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.01/) If that is correct all my concerns are addressed! There's one very unlikely case: a) one creates an OSGi-Application b) one loads a JavaFX UI c) loads an SWT-UI Both webrefs won't address this case if not mistaken, but I have never seen an application like that ;-) Tom On 23.11.16 13:32, Semyon Sadetsky wrote: > On 11/23/2016 12:38 PM, Tom Schindl wrote: > >> From looking at the code I doubt your fix will work reliably in a >> OSGi-Environment who is the Main deployment scenario for SWT and hence >> FXCanvas! >> >> For sure you won't find the SWT-Library on the SystemClassloader and >> whether you find it on the Thread-ContextClassloader is just gambling! >> >> The only area you for sure can detect the swt-library are the >> swt-fx.jar-Classes because those are guaranteed to be loaded with a >> classloader who can look up SWT-Libary classes like >> "org.eclipse.swt.internal.gtk.OS" > What is swt-fx.jar? Maybe you meant javafx-swt.jar? >> >> BTW: Is the statement below really correct? >> >> .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... >> >> If you create an instance of FXCanvas SWT must have been loaded already >> (You need to pass a parent Composite) so the native gtk-libs are there >> already loaded. > That's right concern. Actually the fix covers the scenario when swt.jar > is on the classpath and may be potentially loaded in future with another > GTK version (which will cause the process crash). The rest scenarios are > covered by the 8156491 fix which I just posted for review. > > --Semyon >> >> Tom >> >> On 22.11.16 14:51, Semyon Sadetsky wrote: >>> Hello Kevin & David, >>> >>> Please review the fix for jfx9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >>> >>> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >>> version cannot be detected using the check for the loaded native library >>> version. >>> >>> The fix proposes a way to detect if GTK version of swt.jar library is >>> available on the classpath and tries to get the GTK version from SWT lib >>> internal java classes. >>> >>> --Semyon >>> >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Wed Nov 23 16:31:34 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 23 Nov 2016 17:31:34 +0100 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: <5835B7AC.9000308@oracle.com> References: <5835B7AC.9000308@oracle.com> Message-ID: <07256a69-0c77-ca8d-9968-3f9314bfb990@bestsolution.at> Hi Kevin, Just replied to Semyon and I think the change is fine Tom On 23.11.16 16:37, Kevin Rushforth wrote: > Hi Tom, > > Would you have time to help us test this? > > -- Kevin > > > Tom Schindl wrote: >> From looking at the code I doubt your fix will work reliably in a >> OSGi-Environment who is the Main deployment scenario for SWT and hence >> FXCanvas! >> >> For sure you won't find the SWT-Library on the SystemClassloader and >> whether you find it on the Thread-ContextClassloader is just gambling! >> >> The only area you for sure can detect the swt-library are the >> swt-fx.jar-Classes because those are guaranteed to be loaded with a >> classloader who can look up SWT-Libary classes like >> "org.eclipse.swt.internal.gtk.OS" >> >> BTW: Is the statement below really correct? >> >> .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... >> >> If you create an instance of FXCanvas SWT must have been loaded already >> (You need to pass a parent Composite) so the native gtk-libs are there >> already loaded. >> >> Tom >> >> On 22.11.16 14:51, Semyon Sadetsky wrote: >> >>> Hello Kevin & David, >>> >>> Please review the fix for jfx9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >>> >>> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >>> version cannot be detected using the check for the loaded native library >>> version. >>> >>> The fix proposes a way to detect if GTK version of swt.jar library is >>> available on the classpath and tries to get the GTK version from SWT lib >>> internal java classes. >>> >>> --Semyon >>> >>> >> >> >> -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Wed Nov 23 16:32:21 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Nov 2016 08:32:21 -0800 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: <07256a69-0c77-ca8d-9968-3f9314bfb990@bestsolution.at> References: <5835B7AC.9000308@oracle.com> <07256a69-0c77-ca8d-9968-3f9314bfb990@bestsolution.at> Message-ID: <5835C495.4000502@oracle.com> Thanks, Tom. -- Kevin Tom Schindl wrote: > Hi Kevin, > > Just replied to Semyon and I think the change is fine > > Tom > > On 23.11.16 16:37, Kevin Rushforth wrote: > >> Hi Tom, >> >> Would you have time to help us test this? >> >> -- Kevin >> >> >> Tom Schindl wrote: >> >>> From looking at the code I doubt your fix will work reliably in a >>> OSGi-Environment who is the Main deployment scenario for SWT and hence >>> FXCanvas! >>> >>> For sure you won't find the SWT-Library on the SystemClassloader and >>> whether you find it on the Thread-ContextClassloader is just gambling! >>> >>> The only area you for sure can detect the swt-library are the >>> swt-fx.jar-Classes because those are guaranteed to be loaded with a >>> classloader who can look up SWT-Libary classes like >>> "org.eclipse.swt.internal.gtk.OS" >>> >>> BTW: Is the statement below really correct? >>> >>> .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... >>> >>> If you create an instance of FXCanvas SWT must have been loaded already >>> (You need to pass a parent Composite) so the native gtk-libs are there >>> already loaded. >>> >>> Tom >>> >>> On 22.11.16 14:51, Semyon Sadetsky wrote: >>> >>> >>>> Hello Kevin & David, >>>> >>>> Please review the fix for jfx9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >>>> >>>> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >>>> version cannot be detected using the check for the loaded native library >>>> version. >>>> >>>> The fix proposes a way to detect if GTK version of swt.jar library is >>>> available on the classpath and tries to get the GTK version from SWT lib >>>> internal java classes. >>>> >>>> --Semyon >>>> >>>> >>>> >>> >>> > > > From semyon.sadetsky at oracle.com Wed Nov 23 17:27:27 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 23 Nov 2016 20:27:27 +0300 Subject: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas In-Reply-To: References: <2c13988f-70a9-6125-c0af-64b102010c5a@oracle.com> Message-ID: <1e81a393-ac42-37f6-90f4-da2e7448b9a2@oracle.com> On 23.11.2016 19:29, Tom Schindl wrote: > Hi, > > Ok. I think I got it: > > a) if SWT is loaded first (which is th 99% case I guess) then you are > finding out that you need to run with gtk2 or gtk3 by finding out > what gtk libs are already loaded (webref > http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.00/) > > b) if JavaFX is loaded before SWT but SWT is on the classpath then you > try to findout what SWT will load and align with that (webref > http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.01/) > > If that is correct all my concerns are addressed! There's one very > unlikely case: > > a) one creates an OSGi-Application It is possible that SWT lib is added to an another OSGi bundle classpath which is not accessible. Since all OSGi bundles share the same process it may cause the GTK version conflict. I think we cannot resolve this issue for OSGi and for all other custom ClassLoader hierarchies. --Semyon > b) one loads a JavaFX UI > c) loads an SWT-UI > > Both webrefs won't address this case if not mistaken, but I have never > seen an application like that ;-) > > Tom > > On 23.11.16 13:32, Semyon Sadetsky wrote: >> On 11/23/2016 12:38 PM, Tom Schindl wrote: >> >>> From looking at the code I doubt your fix will work reliably in a >>> OSGi-Environment who is the Main deployment scenario for SWT and hence >>> FXCanvas! >>> >>> For sure you won't find the SWT-Library on the SystemClassloader and >>> whether you find it on the Thread-ContextClassloader is just gambling! >>> >>> The only area you for sure can detect the swt-library are the >>> swt-fx.jar-Classes because those are guaranteed to be loaded with a >>> classloader who can look up SWT-Libary classes like >>> "org.eclipse.swt.internal.gtk.OS" >> What is swt-fx.jar? Maybe you meant javafx-swt.jar? >>> BTW: Is the statement below really correct? >>> >>> .... in JFX embeded into SWT scenarios JFX loads GTK primarily ... >>> >>> If you create an instance of FXCanvas SWT must have been loaded already >>> (You need to pass a parent Composite) so the native gtk-libs are there >>> already loaded. >> That's right concern. Actually the fix covers the scenario when swt.jar >> is on the classpath and may be potentially loaded in future with another >> GTK version (which will cause the process crash). The rest scenarios are >> covered by the 8156491 fix which I just posted for review. >> >> --Semyon >>> Tom >>> >>> On 22.11.16 14:51, Semyon Sadetsky wrote: >>>> Hello Kevin & David, >>>> >>>> Please review the fix for jfx9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157002 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/ >>>> >>>> In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK >>>> version cannot be detected using the check for the loaded native library >>>> version. >>>> >>>> The fix proposes a way to detect if GTK version of swt.jar library is >>>> available on the classpath and tries to get the GTK version from SWT lib >>>> internal java classes. >>>> >>>> --Semyon >>>> > From bourges.laurent at gmail.com Wed Nov 23 22:16:42 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 23 Nov 2016 23:16:42 +0100 Subject: Review request for JDK-8170140: rendering anomaly with MarlinFX renderer Message-ID: Jim & Kevin, Please review the marlin-FX webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170140.0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8170140 Ths bug fix seems very simple in MaskMarlinAlphaConsumer: + // ensure last block flag = 0 to process final block:+ blkFlags[blkE] = 0; But it is less easy to explain: In Renderer, the block flags are set by: blkFlags[(pix_xmax + 1) >> _BLK_SIZE_LG] = 1 I recently added +1 that can lead to flag an extra block when pix_xmax is at a block boundary (32 pixels). pix_xmax = x1 >> _SUBPIXEL_LG_POSITIONS_X x1 <= bboxx1 = bbox_spmaxX = pmaxX << SUBPIXEL_LG_POSITIONS_X So pix_xmax is at most equals to pmaxX = bboxX1 = getOutpixMaxX() The added line in MaskMarlinAlphaConsumer ensures that the setAndClearRelativeAlphas() always process the loop that clears and copies the last block of pixels: blkFlags[blkE] = 0 is equivalent to blkFlags[(bboxX1 + 1) >> _BLK_SIZE_LG] = 0 This is quite difficult to explain but it is now correct. I added a test in System tests as it was not working in javafx.graphics tests (Exception in Application constructor) PS: This bug may be the cause of RegionBackgroundFillUITest failures: https://bugs.openjdk.java.net/browse/JDK-8170026 Regards, Laurent From bley at jpro.io Fri Nov 25 10:45:44 2016 From: bley at jpro.io (Tobias Bley) Date: Fri, 25 Nov 2016 11:45:44 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Hi, @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? Best regards, Tobi > Am 11.11.2016 um 12:08 schrieb Felix Bembrick : > > Thanks Laurent, > > That's another thing we discovered: using Java itself in the most performant way can help a lot. > > It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. > > Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. > > Blessings, > > Felix > >> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >> >> Hi, >> >> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >> >> This approach is generic and could be applied in other critical places of the rendering pipelines. >> >> FYI here are my fosdem 2016 slides on the Marlin renderer: >> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >> >> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >> >> However I would like getting sort of sponsoring for my potential contributions... >> >> Cheers, >> Laurent >> >> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>> >>> Hi, >>> >>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>> >>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>> >>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>> >>> So maybe there are other points than multithreading where we can boost the performance? >>> >>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>> >>> >>> Best regards, >>> Tobi >>> >>> >>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>> >>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>> >>>> So, with all the recent discussions regarding the great contribution by >>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>> general. >>>> >>>> As has been correctly pointed-out, converting or modifying the existing >>>> rendering pipeline into a fully multi-threaded and performant beast is >>>> indeed quite a complex task. >>>> >>>> But, that's exactly what myself and my colleagues have been working on for >>>> about 2 years. >>>> >>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>> >>>> Work on HPR started when we developed FXMark and were (bitterly) >>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>> developers have blogged about the need to dramatically minimise the number >>>> of nodes (especially on embedded devices) in order to achieve even >>>> "acceptable" performance. Often it is the case that most (if not all >>>> rendering) is eventually done in a single Canvas node. >>>> >>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>> can be done with this one node. >>>> >>>> But, the majority of the animation plumbing in JavaFX is related to the >>>> scene graph itself and is designed to make use of multiple nodes and node >>>> types. At the moment, the performance of this scene graph is the Achilles >>>> Heel of JavaFX (or at least one of them). >>>> >>>> Enter HPR. >>>> >>>> I personally have worked with a number of hardware-accelerated toolkits >>>> over the years and am astounded by just how sluggish the rendering pipeline >>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>> the same (very powerful) machine, I can use other toolkits to render >>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>> >>>> So, we refactored the entire scene graph rendering pipeline with the >>>> following goals and principles: >>>> >>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>> back-ported to JavaFX 8 though I see no reason to). >>>> >>>> 2. We analysed how other toolkits had optimised their own rendering >>>> pipelines (especially Qt which has made some significant advances in this >>>> area in recent years). We also analysed recent examples of multi-threaded >>>> rendering using the new Vulkan API. >>>> >>>> 3. We carefully analysed and determined which parts of the pipeline should >>>> best utilise the CPU and which parts should best utilise the GPU. >>>> >>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>> features of Java 8/9 to maximise parallelisation and throughput by >>>> utilising multiple cores & threads in as an efficient manner as possible. >>>> >>>> 5. We devoted a large amount of time to optimising the "communication" >>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>> huge performance gains. >>>> >>>> 6. We also looked at the structure of the scene graph itself and after >>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>> graph in such a way that it lends itself to optimised rendering much more >>>> easily. >>>> >>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>> "patch" is probably rather inappropriate. >>>> >>>> The end result is that we now have a fully-functional prototype of HPR and, >>>> already, we are seeing very significant performance improvements. >>>> >>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>> with judicious and sometimes "tricky" use of caching, we have seen >>>> improvements in performance of 10x or more. >>>> >>>> And... we are only just *starting* with the performance optimisation phase. >>>> >>>> The potential for HPR is massive as it opens-up the possibility for the >>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>> for a whole new class of applications including games, advanced >>>> visualisations etc., without having to rely on imperative programming of a >>>> single Canvas node. >>>> >>>> I believe that HPR, along with tremendous recent developments like JPro and >>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>> >>>> WORA for graphics and UIs is finally within reach! >>>> >>>> Blessings, >>>> >>>> Felix >>> From felix.bembrick at gmail.com Fri Nov 25 11:19:22 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 25 Nov 2016 22:19:22 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Yes. > On 25 Nov. 2016, at 21:45, Tobias Bley wrote: > > Hi, > > @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? > > Best regards, > Tobi > > > > >> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >> >> Thanks Laurent, >> >> That's another thing we discovered: using Java itself in the most performant way can help a lot. >> >> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >> >> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >> >> Blessings, >> >> Felix >> >>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>> >>> Hi, >>> >>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>> >>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>> >>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>> >>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>> >>> However I would like getting sort of sponsoring for my potential contributions... >>> >>> Cheers, >>> Laurent >>> >>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>> >>>> Hi, >>>> >>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>> >>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>> >>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>> >>>> So maybe there are other points than multithreading where we can boost the performance? >>>> >>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>> >>>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>> >>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>> >>>>> So, with all the recent discussions regarding the great contribution by >>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>> general. >>>>> >>>>> As has been correctly pointed-out, converting or modifying the existing >>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>> indeed quite a complex task. >>>>> >>>>> But, that's exactly what myself and my colleagues have been working on for >>>>> about 2 years. >>>>> >>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>> >>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>> developers have blogged about the need to dramatically minimise the number >>>>> of nodes (especially on embedded devices) in order to achieve even >>>>> "acceptable" performance. Often it is the case that most (if not all >>>>> rendering) is eventually done in a single Canvas node. >>>>> >>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>> can be done with this one node. >>>>> >>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>> Heel of JavaFX (or at least one of them). >>>>> >>>>> Enter HPR. >>>>> >>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>> the same (very powerful) machine, I can use other toolkits to render >>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>> >>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>> following goals and principles: >>>>> >>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>> back-ported to JavaFX 8 though I see no reason to). >>>>> >>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>> pipelines (especially Qt which has made some significant advances in this >>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>> rendering using the new Vulkan API. >>>>> >>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>> >>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>> >>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>> huge performance gains. >>>>> >>>>> 6. We also looked at the structure of the scene graph itself and after >>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>> graph in such a way that it lends itself to optimised rendering much more >>>>> easily. >>>>> >>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>> "patch" is probably rather inappropriate. >>>>> >>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>> already, we are seeing very significant performance improvements. >>>>> >>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>> improvements in performance of 10x or more. >>>>> >>>>> And... we are only just *starting* with the performance optimisation phase. >>>>> >>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>> for a whole new class of applications including games, advanced >>>>> visualisations etc., without having to rely on imperative programming of a >>>>> single Canvas node. >>>>> >>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>> >>>>> WORA for graphics and UIs is finally within reach! >>>>> >>>>> Blessings, >>>>> >>>>> Felix >>>> > From hastebrot at gmail.com Fri Nov 25 11:25:48 2016 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 25 Nov 2016 12:25:48 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Wow, thanks for all the great work (Felix and Laurent)! Marlin and HPR seem to really fit into what needs to be done to improve the performance. Speaking of the Vulkan API: Does HPR use shaders to optimize the rendering or does this only apply to rasterization (i.e. Marlin)? Webrender and Servo (by Mozilla written in Rust) use GPU shaders a lot, along with parallelized DOM (scene graph) access, aggressive culling and caching and batching. --Benjamin On Fri, Nov 25, 2016 at 11:45 AM, Tobias Bley wrote: > Hi, > > @Felix: Is there any Github project, demo video or trial to test HPR with > JavaFX? > > Best regards, > Tobi > > > > > > Am 11.11.2016 um 12:08 schrieb Felix Bembrick >: > > > > Thanks Laurent, > > > > That's another thing we discovered: using Java itself in the most > performant way can help a lot. > > > > It can be tricky, but profiling can often highlight various patterns of > object instantiation that show-up red flags and can lead you directly to > regions of the code that can be refactored to be significantly more > efficient. > > > > Also, the often overlooked GC log analysis can lead to similar > discoveries and remedies. > > > > Blessings, > > > > Felix > > > >> On 11 Nov. 2016, at 21:55, Laurent Bourg?s > wrote: > >> > >> Hi, > >> > >> To optimize Pisces that became the Marlin rasterizer, I carefully > avoided any both array allocation (byte/int/float pools) and also reduced > array copies or clean up ie only clear dirty parts. > >> > >> This approach is generic and could be applied in other critical places > of the rendering pipelines. > >> > >> FYI here are my fosdem 2016 slides on the Marlin renderer: > >> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf > >> > >> Of course I would be happy to share my experience and work with a tiger > team on optimizing JavaFX graphics. > >> > >> However I would like getting sort of sponsoring for my potential > contributions... > >> > >> Cheers, > >> Laurent > >> > >> Le 11 nov. 2016 11:29, "Tobi" a ?crit : > >>> > >>> Hi, > >>> > >>> thanks Felix, Laurent and Chris for sharing your stuff with the > community! > >>> > >>> I am happy to see starting a discussion about boosting up the JavaFX > rendering performance. I can confirm that the performance of JavaFX scene > graph is not there where it should be. So multithreading would be an > excellent, but difficult approach. > >>> > >>> Felix, concerning your research of other toolkits: Do they all use > multithreading or are there any toolkits which use single threading but are > faster than JavaFX? > >>> > >>> So maybe there are other points than multithreading where we can boost > the performance? > >>> > >>> 2) your HPR sounds great. Did you already try DemoFX (part 3) > benchmark with your HPR? > >>> > >>> > >>> Best regards, > >>> Tobi > >>> > >>> > >>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick < > felix.bembrick at gmail.com>: > >>>> > >>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). > >>>> > >>>> So, with all the recent discussions regarding the great contribution > by > >>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread > be > >>>> started to discuss parallelisation of the JavaFX rendering pipeline in > >>>> general. > >>>> > >>>> As has been correctly pointed-out, converting or modifying the > existing > >>>> rendering pipeline into a fully multi-threaded and performant beast is > >>>> indeed quite a complex task. > >>>> > >>>> But, that's exactly what myself and my colleagues have been working > on for > >>>> about 2 years. > >>>> > >>>> The result is what we call the Hyper Rendering Pipeline (HPR). > >>>> > >>>> Work on HPR started when we developed FXMark and were (bitterly) > >>>> disappointed with the performance of the JavaFX scene graph. Many > JavaFX > >>>> developers have blogged about the need to dramatically minimise the > number > >>>> of nodes (especially on embedded devices) in order to achieve even > >>>> "acceptable" performance. Often it is the case that most (if not all > >>>> rendering) is eventually done in a single Canvas node. > >>>> > >>>> Now, as well already know, the JavaFX Canvas does perform very well > and the > >>>> recent awesome work (DemoFX) by Chris Newland, just for example, > shows what > >>>> can be done with this one node. > >>>> > >>>> But, the majority of the animation plumbing in JavaFX is related to > the > >>>> scene graph itself and is designed to make use of multiple nodes and > node > >>>> types. At the moment, the performance of this scene graph is the > Achilles > >>>> Heel of JavaFX (or at least one of them). > >>>> > >>>> Enter HPR. > >>>> > >>>> I personally have worked with a number of hardware-accelerated > toolkits > >>>> over the years and am astounded by just how sluggish the rendering > pipeline > >>>> for JavaFX is. When I am animating just a couple of hundred nodes > using > >>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but > on > >>>> the same (very powerful) machine, I can use other toolkits to render > >>>> thousands of "objects" and achieve frame rates well over 1000 FPS. > >>>> > >>>> So, we refactored the entire scene graph rendering pipeline with the > >>>> following goals and principles: > >>>> > >>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be > >>>> back-ported to JavaFX 8 though I see no reason to). > >>>> > >>>> 2. We analysed how other toolkits had optimised their own rendering > >>>> pipelines (especially Qt which has made some significant advances in > this > >>>> area in recent years). We also analysed recent examples of > multi-threaded > >>>> rendering using the new Vulkan API. > >>>> > >>>> 3. We carefully analysed and determined which parts of the pipeline > should > >>>> best utilise the CPU and which parts should best utilise the GPU. > >>>> > >>>> 4. For those parts most suited to the CPU, we use the advanced > concurrency > >>>> features of Java 8/9 to maximise parallelisation and throughput by > >>>> utilising multiple cores & threads in as an efficient manner as > possible. > >>>> > >>>> 5. We devoted a large amount of time to optimising the "communication" > >>>> between the CPU and GPU to be far less "chatty" and this alone led to > some > >>>> huge performance gains. > >>>> > >>>> 6. We also looked at the structure of the scene graph itself and after > >>>> studying products such as OpenSceneGraph, we refactored the JavaFX > scene > >>>> graph in such a way that it lends itself to optimised rendering much > more > >>>> easily. > >>>> > >>>> 7. This is clearly not a "small" patch. In fact to refer to it as a > >>>> "patch" is probably rather inappropriate. > >>>> > >>>> The end result is that we now have a fully-functional prototype of > HPR and, > >>>> already, we are seeing very significant performance improvements. > >>>> > >>>> At the minimum, scene graph rendering performance has improved by > 500% and, > >>>> with judicious and sometimes "tricky" use of caching, we have seen > >>>> improvements in performance of 10x or more. > >>>> > >>>> And... we are only just *starting* with the performance optimisation > phase. > >>>> > >>>> The potential for HPR is massive as it opens-up the possibility for > the > >>>> JavaFX scene graph and the animation/transition infrastructure to be > used > >>>> for a whole new class of applications including games, advanced > >>>> visualisations etc., without having to rely on imperative programming > of a > >>>> single Canvas node. > >>>> > >>>> I believe that HPR, along with tremendous recent developments like > JPro and > >>>> the outstanding work by Gluon on mobiles and embedded devices, could > >>>> position JavaFX to be the best graphics toolkit of any kind in any > language > >>>> and, be the ONLY *truly* cross-platform graphics technology available. > >>>> > >>>> WORA for graphics and UIs is finally within reach! > >>>> > >>>> Blessings, > >>>> > >>>> Felix > >>> > > From bley at jpro.io Fri Nov 25 13:07:19 2016 From: bley at jpro.io (Tobias Bley) Date: Fri, 25 Nov 2016 14:07:19 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: A very short answer ;) ?. Do you have any URL? > Am 25.11.2016 um 12:19 schrieb Felix Bembrick : > > Yes. > >> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >> >> Hi, >> >> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >> >> Best regards, >> Tobi >> >> >> >> >>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>> >>> Thanks Laurent, >>> >>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>> >>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>> >>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>> >>> Blessings, >>> >>> Felix >>> >>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>> >>>> Hi, >>>> >>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>> >>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>> >>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>> >>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>> >>>> However I would like getting sort of sponsoring for my potential contributions... >>>> >>>> Cheers, >>>> Laurent >>>> >>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>> >>>>> Hi, >>>>> >>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>> >>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>> >>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>> >>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>> >>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>> >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> >>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>> >>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>> >>>>>> So, with all the recent discussions regarding the great contribution by >>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>> general. >>>>>> >>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>> indeed quite a complex task. >>>>>> >>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>> about 2 years. >>>>>> >>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>> >>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>> developers have blogged about the need to dramatically minimise the number >>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>> rendering) is eventually done in a single Canvas node. >>>>>> >>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>> can be done with this one node. >>>>>> >>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>> Heel of JavaFX (or at least one of them). >>>>>> >>>>>> Enter HPR. >>>>>> >>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>> >>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>> following goals and principles: >>>>>> >>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>> >>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>> rendering using the new Vulkan API. >>>>>> >>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>> >>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>> >>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>> huge performance gains. >>>>>> >>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>> easily. >>>>>> >>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>> "patch" is probably rather inappropriate. >>>>>> >>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>> already, we are seeing very significant performance improvements. >>>>>> >>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>> improvements in performance of 10x or more. >>>>>> >>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>> >>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>> for a whole new class of applications including games, advanced >>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>> single Canvas node. >>>>>> >>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>> >>>>>> WORA for graphics and UIs is finally within reach! >>>>>> >>>>>> Blessings, >>>>>> >>>>>> Felix >>>>> >> From murali.billa at oracle.com Fri Nov 25 14:15:59 2016 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 25 Nov 2016 06:15:59 -0800 (PST) Subject: [9] Review request for 8164792: Memory leak in JavaFX WebView In-Reply-To: <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> Message-ID: <8f788fd2-3722-45b0-b6f9-6f6161887ef4@default> ? Hi Kevin, Arun, Guru, Please review the below leak fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164792 Webrev: http://cr.openjdk.java.net/~mbilla/8164792/webrev.00/ ? Thanks, Murali From vadim.pakhnushev at oracle.com Fri Nov 25 14:58:19 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 25 Nov 2016 17:58:19 +0300 Subject: In(Sanity) Testing Mondays Message-ID: Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From felix.bembrick at gmail.com Fri Nov 25 15:44:03 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 26 Nov 2016 02:44:03 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Thanks Benjamin, We studied those products you mentioned when designing HPR and, yes, there is extensive use of shaders and much more utilisation of the GPU in general. We also have the beginnings of a Vulkan-only version written in (coincidentally) Rust which is showing amazing promise. Vulkan is something we are investing a lot of research and effort into. Felix > On 25 Nov. 2016, at 22:25, Benjamin Gudehus wrote: > > Wow, thanks for all the great work (Felix and Laurent)! Marlin and HPR seem to really fit into what needs to be done to improve the performance. > > Speaking of the Vulkan API: Does HPR use shaders to optimize the rendering or does this only apply to rasterization (i.e. Marlin)? > > Webrender and Servo (by Mozilla written in Rust) use GPU shaders a lot, along with parallelized DOM (scene graph) access, aggressive culling and caching and batching. > > --Benjamin > >> On Fri, Nov 25, 2016 at 11:45 AM, Tobias Bley wrote: >> Hi, >> >> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >> >> Best regards, >> Tobi >> >> >> >> >> > Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >> > >> > Thanks Laurent, >> > >> > That's another thing we discovered: using Java itself in the most performant way can help a lot. >> > >> > It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >> > >> > Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >> > >> > Blessings, >> > >> > Felix >> > >> >> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >> >> >> >> Hi, >> >> >> >> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >> >> >> >> This approach is generic and could be applied in other critical places of the rendering pipelines. >> >> >> >> FYI here are my fosdem 2016 slides on the Marlin renderer: >> >> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >> >> >> >> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >> >> >> >> However I would like getting sort of sponsoring for my potential contributions... >> >> >> >> Cheers, >> >> Laurent >> >> >> >> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >> >>> >> >>> Hi, >> >>> >> >>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >> >>> >> >>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >> >>> >> >>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >> >>> >> >>> So maybe there are other points than multithreading where we can boost the performance? >> >>> >> >>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >> >>> >> >>> >> >>> Best regards, >> >>> Tobi >> >>> >> >>> >> >>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >> >>>> >> >>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >> >>>> >> >>>> So, with all the recent discussions regarding the great contribution by >> >>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >> >>>> started to discuss parallelisation of the JavaFX rendering pipeline in >> >>>> general. >> >>>> >> >>>> As has been correctly pointed-out, converting or modifying the existing >> >>>> rendering pipeline into a fully multi-threaded and performant beast is >> >>>> indeed quite a complex task. >> >>>> >> >>>> But, that's exactly what myself and my colleagues have been working on for >> >>>> about 2 years. >> >>>> >> >>>> The result is what we call the Hyper Rendering Pipeline (HPR). >> >>>> >> >>>> Work on HPR started when we developed FXMark and were (bitterly) >> >>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >> >>>> developers have blogged about the need to dramatically minimise the number >> >>>> of nodes (especially on embedded devices) in order to achieve even >> >>>> "acceptable" performance. Often it is the case that most (if not all >> >>>> rendering) is eventually done in a single Canvas node. >> >>>> >> >>>> Now, as well already know, the JavaFX Canvas does perform very well and the >> >>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >> >>>> can be done with this one node. >> >>>> >> >>>> But, the majority of the animation plumbing in JavaFX is related to the >> >>>> scene graph itself and is designed to make use of multiple nodes and node >> >>>> types. At the moment, the performance of this scene graph is the Achilles >> >>>> Heel of JavaFX (or at least one of them). >> >>>> >> >>>> Enter HPR. >> >>>> >> >>>> I personally have worked with a number of hardware-accelerated toolkits >> >>>> over the years and am astounded by just how sluggish the rendering pipeline >> >>>> for JavaFX is. When I am animating just a couple of hundred nodes using >> >>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >> >>>> the same (very powerful) machine, I can use other toolkits to render >> >>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >> >>>> >> >>>> So, we refactored the entire scene graph rendering pipeline with the >> >>>> following goals and principles: >> >>>> >> >>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >> >>>> back-ported to JavaFX 8 though I see no reason to). >> >>>> >> >>>> 2. We analysed how other toolkits had optimised their own rendering >> >>>> pipelines (especially Qt which has made some significant advances in this >> >>>> area in recent years). We also analysed recent examples of multi-threaded >> >>>> rendering using the new Vulkan API. >> >>>> >> >>>> 3. We carefully analysed and determined which parts of the pipeline should >> >>>> best utilise the CPU and which parts should best utilise the GPU. >> >>>> >> >>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >> >>>> features of Java 8/9 to maximise parallelisation and throughput by >> >>>> utilising multiple cores & threads in as an efficient manner as possible. >> >>>> >> >>>> 5. We devoted a large amount of time to optimising the "communication" >> >>>> between the CPU and GPU to be far less "chatty" and this alone led to some >> >>>> huge performance gains. >> >>>> >> >>>> 6. We also looked at the structure of the scene graph itself and after >> >>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >> >>>> graph in such a way that it lends itself to optimised rendering much more >> >>>> easily. >> >>>> >> >>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >> >>>> "patch" is probably rather inappropriate. >> >>>> >> >>>> The end result is that we now have a fully-functional prototype of HPR and, >> >>>> already, we are seeing very significant performance improvements. >> >>>> >> >>>> At the minimum, scene graph rendering performance has improved by 500% and, >> >>>> with judicious and sometimes "tricky" use of caching, we have seen >> >>>> improvements in performance of 10x or more. >> >>>> >> >>>> And... we are only just *starting* with the performance optimisation phase. >> >>>> >> >>>> The potential for HPR is massive as it opens-up the possibility for the >> >>>> JavaFX scene graph and the animation/transition infrastructure to be used >> >>>> for a whole new class of applications including games, advanced >> >>>> visualisations etc., without having to rely on imperative programming of a >> >>>> single Canvas node. >> >>>> >> >>>> I believe that HPR, along with tremendous recent developments like JPro and >> >>>> the outstanding work by Gluon on mobiles and embedded devices, could >> >>>> position JavaFX to be the best graphics toolkit of any kind in any language >> >>>> and, be the ONLY *truly* cross-platform graphics technology available. >> >>>> >> >>>> WORA for graphics and UIs is finally within reach! >> >>>> >> >>>> Blessings, >> >>>> >> >>>> Felix >> >>> >> > From felix.bembrick at gmail.com Fri Nov 25 15:45:30 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 26 Nov 2016 02:45:30 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Short answer? Maybe. But exactly one more word than any from Oracle ;-) > On 26 Nov. 2016, at 00:07, Tobias Bley wrote: > > A very short answer ;) ?. > > Do you have any URL? > > > > > >> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >> >> Yes. >> >>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>> >>> Hi, >>> >>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>> >>> Best regards, >>> Tobi >>> >>> >>> >>> >>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>> >>>> Thanks Laurent, >>>> >>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>> >>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>> >>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>> >>>> Blessings, >>>> >>>> Felix >>>> >>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>> >>>>> Hi, >>>>> >>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>> >>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>> >>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>> >>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>> >>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>> >>>>> Cheers, >>>>> Laurent >>>>> >>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>> >>>>>> Hi, >>>>>> >>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>> >>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>> >>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>> >>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>> >>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>>> >>>>>> >>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>> >>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>> >>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>> general. >>>>>>> >>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>> indeed quite a complex task. >>>>>>> >>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>> about 2 years. >>>>>>> >>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>> >>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>> >>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>> can be done with this one node. >>>>>>> >>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>> Heel of JavaFX (or at least one of them). >>>>>>> >>>>>>> Enter HPR. >>>>>>> >>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>> >>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>> following goals and principles: >>>>>>> >>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>> >>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>> rendering using the new Vulkan API. >>>>>>> >>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>> >>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>> >>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>> huge performance gains. >>>>>>> >>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>> easily. >>>>>>> >>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>> "patch" is probably rather inappropriate. >>>>>>> >>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>> already, we are seeing very significant performance improvements. >>>>>>> >>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>> improvements in performance of 10x or more. >>>>>>> >>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>> >>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>> for a whole new class of applications including games, advanced >>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>> single Canvas node. >>>>>>> >>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>> >>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>> >>>>>>> Blessings, >>>>>>> >>>>>>> Felix >>>>>> >>> > From victor.drozdov at oracle.com Fri Nov 25 17:49:58 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Fri, 25 Nov 2016 20:49:58 +0300 Subject: [9] Review request: JDK-8168089, Secondary Launchers (*.exe files) are not generated Message-ID: <9f196b5d-abc1-e0c3-bcff-2b1e96eb25cd@oracle.com> Chris, Please review the changes about secondary launchers: JIRA: https://bugs.openjdk.java.net/browse/JDK-8168089 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8168089/webrev.00/ --Victor From bley at jpro.io Sun Nov 27 19:57:47 2016 From: bley at jpro.io (Tobias Bley) Date: Sun, 27 Nov 2016 20:57:47 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Where can we read more about your HPR renderer? > Am 25.11.2016 um 16:45 schrieb Felix Bembrick : > > Short answer? Maybe. > > But exactly one more word than any from Oracle ;-) > >> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >> >> A very short answer ;) ?. >> >> Do you have any URL? >> >> >> >> >> >>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>> >>> Yes. >>> >>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>> >>>> Hi, >>>> >>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>> >>>> >>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>> >>>>> Thanks Laurent, >>>>> >>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>> >>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>> >>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>> >>>>> Blessings, >>>>> >>>>> Felix >>>>> >>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>> >>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>> >>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>> >>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>> >>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>> >>>>>> Cheers, >>>>>> Laurent >>>>>> >>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>> >>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>> >>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>> >>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>> >>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Tobi >>>>>>> >>>>>>> >>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>> >>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>> >>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>> general. >>>>>>>> >>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>> indeed quite a complex task. >>>>>>>> >>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>> about 2 years. >>>>>>>> >>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>> >>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>> >>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>> can be done with this one node. >>>>>>>> >>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>> >>>>>>>> Enter HPR. >>>>>>>> >>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>> >>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>> following goals and principles: >>>>>>>> >>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>> >>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>> rendering using the new Vulkan API. >>>>>>>> >>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>> >>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>> >>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>> huge performance gains. >>>>>>>> >>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>> easily. >>>>>>>> >>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>> "patch" is probably rather inappropriate. >>>>>>>> >>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>> >>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>> improvements in performance of 10x or more. >>>>>>>> >>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>> >>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>> for a whole new class of applications including games, advanced >>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>> single Canvas node. >>>>>>>> >>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>> >>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>> >>>>>>>> Blessings, >>>>>>>> >>>>>>>> Felix >>>>>>> >>>> >> From felix.bembrick at gmail.com Sun Nov 27 21:57:31 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 28 Nov 2016 08:57:31 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> Message-ID: Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... > On 28 Nov. 2016, at 06:57, Tobias Bley wrote: > > Where can we read more about your HPR renderer? > > > > >> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >> >> Short answer? Maybe. >> >> But exactly one more word than any from Oracle ;-) >> >>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>> >>> A very short answer ;) ?. >>> >>> Do you have any URL? >>> >>> >>> >>> >>> >>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>> >>>> Yes. >>>> >>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>> >>>>> Hi, >>>>> >>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> >>>>> >>>>> >>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>> >>>>>> Thanks Laurent, >>>>>> >>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>> >>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>> >>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>> >>>>>> Blessings, >>>>>> >>>>>> Felix >>>>>> >>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>> >>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>> >>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>> >>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>> >>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>> >>>>>>> Cheers, >>>>>>> Laurent >>>>>>> >>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>> >>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>> >>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>> >>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>> >>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> >>>>>>>> >>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>> >>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>> >>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>> general. >>>>>>>>> >>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>> indeed quite a complex task. >>>>>>>>> >>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>> about 2 years. >>>>>>>>> >>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>> >>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>> >>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>> can be done with this one node. >>>>>>>>> >>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>> >>>>>>>>> Enter HPR. >>>>>>>>> >>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>> >>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>> following goals and principles: >>>>>>>>> >>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>> >>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>> rendering using the new Vulkan API. >>>>>>>>> >>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>> >>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>> >>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>> huge performance gains. >>>>>>>>> >>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>> easily. >>>>>>>>> >>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>> >>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>> >>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>> improvements in performance of 10x or more. >>>>>>>>> >>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>> >>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>> single Canvas node. >>>>>>>>> >>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>> >>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>> >>>>>>>>> Blessings, >>>>>>>>> >>>>>>>>> Felix >>>>>>>> >>>>> >>> > From felix.bembrick at gmail.com Mon Nov 28 05:54:47 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 28 Nov 2016 16:54:47 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> Message-ID: <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> Sorry Gerrit - you did indeed. Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? > On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: > > Well I mentioned before that I'm interested too :) > > Cheers, > > Gerrit > > > Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >> >>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>> >>> Where can we read more about your HPR renderer? >>> >>> >>> >>> >>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>> >>>> Short answer? Maybe. >>>> >>>> But exactly one more word than any from Oracle ;-) >>>> >>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>> >>>>> A very short answer ;) ?. >>>>> >>>>> Do you have any URL? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>> >>>>>> Yes. >>>>>> >>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>> >>>>>>> Best regards, >>>>>>> Tobi >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>> >>>>>>>> Thanks Laurent, >>>>>>>> >>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>> >>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>> >>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>> >>>>>>>> Blessings, >>>>>>>> >>>>>>>> Felix >>>>>>>> >>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>> >>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>> >>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>> >>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>> >>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Laurent >>>>>>>>> >>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>> >>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>> >>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>> >>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>> >>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Tobi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>> >>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>> >>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>> general. >>>>>>>>>>> >>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>> >>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>> about 2 years. >>>>>>>>>>> >>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>> >>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>> >>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>> can be done with this one node. >>>>>>>>>>> >>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>> >>>>>>>>>>> Enter HPR. >>>>>>>>>>> >>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>> >>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>> following goals and principles: >>>>>>>>>>> >>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>> >>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>> >>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>> >>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>> >>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>> huge performance gains. >>>>>>>>>>> >>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>> easily. >>>>>>>>>>> >>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>> >>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>> >>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>> >>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>> >>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>> single Canvas node. >>>>>>>>>>> >>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>> >>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>> >>>>>>>>>>> Blessings, >>>>>>>>>>> >>>>>>>>>>> Felix >>>>>>>>>> >>>>>>> >>>>> >>> From mp at jugs.org Mon Nov 28 07:10:21 2016 From: mp at jugs.org (Michael Paus) Date: Mon, 28 Nov 2016 08:10:21 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> Message-ID: <3e2e620e-ac59-5f2e-4ac3-5003556d49d6@jugs.org> I am interested too although I have only been listening quietly so far due to lack of time. Cheers Michael Am 28.11.16 um 06:54 schrieb Felix Bembrick: > Sorry Gerrit - you did indeed. > > Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? > >> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >> >> Well I mentioned before that I'm interested too :) >> >> Cheers, >> >> Gerrit >> >> >> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>> >>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>> >>>> Where can we read more about your HPR renderer? >>>> >>>> >>>> >>>> >>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>> >>>>> Short answer? Maybe. >>>>> >>>>> But exactly one more word than any from Oracle ;-) >>>>> >>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>> >>>>>> A very short answer ;) ?. >>>>>> >>>>>> Do you have any URL? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>> >>>>>>>>> Thanks Laurent, >>>>>>>>> >>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>> >>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>> >>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>> >>>>>>>>> Blessings, >>>>>>>>> >>>>>>>>> Felix >>>>>>>>> >>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>> >>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>> >>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>> >>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>> >>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Laurent >>>>>>>>>> >>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>> >>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>> >>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>> >>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>> >>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Tobi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>> >>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>> >>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>> general. >>>>>>>>>>>> >>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>> >>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>> about 2 years. >>>>>>>>>>>> >>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>> >>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>> >>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>> >>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>> >>>>>>>>>>>> Enter HPR. >>>>>>>>>>>> >>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>> >>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>> following goals and principles: >>>>>>>>>>>> >>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>> >>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>> >>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>> >>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>> >>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>> huge performance gains. >>>>>>>>>>>> >>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>> easily. >>>>>>>>>>>> >>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>> >>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>> >>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>> >>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>> >>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>> single Canvas node. >>>>>>>>>>>> >>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>> >>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>> >>>>>>>>>>>> Blessings, >>>>>>>>>>>> >>>>>>>>>>>> Felix From felix.bembrick at gmail.com Mon Nov 28 07:51:48 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 28 Nov 2016 18:51:48 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <3e2e620e-ac59-5f2e-4ac3-5003556d49d6@jugs.org> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> <3e2e620e-ac59-5f2e-4ac3-5003556d49d6@jugs.org> Message-ID: <39A46DE5-984D-48A5-AECC-549F73A4E241@gmail.com> Great - good to see interest growing. Especially given that you work for Oracle, right? > On 28 Nov. 2016, at 18:10, Michael Paus wrote: > > I am interested too although I have only been listening quietly so far due to lack of time. > Cheers > Michael > >> Am 28.11.16 um 06:54 schrieb Felix Bembrick: >> Sorry Gerrit - you did indeed. >> >> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >> >>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>> >>> Well I mentioned before that I'm interested too :) >>> >>> Cheers, >>> >>> Gerrit >>> >>> >>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>> >>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>> >>>>> Where can we read more about your HPR renderer? >>>>> >>>>> >>>>> >>>>> >>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>>> >>>>>> Short answer? Maybe. >>>>>> >>>>>> But exactly one more word than any from Oracle ;-) >>>>>> >>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>>> >>>>>>> A very short answer ;) ?. >>>>>>> >>>>>>> Do you have any URL? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Tobi >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>>> >>>>>>>>>> Thanks Laurent, >>>>>>>>>> >>>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>>> >>>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>>> >>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>>> >>>>>>>>>> Blessings, >>>>>>>>>> >>>>>>>>>> Felix >>>>>>>>>> >>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>>> >>>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>>> >>>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>>> >>>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>>> >>>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Laurent >>>>>>>>>>> >>>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>>> >>>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>>> >>>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>>> >>>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>>> >>>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Tobi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>>> >>>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>>> >>>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>>> general. >>>>>>>>>>>>> >>>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>>> >>>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>>> about 2 years. >>>>>>>>>>>>> >>>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>>> >>>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>>> >>>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>>> >>>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>>> >>>>>>>>>>>>> Enter HPR. >>>>>>>>>>>>> >>>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>>> >>>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>>> following goals and principles: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>>> >>>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>>> >>>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>>> >>>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>>> huge performance gains. >>>>>>>>>>>>> >>>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>>> easily. >>>>>>>>>>>>> >>>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>>> >>>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>>> >>>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>>> >>>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>>> >>>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>>> single Canvas node. >>>>>>>>>>>>> >>>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>>> >>>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>>> >>>>>>>>>>>>> Blessings, >>>>>>>>>>>>> >>>>>>>>>>>>> Felix > > From mp at jugs.org Mon Nov 28 08:08:28 2016 From: mp at jugs.org (Michael Paus) Date: Mon, 28 Nov 2016 09:08:28 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <39A46DE5-984D-48A5-AECC-549F73A4E241@gmail.com> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> <3e2e620e-ac59-5f2e-4ac3-5003556d49d6@jugs.org> <39A46DE5-984D-48A5-AECC-549F73A4E241@gmail.com> Message-ID: Am 28.11.16 um 08:51 schrieb Felix Bembrick: > Great - good to see interest growing. > > Especially given that you work for Oracle, right? Sorry, if I have to disappoint you on that but I do not work for Oracle. I run my own little company and are the head of the Java User Group Stuttgart. > >> On 28 Nov. 2016, at 18:10, Michael Paus wrote: >> >> I am interested too although I have only been listening quietly so far due to lack of time. >> Cheers >> Michael >> >>> Am 28.11.16 um 06:54 schrieb Felix Bembrick: >>> Sorry Gerrit - you did indeed. >>> >>> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >>> >>>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>>> >>>> Well I mentioned before that I'm interested too :) >>>> >>>> Cheers, >>>> >>>> Gerrit >>>> >>>> >>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>>> >>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>>> >>>>>> Where can we read more about your HPR renderer? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>>>> >>>>>>> Short answer? Maybe. >>>>>>> >>>>>>> But exactly one more word than any from Oracle ;-) >>>>>>> >>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>>>> >>>>>>>> A very short answer ;) ?. >>>>>>>> >>>>>>>> Do you have any URL? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>>>> >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Tobi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>>>> >>>>>>>>>>> Thanks Laurent, >>>>>>>>>>> >>>>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>>>> >>>>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>>>> >>>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>>>> >>>>>>>>>>> Blessings, >>>>>>>>>>> >>>>>>>>>>> Felix >>>>>>>>>>> >>>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>>>> >>>>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>>>> >>>>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>>>> >>>>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>>>> >>>>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Laurent >>>>>>>>>>>> >>>>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>>>> >>>>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>>>> >>>>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>>>> >>>>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>>>> >>>>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Tobi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>>>> >>>>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>>>> general. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>>>> about 2 years. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Enter HPR. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>>>> following goals and principles: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>>>> huge performance gains. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>>>> easily. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>>>> >>>>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>>>> single Canvas node. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>>>> >>>>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Blessings, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Felix >> From tobi at ultramixer.com Mon Nov 28 08:10:57 2016 From: tobi at ultramixer.com (Tobi) Date: Mon, 28 Nov 2016 09:10:57 +0100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> Message-ID: We should discuss a new rendering pipeline on the openjfx mailing list. It?s not off topic - it?s an important topic for the future of JavaFX. > Am 28.11.2016 um 06:54 schrieb Felix Bembrick : > > Sorry Gerrit - you did indeed. > > Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? > >> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >> >> Well I mentioned before that I'm interested too :) >> >> Cheers, >> >> Gerrit >> >> >> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>> >>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>> >>>> Where can we read more about your HPR renderer? >>>> >>>> >>>> >>>> >>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>> >>>>> Short answer? Maybe. >>>>> >>>>> But exactly one more word than any from Oracle ;-) >>>>> >>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>> >>>>>> A very short answer ;) ?. >>>>>> >>>>>> Do you have any URL? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>> >>>>>>>>> Thanks Laurent, >>>>>>>>> >>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>> >>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>> >>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>> >>>>>>>>> Blessings, >>>>>>>>> >>>>>>>>> Felix >>>>>>>>> >>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>> >>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>> >>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>> >>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>> >>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Laurent >>>>>>>>>> >>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>> >>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>> >>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>> >>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>> >>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Tobi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>> >>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>> >>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>> general. >>>>>>>>>>>> >>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>> >>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>> about 2 years. >>>>>>>>>>>> >>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>> >>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>> >>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>> >>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>> >>>>>>>>>>>> Enter HPR. >>>>>>>>>>>> >>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>> >>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>> following goals and principles: >>>>>>>>>>>> >>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>> >>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>> >>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>> >>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>> >>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>> huge performance gains. >>>>>>>>>>>> >>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>> easily. >>>>>>>>>>>> >>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>> >>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>> >>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>> >>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>> >>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>> single Canvas node. >>>>>>>>>>>> >>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>> >>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>> >>>>>>>>>>>> Blessings, >>>>>>>>>>>> >>>>>>>>>>>> Felix >>>>>>>>>>> >>>>>>>> >>>>>> >>>> From felix.bembrick at gmail.com Mon Nov 28 08:28:32 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 28 Nov 2016 19:28:32 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> <3e2e620e-ac59-5f2e-4ac3-5003556d49d6@jugs.org> <39A46DE5-984D-48A5-AECC-549F73A4E241@gmail.com> Message-ID: <7EC1D2C3-6DCC-4063-AA21-E7C06F95EF1A@gmail.com> No disappointment, no surprises. It was a rhetorical question... > On 28 Nov. 2016, at 19:08, Michael Paus wrote: > >> Am 28.11.16 um 08:51 schrieb Felix Bembrick: >> Great - good to see interest growing. >> >> Especially given that you work for Oracle, right? > Sorry, if I have to disappoint you on that but I do not work for Oracle. > I run my own little company and are the head of the Java User Group Stuttgart. > >> >>> On 28 Nov. 2016, at 18:10, Michael Paus wrote: >>> >>> I am interested too although I have only been listening quietly so far due to lack of time. >>> Cheers >>> Michael >>> >>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick: >>>> Sorry Gerrit - you did indeed. >>>> >>>> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >>>> >>>>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>>>> >>>>> Well I mentioned before that I'm interested too :) >>>>> >>>>> Cheers, >>>>> >>>>> Gerrit >>>>> >>>>> >>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>>>> >>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>>>> >>>>>>> Where can we read more about your HPR renderer? >> Am 28.11.16 um 08:51 schrieb Felix Bembrick: >> >> Great - good to see interest growing. >> >> Especially given that you work for Oracle, right? > Sorry, if I have to disappoint you on that but I do not work for Oracle. > I run my own little company and are the head of the Java User Group Stuttgart. > >> >>> On 28 Nov. 2016, at 18:10, Michael Paus wrote: >>> >>> I am interested too although I have only been listening quietly so far due to lack of time. >>> Cheers >>> Michael >>> >>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick: >>>> Sorry Gerrit - you did indeed. >>>> >>>> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >>>> >>>>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>>>> >>>>> Well I mentioned before that I'm interested too :) >>>>> >>>>> Cheers, >>>>> >>>>> Gerrit >>>>> >>>>> >>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>>>> >>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>>>> >>>>>>> Where can we read more about your HPR renderer? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>>>>> >>>>>>>> Short answer? Maybe. >>>>>>>> >>>>>>>> But exactly one more word than any from Oracle ;-) >>>>>>>> >>>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>>>>> >>>>>>>>> A very short answer ;) ?. >>>>>>>>> >>>>>>>>> Do you have any URL? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>>>>> >>>>>>>>>> Yes. >>>>>>>>>> >>>>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Tobi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>>>>> >>>>>>>>>>>> Thanks Laurent, >>>>>>>>>>>> >>>>>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>>>>> >>>>>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>>>>> >>>>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>>>>> >>>>>>>>>>>> Blessings, >>>>>>>>>>>> >>>>>>>>>>>> Felix >>>>>>>>>>>> >>>>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>>>>> >>>>>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>>>>> >>>>>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>>>>> >>>>>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Laurent >>>>>>>>>>>>> >>>>>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>>>>> >>>>>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Tobi >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>>>>> general. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>>>>> about 2 years. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Enter HPR. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>>>>> following goals and principles: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>>>>> huge performance gains. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>>>>> easily. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>>>>> single Canvas node. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Blessings, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Felix >>> > From felix.bembrick at gmail.com Mon Nov 28 08:29:07 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 28 Nov 2016 19:29:07 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> <3e2e620e-ac59-5f2e-4ac3-5003556d49d6@jugs.org> <39A46DE5-984D-48A5-AECC-549F73A4E241@gmail.com> Message-ID: Agreed. > On 28 Nov. 2016, at 19:08, Michael Paus wrote: > >> Am 28.11.16 um 08:51 schrieb Felix Bembrick: >> Great - good to see interest growing. >> >> Especially given that you work for Oracle, right? > Sorry, if I have to disappoint you on that but I do not work for Oracle. > I run my own little company and are the head of the Java User Group Stuttgart. > >> >>> On 28 Nov. 2016, at 18:10, Michael Paus wrote: >>> >>> I am interested too although I have only been listening quietly so far due to lack of time. >>> Cheers >>> Michael >>> >>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick: >>>> Sorry Gerrit - you did indeed. >>>> >>>> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >>>> >>>>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>>>> >>>>> Well I mentioned before that I'm interested too :) >>>>> >>>>> Cheers, >>>>> >>>>> Gerrit >>>>> >>>>> >>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>>>> >>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>>>> >>>>>>> Where can we read more about your HPR renderer? >> Am 28.11.16 um 08:51 schrieb Felix Bembrick: >> >> Great - good to see interest growing. >> >> Especially given that you work for Oracle, right? > Sorry, if I have to disappoint you on that but I do not work for Oracle. > I run my own little company and are the head of the Java User Group Stuttgart. > >> >>> On 28 Nov. 2016, at 18:10, Michael Paus wrote: >>> >>> I am interested too although I have only been listening quietly so far due to lack of time. >>> Cheers >>> Michael >>> >>>> Am 28.11.16 um 06:54 schrieb Felix Bembrick: >>>> Sorry Gerrit - you did indeed. >>>> >>>> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >>>> >>>>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>>>> >>>>> Well I mentioned before that I'm interested too :) >>>>> >>>>> Cheers, >>>>> >>>>> Gerrit >>>>> >>>>> >>>>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>>>> >>>>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>>>> >>>>>>> Where can we read more about your HPR renderer? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>>>>> >>>>>>>> Short answer? Maybe. >>>>>>>> >>>>>>>> But exactly one more word than any from Oracle ;-) >>>>>>>> >>>>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>>>>> >>>>>>>>> A very short answer ;) ?. >>>>>>>>> >>>>>>>>> Do you have any URL? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>>>>> >>>>>>>>>> Yes. >>>>>>>>>> >>>>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Tobi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>>>>> >>>>>>>>>>>> Thanks Laurent, >>>>>>>>>>>> >>>>>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>>>>> >>>>>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>>>>> >>>>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>>>>> >>>>>>>>>>>> Blessings, >>>>>>>>>>>> >>>>>>>>>>>> Felix >>>>>>>>>>>> >>>>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>>>>> >>>>>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>>>>> >>>>>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>>>>> >>>>>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Laurent >>>>>>>>>>>>> >>>>>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>>>>> >>>>>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Tobi >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>>>>> general. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>>>>> about 2 years. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Enter HPR. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>>>>> following goals and principles: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>>>>> huge performance gains. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>>>>> easily. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>>>>> single Canvas node. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Blessings, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Felix >>> > From felix.bembrick at gmail.com Mon Nov 28 08:33:26 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 28 Nov 2016 19:33:26 +1100 Subject: Optimised, high-performance, multi-threaded rendering pipeline In-Reply-To: References: <927C4200-9200-4198-B6B5-5E68FD43BB84@ultramixer.com> <038006CB-444C-435D-A29A-BE28D7701D7E@gmail.com> <4523dd99-32a9-433a-b3e2-723c913eb064@Spark> <4A6157B6-B229-425E-86A1-F31223B6D6E7@gmail.com> Message-ID: <84A10900-F2B8-4944-A66B-FB799C665E8F@gmail.com> Sorry, the "agreed" comment was meant to be a reply to you Tobi. Pity not everyone "agrees"... > On 28 Nov. 2016, at 19:10, Tobi wrote: > > We should discuss a new rendering pipeline on the openjfx mailing list. It?s not off topic - it?s an important topic for the future of JavaFX. > > >> Am 28.11.2016 um 06:54 schrieb Felix Bembrick : >> >> Sorry Gerrit - you did indeed. >> >> Maybe you'd also like to participate in the offline discussion (especially now that you don't work for Oracle)? >> >>> On 28 Nov. 2016, at 16:07, han.solo at icloud.com wrote: >>> >>> Well I mentioned before that I'm interested too :) >>> >>> Cheers, >>> >>> Gerrit >>> >>> >>> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick : >>>> Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)... >>>> >>>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>>> >>>>> Where can we read more about your HPR renderer? >>>>> >>>>> >>>>> >>>>> >>>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>>> >>>>>> Short answer? Maybe. >>>>>> >>>>>> But exactly one more word than any from Oracle ;-) >>>>>> >>>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>>> >>>>>>> A very short answer ;) ?. >>>>>>> >>>>>>> Do you have any URL? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR with JavaFX? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Tobi >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick : >>>>>>>>>> >>>>>>>>>> Thanks Laurent, >>>>>>>>>> >>>>>>>>>> That's another thing we discovered: using Java itself in the most performant way can help a lot. >>>>>>>>>> >>>>>>>>>> It can be tricky, but profiling can often highlight various patterns of object instantiation that show-up red flags and can lead you directly to regions of the code that can be refactored to be significantly more efficient. >>>>>>>>>> >>>>>>>>>> Also, the often overlooked GC log analysis can lead to similar discoveries and remedies. >>>>>>>>>> >>>>>>>>>> Blessings, >>>>>>>>>> >>>>>>>>>> Felix >>>>>>>>>> >>>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourg?s wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided any both array allocation (byte/int/float pools) and also reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>>> >>>>>>>>>>> This approach is generic and could be applied in other critical places of the rendering pipelines. >>>>>>>>>>> >>>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>>> >>>>>>>>>>> Of course I would be happy to share my experience and work with a tiger team on optimizing JavaFX graphics. >>>>>>>>>>> >>>>>>>>>>> However I would like getting sort of sponsoring for my potential contributions... >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Laurent >>>>>>>>>>> >>>>>>>>>>> Le 11 nov. 2016 11:29, "Tobi" a ?crit : >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the community! >>>>>>>>>>>> >>>>>>>>>>>> I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. >>>>>>>>>>>> >>>>>>>>>>>> Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? >>>>>>>>>>>> >>>>>>>>>>>> So maybe there are other points than multithreading where we can boost the performance? >>>>>>>>>>>> >>>>>>>>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Tobi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick : >>>>>>>>>>>>> >>>>>>>>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>>>>>>>> >>>>>>>>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>>>>>>>> Laurent Bourg?s of MarlinFX, it was suggested that a separate thread be >>>>>>>>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>>>>>>>> general. >>>>>>>>>>>>> >>>>>>>>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>>>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>>>>>>>> indeed quite a complex task. >>>>>>>>>>>>> >>>>>>>>>>>>> But, that's exactly what myself and my colleagues have been working on for >>>>>>>>>>>>> about 2 years. >>>>>>>>>>>>> >>>>>>>>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>>>>>>>> >>>>>>>>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>>>>>>>> disappointed with the performance of the JavaFX scene graph. Many JavaFX >>>>>>>>>>>>> developers have blogged about the need to dramatically minimise the number >>>>>>>>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>>>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>>>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>>>>>>>> >>>>>>>>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and the >>>>>>>>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows what >>>>>>>>>>>>> can be done with this one node. >>>>>>>>>>>>> >>>>>>>>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>>>>>>>> scene graph itself and is designed to make use of multiple nodes and node >>>>>>>>>>>>> types. At the moment, the performance of this scene graph is the Achilles >>>>>>>>>>>>> Heel of JavaFX (or at least one of them). >>>>>>>>>>>>> >>>>>>>>>>>>> Enter HPR. >>>>>>>>>>>>> >>>>>>>>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>>>>>>>> over the years and am astounded by just how sluggish the rendering pipeline >>>>>>>>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>>>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>>>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>>>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>>>>>>>> >>>>>>>>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>>>>>>>> following goals and principles: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>>>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>>>>>>>> >>>>>>>>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>>>>>>>> pipelines (especially Qt which has made some significant advances in this >>>>>>>>>>>>> area in recent years). We also analysed recent examples of multi-threaded >>>>>>>>>>>>> rendering using the new Vulkan API. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. We carefully analysed and determined which parts of the pipeline should >>>>>>>>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>>>>>>>> >>>>>>>>>>>>> 4. For those parts most suited to the CPU, we use the advanced concurrency >>>>>>>>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>>>>>>>> utilising multiple cores & threads in as an efficient manner as possible. >>>>>>>>>>>>> >>>>>>>>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>>>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to some >>>>>>>>>>>>> huge performance gains. >>>>>>>>>>>>> >>>>>>>>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>>>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>>>>>>>> graph in such a way that it lends itself to optimised rendering much more >>>>>>>>>>>>> easily. >>>>>>>>>>>>> >>>>>>>>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>>>>>>>> "patch" is probably rather inappropriate. >>>>>>>>>>>>> >>>>>>>>>>>>> The end result is that we now have a fully-functional prototype of HPR and, >>>>>>>>>>>>> already, we are seeing very significant performance improvements. >>>>>>>>>>>>> >>>>>>>>>>>>> At the minimum, scene graph rendering performance has improved by 500% and, >>>>>>>>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>>>>>>>> improvements in performance of 10x or more. >>>>>>>>>>>>> >>>>>>>>>>>>> And... we are only just *starting* with the performance optimisation phase. >>>>>>>>>>>>> >>>>>>>>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>>>>>>>> JavaFX scene graph and the animation/transition infrastructure to be used >>>>>>>>>>>>> for a whole new class of applications including games, advanced >>>>>>>>>>>>> visualisations etc., without having to rely on imperative programming of a >>>>>>>>>>>>> single Canvas node. >>>>>>>>>>>>> >>>>>>>>>>>>> I believe that HPR, along with tremendous recent developments like JPro and >>>>>>>>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>>>>>>>> position JavaFX to be the best graphics toolkit of any kind in any language >>>>>>>>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>>>>>>>> >>>>>>>>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>>>>>>>> >>>>>>>>>>>>> Blessings, >>>>>>>>>>>>> >>>>>>>>>>>>> Felix >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> > From Rony.Flatscher at wu.ac.at Mon Nov 28 11:55:46 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 28 Nov 2016 12:55:46 +0100 Subject: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ... Message-ID: <22d47b0c-67f3-361e-1d15-c8c50d1b4c75@wu.ac.at> Quite a while ago I asked about javax.script deployments in JavaFX (i.e. when instrumentating javax.script languages when FXMLLoader processes FXML files) without getting any answer or pointer so far. So I am wondering whether there is another mailing group (other than this one) where questions like this can be asked *and* answers can be expected! ;) The same question goes with SceneBuilder, for which I have not found more appropriate e-mail lists. The background for both of these questions is simple: JavaFX is a great infrastructure. All javax.script languages could take much better advantage of it, if there was more specific support for them. (E.g. allowing different javax.script languages to be deployed off the same FXML document, enhancing SceneBuilder support for javax.script languages like jython, ooRexx, even Nashorn, etc.) ---rony From dalibor.topic at oracle.com Mon Nov 28 12:43:01 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 28 Nov 2016 13:43:01 +0100 Subject: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ... In-Reply-To: <22d47b0c-67f3-361e-1d15-c8c50d1b4c75@wu.ac.at> References: <22d47b0c-67f3-361e-1d15-c8c50d1b4c75@wu.ac.at> Message-ID: On 28.11.2016 12:55, Rony G. Flatscher wrote: > So I am wondering whether there is another mailing group (other than this one) where questions like > this can be asked There is a JavaFX forum at https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later within the Oracle Community. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Rony.Flatscher at wu.ac.at Mon Nov 28 13:18:08 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 28 Nov 2016 14:18:08 +0100 Subject: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ... In-Reply-To: References: <22d47b0c-67f3-361e-1d15-c8c50d1b4c75@wu.ac.at> Message-ID: <8ff0cbb4-e200-9c8e-54a3-cc045ca8ed36@wu.ac.at> Dalibor, thank you very much for this link, just posted a comparable question there. Poking around the questions (many unanswered) posted there, my hopes are not very high to get an answer (maybe I am too pessimistic here)... Again, thank you! ---rony On 28.11.2016 13:43, dalibor topic wrote: > > > On 28.11.2016 12:55, Rony G. Flatscher wrote: >> So I am wondering whether there is another mailing group (other than this one) where questions like >> this can be asked > > There is a JavaFX forum at > https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later within the Oracle > Community. > > cheers, > dalibor topic From victor.drozdov at oracle.com Mon Nov 28 17:12:04 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Mon, 28 Nov 2016 20:12:04 +0300 Subject: [9] Review request: JDK-8166281: -Bidentifier="" not working for modules in MAC Message-ID: Chris, Please review the changes about fixing the -Bidentifier for backward compatibility: JIRA: https://bugs.openjdk.java.net/browse/JDK-8166281 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8166281/webrev.00/ --Victor From chris.bensen at oracle.com Mon Nov 28 17:50:44 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 28 Nov 2016 09:50:44 -0800 Subject: [9] Review request: JDK-8170122 Packager Tests Message-ID: Victor, Please review these Java Packager examples: JIRA: https://bugs.openjdk.java.net/browse/JDK-8170122 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170122/webrev.01/ Chris From chris.bensen at oracle.com Mon Nov 28 18:46:33 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 28 Nov 2016 10:46:33 -0800 Subject: [9] Review request: JDK-8170295 fx:jvmarg is not set Message-ID: <65F11F56-6B7E-4156-9802-96980F5CA42A@oracle.com> Victor, Please review this change to fix setting of jvmarg options: JIRA: https://bugs.openjdk.java.net/browse/JDK-8170295 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170295/webrev.00/ Chris From bourges.laurent at gmail.com Mon Nov 28 21:58:14 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 28 Nov 2016 22:58:14 +0100 Subject: Follow-on bugs In-Reply-To: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> Message-ID: Jim, There is one thing I think you should look at, though, and I wasn't sure if > I should file a bug. If you've downloaded the Rasterization verifier from > the old JBS bug for non-AA rendering, try running it with the 4quads mode > (-quad argument I think). It looks like it averages slightly more failures > on Marlin than jpisces or npisces. (3 bad pixels per shape rather than 2 - > or 4 vs. 3 - I forget the exact numbers). This may simply be a difference > in the DEC_INC_BND settings and an easy fix. File a bug if you find > something to fix... > I made tests related to nonAA quality and the related quad decimation thresholds: The quad decrement threshold seem a bit too high => lowering to 0.5 subpixel leads to 2.07 error: OpenPisces: bad paths (78759/100000 == 78,76%, 177046 bad pixels (avg = 2,25), 6524 warnings (avg = 0,08) MarlinFX: bad paths (90332/100000 == 90,33%, 288202 bad pixels (avg = 3,19), 6702 warnings (avg = 0,07) MarlinFX with DEC_BND=0.5: bad paths (77342/100000 == 77,34%, 164702 bad pixels (avg = 2,13), 6649 warnings (avg = 0,09) So the trivial fix consist in lowering the threshold. HOWEVER, it led me having a look again at the algorithmic approach: The (Sun) paper (Lien 87) describes this approach (AFD) to draw curves pixels by pixels so the original thresholds were defined to 1 / 0.5 pixels and it indicates that this algorithm generates at least 1 point per pixel ... so is not related to any error bound nor really the good approach to minimize the number of segments when the curve is "flat". Moreover, this test performs path fills (no stroke) so I am asking several questions about the algorithmic approach: - AFD thresholds are in fact related to delta X/Y or speed and are ensuring small displacements (subpixel) unrelated to any error (ROC ?) between the segment and the curve => it will generate lots more segments than needed except when the curve has cups or inflexions ... - subdividing curves may be a more appropriate approach (agg, QT...) as there are several flatness tests (intermediate point distance like in ShapeSpanIterator.c) to ensure the curve is under-control ie within the tolerance - in Stroker, the curve is subdivided at cups, inflexion points, roots to have monotonic cuves but in the case of path fills, the curve is directly processed by the Renderer: maybe we should first subdivide the curves at those extrema and then use the current approach to improve the affinity at these special points. Finally the curve segments are generated with the floating-point maths so the pixel accuracy is also strongly related to rounding points on the grid (at pixel centers), so this implies to have small tolerance to compensate rounding issues. Jim, do you have advices on: - how to improve both curve accuracy but also minimize the number of generated segments ? which algorithm ? - which flatness test has your recommendations ? - do you know an adaptive AFD variant that determine the step size according to radius of curvature ? (like in Graphics Gem I: p594 Wallis Tutorial on Forward Differencing) Laurent From james.graham at oracle.com Tue Nov 29 00:09:31 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 28 Nov 2016 16:09:31 -0800 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> Message-ID: <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> Hi Laurent, I think you've looked into the issues of flatness and how inflection points affect it about as much as I have at this point. I'm not sure that sub-dividing at min/max values helps filling, but a way to subdivide at inflection points might improve the flattening algorithm. It's worth a try. I believe the original AFD was intended to be used in the inner loop to render each pixel rather than as a flattening metric the way we are using it. Another concept might be to have the scanline converter that currently only deals with lines support quads and cubics as well so we don't have to flatten them (though subdividing to avoid extreme rates of change in the step size might still be called for). It would complicate the code that increments the cur_x on each sample line, but it would reduce the number of segments we'd have to store. Also, we might want to do subdivision at min/max of Y values in that case so that the Y values are monotonic. With respect to float/double, I have another bug somewhere where we have a large inaccuracy for a very large circle that intersects the viewing area along only a very tiny portion. The errors get especially bad with dashing because we iterate each dash using an incrementally relative sub-divide rather than returning always to the original curve to sub-divide from t1-to-t2. I'll look it up and send you a pointer so you can see how Marlin does with those paths. I believe that I briefly modified the Pisces Dasher to simply use doubles and the problem went away, but I didn't do any performance analysis and the newly accurate dashes no longer matched the still-float-based fills so more work was needed. Modern processors tend to deal with double precision natively and so other than storage considerations double calculations are often as fast or sometimes faster than float (because of not needing to be cast back to 32-bit float when the FPU always produces 64-bit double answers)... ...jim On 11/28/16 1:58 PM, Laurent Bourg?s wrote: > Jim, > > There is one thing I think you should look at, though, and I wasn't sure if >> I should file a bug. If you've downloaded the Rasterization verifier from >> the old JBS bug for non-AA rendering, try running it with the 4quads mode >> (-quad argument I think). It looks like it averages slightly more failures >> on Marlin than jpisces or npisces. (3 bad pixels per shape rather than 2 - >> or 4 vs. 3 - I forget the exact numbers). This may simply be a difference >> in the DEC_INC_BND settings and an easy fix. File a bug if you find >> something to fix... >> > > > I made tests related to nonAA quality and the related quad decimation > thresholds: > The quad decrement threshold seem a bit too high => lowering to 0.5 > subpixel leads to 2.07 error: > > OpenPisces: > bad paths (78759/100000 == 78,76%, 177046 bad pixels (avg = 2,25), 6524 > warnings (avg = 0,08) > > MarlinFX: > bad paths (90332/100000 == 90,33%, 288202 bad pixels (avg = 3,19), 6702 > warnings (avg = 0,07) > > MarlinFX with DEC_BND=0.5: > bad paths (77342/100000 == 77,34%, 164702 bad pixels (avg = 2,13), 6649 > warnings (avg = 0,09) > > So the trivial fix consist in lowering the threshold. > > HOWEVER, it led me having a look again at the algorithmic approach: > The (Sun) paper (Lien 87) describes this approach (AFD) to draw curves > pixels by pixels so the original thresholds were defined to 1 / 0.5 pixels > and it indicates that this algorithm generates at least 1 point per pixel > ... so is not related to any error bound nor really the good approach to > minimize the number of segments when the curve is "flat". > > Moreover, this test performs path fills (no stroke) so I am asking several > questions about the algorithmic approach: > - AFD thresholds are in fact related to delta X/Y or speed and are ensuring > small displacements (subpixel) unrelated to any error (ROC ?) between the > segment and the curve => it will generate lots more segments than needed > except when the curve has cups or inflexions ... > - subdividing curves may be a more appropriate approach (agg, QT...) as > there are several flatness tests (intermediate point distance like in > ShapeSpanIterator.c) to ensure the curve is under-control ie within the > tolerance > - in Stroker, the curve is subdivided at cups, inflexion points, roots to > have monotonic cuves but in the case of path fills, the curve is directly > processed by the Renderer: maybe we should first subdivide the curves at > those extrema and then use the current approach to improve the affinity at > these special points. > > Finally the curve segments are generated with the floating-point maths so > the pixel accuracy is also strongly related to rounding points on the grid > (at pixel centers), so this implies to have small tolerance to compensate > rounding issues. > > Jim, do you have advices on: > - how to improve both curve accuracy but also minimize the number of > generated segments ? which algorithm ? > - which flatness test has your recommendations ? > - do you know an adaptive AFD variant that determine the step size > according to radius of curvature ? (like in Graphics Gem I: p594 Wallis > Tutorial on Forward Differencing) > > Laurent > From chien.yang at oracle.com Tue Nov 29 07:26:47 2016 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 28 Nov 2016 23:26:47 -0800 Subject: [9] Code Review Request For 8170421: Ensemble8 black flash at startup on b145+ Message-ID: <583D2DB7.3000608@oracle.com> Jim or Kevin, Please review this simple fix posted in the JIRA: https://bugs.openjdk.java.net/browse/JDK-8170421 Thanks, - Chien From mp at jugs.org Tue Nov 29 07:35:07 2016 From: mp at jugs.org (Michael Paus) Date: Tue, 29 Nov 2016 08:35:07 +0100 Subject: Follow-on bugs In-Reply-To: <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> Message-ID: <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Am 29.11.16 um 01:09 schrieb Jim Graham: > > With respect to float/double, I have another bug somewhere where we > have a large inaccuracy for a very large circle that intersects the > viewing area along only a very tiny portion. The errors get > especially bad with dashing because we iterate each dash using an > incrementally relative sub-divide rather than returning always to the > original curve to sub-divide from t1-to-t2. I'll look it up and send > you a pointer so you can see how Marlin does with those paths. I > believe that I briefly modified the Pisces Dasher to simply use > doubles and the problem went away, but I didn't do any performance > analysis and the newly accurate dashes no longer matched the > still-float-based fills so more work was needed. Modern processors > tend to deal with double precision natively and so other than storage > considerations double calculations are often as fast or sometimes > faster than float (because of not needing to be cast back to 32-bit > float when the FPU always produces 64-bit double answers)... I can help you out here because I have reported these bugs. The references are https://bugs.openjdk.java.net/browse/JDK-8160599 https://bugs.openjdk.java.net/browse/JDK-8160600 I also think that using doubles instead of floats would make things much more accurate especially as the user actually can expect that because the JavaFX API also uses doubles and it is not clear to the user that this is currently reduced internally to float. Michael From bourges.laurent at gmail.com Tue Nov 29 18:29:17 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 29 Nov 2016 19:29:17 +0100 Subject: Follow-on bugs In-Reply-To: <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: Hi, For large curves, I would recommend using a first step to subdivide the curve into smaller ones (1024 pixels as described in Lien paper) to ensure the AFD algorithm preserves enough accuracy with float values (first) in the Dasher. Basic recursive subdivision at halves with a large flatness tolerance would do the job... this initial step could also subdivide at cups, inflexion and roots for fills ? Moreover, it could help a basic clipper based on simple hulls (all control points) to reject curve portions out of the top, bottom and maybe right and left parts (tricky as interior rules are based on left to right intersections...) What are good curve length estimators ? Help is welcome as usual and will have a look to the test classes asap. PS: anyway I will later try using doubles instead of floats in Marlin, but it will time consuming, so let's postpone such task. Cheers, Laurent Le 29 nov. 2016 08:37, "Michael Paus" a ?crit : > > Am 29.11.16 um 01:09 schrieb Jim Graham: > >> >> With respect to float/double, I have another bug somewhere where we have a large inaccuracy for a very large circle that intersects the viewing area along only a very tiny portion. The errors get especially bad with dashing because we iterate each dash using an incrementally relative sub-divide rather than returning always to the original curve to sub-divide from t1-to-t2. I'll look it up and send you a pointer so you can see how Marlin does with those paths. I believe that I briefly modified the Pisces Dasher to simply use doubles and the problem went away, but I didn't do any performance analysis and the newly accurate dashes no longer matched the still-float-based fills so more work was needed. Modern processors tend to deal with double precision natively and so other than storage considerations double calculations are often as fast or sometimes faster than float (because of not needing to be cast back to 32-bit float when the FPU always produces 64-bit double answers)... > > I can help you out here because I have reported these bugs. The references are > > https://bugs.openjdk.java.net/browse/JDK-8160599 > https://bugs.openjdk.java.net/browse/JDK-8160600 > > I also think that using doubles instead of floats would make things much more accurate > especially as the user actually can expect that because the JavaFX API also uses doubles > and it is not clear to the user that this is currently reduced internally to float. > > Michael > From bourges.laurent at gmail.com Tue Nov 29 22:45:03 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 29 Nov 2016 23:45:03 +0100 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: Hi again, As I wanted to use double precision for long, I ported main marlinFX classes using a tricky sed scripts... fixed the 'D' pipeline and it seems already working well. The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark (webview) seems the same as the hot spot is in scanline processing + coverage / mask processing, not in the dasher or stroker parts. This first prototype is promising and it only took me few hours... However, subdiving large curves is still an interesting option to preserve quality / accuracy even with double precision as mentioned in my previous email. Laurent > PS: anyway I will later try using doubles instead of floats in Marlin, but it will time consuming, so let's postpone such task. From arunprasad.rajkumar at oracle.com Wed Nov 30 14:03:52 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 30 Nov 2016 19:33:52 +0530 Subject: [webkit] [9] Review request for 8170450: Crash while loading wordpress.com in HiDPI / Retina display Message-ID: <4D409116-940B-4EA8-A021-FBE0FA57AAC1@oracle.com> Hello Kevin, Guru, Murali, Please review the fix for JDK-8170450 . Analysis: While applying a filter, WebCore get's ImageData from ImageDataJava using getPremultipliedImageData method. Our current implementation doesn't considers resolutionScale/pixelScale while returning the data, due to this, unscaled image data is returned to WebCore which leads to crash while accessing. Solution: Similar other WebKit implementations(Apple, GTK), we must scale the given rectangle according the resolutionScale. Fix: http://cr.openjdk.java.net/~arajkumar/8170450/webrev [1] https://wordpress.com/start/design-type-with-store Thanks, Arun From semyon.sadetsky at oracle.com Wed Nov 30 14:23:56 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 30 Nov 2016 17:23:56 +0300 Subject: [9] Review request for 8151170: WINDOW_MODAL dialog does not popup when restoring iconified owner window, which causes application freeze Message-ID: <65a825a9-cc28-4e04-2d55-bf73311f3514@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8151170 webrev: http://cr.openjdk.java.net/~ssadetsky/8151170/webrev.00/ Win32 API ::GetWindowRect() call returns fake -32000,-32000 location for iconified window. Solution: skip WM_MOVE if window iconified. --Semyon From andrey.rusakov at oracle.com Wed Nov 30 15:58:15 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Wed, 30 Nov 2016 18:58:15 +0300 Subject: JDK-8169649 Review request In-Reply-To: References: Message-ID: <000a9d8d-67a4-4bb0-4717-dc5d6d3c2f1a@oracle.com> Hello, everyone. Please have a look at my review request for new small test: Jira issue: https://bugs.openjdk.java.net/browse/JDK-8169649 Webrev: http://cr.openjdk.java.net/~arusakov/8169649/webrev.00/ Thanks in advance. From bourges.laurent at gmail.com Wed Nov 30 22:12:22 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 30 Nov 2016 23:12:22 +0100 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: Jim, As announced yesterday night, I made a new 'Double' (alias D) pipeline for marlinFX with 2 webrevs: - cmp that compares the D pipeline vs the float pipeline: http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/ - raw that makes no comparison to be easily applicable as a patch: http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/ As explained, I duplicated the complete pipeline (including MarlinRasterizer) so both can be used for comparisons. To enable the D pipeline, just add -Dprism.marlin.double=true else the float pipeline will be used ! I left the conv.sh script that makes the 90% of the class conversions. It is very preliminary as I doubt we will keep two pipelines (for maintenance reasons) and here my test results: - DemoFX (stars / sierpinski) / GuiMark performance are so close that I can not really see any real difference on my linux with intel 7-4800 ; maybe other cpu may have more impact with double vs float but the floating-point computations are representing a minor part of the shape rendering (dasher, stroker, curve interpolation in Renderer) Quality: - Dasher issue with large shapes: all issues are fixed with marlinFX-D (rect, circle) - TestNonAARasterization: the errors seem are more important (poly, quad, cubic) so there may be either a bug in the test (Path2D comparisons) or an important issue in the D pipeline as also polygons are affected I wanted to present you this work to get your early feedback and mention the issues with TestNonAARasterization that will require some work to understand clearly what's happening ! Cheers, Laurent As I wanted to use double precision for long, I ported main marlinFX > classes using a tricky sed scripts... fixed the 'D' pipeline and it seems > already working well. > > The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark > (webview) seems the same as the hot spot is in scanline processing + > coverage / mask processing, not in the dasher or stroker parts. > > This first prototype is promising and it only took me few hours... > > However, subdiving large curves is still an interesting option to preserve > quality / accuracy even with double precision as mentioned in my previous > email. > From bourges.laurent at gmail.com Wed Nov 30 22:41:56 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 30 Nov 2016 23:41:56 +0100 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: Jim, I found the bug in RendererNoAA caused by a 'bad' regexp match: 0x7fffffff was modified to 0x7Dffffff ! so there is no more regression in TestNonAARasterization ! Laurent FYI, here is the diff of the correction (over the previous big patches): < +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java 2016-11-30 22:48:51.710420442 +0100 --- > +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java 2016-11-30 23:35:42.879588649 +0100 2276,2277c2276,2277 < + private static final int ALL_BUT_LSB = 0xfffffffe; < + private static final int ERR_STEP_MAX = 0x7Dffffff; // = 2^31 - 1 --- > + private static final int ALL_BUT_LSB = 0xFFFFFFFe; > + private static final int ERR_STEP_MAX = 0x7FFFFFFF; // = 2^31 - 1 2675,2676c2675,2676 < + // = fixed_floor(x1_fixed + 0x7Dffffff) < + // and error = fixed_fract(x1_fixed + 0x7Dffffff) --- > + // = fixed_floor(x1_fixed + 0x7FFFFFFF) > + // and error = fixed_fract(x1_fixed + 0x7FFFFFFF) 2681c2681 < + + 0x7DffffffL; --- > + + 0x7FFFFFFFL; < +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java 2016-11-30 22:48:52.662420517 +0100 --- > +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java 2016-11-30 23:35:43.835587936 +0100 4147,4148c4147,4148 < + private static final int ALL_BUT_LSB = 0xfffffffe; < + private static final int ERR_STEP_MAX = 0x7Dffffff; // = 2^31 - 1 --- > + private static final int ALL_BUT_LSB = 0xFFFFFFFe; > + private static final int ERR_STEP_MAX = 0x7FFFFFFF; // = 2^31 - 1 4537,4538c4537,4538 < + // = fixed_floor(x1_fixed + 0x7Dffffff) < + // and error = fixed_fract(x1_fixed + 0x7Dffffff) --- > + // = fixed_floor(x1_fixed + 0x7FFFFFFF) > + // and error = fixed_fract(x1_fixed + 0x7FFFFFFF) 4543c4543 < + + 0x7DffffffL; --- > + + 0x7FFFFFFFL; 2016-11-30 23:12 GMT+01:00 Laurent Bourg?s : > Jim, > > As announced yesterday night, I made a new 'Double' (alias D) pipeline for > marlinFX with 2 webrevs: > - cmp that compares the D pipeline vs the float pipeline: > http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/ > - raw that makes no comparison to be easily applicable as a patch: > http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/ > > As explained, I duplicated the complete pipeline (including > MarlinRasterizer) so both can be used for comparisons. > To enable the D pipeline, just add -Dprism.marlin.double=true else the > float pipeline will be used ! > > I left the conv.sh script that makes the 90% of the class conversions. > > > It is very preliminary as I doubt we will keep two pipelines (for > maintenance reasons) and here my test results: > - DemoFX (stars / sierpinski) / GuiMark performance are so close that I > can not really see any real difference on my linux with intel 7-4800 ; > maybe other cpu may have more impact with double vs float but the > floating-point computations are representing a minor part of the shape > rendering (dasher, stroker, curve interpolation in Renderer) > > Quality: > - Dasher issue with large shapes: all issues are fixed with marlinFX-D > (rect, circle) > - TestNonAARasterization: the errors seem are more important (poly, quad, > cubic) so there may be either a bug in the test (Path2D comparisons) or an > important issue in the D pipeline as also polygons are affected > > I wanted to present you this work to get your early feedback and mention > the issues with TestNonAARasterization that will require some work to > understand clearly what's happening ! > > Cheers, > Laurent > > As I wanted to use double precision for long, I ported main marlinFX >> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems >> already working well. >> >> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark >> (webview) seems the same as the hot spot is in scanline processing + >> coverage / mask processing, not in the dasher or stroker parts. >> >> This first prototype is promising and it only took me few hours... >> >> However, subdiving large curves is still an interesting option to >> preserve quality / accuracy even with double precision as mentioned in my >> previous email. >> > From james.graham at oracle.com Wed Nov 30 23:18:43 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 30 Nov 2016 15:18:43 -0800 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: <8c21a4e1-af45-bcca-eb57-907ef381461d@oracle.com> One thing that might cause a problem is that the script modified ERR_STEP_MAX because it had 7f, but it was 0x7f, not 1.7f. Some other constants might be affected as well... ...jim On 11/30/16 2:12 PM, Laurent Bourg?s wrote: > - TestNonAARasterization: the errors seem are more important (poly, quad, cubic) so there may be either a bug in the > test (Path2D comparisons) or an important issue in the D pipeline as also polygons are affected > > I wanted to present you this work to get your early feedback and mention the issues with TestNonAARasterization that > will require some work to understand clearly what's happening !