From jeffhain at rocketmail.com Sat Aug 1 17:38:48 2015 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sat, 1 Aug 2015 17:38:48 +0000 (UTC) Subject: Fwd: no Point2D.setLocation(x,y)? In-Reply-To: References: Message-ID: <1202244909.251320.1438450728886.JavaMail.yahoo@mail.yahoo.com> >Math.sqrt(a * a + b * b) could be replaced with Math.hypot(a,b) hypot is typically much slower than the "naive" computation. Instead of trying to make all the code handle huge or tiny valuesas well as it could, which would make it complicated, slow and brittle,and would not necessarily make sense for graphic stuffs (x * x overflowsnear x = 1e154ish, which should be well out of the frustum), what can be done is checking that values are "reasonable" whenthey enter the program, and that the program doesn't generateproblematic values by itself from reasonable ones. -Jeff From vadim.pakhnushev at oracle.com Mon Aug 3 10:55:06 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 3 Aug 2015 13:55:06 +0300 Subject: [9] Review request for 8130458: Memory leak in bind/unbind of [Primitive]PropertyBase Message-ID: <55BF488A.1020609@oracle.com> Chien, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8130458 http://cr.openjdk.java.net/~vadim/8130458/webrev.00/ Thanks, Vadim From tobi at ultramixer.com Mon Aug 3 13:13:22 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 3 Aug 2015 15:13:22 +0200 Subject: Loading Helvetica Neue Light font? Message-ID: <59B15130-F270-4F1D-8870-8BDAE2A5E76E@ultramixer.com> Hi, does anybody know how to use or load the ?Helvetica Neue Light? font in JavaFX? Font font = Font.font("Helvetica Neue", FontWeight.EXTRA_LIGHT,FontPosture.REGULAR, 16.0); => gives me the medium style font: font = Font[name=Helvetica Neue Medium, family=Helvetica Neue, style=Medium, size=16.0] Regards, Tobi From David.Hill at Oracle.com Mon Aug 3 13:25:01 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 03 Aug 2015 09:25:01 -0400 Subject: Loading Helvetica Neue Light font? In-Reply-To: <59B15130-F270-4F1D-8870-8BDAE2A5E76E@ultramixer.com> References: <59B15130-F270-4F1D-8870-8BDAE2A5E76E@ultramixer.com> Message-ID: <55BF6BAD.6010300@Oracle.com> On 8/3/15, 9:13 AM, Tobias Bley wrote: > Hi, > > does anybody know how to use or load the ?Helvetica Neue Light? font in JavaFX? > > Font font = Font.font("Helvetica Neue", FontWeight.EXTRA_LIGHT,FontPosture.REGULAR, 16.0); > > => gives me the medium style font: > > font = Font[name=Helvetica Neue Medium, family=Helvetica Neue, style=Medium, size=16.0] > > Regards, > Tobi > I wrote this wiki page up a while back, while trying to understand fonts .... :-) https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup A lot of fonts depend on your platform too, which you did not mention. Adding -Dprism.debugfonts=true can give some good hints. If you have suggestions to add to the page let me know. -- 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 tbee at tbee.org Mon Aug 3 14:10:29 2015 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 3 Aug 2015 16:10:29 +0200 Subject: RejectedExecutionException Message-ID: <55BF7655.9070200@tbee.org> Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell me with this exception? java.util.concurrent.RejectedExecutionException: Task com.sun.javafx.tk.quantum.PaintRenderJob at 33cf88 rejected from com.sun.javafx.tk.quantum.QuantumRenderer at 1133212[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 30] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) at com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) at com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown Source) 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$145(WinApplication.java:101) at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) From herve.girod at gmail.com Mon Aug 3 16:13:45 2015 From: herve.girod at gmail.com (Herve Girod) Date: Mon, 3 Aug 2015 18:13:45 +0200 Subject: RejectedExecutionException In-Reply-To: <55BF7655.9070200@tbee.org> References: <55BF7655.9070200@tbee.org> Message-ID: I often have this exception when I interrupt Unit tests forcefully in NetBeans if the JavaFX platform has been started in the Unit Tests 2015-08-03 16:10 GMT+02:00 Tom Eugelink : > Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell > me with this exception? > > java.util.concurrent.RejectedExecutionException: Task > com.sun.javafx.tk.quantum.PaintRenderJob at 33cf88 rejected from > com.sun.javafx.tk.quantum.QuantumRenderer at 1133212[Terminated, pool size = > 0, active threads = 0, queued tasks = 0, completed tasks = 30] > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) > at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) > at > com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) > at > com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) > at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) > at > com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) > at > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) > at > com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown > Source) > 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$145(WinApplication.java:101) > at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > From tbee at tbee.org Mon Aug 3 17:01:53 2015 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 3 Aug 2015 19:01:53 +0200 Subject: RejectedExecutionException In-Reply-To: References: <55BF7655.9070200@tbee.org> Message-ID: <55BF9E81.3070604@tbee.org> Yes, it happens during unit testing (TestFX) but only with this skin. I have a hundred of other tests on a dozen controls that do not throw any exception. On 3-8-2015 18:13, Herve Girod wrote: > I often have this exception when I interrupt Unit tests forcefully in NetBeans if the JavaFX platform has been started in the Unit Tests > > 2015-08-03 16:10 GMT+02:00 Tom Eugelink >: > > Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell me with this exception? > > java.util.concurrent.RejectedExecutionException: Task com.sun.javafx.tk.quantum.PaintRenderJob at 33cf88 rejected from com.sun.javafx.tk.quantum.QuantumRenderer at 1133212[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 30] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) > at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) > at com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) > at com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) > at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) > at com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) > at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) > at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown Source) > 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$145(WinApplication.java:101) > at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > > From David.Hill at Oracle.com Mon Aug 3 20:10:28 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 03 Aug 2015 16:10:28 -0400 Subject: after sanity testing - repo is unlocked. Message-ID: <55BFCAB4.1080100@Oracle.com> (Filling in for Kevin). No new issues were found so we are back open for business. Dave -- 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 vadim.pakhnushev at oracle.com Tue Aug 4 09:53:13 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 4 Aug 2015 12:53:13 +0300 Subject: [9] post-commit notification for 8132906: ReadOnly*Wrapper.ReadOnlyPropertyImpl could use ReadOnly*PropertyBase Message-ID: <55C08B89.9090400@oracle.com> Hello, https://bugs.openjdk.java.net/browse/JDK-8132906 Changeset: f06e176e6142 Author: vadim Date: 2015-08-04 12:49 +0300 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/f06e176e6142 Thanks, Vadim From vadim.pakhnushev at oracle.com Tue Aug 4 11:35:03 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 4 Aug 2015 14:35:03 +0300 Subject: [9] Review request for 8089557: bindBidirection works for ReadOnly*Wrapper incorrectly Message-ID: <55C0A367.3070201@oracle.com> Chien, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8089557 http://cr.openjdk.java.net/~vadim/8089557/webrev.00/ Thanks, Vadim From mike at plan99.net Tue Aug 4 12:43:19 2015 From: mike at plan99.net (Mike Hearn) Date: Tue, 4 Aug 2015 14:43:19 +0200 Subject: RejectedExecutionException In-Reply-To: <55BF7655.9070200@tbee.org> References: <55BF7655.9070200@tbee.org> Message-ID: Race free shutdown in multi-threaded programs is always very hard. At Google some programs and libraries simply didn't support it: for servers, the cost in terms of bugs and extra code was deemed to outweigh the benefits, so the only "supported" way for a process to end was for it to be killed. JavaFX does not have that luxury. It must be able to shut down cleanly without races. In this case, the message is probably harmless: who cares if a render job doesn't complete if you're busy tearing down process state? So perhaps Quantum should just set a custom reject handler that ignores the issue instead of throwing. On Mon, Aug 3, 2015 at 4:10 PM, Tom Eugelink wrote: > Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell > me with this exception? > > java.util.concurrent.RejectedExecutionException: Task > com.sun.javafx.tk.quantum.PaintRenderJob at 33cf88 rejected from > com.sun.javafx.tk.quantum.QuantumRenderer at 1133212[Terminated, pool size = > 0, active threads = 0, queued tasks = 0, completed tasks = 30] > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) > at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) > at > com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) > at > com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) > at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) > at > com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) > at > com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) > at > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) > at > com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown > Source) > 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$145(WinApplication.java:101) > at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:745) > From swpalmer at gmail.com Tue Aug 4 17:26:06 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 4 Aug 2015 13:26:06 -0400 Subject: Camera Access Message-ID: The issue is: https://bugs.openjdk.java.net/browse/JDK-8090438 A target release has not been set. But I really hope it could make it into 9.0. Has there been any further discussion on this? Regards, Scott From david.dehaven at oracle.com Tue Aug 4 22:56:56 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 4 Aug 2015 15:56:56 -0700 Subject: MediaView fails to play HLS video encoded with Main Profile? In-Reply-To: <55A6AF33.1040401@gmail.com> References: <55A6AF33.1040401@gmail.com> Message-ID: <2A48FAA3-3113-44BE-B6C3-827C2BBB140E@oracle.com> > I'm trying to play an HLS file with mediaview and it is failing with a "Media unsupported message", I have been doing some tests with other HLS files and the only difference I've found is the Profile used. > > The one that plays says (according to MediaInfo) "AVC Baseline at L2.1 - 1 Ref Frames", the one that fails says "AVC Main at L3.1 1 - CABAC/ 6 Ref Frames". > > Is there anything I can do (other than reencode, not possible) to play it? What platform? On Mac, it should play any flavor that QuickTime Player can since it uses AVFoundation. -DrD- From tbee at tbee.org Wed Aug 5 07:40:57 2015 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 5 Aug 2015 09:40:57 +0200 Subject: RejectedExecutionException In-Reply-To: References: <55BF7655.9070200@tbee.org> Message-ID: <55C1BE09.9080507@tbee.org> Indeed, this exception put me on the wrong track, trying to figure out why the test was failing based on the exception, while I was "just" asserting the wrong property. I now also understand what it is trying to tell me. And I must agree with Mike; given that the renderer is terminated, and it does no longer accept new jobs, there is no need to confuse coders and users with exceptions that neither have control over. Or can the coder do something to prevent these? Maybe allow for a way to hook into these exceptions with a callback / listener, or have them thrown via a command line setting, so if there is some kind issue they still can be tracked. On 4-8-2015 14:43, Mike Hearn wrote: > Race free shutdown in multi-threaded programs is always very hard. At Google some programs and libraries simply didn't support it: for servers, the cost in terms of bugs and extra code was deemed to outweigh the benefits, so the only "supported" way for a process to end was for it to be killed. > > JavaFX does not have that luxury. It must be able to shut down cleanly without races. In this case, the message is probably harmless: who cares if a render job doesn't complete if you're busy tearing down process state? So perhaps Quantum should just set a custom reject handler that ignores the issue instead of throwing. > > > On Mon, Aug 3, 2015 at 4:10 PM, Tom Eugelink > wrote: > > Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell me with this exception? > > java.util.concurrent.RejectedExecutionException: Task com.sun.javafx.tk.quantum.PaintRenderJob at 33cf88 rejected from com.sun.javafx.tk.quantum.QuantumRenderer at 1133212[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 30] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) > at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) > at com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) > at com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) > at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) > at com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) > at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) > at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown Source) > 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$145(WinApplication.java:101) > at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown Source) > at java.lang.Thread.run(Thread.java:745) > > From swpalmer at gmail.com Wed Aug 5 17:52:10 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 5 Aug 2015 13:52:10 -0400 Subject: 8u60-b26 ? Message-ID: <97F8C8E4-F393-40E7-82E9-EEF5606D7797@gmail.com> It was there a few days ago, when I downloaded it for OS X. Now the page only shows b25. It?s the first FCS build, so I wonder if it was removed for a reason. It?s still there for download if you guess the URL. Scott From philip.race at oracle.com Wed Aug 5 18:01:55 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 05 Aug 2015 11:01:55 -0700 Subject: 8u60-b26 ? In-Reply-To: <97F8C8E4-F393-40E7-82E9-EEF5606D7797@gmail.com> References: <97F8C8E4-F393-40E7-82E9-EEF5606D7797@gmail.com> Message-ID: <55C24F93.5080600@oracle.com> I am going to guess its because when you get real close to release and start building candidates for release the build string no longer has "EA" in it, and someone might mistakenly think it is an actual confirmed FCS build you can use in production. That is not the case until it has passed final testing. So the FCS candidate builds are not ones you would put up for download as an EA. So it just sounds like a boo-boo to me that got semi-fixed. -phil. On 08/05/2015 10:52 AM, Scott Palmer wrote: > It was there a few days ago, when I downloaded it for OS X. Now the page only shows b25. It?s the first FCS build, so I wonder if it was removed for a reason. It?s still there for download if you guess the URL. > > Scott From j.kapitza at schwarze-allianz.de Wed Aug 5 21:06:42 2015 From: j.kapitza at schwarze-allianz.de (Jens Kapitza) Date: Wed, 05 Aug 2015 23:06:42 +0200 Subject: Camera Access In-Reply-To: References: Message-ID: <5741451.mS1YFgW0FB@medion> Am Dienstag, 4. August 2015, 13:26:06 schrieb Scott Palmer: > The issue is: https://bugs.openjdk.java.net/browse/JDK-8090438 > > > A target release has not been set. But I really hope it could make it into > 9.0. Has there been any further discussion on this? > Why not like this? https://github.com/sarxos/webcam-capture/tree/master/webcam-capture-examples/webcam-capture-javafx feels a bit like JDBC, is there a chance to access webkit API (and use the internel API?) > Regards, > > Scott Jens Kapitza From rahman.usta.88 at gmail.com Thu Aug 6 09:25:19 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 6 Aug 2015 12:25:19 +0300 Subject: Another JavaFX Application Thread Message-ID: Hello all; I'm developing AsciidocFX . Everything is good with JavaFX but I have some trouble of it's threading model. My case is; AsciidocFX converts AsciiDoc documents to another formats (html, docbook, etc.) with asciidoctor.js using a WebView component . When we are using big AsciiDoc files (for example a book), generating docbook or something takes some seconds. While converting AsciiDoc documents, UI is being unresponsive until conversion completed because Asciidoctor.js must be run on JavaFX Application Thread and conversion takes long time. I think there must be a hack or something to handle that scenario. I thought to use HTML 5 Web Worker in WebView, but it will brings me more complexity in JavaScript side. I need a solution in Java FX side. Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From j.kapitza at schwarze-allianz.de Thu Aug 6 10:41:25 2015 From: j.kapitza at schwarze-allianz.de (Jens Kapitza) Date: Thu, 06 Aug 2015 12:41:25 +0200 Subject: Another JavaFX Application Thread In-Reply-To: References: Message-ID: <11423320.JZeKktU9FN@medion> Am Donnerstag, 6. August 2015, 12:25:19 schrieb Rahman USTA: > Hello all; > > I'm developing AsciidocFX . > Everything is good with JavaFX but I have some trouble of it's threading > model. > > My case is; > > AsciidocFX converts AsciiDoc documents to another formats (html, docbook, > etc.) with asciidoctor.js using a WebView component . When we are using big > AsciiDoc files (for example a book), generating docbook or something takes > some seconds. While converting AsciiDoc documents, UI is being unresponsive > until conversion completed because Asciidoctor.js must be run on JavaFX > Application Thread and conversion takes long time. I think there must be a > hack or something to handle that scenario. > > I thought to use HTML 5 Web Worker in WebView, but it will brings me more > complexity in JavaScript side. I need a solution in Java FX side. > > Thanks. Can you tell me the classes (method) which you call and the freeze occure? You should stop your ExecuterService, and avoid using System.exit Take a look at javafx.concurrent.Task; and do not calculate the result in FX Thread example: https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/boot/AppStarter.java StartupNotification.registerStartupListener(parameters -> { threadService.runActionLater(() -> { String[] files = parameters.split(" "); for (String file : files) { file = file.replace("\"", ""); tabService.addTab(Paths.get(file).toAbsolutePath()); } }); }); if replace may be expensive StartupNotification.registerStartupListener(parameters -> { String[] files = parameters.split(" "); for (String file : files) { final Path myFile = Paths.get( file.replace("\"", "")).toAbsolutePath(); threadService.runActionLater(() -> { tabService.addTab(myFile); // <<< only do this in FX thread }); } }); this would be better to avoid freeze. replace is just for illustrate the problem. -- Jens Kapitza p.s. sorry for my bad english From mike at plan99.net Thu Aug 6 10:45:25 2015 From: mike at plan99.net (Mike Hearn) Date: Thu, 6 Aug 2015 12:45:25 +0200 Subject: Another JavaFX Application Thread In-Reply-To: References: Message-ID: That seems like a roundabout way to do things. The web tells me: "The asciidoctor.js project is a direct port of Asciidoctor from Ruby to JavaScript using the Opal Ruby-to-JavaScript cross compiler" Why don't you use JRuby and run the original Asciidoctor code directly in a background thread? That way, no webview is needed and it can all be done in the background. From rahman.usta.88 at gmail.com Thu Aug 6 11:00:27 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 6 Aug 2015 14:00:27 +0300 Subject: Another JavaFX Application Thread In-Reply-To: References: Message-ID: @Mike JRuby brings me ~ +30 MB. I tried to use Nashorn also but it is so slow. I'm thinking to continue with WebView. The question is why there is HTML 5 Web Workers. Why there is no like that for JavaFX threading model. @Jens Expensiveness comes from JavaScript code that runs on UI thread. Script execution takes long time normally. For example docbook conversion execution starts from here https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/component/HtmlPane.java#L56 2015-08-06 13:45 GMT+03:00 Mike Hearn : > That seems like a roundabout way to do things. > > The web tells me: "The asciidoctor.js project is a direct port of > Asciidoctor from Ruby to JavaScript using the Opal Ruby-to-JavaScript cross > compiler" > > Why don't you use JRuby and run the original Asciidoctor code directly in > a background thread? That way, no webview is needed and it can all be done > in the background. > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From j.kapitza at schwarze-allianz.de Thu Aug 6 11:17:50 2015 From: j.kapitza at schwarze-allianz.de (Jens Kapitza) Date: Thu, 06 Aug 2015 13:17:50 +0200 Subject: Another JavaFX Application Thread In-Reply-To: References: Message-ID: <2276895.hJgdCIMsl6@medion> Am Donnerstag, 6. August 2015, 14:00:27 schrieb Rahman USTA: > @Mike > > JRuby brings me ~ +30 MB. I tried to use Nashorn also but it is so slow. > I'm thinking to continue with WebView. > > The question is why there is HTML 5 Web Workers. Why there is no like that > for JavaFX threading model. > > @Jens > > Expensiveness comes from JavaScript code that runs on UI thread. Script > execution takes long time normally. For example docbook conversion > execution starts from here > https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu > /component/HtmlPane.java#L56 i would replace: JSObject result = (JSObject) webEngine().executeScript(String.format("convertDocbook(editorValue,docbookOptions)")); return .... with: CompletableFuture future = CompletableFuture.supplyAsync( () -> { return (JSObject) webEngine().executeScript(String.format("convertDocbook(editorValue,docbookOptions)")); } ); return new ConverterResult(future); <<< you should check if future is present change your method an provide a consumer to call on completion an do not return the result (would be better) -- Jens Kapitza From rahman.usta.88 at gmail.com Thu Aug 6 12:26:05 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 6 Aug 2015 15:26:05 +0300 Subject: Another JavaFX Application Thread In-Reply-To: <2276895.hJgdCIMsl6@medion> References: <2276895.hJgdCIMsl6@medion> Message-ID: Jens; executeScript must be run on JavaFX Application Thread, and execution of my script takes long time. There is an unavoidable freezing case if your script takes long time. CompletableFuture can't help us because the issue arise from JavaScript execution. 2015-08-06 14:17 GMT+03:00 Jens Kapitza : > Am Donnerstag, 6. August 2015, 14:00:27 schrieb Rahman USTA: > > @Mike > > > > JRuby brings me ~ +30 MB. I tried to use Nashorn also but it is so slow. > > I'm thinking to continue with WebView. > > > > The question is why there is HTML 5 Web Workers. Why there is no like > that > > for JavaFX threading model. > > > > @Jens > > > > Expensiveness comes from JavaScript code that runs on UI thread. Script > > execution takes long time normally. For example docbook conversion > > execution starts from here > > > https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu > > /component/HtmlPane.java#L56 > > i would replace: > JSObject result = (JSObject) > > webEngine().executeScript(String.format("convertDocbook(editorValue,docbookOptions)")); > return .... > > with: > > > > CompletableFuture future = CompletableFuture.supplyAsync( > () -> { > return > (JSObject) > > webEngine().executeScript(String.format("convertDocbook(editorValue,docbookOptions)")); > } > ); > > > return new ConverterResult(future); <<< you should check if future is > present > > change your method an provide a consumer to call on completion an do not > return the result (would be better) > > > > > -- > Jens Kapitza > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From danielhilst at gmail.com Thu Aug 6 13:36:10 2015 From: danielhilst at gmail.com (Daniel.) Date: Thu, 6 Aug 2015 10:36:10 -0300 Subject: VNC alternative for JavaFX running directly on framebuffer. Message-ID: Hi all, I'm running applications on Freescale's iMX.6 using JavaFX. It's known that it doesn't uses X but directly access the framebuffer instead, so x11vnc doesn't applies. I need to export the video input/output as VNC does. Does anybody knows an alternative solution for this? Best regards, - dhs -- "Do or do not. There is no try" Yoda Master From David.Hill at Oracle.com Thu Aug 6 13:40:42 2015 From: David.Hill at Oracle.com (David Hill) Date: Thu, 06 Aug 2015 09:40:42 -0400 Subject: VNC alternative for JavaFX running directly on framebuffer. In-Reply-To: References: Message-ID: <55C363DA.2060200@Oracle.com> On 8/6/15, 9:36 AM, Daniel. wrote: > Hi all, > > I'm running applications on Freescale's iMX.6 using JavaFX. It's known > that it doesn't uses X but directly access the framebuffer instead, so > x11vnc doesn't applies. I need to export the video input/output as VNC > does. > > Does anybody knows an alternative solution for this? > > Best regards, > - dhs > I did have an older Glass module running with VNC at one point, mostly as a demonstration, but that was left behind when we moved to Monocle. The structure of Monocle is such that it would not take too much to make it VNC compatible, the biggest effort actually is the input mapping. I would probably stuff it in to the "headless" support we have in there. I don't have bandwidth to take on something like this right now, as fun as it would be. Dave -- 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 Thu Aug 6 15:10:50 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Aug 2015 08:10:50 -0700 Subject: 8u60-b26 ? In-Reply-To: <55C24F93.5080600@oracle.com> References: <97F8C8E4-F393-40E7-82E9-EEF5606D7797@gmail.com> <55C24F93.5080600@oracle.com> Message-ID: <55C378FA.1010702@oracle.com> Exactly. -- Kevin Phil Race wrote: > I am going to guess its because when you get real close to release and > start building > candidates for release the build string no longer has "EA" in it, and > someone might > mistakenly think it is an actual confirmed FCS build you can use in > production. > That is not the case until it has passed final testing. So the FCS > candidate builds > are not ones you would put up for download as an EA. > So it just sounds like a boo-boo to me that got semi-fixed. > > -phil. > > On 08/05/2015 10:52 AM, Scott Palmer wrote: >> It was there a few days ago, when I downloaded it for OS X. Now the >> page only shows b25. It?s the first FCS build, so I wonder if it was >> removed for a reason. It?s still there for download if you guess the >> URL. >> >> Scott > From kevin.rushforth at oracle.com Thu Aug 6 15:10:56 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Aug 2015 08:10:56 -0700 Subject: RejectedExecutionException In-Reply-To: <55C1BE09.9080507@tbee.org> References: <55BF7655.9070200@tbee.org> <55C1BE09.9080507@tbee.org> Message-ID: <55C37900.3080906@oracle.com> I agree. Please file a bug. -- Kevin Tom Eugelink wrote: > Indeed, this exception put me on the wrong track, trying to figure out > why the test was failing based on the exception, while I was "just" > asserting the wrong property. > > I now also understand what it is trying to tell me. And I must agree > with Mike; given that the renderer is terminated, and it does no > longer accept new jobs, there is no need to confuse coders and users > with exceptions that neither have control over. Or can the coder do > something to prevent these? Maybe allow for a way to hook into these > exceptions with a callback / listener, or have them thrown via a > command line setting, so if there is some kind issue they still can be > tracked. > > > On 4-8-2015 14:43, Mike Hearn wrote: >> Race free shutdown in multi-threaded programs is always very hard. At >> Google some programs and libraries simply didn't support it: for >> servers, the cost in terms of bugs and extra code was deemed to >> outweigh the benefits, so the only "supported" way for a process to >> end was for it to be killed. >> >> JavaFX does not have that luxury. It must be able to shut down >> cleanly without races. In this case, the message is probably >> harmless: who cares if a render job doesn't complete if you're busy >> tearing down process state? So perhaps Quantum should just set a >> custom reject handler that ignores the issue instead of throwing. >> >> >> On Mon, Aug 3, 2015 at 4:10 PM, Tom Eugelink > > wrote: >> >> Working on a new skin for JFXtras Agenda... What is JavaFX trying >> to tell me with this exception? >> >> java.util.concurrent.RejectedExecutionException: Task >> com.sun.javafx.tk.quantum.PaintRenderJob at 33cf88 rejected from >> com.sun.javafx.tk.quantum.QuantumRenderer at 1133212[Terminated, pool >> size = 0, active threads = 0, queued tasks = 0, completed tasks = 30] >> at >> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) >> >> at >> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) >> >> at >> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) >> >> at >> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) >> >> at >> com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) >> >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) >> >> at >> com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) >> at >> com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) >> >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) >> >> at >> com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown >> Source) >> 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$145(WinApplication.java:101) >> >> at >> com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown >> Source) >> at java.lang.Thread.run(Thread.java:745) >> >> > From danielhilst at gmail.com Thu Aug 6 18:31:41 2015 From: danielhilst at gmail.com (Daniel.) Date: Thu, 6 Aug 2015 15:31:41 -0300 Subject: JVM (8u60) crashing on ARM Message-ID: Hi all, I'm running a java application on iMX.6 (Freescale) with javafx within it. The JVM crashes after some time. I have two files: hs_err_pid1101.log (few kbytes) and core (this is big, 500mb~). Where I can get help with that crashes? Should I provide the core dump here or shold be delivered to Oracle or something like that? Any help is helpful :) Best regards, - dhs -- *"Do or do not. There is no try"* *Yoda Master* From tai.hu at veroanalytics.com Thu Aug 6 20:11:04 2015 From: tai.hu at veroanalytics.com (Tai Hu) Date: Thu, 6 Aug 2015 16:11:04 -0400 Subject: How to Include a License File in Self-Contained Application Package Message-ID: <1C6C6760-D278-494B-A426-5C9539C9E46E@veroanalytics.com> Hi all, I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn?t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? Thanks, Tai From mikegps1 at gmail.com Thu Aug 6 20:38:59 2015 From: mikegps1 at gmail.com (Mike) Date: Thu, 6 Aug 2015 13:38:59 -0700 Subject: How to Include a License File in Self-Contained Application Package In-Reply-To: <1C6C6760-D278-494B-A426-5C9539C9E46E@veroanalytics.com> References: <1C6C6760-D278-494B-A426-5C9539C9E46E@veroanalytics.com> Message-ID: <37BF8919-B1AA-480F-BD02-D0613E02C31C@gmail.com> This is awesome news! Congrats Sent from Objectwheel & Mike > On Aug 6, 2015, at 1:11 PM, Tai Hu wrote: > > Hi all, > I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn?t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? > > Thanks, > > Tai From jonathan.giles at oracle.com Thu Aug 6 23:07:39 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 7 Aug 2015 11:07:39 +1200 Subject: JEP 253: UI control skins and input mapping discussion Message-ID: <55C3E8BB.6000903@oracle.com> Hi all, As you might be aware, JEP 253 is all about getting private JavaFX UI control and CSS APIs out into the public. You can read all about JEP 253 at [1]. This JEP is split into three sub-projects: 1) Make UI control skins into public APIs 2) Improve support for input mapping 3) Review and make public relevant CSS APIs Today I'm posting a first javadoc that contains a proposed set of API for project 1) and 2). The javadoc for project 3) will come in a week or two, once it is closer to completion. You can find the javadoc for the first two projects at [2]. In this javadoc you'll see three packages. Here's a few brief comments: 1) javafx.scene.control: This package is unchanged. It is only here for completeness (so you can compare control classes to skin classes). 2) javafx.scene.control.skin: This package is entirely new. It consists of many of the classes that previously inhabited com.sun.javafx.scene.control.skin. Look closely at the skin classes you are interested in - almost all classes do not resemble their original form. This is because up until now, skin classes have never been considered public API, and as such not much was done to ensure a sane API. With JDK 9 this changes, and so the amount of API on each class is significantly less than what existed previously. We will take the normal approach of growing the API as demand is shown - so if something is missing, please comment ASAP! 3) javafx.scene.input: This package contains just the new classes as part of this JEP. In general the classes here are the most preliminary of the bunch - they are likely to go under the most change between now and JDK 9 being released. Please review and comment. The primary implementation change is that whilst Skins are mostly unchanged, they handle behaviors differently than now. Input mappings are now created by the skin and installed on the control. It is conceivable that in a future release these behaviors will themselves become public API, but for JEP 253 that is out of scope. There are still a few things to be thought through: 1) How to document the available input mappings so they can be easily searched for at runtime (javadoc? Java API?) 2) Controls have an empty inputMap until skin is instantiated - this means manipulating the mappings can't happen as soon as the control is created. 3) No plan on how this might support Action-style API in the future. 4) There is no API to access context menus in controls such as TextField (to add / remove functionality). I look forward to any feedback you may have. Feel free to email me on- or off- list. [1] http://openjdk.java.net/jeps/253 [2] http://jonathangiles.net/javafx/jdk9/public-skins/2/ Thanks, -- Jonathan From jonathan.giles at oracle.com Thu Aug 6 23:10:47 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 7 Aug 2015 11:10:47 +1200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 Message-ID: <55C3E977.2060604@oracle.com> Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: == 'Toolkit' API == A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. == 'Traversal' API == This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. == 'Collections Event' API == There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. == 'Utils' API == There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class (although there are no plans to move all the methods over!). == Miscellaneous API == Finally, there are a few classes that popped up quite frequently. Here is the list, and my thoughts on what to do with them: 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - not a likely candidate for JDK 9. 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - not a likely candidate for JDK 9. 3) Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. 4) PerformanceTracker: Same as Robot - good, but API might require more time than is available for JDK 9. == What about other private API == If I've stated that an API you use isn't likely to make the cut for 9, there is another option: pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API. I should note that you shouldn't just dive in and do this - ping us and let us know first, so we can sync up and make sure the plan is feasible (and not overlapping). Because any large chunk of work would require moving through the JEP process, it is unlikely that anything other than small tweaks would be acceptable. One such example might be the PerformanceTracker. == Where to from here? == The first milestone is to get JEP 253 into the main repo. That should hopefully be done before the end of August. Once that is done, focus can shift to the areas identified in this email. In the mean time, if there is any community feedback, please get it in ASAP so it can be included in the consideration. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html [2] http://openjdk.java.net/jeps/253 Thanks! -- Jonathan From danno.ferrin at oracle.com Fri Aug 7 02:39:18 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Thu, 6 Aug 2015 20:39:18 -0600 Subject: How to Include a License File in Self-Contained Application Package In-Reply-To: <1C6C6760-D278-494B-A426-5C9539C9E46E@veroanalytics.com> References: <1C6C6760-D278-494B-A426-5C9539C9E46E@veroanalytics.com> Message-ID: <8F703122-812C-4932-B765-6BC5872CBDDF@oracle.com> Currently the Mac App Store support for java packager does not support a click-through license. One could be added if a web-bug feature request was posted, and we could add it to the queue. We do support click-through licenses for .DMG and .PKG distributions on mac, just not MAS right now. Right now we only use synthesized distribution.xml files created by productbuild and don't create our own, this is much more resilient to the OS changing underneath us. --Danno > On Aug 6, 2015, at 2:11 PM, Tai Hu wrote: > > Hi all, > I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn?t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? > > Thanks, > > Tai From tai.hu at veroanalytics.com Fri Aug 7 02:44:26 2015 From: tai.hu at veroanalytics.com (Tai Hu) Date: Thu, 6 Aug 2015 22:44:26 -0400 Subject: How to Include a License File in Self-Contained Application Package In-Reply-To: <8F703122-812C-4932-B765-6BC5872CBDDF@oracle.com> References: <1C6C6760-D278-494B-A426-5C9539C9E46E@veroanalytics.com> <8F703122-812C-4932-B765-6BC5872CBDDF@oracle.com> Message-ID: Danno, Thanks so much for the information. Could you show a sample about how to include a click-thought license in my build? Right now I have entire build process set up and could successfully build all DMG, PKG and PKG_MacAppStore and signed by our Developer certificate. What should I do to put our license file into build? Any info are really appreciate. Thanks, Tai > On Aug 6, 2015, at 10:39 PM, Danno Ferrin wrote: > > Currently the Mac App Store support for java packager does not support a click-through license. One could be added if a web-bug feature request was posted, and we could add it to the queue. We do support click-through licenses for .DMG and .PKG distributions on mac, just not MAS right now. > > Right now we only use synthesized distribution.xml files created by productbuild and don't create our own, this is much more resilient to the OS changing underneath us. > > --Danno > >> On Aug 6, 2015, at 2:11 PM, Tai Hu wrote: >> >> Hi all, >> I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn?t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? >> >> Thanks, >> >> Tai > From hastebrot at gmail.com Fri Aug 7 09:51:04 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 7 Aug 2015 11:51:04 +0200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: <55C3E977.2060604@oracle.com> References: <55C3E977.2060604@oracle.com> Message-ID: Hi Jonathan, thanks for the summary! >pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API I'd like to help with the public API for profiling and performance tracking (mainly PulseLogger, maybe PerformanceTracker). >These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class Sounds good. TestFX has a dependency to com.sun.javafx.application.ParametersImpl to provide the ability to test multiple different `Application`s. It currently depends on private fields and methods of internal classes. >Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. The headless testing feature in TestFX has dependencies to com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the AWT robot, the "normal" testing mode needs no access to the internal APIs. The screenshot feature in headless testing depends on com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. Additionally we also need access to com.sun.glass.ui.PlatformFactory in order to activate Monocle on desktop systems. --Benjamin On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles wrote: > Hi all. In April of this year a discussion began when news broke that with > JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while > back I posted a request to openjfx-dev for people to send me their JDeps > output so that it could be analysed and used to inform our decisions around > which API we should try to promote into public API. The response was very > useful (and I should note: its too late now, please don't send me anymore > JDeps files), and I believe we have the beginnings of a plan on how to move > forward. > > Before I outline the plan, please note that this discussion would ideally > _not_ devolve into a feature requests discussion. What we are wanting to > talk about today is simply API that exists in the com.sun.* package > namespace which we can conceivably bring out of this namespace for JDK 9. > Developing new API is expressly out of scope (unless it is related to > simplifying or wrapping the com.sun.* API). > > Another important point - UI control skins and a lot of very useful CSS > API are being made public under JEP 253 [2]. A lot of the skin code has > already been cleaned up, simplified, documented, etc, and will be merging > into a repo very soon. I'll also post a separate post about JEP 253 soon. > > So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, > which has been largely resolved by JEP 253)? I can sum it up in the > following categories: > > == 'Toolkit' API == > A lot of people use a small amount of API from Toolkit, such as the API > for nested event loops, to fire a pulse, and to add / remove pulse > listeners. Based on this analysis, the current thinking is to add API into > the javafx.application.Platform class to enable the first two use cases > above (nested event loops and pulse firing). The third use case needs more > engineering effort, and is a far less common use case, so isn't being > considered for JDK 9. > > == 'Traversal' API == > This API lives in com.sun.javafx.scene.traversal, and is quite useful when > writing custom controls to ensure that keyboard traversal puts the focus in > the right node at the right time. My ControlsFX open source project is a > common (ab)user of this API, so I have a vested interest in making this > public. Having said this, the API is actually in quite good shape, and it > is possible with just a little JavaDoc work it could make the move into > javafx.scene.traversal. > > == 'Collections Event' API == > There exists classes in com.sun.javafx.collections that are quite useful > if you create your own custom ObservableList implementation and want to > fire events at certain times. In my analysis there are only two projects > using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent > point is that this code is quite easy to reproduce, so, whilst I would like > to see this API public, it doesn't seem to make sense for JavaFX 9. > > == 'Utils' API == > There exists three classes that are quite commonly used by people for the > various utility methods contained within. These classes are > com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and > com.sun.javafx.application.PlatformImpl. As most of these classes are just > a collection of self-contained methods, it is quite likely that a number of > these methods will find public API alternatives in a new class (although > there are no plans to move all the methods over!). > > == Miscellaneous API == > Finally, there are a few classes that popped up quite frequently. Here is > the list, and my thoughts on what to do with them: > > 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - not > a likely candidate for JDK 9. > 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - not > a likely candidate for JDK 9. > 3) Robot: A good API to make public, but not a small API, so the scope is > possibly too great for JDK 9. > 4) PerformanceTracker: Same as Robot - good, but API might require more > time than is available for JDK 9. > > == What about other private API == > If I've stated that an API you use isn't likely to make the cut for 9, > there is another option: pull up your sleeves and work with us to get the > API into a shape where it is good enough to commit to as public API. I > should note that you shouldn't just dive in and do this - ping us and let > us know first, so we can sync up and make sure the plan is feasible (and > not overlapping). Because any large chunk of work would require moving > through the JEP process, it is unlikely that anything other than small > tweaks would be acceptable. One such example might be the > PerformanceTracker. > > == Where to from here? == > The first milestone is to get JEP 253 into the main repo. That should > hopefully be done before the end of August. Once that is done, focus can > shift to the areas identified in this email. In the mean time, if there is > any community feedback, please get it in ASAP so it can be included in the > consideration. > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html > [2] http://openjdk.java.net/jeps/253 > > Thanks! > -- Jonathan > From mike at plan99.net Fri Aug 7 10:31:29 2015 From: mike at plan99.net (Mike Hearn) Date: Fri, 7 Aug 2015 12:31:29 +0200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: References: <55C3E977.2060604@oracle.com> Message-ID: If there were to be an API for getting basic graphics device data, what would that look like and would it be hard to write? My app uses some internal APIs not listed above to query the pixel scale and whether we're using software/hardware graphics, to reduce usage of some expensive effects. These are just booleans, essentially. On Fri, Aug 7, 2015 at 11:51 AM, Benjamin Gudehus wrote: > Hi Jonathan, > > thanks for the summary! > > >pull up your sleeves and work with us to get the API into a shape where it > is good enough to commit to as public API > > I'd like to help with the public API for profiling and performance tracking > (mainly PulseLogger, maybe PerformanceTracker). > > >These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, > and com.sun.javafx.application.PlatformImpl. As most of these classes are > just a collection of self-contained methods, it is quite likely that a > number of these methods will find public API alternatives in a new class > > Sounds good. TestFX has a dependency to > com.sun.javafx.application.ParametersImpl to provide the ability to test > multiple different `Application`s. It currently depends on private fields > and methods of internal classes. > > >Robot: A good API to make public, but not a small API, so the scope is > possibly too great for JDK 9. > > The headless testing feature in TestFX has dependencies to > com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the > AWT robot, the "normal" testing mode needs no access to the internal APIs. > > The screenshot feature in headless testing depends on > com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. > > Additionally we also need access to com.sun.glass.ui.PlatformFactory in > order to activate Monocle on desktop systems. > > --Benjamin > > On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles > wrote: > > > Hi all. In April of this year a discussion began when news broke that > with > > JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while > > back I posted a request to openjfx-dev for people to send me their JDeps > > output so that it could be analysed and used to inform our decisions > around > > which API we should try to promote into public API. The response was very > > useful (and I should note: its too late now, please don't send me anymore > > JDeps files), and I believe we have the beginnings of a plan on how to > move > > forward. > > > > Before I outline the plan, please note that this discussion would ideally > > _not_ devolve into a feature requests discussion. What we are wanting to > > talk about today is simply API that exists in the com.sun.* package > > namespace which we can conceivably bring out of this namespace for JDK 9. > > Developing new API is expressly out of scope (unless it is related to > > simplifying or wrapping the com.sun.* API). > > > > Another important point - UI control skins and a lot of very useful CSS > > API are being made public under JEP 253 [2]. A lot of the skin code has > > already been cleaned up, simplified, documented, etc, and will be merging > > into a repo very soon. I'll also post a separate post about JEP 253 soon. > > > > So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, > > which has been largely resolved by JEP 253)? I can sum it up in the > > following categories: > > > > == 'Toolkit' API == > > A lot of people use a small amount of API from Toolkit, such as the API > > for nested event loops, to fire a pulse, and to add / remove pulse > > listeners. Based on this analysis, the current thinking is to add API > into > > the javafx.application.Platform class to enable the first two use cases > > above (nested event loops and pulse firing). The third use case needs > more > > engineering effort, and is a far less common use case, so isn't being > > considered for JDK 9. > > > > == 'Traversal' API == > > This API lives in com.sun.javafx.scene.traversal, and is quite useful > when > > writing custom controls to ensure that keyboard traversal puts the focus > in > > the right node at the right time. My ControlsFX open source project is a > > common (ab)user of this API, so I have a vested interest in making this > > public. Having said this, the API is actually in quite good shape, and it > > is possible with just a little JavaDoc work it could make the move into > > javafx.scene.traversal. > > > > == 'Collections Event' API == > > There exists classes in com.sun.javafx.collections that are quite useful > > if you create your own custom ObservableList implementation and want to > > fire events at certain times. In my analysis there are only two projects > > using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent > > point is that this code is quite easy to reproduce, so, whilst I would > like > > to see this API public, it doesn't seem to make sense for JavaFX 9. > > > > == 'Utils' API == > > There exists three classes that are quite commonly used by people for the > > various utility methods contained within. These classes are > > com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and > > com.sun.javafx.application.PlatformImpl. As most of these classes are > just > > a collection of self-contained methods, it is quite likely that a number > of > > these methods will find public API alternatives in a new class (although > > there are no plans to move all the methods over!). > > > > == Miscellaneous API == > > Finally, there are a few classes that popped up quite frequently. Here is > > the list, and my thoughts on what to do with them: > > > > 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - > not > > a likely candidate for JDK 9. > > 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - > not > > a likely candidate for JDK 9. > > 3) Robot: A good API to make public, but not a small API, so the scope is > > possibly too great for JDK 9. > > 4) PerformanceTracker: Same as Robot - good, but API might require more > > time than is available for JDK 9. > > > > == What about other private API == > > If I've stated that an API you use isn't likely to make the cut for 9, > > there is another option: pull up your sleeves and work with us to get the > > API into a shape where it is good enough to commit to as public API. I > > should note that you shouldn't just dive in and do this - ping us and let > > us know first, so we can sync up and make sure the plan is feasible (and > > not overlapping). Because any large chunk of work would require moving > > through the JEP process, it is unlikely that anything other than small > > tweaks would be acceptable. One such example might be the > > PerformanceTracker. > > > > == Where to from here? == > > The first milestone is to get JEP 253 into the main repo. That should > > hopefully be done before the end of August. Once that is done, focus can > > shift to the areas identified in this email. In the mean time, if there > is > > any community feedback, please get it in ASAP so it can be included in > the > > consideration. > > > > [1] > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html > > [2] http://openjdk.java.net/jeps/253 > > > > Thanks! > > -- Jonathan > > > From mike at plan99.net Fri Aug 7 10:36:02 2015 From: mike at plan99.net (Mike Hearn) Date: Fri, 7 Aug 2015 12:36:02 +0200 Subject: JEP 253: UI control skins and input mapping discussion In-Reply-To: <55C3E8BB.6000903@oracle.com> References: <55C3E8BB.6000903@oracle.com> Message-ID: I don't know much about skins and how they work, as I haven't implemented custom controls. My only knowledge comes from rummaging around inside the code to find some hacky way to get a particular effect, often via CSS. I was hoping to read about the skins infrastructure, what it's for, how it works etc in the jfx.s.c.skins package description but no such luck. Is the plan for the JavaDocs to give a high level description of skinning, how to implement it in your own code etc, or are there plans for other articles to describe this? From swpalmer at gmail.com Fri Aug 7 13:39:34 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 7 Aug 2015 09:39:34 -0400 Subject: Camera Access In-Reply-To: <5741451.mS1YFgW0FB@medion> References: <5741451.mS1YFgW0FB@medion> Message-ID: <68C4D3FA-6242-4D9C-ABCA-9E124452134E@gmail.com> > On Aug 5, 2015, at 5:06 PM, Jens Kapitza wrote: > > Am Dienstag, 4. August 2015, 13:26:06 schrieb Scott Palmer: >> The issue is: https://bugs.openjdk.java.net/browse/JDK-8090438 >> >> >> A target release has not been set. But I really hope it could make it into >> 9.0. Has there been any further discussion on this? >> > Why not like this? > > https://github.com/sarxos/webcam-capture/tree/master/webcam-capture-examples/webcam-capture-javafx > When I ran the JavaFX example on OS X, it locked up before even showing a UI. (It may have something to do with accessing Swing/AWT classes off the Event Dispatch thread, or before such thread exists*.) It?s also a pretty heavy library with way too many dependencies. It cobbles together or relies on 10 different APIs/libraries, or ?drivers" to get the job done. In short it?s a mess compared to what the camera API should be. For reasonable camera access Java needs something much simpler. Cameras are built-in to most of the devices Java runs on, and have been for some time. Heck, even the Raspberry PI has a standard camera module and it runs JavaFX. There should be an official API for camera access. *On a side note, it?s a shame that there is no Image data type that is independent of JavaFX/Swing so manipulating image data doesn?t have to bring in a particular UI toolkit, and therefore force use of Swing even though your API is JavaFX based. E.g. ImageIO requires Swing-based images when it should have been independent of the UI toolkit. A Raster interface could be factored out and shared between whatever UI image classes are used, ImageIO, and the future camera API? probably too late now though. Regards, Scott From tai.hu at veroanalytics.com Sat Aug 8 03:11:22 2015 From: tai.hu at veroanalytics.com (Tai Hu) Date: Fri, 7 Aug 2015 23:11:22 -0400 Subject: JavaFX Self-contained PKG and MacAppStore_PKG did not work Message-ID: <2B03BFAE-A1BB-44EC-8142-7A864A7AF126@veroanalytics.com> Hi, I used JavaFX ant tasks to create all native packages on Mac OS X (JDK 8u51 on latest Mac OS X). Both .app and .dmg packages are working flawlessly. However, for PKG package, the very first installation was successful and my application show up in /Applications folder. However, if I delete my app from /Applications and use PKG package to install again, the installation process will always run successfully. However, my application did not show up inside of /Applications. I already tried to use pkgutil ?forget and rebooted my Mac. It is still the same result. Installation of PKG package are always successful. But my application is not installed under /Applications folder. Thanks, Tai From swpalmer at gmail.com Sat Aug 8 23:16:42 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 8 Aug 2015 19:16:42 -0400 Subject: Can we use JavaPackager and a get full JRE? Message-ID: I?m using the JavaFX gradle plugin to build a very simple application with the new java packager and I?ve noticed a problem with the embedded JRE, at least on OS X. Specifically, the ?bin? folder is missing from the embedded JRE, presumably because the embedded launcher replaces it. However my application (and many others) needs to launch a new java process. Part of the reason for doing so is so it can be launched with new JVM options that are determined at runtime. For example modifying the java.library.dir after finding ?plugins? that have native code. Now it fails when running from the app bundle (works fine from a command line). The problems is that it fails to launch a new ?java? process because it expects to find 'bin/java' in the JRE folder. What is the solution? Since I?m using Gradle, I?m thinking I could tweak things to copy the JRE bin folder into the xxxx.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/ folder, but really the javapackager should have an option to include the ?full? JRE. Or perhaps we need a new API in Java 9 to support launching a new Java process? Regards, Scott From berry120 at gmail.com Sun Aug 9 13:13:45 2015 From: berry120 at gmail.com (Michael Berry) Date: Sun, 9 Aug 2015 14:13:45 +0100 Subject: Combobox issue with Windows 10 Message-ID: After upgrading to windows 10, I've had many reports of users hitting this issue (https://bugs.openjdk.java.net/browse/JDK-8132897) whereby clicking any unfocused combobox in our application completely freezes it up. (Interestingly, tabbing so the combobox is selected first before clicking provides a workaround, but clearly this is not a good solution.) I haven't been able to reproduce unfortunately, but it's certainly causing problems our end and I can't imagine we're the only ones. Has anyone else noticed this and been able to reproduce it more reliably? I would look to contribute a fix, but not being able to reproduce makes it pretty much impossible. Michael From mike at plan99.net Sun Aug 9 14:03:57 2015 From: mike at plan99.net (Mike Hearn) Date: Sun, 9 Aug 2015 16:03:57 +0200 Subject: Can we use JavaPackager and a get full JRE? In-Reply-To: References: Message-ID: UpdateFX has code that can restart a javapackager packaged process, look here: https://github.com/vinumeris/updatefx/blob/master/api/src/main/java/com/vinumeris/updatefx/UpdateFX.java#L60 It's not beautiful but it works. You could extract the code and use it in your app: UpdateFX is Apache licensed. From jeff at reportmill.com Sun Aug 9 18:47:38 2015 From: jeff at reportmill.com (Jeff Martin) Date: Sun, 9 Aug 2015 13:47:38 -0500 Subject: Can we use JavaPackager and a get full JRE? In-Reply-To: References: Message-ID: You can add a post-image script to your javapackager build to manually add the java.exe into your application. If you search the output from the javapackager for ?post-image? I think it will tell you what file to create and where to put it. Here is a post-image file that I use to move java.exe into my native app on Windows: MyApp-post-image.wsf: On MacOS, I just build a native ?image? as opposed to a .dmg. So it?s easy to add the java binary in an external script (I do some codesign stuff there as well, which has to happen after I modify the native package). Jeff Martin 214.513.1636 > On Aug 8, 2015, at 6:16 PM, Scott Palmer wrote: > > I?m using the JavaFX gradle plugin to build a very simple application with the new java packager and I?ve noticed a problem with the embedded JRE, at least on OS X. > > Specifically, the ?bin? folder is missing from the embedded JRE, presumably because the embedded launcher replaces it. > However my application (and many others) needs to launch a new java process. Part of the reason for doing so is so it can be launched with new JVM options that are determined at runtime. For example modifying the java.library.dir after finding ?plugins? that have native code. > > Now it fails when running from the app bundle (works fine from a command line). The problems is that it fails to launch a new ?java? process because it expects to find 'bin/java' in the JRE folder. > > What is the solution? > > Since I?m using Gradle, I?m thinking I could tweak things to copy the JRE bin folder into the xxxx.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/ folder, but really the javapackager should have an option to include the ?full? JRE. > > Or perhaps we need a new API in Java 9 to support launching a new Java process? > > > Regards, > > Scott > > From jonathan.giles at oracle.com Mon Aug 10 00:11:32 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 10 Aug 2015 12:11:32 +1200 Subject: Combobox issue with Windows 10 In-Reply-To: References: Message-ID: <55C7EC34.60405@oracle.com> I don't have a Windows 10 set up here yet, although if necessary I can go through the process of installing Windows 10 as another boot option on my PC. As it stands I can not reproduce this issue on my Windows 8 install. It would probably be beneficial to try to get more data from your users. Depending on how technical they are you can have them run a tool like VisualVM to see if something is locking up. Thanks, -- Jonathan On 10/08/2015 1:13 a.m., Michael Berry wrote: > After upgrading to windows 10, I've had many reports of users hitting this > issue (https://bugs.openjdk.java.net/browse/JDK-8132897) whereby clicking > any unfocused combobox in our application completely freezes it up. > (Interestingly, tabbing so the combobox is selected first before clicking > provides a workaround, but clearly this is not a good solution.) I haven't > been able to reproduce unfortunately, but it's certainly causing problems > our end and I can't imagine we're the only ones. > > Has anyone else noticed this and been able to reproduce it more reliably? I > would look to contribute a fix, but not being able to reproduce makes it > pretty much impossible. > > Michael From jonathan.giles at oracle.com Mon Aug 10 01:58:22 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 10 Aug 2015 13:58:22 +1200 Subject: JEP 253: UI control skins and input mapping discussion In-Reply-To: References: <55C3E8BB.6000903@oracle.com> Message-ID: <55C8053E.9080501@oracle.com> The plan is for this kind of detail to be included in the javadoc documentation. Thanks, -- Jonathan On 7/08/2015 10:36 p.m., Mike Hearn wrote: > I don't know much about skins and how they work, as I haven't > implemented custom controls. My only knowledge comes from rummaging > around inside the code to find some hacky way to get a particular > effect, often via CSS. > > I was hoping to read about the skins infrastructure, what it's for, > how it works etc in the jfx.s.c.skins package description but no such > luck. Is the plan for the JavaDocs to give a high level description of > skinning, how to implement it in your own code etc, or are there plans > for other articles to describe this? From danno.ferrin at oracle.com Mon Aug 10 04:14:25 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Sun, 9 Aug 2015 22:14:25 -0600 Subject: Can we use JavaPackager and a get full JRE? In-Reply-To: References: Message-ID: > On Aug 8, 2015, at 5:16 PM, Scott Palmer wrote: > > I?m using the JavaFX gradle plugin to build a very simple application with the new java packager and I?ve noticed a problem with the embedded JRE, at least on OS X. > > Specifically, the ?bin? folder is missing from the embedded JRE, presumably because the embedded launcher replaces it. We deliberately strip that folder from the package. The functionality provided by the launcher is not equivalent and is only sufficient to support application launch. The goal is to have a JRE embedded just for the application, and leaving the bin folder leaves entry points for non-embeded use of the JRE. > However my application (and many others) needs to launch a new java process. Part of the reason for doing so is so it can be launched with new JVM options that are determined at runtime. For example modifying the java.library.dir after finding ?plugins? that have native code. > > Now it fails when running from the app bundle (works fine from a command line). The problems is that it fails to launch a new ?java? process because it expects to find 'bin/java' in the JRE folder. > > What is the solution? It's not easy, since this is functionality that is deliberately removed in the name of security. You could copy the .../bin/java file somewhere else prior to packaging and then copy it back into place after packaging, but that would be platform specific. > > Since I?m using Gradle, I?m thinking I could tweak things to copy the JRE bin folder into the xxxx.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/ folder, This would be very difficult to accomplish with the current gradle plugin. It's an unconventional step and hence the plugin makes unconventional stuff difficult unless hand wired soup to nuts. > but really the javapackager should have an option to include the ?full? JRE. I haven't seen how the bugs.openjdk.java.net transition has affectied it, but in the JIRA days I would say open a JIRA and we can add it to our feature queue. But this would have an additional step of going through a security audit (since the removal was deliberate for security) and the security engineers may not be cool with it (then again, if it is a non default option they may accept it), so it's not a slam dunk. > > Or perhaps we need a new API in Java 9 to support launching a new Java process? > Officially it's not too late to get new features such as this into the 9.0 release, but unless it is related to the module system and making it work somehow my thoughts are that it won't get accepted into 9.0. > > Regards, > > Scott > > From danno.ferrin at oracle.com Mon Aug 10 04:23:17 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Sun, 9 Aug 2015 22:23:17 -0600 Subject: JavaFX Self-contained PKG and MacAppStore_PKG did not work In-Reply-To: <2B03BFAE-A1BB-44EC-8142-7A864A7AF126@veroanalytics.com> References: <2B03BFAE-A1BB-44EC-8142-7A864A7AF126@veroanalytics.com> Message-ID: Mac installer is weird. The install location in the installer is at best a strongly worded suggestion to the pkgutil code and I don't completely understand when it follows it and when it doesn't. What I have seen in my development is that if the package has been installed and or run anywhere else on the machine then the pkgutil will install the app into that location as an update to the existing application. So in my case I had an instance of the app that I had run from my source control build directory, and pkgutil chose to update that instance of the application rather than one I had in /Applicaitons that I drug in from a DMG. It appears that this is driven by the CFBundleIdentifier, so changing the identifier may get a clean install. Running pkgutil --pkg-info may tell you where it is installed or where it thinks it is installed. > On Aug 7, 2015, at 9:11 PM, Tai Hu wrote: > > Hi, > I used JavaFX ant tasks to create all native packages on Mac OS X (JDK 8u51 on latest Mac OS X). Both .app and .dmg packages are working flawlessly. However, for PKG package, the very first installation was successful and my application show up in /Applications folder. However, if I delete my app from /Applications and use PKG package to install again, the installation process will always run successfully. However, my application did not show up inside of /Applications. I already tried to use pkgutil ?forget and rebooted my Mac. It is still the same result. Installation of PKG package are always successful. But my application is not installed under /Applications folder. > > Thanks, > > Tai From mik3hall at gmail.com Mon Aug 10 08:52:24 2015 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 10 Aug 2015 03:52:24 -0500 Subject: Can we use JavaPackager and a get full JRE? In-Reply-To: References: Message-ID: > On Aug 9, 2015, at 11:14 PM, Danno Ferrin wrote: > > It's not easy, since this is functionality that is deliberately removed in the name of security. You could copy the .../bin/java file somewhere else prior to packaging and then copy it back into place after packaging, but that would be platform specific. Wouldn?t this break code signing? For now, OS X only, couldn?t you require your users to have the common, ?browser?, jre installed? alias javajre="/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java" javajre -version java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b70) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b70, mixed mode) Then you could Runtime exec that? Michael Hall > From mik3hall at gmail.com Mon Aug 10 09:04:39 2015 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 10 Aug 2015 04:04:39 -0500 Subject: Can we use JavaPackager and a get full JRE? In-Reply-To: References: Message-ID: <1313F97E-1CA4-4AF9-B3B7-4AA19F18D116@gmail.com> > For now, OS X only, couldn?t you require your users to have the common, ?browser?, jre installed? Or, thinking about I guess you could require the jdk to be installed. Then normal Runtime would work, OS X I?m pretty sure and maybe cross platform. For Java 9 I thought the jdk/jre separation sort of goes away and you either just get the jdk tools or can include their module? Michael Hall From tobi at ultramixer.com Mon Aug 10 11:04:54 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 10 Aug 2015 13:04:54 +0200 Subject: Blur effect on live scene? Message-ID: Hi, is it possible to set a blur effect on the complete scene or maybe a part of it? I would like to place a pane over another pane (via StackPane) which blurs the underlaying pane? like a ?milk glass effect?? Any ideas? Best regards, Tobi From info at michaelhoffer.de Mon Aug 10 11:17:52 2015 From: info at michaelhoffer.de (Michael Hoffer) Date: Mon, 10 Aug 2015 13:17:52 +0200 Subject: Blur effect on live scene? In-Reply-To: References: Message-ID: Hi Tobias, a while ago I did some experiments in that direction: http://mihosoft.eu/?p=1025 Does that help? Regards, Michael 2015-08-10 13:04 GMT+02:00 Tobias Bley : > Hi, > > is it possible to set a blur effect on the complete scene or maybe a part > of it? I would like to place a pane over another pane (via StackPane) which > blurs the underlaying pane? like a ?milk glass effect?? > > Any ideas? > > Best regards, > Tobi > > -- Dipl.-Math. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de From tobi at ultramixer.com Mon Aug 10 11:29:28 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 10 Aug 2015 13:29:28 +0200 Subject: Blur effect on live scene? In-Reply-To: References: Message-ID: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> Hi Michael, thanks for your demo. Yes, that would be a solution, but I do not want this cpu / gpu consuming capture approach. In OpenGL it would be very simple to simulate this milke glass effect: simply create a transparent texture and use a shader in the GPU to blur the underlying content - no cpu usage needed. So my question is: In JavaFX I can apply a blur effect to a pane - that?s fine. But can I use the blur effect on a pane too to blur the underlying content? Best regards, Tobi > Am 10.08.2015 um 13:17 schrieb Michael Hoffer : > > Hi Tobias, > > a while ago I did some experiments in that direction: http://mihosoft.eu/?p=1025 Does that help? > > Regards, > Michael > > 2015-08-10 13:04 GMT+02:00 Tobias Bley >: > Hi, > > is it possible to set a blur effect on the complete scene or maybe a part of it? I would like to place a pane over another pane (via StackPane) which blurs the underlaying pane? like a ?milk glass effect?? > > Any ideas? > > Best regards, > Tobi > > > > > -- > Dipl.-Math. Michael Hoffer > > Twitter: @mihosoft > Webpage: www.mihosoft.eu > > Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) > Goethe-Universit?t > Kettenhofweg 139 > 60325 Frankfurt am Main > phone: +49 69 798 25254 > info at michaelhoffer.de From mike at plan99.net Mon Aug 10 12:13:22 2015 From: mike at plan99.net (Mike Hearn) Date: Mon, 10 Aug 2015 14:13:22 +0200 Subject: Blur effect on live scene? In-Reply-To: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> Message-ID: Yes, it can be done, and I have done this in my app. Take a look here: https://github.com/vinumeris/lighthouse/blob/master/client/src/main/java/lighthouse/Main.java#L474 I do it by taking a snapshot, then blurring that, then cross-fading, then replacing it with a live blur effect once done. I found this gave better frame rates than the simpler way of just animating the blur property of a blur effect, with very little visual degradation. Be aware that this won't work well on software pipelines, so I use some internal API to detect that and use a lighter weight effect instead. You can download a binary of the app from https://www.vinumeris.com/lighthouse if you want to see the effect in action (press one of the buttons at the top to trigger it). From tai.hu at veroanalytics.com Mon Aug 10 12:17:50 2015 From: tai.hu at veroanalytics.com (Tai Hu) Date: Mon, 10 Aug 2015 08:17:50 -0400 Subject: JavaFX Self-contained PKG and MacAppStore_PKG did not work In-Reply-To: References: <2B03BFAE-A1BB-44EC-8142-7A864A7AF126@veroanalytics.com> Message-ID: <23D2BE89-9DC5-4184-996F-35EBF0BF386F@veroanalytics.com> Danno, You are absolutely correct on this one. In my build script since I used native=?all?, .app, .dmg and .pkg were all generated. When I use pkg to install the app, it actually just updated .app under my build folder instead of /Applications. pkgutil ?pkg-info still think application is installed under /Applications. Once I deleted .app under my build folder. Then pkg works as expected. Thanks, Tai > On Aug 10, 2015, at 12:23 AM, Danno Ferrin wrote: > > Mac installer is weird. The install location in the installer is at best a strongly worded suggestion to the pkgutil code and I don't completely understand when it follows it and when it doesn't. > > What I have seen in my development is that if the package has been installed and or run anywhere else on the machine then the pkgutil will install the app into that location as an update to the existing application. So in my case I had an instance of the app that I had run from my source control build directory, and pkgutil chose to update that instance of the application rather than one I had in /Applicaitons that I drug in from a DMG. > > It appears that this is driven by the CFBundleIdentifier, so changing the identifier may get a clean install. > > Running pkgutil --pkg-info may tell you where it is installed or where it thinks it is installed. > > >> On Aug 7, 2015, at 9:11 PM, Tai Hu > wrote: >> >> Hi, >> I used JavaFX ant tasks to create all native packages on Mac OS X (JDK 8u51 on latest Mac OS X). Both .app and .dmg packages are working flawlessly. However, for PKG package, the very first installation was successful and my application show up in /Applications folder. However, if I delete my app from /Applications and use PKG package to install again, the installation process will always run successfully. However, my application did not show up inside of /Applications. I already tried to use pkgutil ?forget and rebooted my Mac. It is still the same result. Installation of PKG package are always successful. But my application is not installed under /Applications folder. >> >> Thanks, >> >> Tai > From tobi at ultramixer.com Mon Aug 10 12:28:22 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 10 Aug 2015 14:28:22 +0200 Subject: Blur effect on live scene? In-Reply-To: References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> Message-ID: <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> Hi Mike, yes, but that?s another demo of using snapshot approach?the question is: why can?t we use this effect in live? So one solution would be to set clip on the effect? Best, Tobi > Am 10.08.2015 um 14:13 schrieb Mike Hearn : > > Yes, it can be done, and I have done this in my app. Take a look here: > > https://github.com/vinumeris/lighthouse/blob/master/client/src/main/java/lighthouse/Main.java#L474 > > I do it by taking a snapshot, then blurring that, then cross-fading, then replacing it with a live blur effect once done. I found this gave better frame rates than the simpler way of just animating the blur property of a blur effect, with very little visual degradation. > > Be aware that this won't work well on software pipelines, so I use some internal API to detect that and use a lighter weight effect instead. > > You can download a binary of the app from https://www.vinumeris.com/lighthouse if you want to see the effect in action (press one of the buttons at the top to trigger it). From mike at plan99.net Mon Aug 10 12:54:41 2015 From: mike at plan99.net (Mike Hearn) Date: Mon, 10 Aug 2015 14:54:41 +0200 Subject: Blur effect on live scene? In-Reply-To: <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> Message-ID: > > yes, but that?s another demo of using snapshot approach?the question is: > why can?t we use this effect in live? > You can. It works, and can even be quite smooth if you have a good GPU and non-hidpi display. It just isn't smooth enough for my liking on retina displays. From tobi at ultramixer.com Mon Aug 10 13:39:29 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 10 Aug 2015 15:39:29 +0200 Subject: Blur effect on live scene? In-Reply-To: References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> Message-ID: <1766E390-BF54-4FC5-B279-6C15AD31E712@ultramixer.com> You only can set the blur effect on a whole pane but not on a part of it. What I want to do is to simulate the iOS and Mac OS X header? they blur their background which can scrolled under the header?take a look here: http://codepen.io/rikschennink/pen/zvcgx Is it possible in JavaFX to show the same node (or pane) twice? So we could blur one copy and clip it :) Best regards, Tobi > Am 10.08.2015 um 14:54 schrieb Mike Hearn : > > yes, but that?s another demo of using snapshot approach?the question is: why can?t we use this effect in live? > > You can. It works, and can even be quite smooth if you have a good GPU and non-hidpi display. It just isn't smooth enough for my liking on retina displays. From info at michaelhoffer.de Mon Aug 10 13:39:54 2015 From: info at michaelhoffer.de (Michael Hoffer) Date: Mon, 10 Aug 2015 15:39:54 +0200 Subject: Blur effect on live scene? In-Reply-To: References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> Message-ID: Hi Mike, I have to agree with Tobias. While the effect works live (that was the whole point of my demo video) it still does a lot of unnecessary copying between CPU and GPU. OpenGL works without that. It doesn't have to transfer data between CPU and GPU for each and every pulse. Unfortunately, I didn't find another way without using private API or patching OpenJFX. Ideas welcome :) Regards, Michael 2015-08-10 14:54 GMT+02:00 Mike Hearn : > yes, but that?s another demo of using snapshot approach?the question is: >> why can?t we use this effect in live? >> > > You can. It works, and can even be quite smooth if you have a good GPU and > non-hidpi display. It just isn't smooth enough for my liking on retina > displays. > -- Dipl.-Math. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de From herve.girod at gmail.com Mon Aug 10 16:42:01 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_girod?=) Date: Mon, 10 Aug 2015 18:42:01 +0200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: <55C3E977.2060604@oracle.com> References: <55C3E977.2060604@oracle.com> Message-ID: <792025F4-EE96-4770-B55E-C19EC223430E@gmail.com> It passed under my radar that we use classes in com.sun.javafx.css, and com.sun.javafx.css.parser, mainly : - CSSParser - Stylesheet - Selector - Rule The use case is to be able to process JavaFX stylesheets properties. Herv? Sent from my iPad > On 7 ao?t 2015, at 01:10, Jonathan Giles wrote: > > Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. > > Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). > > Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. > > So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: > > == 'Toolkit' API == > A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. > > == 'Traversal' API == > This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. > > == 'Collections Event' API == > There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. > > == 'Utils' API == > There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class (although there are no plans to move all the methods over!). > > == Miscellaneous API == > Finally, there are a few classes that popped up quite frequently. Here is the list, and my thoughts on what to do with them: > > 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - not a likely candidate for JDK 9. > 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - not a likely candidate for JDK 9. > 3) Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. > 4) PerformanceTracker: Same as Robot - good, but API might require more time than is available for JDK 9. > > == What about other private API == > If I've stated that an API you use isn't likely to make the cut for 9, there is another option: pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API. I should note that you shouldn't just dive in and do this - ping us and let us know first, so we can sync up and make sure the plan is feasible (and not overlapping). Because any large chunk of work would require moving through the JEP process, it is unlikely that anything other than small tweaks would be acceptable. One such example might be the PerformanceTracker. > > == Where to from here? == > The first milestone is to get JEP 253 into the main repo. That should hopefully be done before the end of August. Once that is done, focus can shift to the areas identified in this email. In the mean time, if there is any community feedback, please get it in ASAP so it can be included in the consideration. > > [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html > [2] http://openjdk.java.net/jeps/253 > > Thanks! > -- Jonathan From sirishreddy at gmail.com Mon Aug 10 18:27:36 2015 From: sirishreddy at gmail.com (Sirish Vadala) Date: Mon, 10 Aug 2015 11:27:36 -0700 Subject: Issue With Drag-n-Drop Message-ID: ?? NOTE: I have posted the same question on stackoverflow.com . ?? I am trying to implement a requirement to drag and drop documents attached in an email into a JavaFX 8 application running on jdk 8b45. I am able to drag and drop from any folder on my computer but not from an email attachment [Running on Microsoft Outlook Professional Plus 2010]. // MY VBOX WHERE I WANT TO DROP FILES INTO VBox bkgrndDocsVBox = new VBox(10.0); bkgrndDocsVBox.setPadding(new Insets(15, 10, 5, 10)); bkgrndDocsVBox.setStyle("-fx-border-color: transparent;"); bkgrndDocsVBox.setOnDragOver((final DragEvent event) -> { mouseDragOver(event, bkgrndDocsVBox); }); bkgrndDocsVBox.setOnDragDropped((final DragEvent event) -> { mouseDragDropped(event, backgroundDocsDataTable); }); bkgrndDocsVBox.setOnDragExited((final DragEvent event) -> { bkgrndDocsVBox.setStyle("-fx-border-color: transparent;"); }); .............................. .............................. private void mouseDragOver(DragEvent dragEvent, VBox bkgrndDocsVBox) { final Dragboard dragboard = dragEvent.getDragboard(); System.out.println("dragboard.hasFiles()::"+dragboard.hasFiles()); if (dragboard.hasFiles()) { bkgrndDocsVBox.setStyle("-fx-border-color: green;"); dragEvent.acceptTransferModes(TransferMode.ANY); } else { dragEvent.consume(); } } .............................. .............................. private void mouseDragDropped(DragEvent dragEvent, TableView bgDocsTable) { System.out.println("ENTER mouseDragDropped"); final Dragboard dragBoard = dragEvent.getDragboard(); boolean success = false; boolean isAccepted = false; // SAVE the FILES into the DATABASE .......... .......... .......... .......... .......... .......... .......... .......... } The above code works when I try to drag and drop files from a windows folder. However when I try to drag and drop files from an email attachment, the 'dragboard.hasFiles()::false' is displayed on the console and the functionality does not work. Please see the fully functional POC below: import javafx.util.Duration; import javafx.animation.KeyFrame; import javafx.animation.Timeline; import javafx.application.Application; import javafx.event.ActionEvent; import javafx.geometry.Pos; import javafx.scene.Scene; import javafx.scene.input.*; import javafx.scene.layout.VBox; import javafx.scene.paint.Color; import javafx.scene.text.Text; import javafx.stage.Stage; public class HelloDragAndDrop extends Application { @Override public void start(Stage stage) { stage.setTitle("Hello Drag And Drop"); VBox root = new VBox(); root.setStyle("-fx-border-color: transparent;"); root.setAlignment(Pos.CENTER); Scene scene = new Scene(root, 400, 200); scene.setFill(Color.WHITESMOKE); Text target = new Text("DROP HERE"); target.setScaleX(2.0); target.setScaleY(2.0); root.setOnDragOver((DragEvent event) -> { System.out.println("onDragOver"); System.out.println("event.getDragboard().hasFiles()::" + event.getDragboard().hasFiles()); if (event.getGestureSource() != root && event.getDragboard().hasFiles()) { event.acceptTransferModes(TransferMode.ANY); } event.consume(); }); root.setOnDragEntered((DragEvent event) -> { System.out.println("onDragEntered"); if (event.getGestureSource() != root && event.getDragboard().hasFiles()) { root.setStyle("-fx-border-color: green;"); } event.consume(); }); root.setOnDragExited((DragEvent event) -> { root.setStyle("-fx-border-color: transparent;"); event.consume(); }); root.setOnDragDropped((DragEvent event) -> { System.out.println("onDragDropped"); Dragboard db = event.getDragboard(); System.out.println("db.hasFiles()::" + db.hasFiles()); boolean success = false; if (db.hasFiles()) { target.setText("SUCCESSFULLY DROPPED"); success = true; } event.setDropCompleted(success); event.consume(); Timeline timeline = new Timeline( new KeyFrame(Duration.seconds(2), (ActionEvent actionEvent) -> { target.setText("DROP HERE"); }), new KeyFrame(Duration.seconds(5)) ); timeline.setCycleCount(1); timeline.play(); }); root.getChildren().add(target); stage.setScene(scene); stage.show(); } public static void main(String[] args) { Application.launch(args); } } On my console it always displays 'event.getDragboard().hasFiles()::false' when I drag and drop an attachment from Microsoft Outlook Professional Plus 2010. I would highly appreciate any hints on how this could be successfully implemented. Thanks. Thanks. -SV- From james.graham at oracle.com Mon Aug 10 18:29:36 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Aug 2015 11:29:36 -0700 Subject: Blur effect on live scene? In-Reply-To: References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> Message-ID: <55C8ED90.2000605@oracle.com> Let me understand what is going on here. I get the result you are trying to achieve - blur the scene as background for something. I get that Mac and iOS seem to have direct support for this technique which appears to work faster than what we provide via the Effect mechanism. I also get that attempts to make it appear better via snapshot will unfortunately involve a copy to main memory to produce the "Image" object. If we had a "snapshot to texture" mechanism then that might reduce the memory copying of the work around technique. I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... There is the implication that one can add a shader to an overlay texture that will cause it to have a dynamic "blurred lens" effect. I'm not familiar with how that would be done. AFAIK, shaders work on inputs and produce an output which is transferred to the destination using the pixel transfer functions and you can't source the destination pixels in the shader in order to blur them. I would imagine that the Mac/iOS technique is done by sourcing directly from the back buffer into the overlay texture using a blurring shader. That gives the overlay texture a solid background that is a blurred copy of the back buffer. They then draw the overlay contents (menu bar?) on top of that blurred background data and transfer the overlay texture back into the scene. The blurred vision you are seeing is not "the pixels being blurred through the overlay texture" but rather a very quickly managed "blurred copy of" the data in the underlying buffer. If the scene changes, then the entire process would need to be repeated on the new underlying pixels to get a new blurred copy of them as background in the overlay texture. I can also imagine that they may have more direct support for blurring (there is an OpenGL EXT_convolution extension which we do not use - using our own convolution shaders instead - which may potentially work faster than what we do). Also, they may be a little more efficient at managing the buffers involved in that dynamic operation (our Decora Effect engine isn't necessarily set up to use the "back buffer" as a source and so sometimes we may have to render parts of a scene an extra time specially to make an input texture for Decora). If I'm understanding all of this correctly, then it seems that: - it may be time to investigate tighter integration of Decora and Prism texture mechanisms (they use the same underlying objects, but don't have a good way to share pre-existing textures with each other). - Node.cache may provide some additional short-term techniques for achieving this effect - EXT_convolution may help us with performance if it is available - if worse comes to worst, we might have to add "blurred parent" as a direct feature of a Node to streamline the processing of this effect, but hopefully we can get there with some combination of the above. Or, if someone can enlighten me on some techniques they may be using that I'm not familiar with - please do! ...jim From mike at plan99.net Mon Aug 10 18:44:20 2015 From: mike at plan99.net (Mike Hearn) Date: Mon, 10 Aug 2015 20:44:20 +0200 Subject: Blur effect on live scene? In-Reply-To: <55C8ED90.2000605@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> Message-ID: That seems like a great summary Jim, thanks. From kevin.rushforth at oracle.com Mon Aug 10 19:53:37 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Aug 2015 12:53:37 -0700 Subject: Issue With Drag-n-Drop In-Reply-To: References: Message-ID: <55C90141.8050204@oracle.com> Please file a bug with a complete test program and instructions as to how to reproduce it. -- Kevin Sirish Vadala wrote: > ?? NOTE: I have posted the same question on stackoverflow.com > > . ?? > > I am trying to implement a requirement to drag and drop documents attached > in an email into a JavaFX 8 application running on jdk 8b45. I am able to > drag and drop from any folder on my computer but not from an email > attachment [Running on Microsoft Outlook Professional Plus 2010]. > > // MY VBOX WHERE I WANT TO DROP FILES INTO > VBox bkgrndDocsVBox = new VBox(10.0); > bkgrndDocsVBox.setPadding(new Insets(15, 10, 5, 10)); > > bkgrndDocsVBox.setStyle("-fx-border-color: transparent;"); > bkgrndDocsVBox.setOnDragOver((final DragEvent event) -> { > mouseDragOver(event, bkgrndDocsVBox); > }); > bkgrndDocsVBox.setOnDragDropped((final DragEvent event) -> { > mouseDragDropped(event, backgroundDocsDataTable); > }); > bkgrndDocsVBox.setOnDragExited((final DragEvent event) -> { > bkgrndDocsVBox.setStyle("-fx-border-color: transparent;"); > }); > > .............................. > .............................. > > private void mouseDragOver(DragEvent dragEvent, VBox bkgrndDocsVBox) { > final Dragboard dragboard = dragEvent.getDragboard(); > > System.out.println("dragboard.hasFiles()::"+dragboard.hasFiles()); > > if (dragboard.hasFiles()) { > bkgrndDocsVBox.setStyle("-fx-border-color: green;"); > dragEvent.acceptTransferModes(TransferMode.ANY); > } else { > dragEvent.consume(); > } > } > > .............................. > .............................. > private void mouseDragDropped(DragEvent dragEvent, TableView > bgDocsTable) { > > System.out.println("ENTER mouseDragDropped"); > final Dragboard dragBoard = dragEvent.getDragboard(); > boolean success = false; > boolean isAccepted = false; > > // SAVE the FILES into the DATABASE > .......... .......... .......... .......... > .......... .......... .......... .......... > } > The above code works when I try to drag and drop files from a windows > folder. However when I try to drag and drop files from an email attachment, > the 'dragboard.hasFiles()::false' is displayed on the console and the > functionality does not work. > > Please see the fully functional POC below: > > import javafx.util.Duration; > import javafx.animation.KeyFrame; > import javafx.animation.Timeline; > import javafx.application.Application; > import javafx.event.ActionEvent; > import javafx.geometry.Pos; > import javafx.scene.Scene; > import javafx.scene.input.*; > import javafx.scene.layout.VBox; > import javafx.scene.paint.Color; > import javafx.scene.text.Text; > import javafx.stage.Stage; > > public class HelloDragAndDrop extends Application { > > @Override > public void start(Stage stage) { > stage.setTitle("Hello Drag And Drop"); > > VBox root = new VBox(); > root.setStyle("-fx-border-color: transparent;"); > root.setAlignment(Pos.CENTER); > Scene scene = new Scene(root, 400, 200); > scene.setFill(Color.WHITESMOKE); > > Text target = new Text("DROP HERE"); > target.setScaleX(2.0); > target.setScaleY(2.0); > > root.setOnDragOver((DragEvent event) -> { > System.out.println("onDragOver"); > System.out.println("event.getDragboard().hasFiles()::" + > event.getDragboard().hasFiles()); > if (event.getGestureSource() != root && > event.getDragboard().hasFiles()) { > event.acceptTransferModes(TransferMode.ANY); > } > event.consume(); > }); > > root.setOnDragEntered((DragEvent event) -> { > System.out.println("onDragEntered"); > if (event.getGestureSource() != root && > event.getDragboard().hasFiles()) { > root.setStyle("-fx-border-color: green;"); > } > event.consume(); > }); > > root.setOnDragExited((DragEvent event) -> { > root.setStyle("-fx-border-color: transparent;"); > event.consume(); > }); > > root.setOnDragDropped((DragEvent event) -> { > System.out.println("onDragDropped"); > Dragboard db = event.getDragboard(); > System.out.println("db.hasFiles()::" + db.hasFiles()); > boolean success = false; > if (db.hasFiles()) { > target.setText("SUCCESSFULLY DROPPED"); > success = true; > } > event.setDropCompleted(success); > event.consume(); > > Timeline timeline = new Timeline( > new KeyFrame(Duration.seconds(2), (ActionEvent actionEvent) > -> { > target.setText("DROP HERE"); > }), > new KeyFrame(Duration.seconds(5)) > ); > timeline.setCycleCount(1); > timeline.play(); > > }); > > root.getChildren().add(target); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > Application.launch(args); > } > } > > On my console it always displays 'event.getDragboard().hasFiles()::false' > when I drag and drop an attachment from Microsoft Outlook Professional Plus > 2010. > > I would highly appreciate any hints on how this could be successfully > implemented. Thanks. > > Thanks. -SV- > From kevin.rushforth at oracle.com Mon Aug 10 19:54:09 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Aug 2015 12:54:09 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <55C90161.8090600@oracle.com> From sirishreddy at gmail.com Mon Aug 10 20:33:13 2015 From: sirishreddy at gmail.com (Sirish Vadala) Date: Mon, 10 Aug 2015 13:33:13 -0700 Subject: Issue With Drag-n-Drop In-Reply-To: <55C90141.8050204@oracle.com> References: <55C90141.8050204@oracle.com> Message-ID: Thank you Kevin! I have filed a bug in Oracle's Java Bug Database [Review ID: JI-9023310] with a complete test program and steps to reproduce the issue. Thanks. -SV- On Mon, Aug 10, 2015 at 12:53 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > Please file a bug with a complete test program and instructions as to how > to reproduce it. > > -- Kevin > > > Sirish Vadala wrote: > >> ?? NOTE: I have posted the same question on stackoverflow.com >> < >> http://stackoverflow.com/questions/31886709/drag-and-drop-an-email-attachment-into-a-javafx-8-application >> > >> . ?? >> >> >> I am trying to implement a requirement to drag and drop documents attached >> in an email into a JavaFX 8 application running on jdk 8b45. I am able to >> drag and drop from any folder on my computer but not from an email >> attachment [Running on Microsoft Outlook Professional Plus 2010]. >> >> // MY VBOX WHERE I WANT TO DROP FILES INTO >> VBox bkgrndDocsVBox = new VBox(10.0); >> bkgrndDocsVBox.setPadding(new Insets(15, 10, 5, 10)); >> >> bkgrndDocsVBox.setStyle("-fx-border-color: transparent;"); >> bkgrndDocsVBox.setOnDragOver((final DragEvent event) -> { >> mouseDragOver(event, bkgrndDocsVBox); >> }); >> bkgrndDocsVBox.setOnDragDropped((final DragEvent event) -> { >> mouseDragDropped(event, backgroundDocsDataTable); >> }); >> bkgrndDocsVBox.setOnDragExited((final DragEvent event) -> { >> bkgrndDocsVBox.setStyle("-fx-border-color: transparent;"); >> }); >> >> .............................. >> .............................. >> >> private void mouseDragOver(DragEvent dragEvent, VBox bkgrndDocsVBox) { >> final Dragboard dragboard = dragEvent.getDragboard(); >> >> System.out.println("dragboard.hasFiles()::"+dragboard.hasFiles()); >> >> if (dragboard.hasFiles()) { >> bkgrndDocsVBox.setStyle("-fx-border-color: green;"); >> dragEvent.acceptTransferModes(TransferMode.ANY); >> } else { >> dragEvent.consume(); >> } >> } >> >> .............................. >> .............................. >> private void mouseDragDropped(DragEvent dragEvent, TableView >> bgDocsTable) { >> >> System.out.println("ENTER mouseDragDropped"); >> final Dragboard dragBoard = dragEvent.getDragboard(); >> boolean success = false; >> boolean isAccepted = false; >> >> // SAVE the FILES into the DATABASE >> .......... .......... .......... .......... >> .......... .......... .......... .......... >> } >> The above code works when I try to drag and drop files from a windows >> folder. However when I try to drag and drop files from an email >> attachment, >> the 'dragboard.hasFiles()::false' is displayed on the console and the >> functionality does not work. >> >> Please see the fully functional POC below: >> >> import javafx.util.Duration; >> import javafx.animation.KeyFrame; >> import javafx.animation.Timeline; >> import javafx.application.Application; >> import javafx.event.ActionEvent; >> import javafx.geometry.Pos; >> import javafx.scene.Scene; >> import javafx.scene.input.*; >> import javafx.scene.layout.VBox; >> import javafx.scene.paint.Color; >> import javafx.scene.text.Text; >> import javafx.stage.Stage; >> >> public class HelloDragAndDrop extends Application { >> >> @Override >> public void start(Stage stage) { >> stage.setTitle("Hello Drag And Drop"); >> >> VBox root = new VBox(); >> root.setStyle("-fx-border-color: transparent;"); >> root.setAlignment(Pos.CENTER); >> Scene scene = new Scene(root, 400, 200); >> scene.setFill(Color.WHITESMOKE); >> >> Text target = new Text("DROP HERE"); >> target.setScaleX(2.0); >> target.setScaleY(2.0); >> >> root.setOnDragOver((DragEvent event) -> { >> System.out.println("onDragOver"); >> System.out.println("event.getDragboard().hasFiles()::" + >> event.getDragboard().hasFiles()); >> if (event.getGestureSource() != root && >> event.getDragboard().hasFiles()) { >> event.acceptTransferModes(TransferMode.ANY); >> } >> event.consume(); >> }); >> >> root.setOnDragEntered((DragEvent event) -> { >> System.out.println("onDragEntered"); >> if (event.getGestureSource() != root && >> event.getDragboard().hasFiles()) { >> root.setStyle("-fx-border-color: green;"); >> } >> event.consume(); >> }); >> >> root.setOnDragExited((DragEvent event) -> { >> root.setStyle("-fx-border-color: transparent;"); >> event.consume(); >> }); >> >> root.setOnDragDropped((DragEvent event) -> { >> System.out.println("onDragDropped"); >> Dragboard db = event.getDragboard(); >> System.out.println("db.hasFiles()::" + db.hasFiles()); >> boolean success = false; >> if (db.hasFiles()) { >> target.setText("SUCCESSFULLY DROPPED"); >> success = true; >> } >> event.setDropCompleted(success); >> event.consume(); >> >> Timeline timeline = new Timeline( >> new KeyFrame(Duration.seconds(2), (ActionEvent >> actionEvent) >> -> { >> target.setText("DROP HERE"); >> }), >> new KeyFrame(Duration.seconds(5)) >> ); >> timeline.setCycleCount(1); >> timeline.play(); >> >> }); >> >> root.getChildren().add(target); >> stage.setScene(scene); >> stage.show(); >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> } >> >> On my console it always displays 'event.getDragboard().hasFiles()::false' >> when I drag and drop an attachment from Microsoft Outlook Professional >> Plus >> 2010. >> >> I would highly appreciate any hints on how this could be successfully >> implemented. Thanks. >> >> Thanks. -SV- >> >> > From jonathan.giles at oracle.com Mon Aug 10 22:33:33 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 11 Aug 2015 10:33:33 +1200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: <792025F4-EE96-4770-B55E-C19EC223430E@gmail.com> References: <55C3E977.2060604@oracle.com> <792025F4-EE96-4770-B55E-C19EC223430E@gmail.com> Message-ID: <55C926BD.90609@oracle.com> It is likely that these classes will be included as part of JEP 253 (in subproject 3), so they will likely become public API. Javadoc output for this subproject will be posted in the next week or two. Keep your eyes peeled :-) -- Jonathan On 11/08/2015 4:42 a.m., Herv? girod wrote: > It passed under my radar that we use classes in com.sun.javafx.css, and com.sun.javafx.css.parser, mainly : > - CSSParser > - Stylesheet > - Selector > - Rule > > The use case is to be able to process JavaFX stylesheets properties. > > Herv? > > Sent from my iPad > >> On 7 ao?t 2015, at 01:10, Jonathan Giles wrote: >> >> Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. >> >> Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). >> >> Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. >> >> So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: >> >> == 'Toolkit' API == >> A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. >> >> == 'Traversal' API == >> This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. >> >> == 'Collections Event' API == >> There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. >> >> == 'Utils' API == >> There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class (although there are no plans to move all the methods over!). >> >> == Miscellaneous API == >> Finally, there are a few classes that popped up quite frequently. Here is the list, and my thoughts on what to do with them: >> >> 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - not a likely candidate for JDK 9. >> 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - not a likely candidate for JDK 9. >> 3) Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. >> 4) PerformanceTracker: Same as Robot - good, but API might require more time than is available for JDK 9. >> >> == What about other private API == >> If I've stated that an API you use isn't likely to make the cut for 9, there is another option: pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API. I should note that you shouldn't just dive in and do this - ping us and let us know first, so we can sync up and make sure the plan is feasible (and not overlapping). Because any large chunk of work would require moving through the JEP process, it is unlikely that anything other than small tweaks would be acceptable. One such example might be the PerformanceTracker. >> >> == Where to from here? == >> The first milestone is to get JEP 253 into the main repo. That should hopefully be done before the end of August. Once that is done, focus can shift to the areas identified in this email. In the mean time, if there is any community feedback, please get it in ASAP so it can be included in the consideration. >> >> [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html >> [2] http://openjdk.java.net/jeps/253 >> >> Thanks! >> -- Jonathan From jonathan.giles at oracle.com Mon Aug 10 22:36:38 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 11 Aug 2015 10:36:38 +1200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: References: <55C3E977.2060604@oracle.com> Message-ID: <55C92776.7030402@oracle.com> On 7/08/2015 9:51 p.m., Benjamin Gudehus wrote: > Hi Jonathan, > > thanks for the summary! > > >pull up your sleeves and work with us to get the API into a shape > where it is good enough to commit to as public API > > I'd like to help with the public API for profiling and performance > tracking (mainly PulseLogger, maybe PerformanceTracker). It would be good to discuss this via a JBS issue. Please file one and we can discuss logistics further. > > >These classes are com.sun.javafx.util.Utils, > com.sun.javafx.PlatformUtil, and > com.sun.javafx.application.PlatformImpl. As most of these classes are > just a collection of self-contained methods, it is quite likely that a > number of these methods will find public API alternatives in a new class > > Sounds good. TestFX has a dependency to > com.sun.javafx.application.ParametersImpl to provide the ability to > test multiple different `Application`s. It currently depends on > private fields and methods of internal classes. It is highly unlikely that ParemetersImpl will be made public API. > > >Robot: A good API to make public, but not a small API, so the scope > is possibly too great for JDK 9. > > The headless testing feature in TestFX has dependencies to > com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX > uses the AWT robot, the "normal" testing mode needs no access to the > internal APIs. > > The screenshot feature in headless testing depends on > com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. > > Additionally we also need access to com.sun.glass.ui.PlatformFactory > in order to activate Monocle on desktop systems. These areas are outside my area of expertise, but my understanding is that it is extremely unlikely that any of the classes you mentioned will become public API in JDK 9. -- Jonathan From herve.girod at gmail.com Tue Aug 11 00:31:38 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_girod?=) Date: Tue, 11 Aug 2015 02:31:38 +0200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: <55C926BD.90609@oracle.com> References: <55C3E977.2060604@oracle.com> <792025F4-EE96-4770-B55E-C19EC223430E@gmail.com> <55C926BD.90609@oracle.com> Message-ID: <35CD185D-D5EE-4081-AA9C-3DAD9D64C710@gmail.com> Thanks, I will ! :-) Sent from my iPad > On 11 ao?t 2015, at 00:33, Jonathan Giles wrote: > > It is likely that these classes will be included as part of JEP 253 (in subproject 3), so they will likely become public API. Javadoc output for this subproject will be posted in the next week or two. Keep your eyes peeled :-) > > -- Jonathan > >> On 11/08/2015 4:42 a.m., Herv? girod wrote: >> It passed under my radar that we use classes in com.sun.javafx.css, and com.sun.javafx.css.parser, mainly : >> - CSSParser >> - Stylesheet >> - Selector >> - Rule >> >> The use case is to be able to process JavaFX stylesheets properties. >> >> Herv? >> >> Sent from my iPad >> >>> On 7 ao?t 2015, at 01:10, Jonathan Giles wrote: >>> >>> Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. >>> >>> Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). >>> >>> Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. >>> >>> So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: >>> >>> == 'Toolkit' API == >>> A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. >>> >>> == 'Traversal' API == >>> This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. >>> >>> == 'Collections Event' API == >>> There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. >>> >>> == 'Utils' API == >>> There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class (although there are no plans to move all the methods over!). >>> >>> == Miscellaneous API == >>> Finally, there are a few classes that popped up quite frequently. Here is the list, and my thoughts on what to do with them: >>> >>> 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - not a likely candidate for JDK 9. >>> 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - not a likely candidate for JDK 9. >>> 3) Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. >>> 4) PerformanceTracker: Same as Robot - good, but API might require more time than is available for JDK 9. >>> >>> == What about other private API == >>> If I've stated that an API you use isn't likely to make the cut for 9, there is another option: pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API. I should note that you shouldn't just dive in and do this - ping us and let us know first, so we can sync up and make sure the plan is feasible (and not overlapping). Because any large chunk of work would require moving through the JEP process, it is unlikely that anything other than small tweaks would be acceptable. One such example might be the PerformanceTracker. >>> >>> == Where to from here? == >>> The first milestone is to get JEP 253 into the main repo. That should hopefully be done before the end of August. Once that is done, focus can shift to the areas identified in this email. In the mean time, if there is any community feedback, please get it in ASAP so it can be included in the consideration. >>> >>> [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html >>> [2] http://openjdk.java.net/jeps/253 >>> >>> Thanks! >>> -- Jonathan > From haenel at ultramixer.com Tue Aug 11 06:44:09 2015 From: haenel at ultramixer.com (=?utf-8?Q?Matthias_H=C3=A4nel?=) Date: Tue, 11 Aug 2015 08:44:09 +0200 Subject: Blur effect on live scene? In-Reply-To: <55C8ED90.2000605@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> Message-ID: <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> Hey Jim, internally we are argueing pretty often about pro and cons of different technologies espacially java. When I first read about JavaFX I was very happy to see a hardware accelerated approach in the Java world that could stop the common sense of laggy java-apps. From a software persepective I am located at the very first few layers right in the hardware (firmware) and right above (drivers, interfaces etc.). That's why please forgive me if I am wrong on UI specific stuff. This is not my expertice. Actually, I build the native opengl implementation for our software. That means it uses jogl, but it is pretty standard OGL. Therefor I a know a bit about the OGL state machine and their usage. I am very sure DirectX has similar techniques for any of those purposes. > Am 10.08.2015 um 20:29 schrieb Jim Graham : > > Let me understand what is going on here. > > I get the result you are trying to achieve - blur the scene as background for something. > > I get that Mac and iOS seem to have direct support for this technique which appears to work faster than what we provide via the Effect mechanism. > > I also get that attempts to make it appear better via snapshot will unfortunately involve a copy to main memory to produce the "Image" object. > > If we had a "snapshot to texture" mechanism then that might reduce the memory copying of the work around technique. Well, did you say there is no snapshot to texture in JavaFX? In plain OpenGL you can use FBO's (Frame Buffer Objects) to render them. This is nothing more than a snapshot. They are even sliceable and strechable. Yesterday we discussed the JavaFX API and we came to the conclusion that there must be tow APIs 1. standard copyFromRAMAnDraw 2. FBO based. Drawing to a framebuffer and manipulating. This is not only needed for this small effect here. It is much more. One very big damand of a new technology would be a feature that's called "conext sharing". This is one of the most important copy-prevention-mechanisms to us. That makes it possible to push an image to the graphics RAM and draw it two, three or even multiple times. > I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... I am not pretty sure what cache does. Probably some hasmap that holds objects and they are not instantly destroyed in the graphics RAM? > There is the implication that one can add a shader to an overlay texture that will cause it to have a dynamic "blurred lens" effect. I'm not familiar with how that would be done. AFAIK, shaders work on inputs and produce an output which is transferred to the destination using the pixel transfer functions and you can't source the destination pixels in the shader in order to blur them. I would imagine that the Mac/iOS technique is done by sourcing directly from the back buffer into the overlay texture using a blurring shader. That gives the overlay texture a solid background that is a blurred copy of the back buffer. They then draw the overlay contents (menu bar?) on top of that blurred background data and transfer the overlay texture back into the scene. The blurred vision you are seeing is not "the pixels being blurred through the overlay texture" but rather a very quickly managed "blurred copy of" the data in the underlying buffer. > If the scene changes, then the entire process would need to be repeated on the new underlying pixels to get a new blurred copy of them as background in the overlay texture. I can also imagine that they may have more direct support for blurring (there is an OpenGL EXT_convolution extension which we do not use - using our own convolution shaders instead - which may potentially work faster than what we do). Also, they may be a little more efficient at managing the buffers involved in that dynamic operation (our Decora Effect engine isn't necessarily set up to use the "back buffer" as a source and so sometimes we may have to render parts of a scene an extra time specially to make an input texture for Decora). I am not sure what Decora is, but you are right with the sourcing from the back. You can only shade 1:1 in OGL's shading Engine but that's not a real problem since we have FBO's :) The Background is rendered to an FBO. This FBO renders as a Background and a second time the same FBO is rendered as Blurry shaped Foreground. > > If I'm understanding all of this correctly, then it seems that: > > - it may be time to investigate tighter integration of Decora and Prism texture mechanisms (they use the same underlying objects, but don't have a good way to share pre-existing textures with each other). > > - Node.cache may provide some additional short-term techniques for achieving this effect > > - EXT_convolution may help us with performance if it is available > > - if worse comes to worst, we might have to add "blurred parent" as a direct feature of a Node to streamline the processing of this effect, but hopefully we can get there with some combination of the above. Well, I am not sure that you understood Tobis intention correctly :) I was never the intention to get this small little effect running in some way, but he is still testing the technology and to find the problematic stuff. From my current point the major problem with JavaFX is still the same. 1. Has a good API 2. renders most of its stuff in software, hence does not run performant 3. Has good approaches, but the overall sight on the technology is broken somewhere. I wonder JavaFX should be used in IOT stuff. I developed a lot of small nifty hardware tools. The main goal is ALWAYS to get thos most performance out of the least hardware. JavaFX does the opposite right now. It's not just this little example I have seem some bigger software products here build with JavaFX and it was still this "laggy java-apps"-feeling. I don't know the whole JavaFX core, but when there is always this kind of a discussion about a feature that leads to a software rendered variant, the you waste the power of a GPU. I wonder JavaFX could be ideal for iOS and Android, if the GPU rendering is done right. Is this not on the agenda? I wonder JavaFX would be the game changer for desktop apps and games. Personally, I would this is also just the case when the GPU is utilized in a good way. Desktops are much more capably and for Finance-Software it might be good to have SoftwareRendering but for any Media/Video/Game-Software it is needed to get the most power out of their GPU. We are not compared to other Java/JavaFX-Apps, but to native optimized Games and Media-Software. It took pretty long to get the JRE with JIT where it is now and you can even convince me from the performance and even time-to-market with standard JRE-Software. Well, on the other hand I don't know ONE Software that is using either Swing or even JavaFX for Media/Games besides us. Everytime I speak with other developers, I get the same answer: "We would love to use Swing/JavaFX, but it is not made for us." Most of the code their own drawing-API or even just use native code. The trough is. Java APIs are not made for high performance (sure in sever terms you can scale by hardware, but that is is meant) use, they can present little 60 fps Demos (at 100% cpu load) and that's it. The real world has a demand for a full flegded API that is performance optimized. Beeing a developer myself I know it's not that easy to achieve. The fallback would be the two API approach for above. The you can select what to do as a user. Currently, nobod knows what actually is going on and nobody cares until something is going out of order. regards Matthias From andrey.rusakov at oracle.com Tue Aug 11 09:31:11 2015 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Tue, 11 Aug 2015 12:31:11 +0300 Subject: Combobox issue with Windows 10 In-Reply-To: <55C7EC34.60405@oracle.com> References: <55C7EC34.60405@oracle.com> Message-ID: <55C9C0DF.6060908@oracle.com> Yes, I was able to reproduce that, but only on one machine, so I decided, that it is a driver issue, or something like that. I'll send you machine name so you can reproduce that. 10.08.2015 03:11, Jonathan Giles ?????: > I don't have a Windows 10 set up here yet, although if necessary I can > go through the process of installing Windows 10 as another boot option > on my PC. As it stands I can not reproduce this issue on my Windows 8 > install. > > It would probably be beneficial to try to get more data from your > users. Depending on how technical they are you can have them run a > tool like VisualVM to see if something is locking up. > > Thanks, > > -- Jonathan > > On 10/08/2015 1:13 a.m., Michael Berry wrote: >> After upgrading to windows 10, I've had many reports of users hitting >> this >> issue (https://bugs.openjdk.java.net/browse/JDK-8132897) whereby >> clicking >> any unfocused combobox in our application completely freezes it up. >> (Interestingly, tabbing so the combobox is selected first before >> clicking >> provides a workaround, but clearly this is not a good solution.) I >> haven't >> been able to reproduce unfortunately, but it's certainly causing >> problems >> our end and I can't imagine we're the only ones. >> >> Has anyone else noticed this and been able to reproduce it more >> reliably? I >> would look to contribute a fix, but not being able to reproduce makes it >> pretty much impossible. >> >> Michael > From hastebrot at gmail.com Tue Aug 11 18:52:29 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 11 Aug 2015 20:52:29 +0200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: References: <55C3E977.2060604@oracle.com> Message-ID: >would there be a command line switch in Java 9 that would grant TestFX access to internals? A command line switch like this would be great. On Mon, Aug 10, 2015 at 3:54 PM, wrote: > TestFX is a great tool. > > If needed for Testing (not release), would there be a command line switch > in Java 9 that would grant TestFX access to internals? > > > Neil > > > > > From: Benjamin Gudehus > To: jonathan.giles at oracle.com, > Cc: "openjfx-dev at openjdk.java.net" > Date: 08/07/2015 05:51 AM > Subject: Re: Results of review of private JavaFX API for > consideration to make public in JDK 9 > Sent by: "openjfx-dev" > ------------------------------ > > > > Hi Jonathan, > > thanks for the summary! > > >pull up your sleeves and work with us to get the API into a shape where it > is good enough to commit to as public API > > I'd like to help with the public API for profiling and performance tracking > (mainly PulseLogger, maybe PerformanceTracker). > > >These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, > and com.sun.javafx.application.PlatformImpl. As most of these classes are > just a collection of self-contained methods, it is quite likely that a > number of these methods will find public API alternatives in a new class > > Sounds good. TestFX has a dependency to > com.sun.javafx.application.ParametersImpl to provide the ability to test > multiple different `Application`s. It currently depends on private fields > and methods of internal classes. > > >Robot: A good API to make public, but not a small API, so the scope is > possibly too great for JDK 9. > > The headless testing feature in TestFX has dependencies to > com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the > AWT robot, the "normal" testing mode needs no access to the internal APIs. > > The screenshot feature in headless testing depends on > com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. > > Additionally we also need access to com.sun.glass.ui.PlatformFactory in > order to activate Monocle on desktop systems. > > --Benjamin > > On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles > wrote: > > > Hi all. In April of this year a discussion began when news broke that > with > > JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while > > back I posted a request to openjfx-dev for people to send me their JDeps > > output so that it could be analysed and used to inform our decisions > around > > which API we should try to promote into public API. The response was very > > useful (and I should note: its too late now, please don't send me anymore > > JDeps files), and I believe we have the beginnings of a plan on how to > move > > forward. > > > > Before I outline the plan, please note that this discussion would ideally > > _not_ devolve into a feature requests discussion. What we are wanting to > > talk about today is simply API that exists in the com.sun.* package > > namespace which we can conceivably bring out of this namespace for JDK 9. > > Developing new API is expressly out of scope (unless it is related to > > simplifying or wrapping the com.sun.* API). > > > > Another important point - UI control skins and a lot of very useful CSS > > API are being made public under JEP 253 [2]. A lot of the skin code has > > already been cleaned up, simplified, documented, etc, and will be merging > > into a repo very soon. I'll also post a separate post about JEP 253 soon. > > > > So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, > > which has been largely resolved by JEP 253)? I can sum it up in the > > following categories: > > > > == 'Toolkit' API == > > A lot of people use a small amount of API from Toolkit, such as the API > > for nested event loops, to fire a pulse, and to add / remove pulse > > listeners. Based on this analysis, the current thinking is to add API > into > > the javafx.application.Platform class to enable the first two use cases > > above (nested event loops and pulse firing). The third use case needs > more > > engineering effort, and is a far less common use case, so isn't being > > considered for JDK 9. > > > > == 'Traversal' API == > > This API lives in com.sun.javafx.scene.traversal, and is quite useful > when > > writing custom controls to ensure that keyboard traversal puts the focus > in > > the right node at the right time. My ControlsFX open source project is a > > common (ab)user of this API, so I have a vested interest in making this > > public. Having said this, the API is actually in quite good shape, and it > > is possible with just a little JavaDoc work it could make the move into > > javafx.scene.traversal. > > > > == 'Collections Event' API == > > There exists classes in com.sun.javafx.collections that are quite useful > > if you create your own custom ObservableList implementation and want to > > fire events at certain times. In my analysis there are only two projects > > using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent > > point is that this code is quite easy to reproduce, so, whilst I would > like > > to see this API public, it doesn't seem to make sense for JavaFX 9. > > > > == 'Utils' API == > > There exists three classes that are quite commonly used by people for the > > various utility methods contained within. These classes are > > com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and > > com.sun.javafx.application.PlatformImpl. As most of these classes are > just > > a collection of self-contained methods, it is quite likely that a number > of > > these methods will find public API alternatives in a new class (although > > there are no plans to move all the methods over!). > > > > == Miscellaneous API == > > Finally, there are a few classes that popped up quite frequently. Here is > > the list, and my thoughts on what to do with them: > > > > 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - > not > > a likely candidate for JDK 9. > > 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - > not > > a likely candidate for JDK 9. > > 3) Robot: A good API to make public, but not a small API, so the scope is > > possibly too great for JDK 9. > > 4) PerformanceTracker: Same as Robot - good, but API might require more > > time than is available for JDK 9. > > > > == What about other private API == > > If I've stated that an API you use isn't likely to make the cut for 9, > > there is another option: pull up your sleeves and work with us to get the > > API into a shape where it is good enough to commit to as public API. I > > should note that you shouldn't just dive in and do this - ping us and let > > us know first, so we can sync up and make sure the plan is feasible (and > > not overlapping). Because any large chunk of work would require moving > > through the JEP process, it is unlikely that anything other than small > > tweaks would be acceptable. One such example might be the > > PerformanceTracker. > > > > == Where to from here? == > > The first milestone is to get JEP 253 into the main repo. That should > > hopefully be done before the end of August. Once that is done, focus can > > shift to the areas identified in this email. In the mean time, if there > is > > any community feedback, please get it in ASAP so it can be included in > the > > consideration. > > > > [1] > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html > > [2] http://openjdk.java.net/jeps/253 > > > > Thanks! > > -- Jonathan > > > > > > > NOTICE *from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or is > legally privileged, and sender does not waive confidentiality or privilege. > If received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. * From hastebrot at gmail.com Tue Aug 11 19:32:21 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 11 Aug 2015 21:32:21 +0200 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: <55C92776.7030402@oracle.com> References: <55C3E977.2060604@oracle.com> <55C92776.7030402@oracle.com> Message-ID: >It would be good to discuss this via a JBS issue. Please file one and we can discuss logistics further. I have no project author status on JBS to create an issue. :/ I could sign the Oracle Contributor Agreement, but I doubt I will able provide the two required non-trivial patches anytime soon in order to become an author. This was much easier with the previous OpenJFX issue system. On Tue, Aug 11, 2015 at 12:36 AM, Jonathan Giles wrote: > > On 7/08/2015 9:51 p.m., Benjamin Gudehus wrote: > >> Hi Jonathan, >> >> thanks for the summary! >> >> >pull up your sleeves and work with us to get the API into a shape where >> it is good enough to commit to as public API >> >> I'd like to help with the public API for profiling and performance >> tracking (mainly PulseLogger, maybe PerformanceTracker). >> > > It would be good to discuss this via a JBS issue. Please file one and we > can discuss logistics further. > >> >> >These classes are com.sun.javafx.util.Utils, >> com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. >> As most of these classes are just a collection of self-contained methods, >> it is quite likely that a number of these methods will find public API >> alternatives in a new class >> >> Sounds good. TestFX has a dependency to >> com.sun.javafx.application.ParametersImpl to provide the ability to test >> multiple different `Application`s. It currently depends on private fields >> and methods of internal classes. >> > It is highly unlikely that ParemetersImpl will be made public API. > >> >> >Robot: A good API to make public, but not a small API, so the scope is >> possibly too great for JDK 9. >> >> The headless testing feature in TestFX has dependencies to >> com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the >> AWT robot, the "normal" testing mode needs no access to the internal APIs. >> >> The screenshot feature in headless testing depends on >> com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. >> >> Additionally we also need access to com.sun.glass.ui.PlatformFactory in >> order to activate Monocle on desktop systems. >> > > These areas are outside my area of expertise, but my understanding is that > it is extremely unlikely that any of the classes you mentioned will become > public API in JDK 9. > > -- Jonathan > From kevin.rushforth at oracle.com Tue Aug 11 20:09:00 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Aug 2015 13:09:00 -0700 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: References: <55C3E977.2060604@oracle.com> <55C92776.7030402@oracle.com> Message-ID: <55CA565C.6040106@oracle.com> Anyone can create a bug here: http://bugs.java.com/ No, it isn't the same as having direct access to JIRA, but the bugs will end up in the same bug database. -- Kevin Benjamin Gudehus wrote: >> It would be good to discuss this via a JBS issue. Please file one and we >> > can discuss logistics further. > > I have no project author status on JBS to create an issue. :/ I could sign > the Oracle Contributor Agreement, but I doubt I will able provide the two > required non-trivial patches anytime soon in order to become an author. > This was much easier with the previous OpenJFX issue system. > > > > On Tue, Aug 11, 2015 at 12:36 AM, Jonathan Giles > wrote: > > >> On 7/08/2015 9:51 p.m., Benjamin Gudehus wrote: >> >> >>> Hi Jonathan, >>> >>> thanks for the summary! >>> >>> >>>> pull up your sleeves and work with us to get the API into a shape where >>>> >>> it is good enough to commit to as public API >>> >>> I'd like to help with the public API for profiling and performance >>> tracking (mainly PulseLogger, maybe PerformanceTracker). >>> >>> >> It would be good to discuss this via a JBS issue. Please file one and we >> can discuss logistics further. >> >> >>>> These classes are com.sun.javafx.util.Utils, >>>> >>> com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. >>> As most of these classes are just a collection of self-contained methods, >>> it is quite likely that a number of these methods will find public API >>> alternatives in a new class >>> >>> Sounds good. TestFX has a dependency to >>> com.sun.javafx.application.ParametersImpl to provide the ability to test >>> multiple different `Application`s. It currently depends on private fields >>> and methods of internal classes. >>> >>> >> It is highly unlikely that ParemetersImpl will be made public API. >> >> >>>> Robot: A good API to make public, but not a small API, so the scope is >>>> >>> possibly too great for JDK 9. >>> >>> The headless testing feature in TestFX has dependencies to >>> com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the >>> AWT robot, the "normal" testing mode needs no access to the internal APIs. >>> >>> The screenshot feature in headless testing depends on >>> com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. >>> >>> Additionally we also need access to com.sun.glass.ui.PlatformFactory in >>> order to activate Monocle on desktop systems. >>> >>> >> These areas are outside my area of expertise, but my understanding is that >> it is extremely unlikely that any of the classes you mentioned will become >> public API in JDK 9. >> >> -- Jonathan >> >> From kevin.rushforth at oracle.com Tue Aug 11 20:11:07 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Aug 2015 13:11:07 -0700 Subject: Results of review of private JavaFX API for consideration to make public in JDK 9 In-Reply-To: References: <55C3E977.2060604@oracle.com> Message-ID: <55CA56DB.8070907@oracle.com> Yes. And we will certainly need to use this for our own unit testing, too. Details are tbd, but you will be able to use it for testing. I note that this is only for testing purposes, although standalone apps will be able to make use of it as well (no such provision will be made for applets or web start apps). As with today using internal packages is not supported and is discouraged, except for testing. -- Kevin Benjamin Gudehus wrote: >> would there be a command line switch in Java 9 that would grant TestFX >> > access to internals? > > A command line switch like this would be great. > > On Mon, Aug 10, 2015 at 3:54 PM, wrote: > > >> TestFX is a great tool. >> >> If needed for Testing (not release), would there be a command line switch >> in Java 9 that would grant TestFX access to internals? >> >> >> Neil >> >> >> >> >> From: Benjamin Gudehus >> To: jonathan.giles at oracle.com, >> Cc: "openjfx-dev at openjdk.java.net" >> Date: 08/07/2015 05:51 AM >> Subject: Re: Results of review of private JavaFX API for >> consideration to make public in JDK 9 >> Sent by: "openjfx-dev" >> ------------------------------ >> >> >> >> Hi Jonathan, >> >> thanks for the summary! >> >> >>> pull up your sleeves and work with us to get the API into a shape where it >>> >> is good enough to commit to as public API >> >> I'd like to help with the public API for profiling and performance tracking >> (mainly PulseLogger, maybe PerformanceTracker). >> >> >>> These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, >>> >> and com.sun.javafx.application.PlatformImpl. As most of these classes are >> just a collection of self-contained methods, it is quite likely that a >> number of these methods will find public API alternatives in a new class >> >> Sounds good. TestFX has a dependency to >> com.sun.javafx.application.ParametersImpl to provide the ability to test >> multiple different `Application`s. It currently depends on private fields >> and methods of internal classes. >> >> >>> Robot: A good API to make public, but not a small API, so the scope is >>> >> possibly too great for JDK 9. >> >> The headless testing feature in TestFX has dependencies to >> com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the >> AWT robot, the "normal" testing mode needs no access to the internal APIs. >> >> The screenshot feature in headless testing depends on >> com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. >> >> Additionally we also need access to com.sun.glass.ui.PlatformFactory in >> order to activate Monocle on desktop systems. >> >> --Benjamin >> >> On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles >> wrote: >> >> >>> Hi all. In April of this year a discussion began when news broke that >>> >> with >> >>> JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while >>> back I posted a request to openjfx-dev for people to send me their JDeps >>> output so that it could be analysed and used to inform our decisions >>> >> around >> >>> which API we should try to promote into public API. The response was very >>> useful (and I should note: its too late now, please don't send me anymore >>> JDeps files), and I believe we have the beginnings of a plan on how to >>> >> move >> >>> forward. >>> >>> Before I outline the plan, please note that this discussion would ideally >>> _not_ devolve into a feature requests discussion. What we are wanting to >>> talk about today is simply API that exists in the com.sun.* package >>> namespace which we can conceivably bring out of this namespace for JDK 9. >>> Developing new API is expressly out of scope (unless it is related to >>> simplifying or wrapping the com.sun.* API). >>> >>> Another important point - UI control skins and a lot of very useful CSS >>> API are being made public under JEP 253 [2]. A lot of the skin code has >>> already been cleaned up, simplified, documented, etc, and will be merging >>> into a repo very soon. I'll also post a separate post about JEP 253 soon. >>> >>> So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, >>> which has been largely resolved by JEP 253)? I can sum it up in the >>> following categories: >>> >>> == 'Toolkit' API == >>> A lot of people use a small amount of API from Toolkit, such as the API >>> for nested event loops, to fire a pulse, and to add / remove pulse >>> listeners. Based on this analysis, the current thinking is to add API >>> >> into >> >>> the javafx.application.Platform class to enable the first two use cases >>> above (nested event loops and pulse firing). The third use case needs >>> >> more >> >>> engineering effort, and is a far less common use case, so isn't being >>> considered for JDK 9. >>> >>> == 'Traversal' API == >>> This API lives in com.sun.javafx.scene.traversal, and is quite useful >>> >> when >> >>> writing custom controls to ensure that keyboard traversal puts the focus >>> >> in >> >>> the right node at the right time. My ControlsFX open source project is a >>> common (ab)user of this API, so I have a vested interest in making this >>> public. Having said this, the API is actually in quite good shape, and it >>> is possible with just a little JavaDoc work it could make the move into >>> javafx.scene.traversal. >>> >>> == 'Collections Event' API == >>> There exists classes in com.sun.javafx.collections that are quite useful >>> if you create your own custom ObservableList implementation and want to >>> fire events at certain times. In my analysis there are only two projects >>> using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent >>> point is that this code is quite easy to reproduce, so, whilst I would >>> >> like >> >>> to see this API public, it doesn't seem to make sense for JavaFX 9. >>> >>> == 'Utils' API == >>> There exists three classes that are quite commonly used by people for the >>> various utility methods contained within. These classes are >>> com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and >>> com.sun.javafx.application.PlatformImpl. As most of these classes are >>> >> just >> >>> a collection of self-contained methods, it is quite likely that a number >>> >> of >> >>> these methods will find public API alternatives in a new class (although >>> there are no plans to move all the methods over!). >>> >>> == Miscellaneous API == >>> Finally, there are a few classes that popped up quite frequently. Here is >>> the list, and my thoughts on what to do with them: >>> >>> 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - >>> >> not >> >>> a likely candidate for JDK 9. >>> 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - >>> >> not >> >>> a likely candidate for JDK 9. >>> 3) Robot: A good API to make public, but not a small API, so the scope is >>> possibly too great for JDK 9. >>> 4) PerformanceTracker: Same as Robot - good, but API might require more >>> time than is available for JDK 9. >>> >>> == What about other private API == >>> If I've stated that an API you use isn't likely to make the cut for 9, >>> there is another option: pull up your sleeves and work with us to get the >>> API into a shape where it is good enough to commit to as public API. I >>> should note that you shouldn't just dive in and do this - ping us and let >>> us know first, so we can sync up and make sure the plan is feasible (and >>> not overlapping). Because any large chunk of work would require moving >>> through the JEP process, it is unlikely that anything other than small >>> tweaks would be acceptable. One such example might be the >>> PerformanceTracker. >>> >>> == Where to from here? == >>> The first milestone is to get JEP 253 into the main repo. That should >>> hopefully be done before the end of August. Once that is done, focus can >>> shift to the areas identified in this email. In the mean time, if there >>> >> is >> >>> any community feedback, please get it in ASAP so it can be included in >>> >> the >> >>> consideration. >>> >>> [1] >>> >>> >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html >> >>> [2] http://openjdk.java.net/jeps/253 >>> >>> Thanks! >>> -- Jonathan >>> >>> >> >> >> NOTICE *from Ab Initio: This email (including any attachments) may >> contain information that is subject to confidentiality obligations or is >> legally privileged, and sender does not waive confidentiality or privilege. >> If received in error, please notify the sender, delete this email, and make >> no further use, disclosure, or distribution. * >> From steve.hruda at hexagongeospatial.com Wed Aug 12 11:45:02 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Wed, 12 Aug 2015 11:45:02 +0000 Subject: [WebView] Java user's Timezone will be ignored? Message-ID: Hi, maybe I did something wrong, but could it be possible that the JavaFX?s WebView ignores the Java user?s timezone? Used he -Duser.timezone VM Argument 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 james.graham at oracle.com Thu Aug 13 00:15:29 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 12 Aug 2015 17:15:29 -0700 Subject: Blur effect on live scene? In-Reply-To: <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> Message-ID: <55CBE1A1.2030904@oracle.com> Hi Matthias, On 8/10/2015 11:44 PM, Matthias H?nel wrote: >> If we had a "snapshot to texture" mechanism then that might reduce the memory copying of the work around technique. > > Well, did you say there is no snapshot to texture in JavaFX? In plain OpenGL you can use FBO's (Frame Buffer Objects) to render them. This is nothing more than a snapshot. They are even sliceable and strechable. To be clear, there is no API to directly specify "snapshot this Node/Group to a texture and give me a handle to it to manipulate". As I said later, there is a mechanism to get Node/trees rendered into a texture and that is the Node cache property, but we do that behind the scenes, the developer doesn't get a handle to the texture in that case. >> I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... > > I am not pretty sure what cache does. Probably some hasmap that holds objects and they are not instantly destroyed in the graphics RAM? It is not a hashmap. It is a hint to save the rendering of that node in a buffer: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#cacheProperty I don't like the way that this doc comment is worded as it implies that using it on a node that is blurred is unwise, but if the node is animated over even GPU acceleration of the rendering and blurring operations" are going to have some cost that it could save. > From my current point the major problem with JavaFX is still the same. > > 1. Has a good API > 2. renders most of its stuff in software, hence does not run performant > 3. Has good approaches, but the overall sight on the technology is broken somewhere. I am not sure how you come to the conclusion that it renders most of its stuff in software. It renders quite a lot in hardware. Even the example here of using snapshot to optimize a blurred background - the rendering of the scene is done in hw. It is only copied to main memory because the API requires a persistent image. If you render that image to the screen it is copied back into a texture and reused from that texture unless we run low on vram. There is no rendering in software there, only use of a heap buffer for persistent storage... ...jim From tobi at ultramixer.com Thu Aug 13 07:43:59 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 13 Aug 2015 09:43:59 +0200 Subject: JarBundler project moved to GitHub Message-ID: Hi, to who it may concern: We have moved the JarBundler project from SourceForge to GitHub. Additionally we ported the project structure to maven structure and published a new version "JarBundler 3.2.2" to the maven repository. JarBundler is an ant task to create Mac ?*.app? bundles for Apples JDK 6. https://github.com/UltraMixer/JarBundler Best regards, Tobi From haenel at ultramixer.com Thu Aug 13 08:29:40 2015 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Thu, 13 Aug 2015 10:29:40 +0200 Subject: Blur effect on live scene? In-Reply-To: <55CBE1A1.2030904@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> <55CBE1A1.2030904@oracle.com> Message-ID: Hi Jim, > On 8/10/2015 11:44 PM, Matthias H?nel wrote: >>> If we had a "snapshot to texture" mechanism then that might reduce the memory copying of the work around technique. >> >> Well, did you say there is no snapshot to texture in JavaFX? In plain OpenGL you can use FBO's (Frame Buffer Objects) to render them. This is nothing more than a snapshot. They are even sliceable and strechable. > > To be clear, there is no API to directly specify "snapshot this Node/Group to a texture and give me a handle to it to manipulate". As I said later, there is a mechanism to get Node/trees rendered into a texture and that is the Node cache property, but we do that behind the scenes, the developer doesn't get a handle to the texture in that case. Okay, that are different OSI layers. On the lowest OpenGL Layer it could be a FBO implementation. On higher layers there must be APIs that support this. >>> I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... >> >> I am not pretty sure what cache does. Probably some hasmap that holds objects and they are not instantly destroyed in the graphics RAM? > > It is not a hashmap. > > It is a hint to save the rendering of that node in a buffer: > > https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#cacheProperty > > I don't like the way that this doc comment is worded as it implies that using it on a node that is blurred is unwise, but if the node is animated over even GPU acceleration of the rendering and blurring operations" are going to have some cost that it could save. That documentation says nodes are cached as Bitmaps. In GPU or in CPU space? It is not clear here. I suspect it is in CPU RAM space. That will just lead to more copy-tasks from CPU to GPU or not? If optimized there is no benefit at all as stated in the docu "note that on some platforms such as GPU accelerated platforms there is little benefit". Actually, I would expect that renered Nodes are textures in GPU-VRAM to get the most performance out of it. >> From my current point the major problem with JavaFX is still the same. >> >> 1. Has a good API >> 2. renders most of its stuff in software, hence does not run performant >> 3. Has good approaches, but the overall sight on the technology is broken somewhere. > > I am not sure how you come to the conclusion that it renders most of its stuff in software. It renders quite a lot in hardware. Even the example here of using snapshot to optimize a blurred background - the rendering of the scene is done in hw. It is only copied to main memory because the API requires a persistent image. If you render that image to the screen it is copied back into a texture and reused from that texture unless we run low on vram. There is no rendering in software there, only use of a heap buffer for persistent storage... Your point is that it uses hardware to render and it just uses snapshot to satisfy the API? My current understaning is ... what happens in our blurred-effect case? 1. the application constructs a JavaFX node tree. 2. the node tree is rendered mostly in hardware (shader effects and so on on top) to the main framebuffer 3. Snapshot calls ReadPixels (or whatever it is called on the particular platform) 4. JavaFX encapsulates this "new" image with Object 5. We draw the "new" image with effects to the OGL context with the same node-tree API as we did before on top of the first node-tree. That works, but there is too much CPU and memcpy involved for my believe. Furthermore ReadPixels takes forever in an OpenGL perspective. Since this is just one very simple effect, it is actually not good to spend more than approx. 20% CPU (i7) load on it. I expect 0% (not noticable) for this blurry effect. The ideal implementation from my perspective would be: 1. the application constructs a JavaFX node tree. 2. the node tree is rendered mostly in hardware (shader effects and so on on top) to a virtual framebuffer in the GPU space 3. The virtual framebuffer is drawn by a simple drawVert-call for the background 4. The virtual framebuffer is drawn once again shaped and shaded (blurry filter) by another drawVert-call This would reduce CPU usage by a very big amount of cycles. (From an Shader perspective we could reduce GPU load one more if we merge point 3 and 4 and run a partially shader to blur just the upper corner. Well this is much more hand-coding and not good integratable in a bigger API.) Even tough these ReadPixel-Functions to retrieve GPU rendered images to the CPU space are not very fast. I have to correct my assumption that JavaFX renders most of its stuff in software a bit. The wording "rendering" was not correct. This feeling comes probaly from the massive use of Snapshot. I have not understood the entire core of Prism until now. In some implementation of snapshot it seems to do the rendering entirely in software. That might only the fallback, but the ReadPixels-Stuff is still valid. Additionally to that I have the feeling that not all effects can be translated to Shaders and so it falls back pretty fast to software rendering. The main problem here is that as a developer we cannot see, where we are and what is done fast and what is not. Is there a better way to debug performance leaks in JavaFX than guessing? OpenGL tools don't help much, since they are soo far away, that it is pretty hard to get the right way. Tiny-Offtopic: I already meantioned on this list that JFXPanel (Swing) is way below it's expectations. The main reason there is also the use of the snapshot function instead of letting render JavaFX in it's own heavy weight window. In our small test case a simple List displayed via JFXPanel was not even to render more than 1 fps and it slowed down the entire Swing-UI. Since I know jogle and it's canvas implementation, would it be good to have a similar heavy weight JFX canvas in Swing? This would let JFX use it's full hardware rendered power. Matthias From johan at lodgon.com Thu Aug 13 10:12:41 2015 From: johan at lodgon.com (Johan Vos) Date: Thu, 13 Aug 2015 12:12:41 +0200 Subject: Blur effect on live scene? In-Reply-To: References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> Message-ID: Great summary indeed. Any work that results in offload work from the CPU to the GPU would be very much appreciated. It would be a huge performance gain for mobile. Thanks, - Johan 2015-08-10 20:44 GMT+02:00 Mike Hearn : > That seems like a great summary Jim, thanks. > From james.graham at oracle.com Thu Aug 13 16:46:34 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Aug 2015 09:46:34 -0700 Subject: Blur effect on live scene? In-Reply-To: <55C8ED90.2000605@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> Message-ID: <55CCC9EA.1090102@oracle.com> One more complication to note - in some cases an application might want to blur an entire underlying node/pane. In other cases an application might want to blur a piece of an underlying node/pane that lies behind an overlay node. Those two cases would be accomplished in different ways with the current JavaFX APIs. The first case would simply involve adding a blur effect to the underlying node (and possibly turning on its cache hint for performance if it is relatively static). The second case could only be done by either using snapshot on the underlying nodes, or by recreating a duplicate copy of the underlying tree and setting a blur effect and a clip (and possibly cache=true) on the copy and placing that behind the overlying node... ...jim On 8/10/2015 11:29 AM, Jim Graham wrote: > Let me understand what is going on here. > > I get the result you are trying to achieve - blur the scene as > background for something. > > I get that Mac and iOS seem to have direct support for this technique > which appears to work faster than what we provide via the Effect mechanism. > > I also get that attempts to make it appear better via snapshot will > unfortunately involve a copy to main memory to produce the "Image" object. > > If we had a "snapshot to texture" mechanism then that might reduce the > memory copying of the work around technique. I'd argue that we sort of > do have something like that - it is the cache flag. If a Node is cached > then we do have a copy of it in a texture and that can help make the > Blur Effect work more efficiently, but there may be some additional > copies between textures if everything isn't set up right. Still, that > is an avenue for someone to check to see if there isn't a better way to > achieve this effect in the short term... > > There is the implication that one can add a shader to an overlay texture > that will cause it to have a dynamic "blurred lens" effect. I'm not > familiar with how that would be done. AFAIK, shaders work on inputs and > produce an output which is transferred to the destination using the > pixel transfer functions and you can't source the destination pixels in > the shader in order to blur them. I would imagine that the Mac/iOS > technique is done by sourcing directly from the back buffer into the > overlay texture using a blurring shader. That gives the overlay texture > a solid background that is a blurred copy of the back buffer. They then > draw the overlay contents (menu bar?) on top of that blurred background > data and transfer the overlay texture back into the scene. The blurred > vision you are seeing is not "the pixels being blurred through the > overlay texture" but rather a very quickly managed "blurred copy of" the > data in the underlying buffer. If the scene changes, then the entire > process would need to be repeated on the new underlying pixels to get a > new blurred copy of them as background in the overlay texture. I can > also imagine that they may have more direct support for blurring (there > is an OpenGL EXT_convolution extension which we do not use - using our > own convolution shaders instead - which may potentially work faster than > what we do). Also, they may be a little more efficient at managing the > buffers involved in that dynamic operation (our Decora Effect engine > isn't necessarily set up to use the "back buffer" as a source and so > sometimes we may have to render parts of a scene an extra time specially > to make an input texture for Decora). > > If I'm understanding all of this correctly, then it seems that: > > - it may be time to investigate tighter integration of Decora and Prism > texture mechanisms (they use the same underlying objects, but don't have > a good way to share pre-existing textures with each other). > > - Node.cache may provide some additional short-term techniques for > achieving this effect > > - EXT_convolution may help us with performance if it is available > > - if worse comes to worst, we might have to add "blurred parent" as a > direct feature of a Node to streamline the processing of this effect, > but hopefully we can get there with some combination of the above. > > Or, if someone can enlighten me on some techniques they may be using > that I'm not familiar with - please do! > > ...jim > From james.graham at oracle.com Thu Aug 13 17:06:35 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Aug 2015 10:06:35 -0700 Subject: Blur effect on live scene? In-Reply-To: References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> <55CBE1A1.2030904@oracle.com> Message-ID: <55CCCE9B.2080604@oracle.com> On 8/13/2015 1:29 AM, Matthias H?nel wrote: >>>> I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... >>> >>> I am not pretty sure what cache does. Probably some hasmap that holds objects and they are not instantly destroyed in the graphics RAM? >> >> It is not a hashmap. >> >> It is a hint to save the rendering of that node in a buffer: >> >> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#cacheProperty >> >> I don't like the way that this doc comment is worded as it implies that using it on a node that is blurred is unwise, but if the node is animated over even GPU acceleration of the rendering and blurring operations" are going to have some cost that it could save. > > That documentation says nodes are cached as Bitmaps. In GPU or in CPU space? It is not clear here. I suspect it is in CPU RAM space. > That will just lead to more copy-tasks from CPU to GPU or not? If optimized there is no benefit at all as stated in the docu "note that on some platforms such as GPU accelerated platforms there is little benefit". As I said, the doc comments there are confusing. "bitmap" here, despite any capitalization, is a general term for "some type of pixel store". On GPU accelerated platforms, this is a vram texture/FBO. > Actually, I would expect that renered Nodes are textures in GPU-VRAM to get the most performance out of it. Yes, nodes with the cache hint are rendered into VRAM textures and reused for subsequent frames if the cache hint is set - subject to the policies of the cacheHint property if any (mainly transform) properties of the node are changed in the meantime. >>> From my current point the major problem with JavaFX is still the same. >>> >>> 1. Has a good API >>> 2. renders most of its stuff in software, hence does not run performant >>> 3. Has good approaches, but the overall sight on the technology is broken somewhere. >> >> I am not sure how you come to the conclusion that it renders most of its stuff in software. It renders quite a lot in hardware. Even the example here of using snapshot to optimize a blurred background - the rendering of the scene is done in hw. It is only copied to main memory because the API requires a persistent image. If you render that image to the screen it is copied back into a texture and reused from that texture unless we run low on vram. There is no rendering in software there, only use of a heap buffer for persistent storage... > > Your point is that it uses hardware to render and it just uses snapshot to satisfy the API? What is "it"? JavaFX doesn't "use" snapshot anywhere. It provides the snapshot API so the developer can use snapshot where the developer wants to, but JavaFX doesn't invoke the snapshot API on its own. In particular, the node cache hint does not use the snapshot API under the covers. > My current understaning is ... what happens in our blurred-effect case? To be clear, you are describing what happens in a particular implementation of the blurred-effect case. The implementation that uses snapshot, which may be the popular technique in use at this time. > 1. the application constructs a JavaFX node tree. > 2. the node tree is rendered mostly in hardware (shader effects and so on on top) to the main framebuffer Correct > 3. Snapshot calls ReadPixels (or whatever it is called on the particular platform) > 4. JavaFX encapsulates this "new" image with Object Technically, snapshot does its own (hardware accelerated) rendering into a separate GPU texture/FBO and does a read pixels on that texture. It then encapsulates those pixels into an Image object. This snapshot operation need only be done once if the underlying node tree is static. > 5. We draw the "new" image with effects to the OGL context with the same node-tree API as we did before on top of the first node-tree. Correct. Note that when you render that Image object its pixels are cached in vram and that vram copy is reused from frame to frame. So, if you reuse the one snapshot then there was only one trip from vram to memory and back to vram on the first frame you did this and then everything should be done in vram for subsequent frames reusing the same snapshot. > That works, but there is too much CPU and memcpy involved for my believe. Furthermore ReadPixels takes forever in > an OpenGL perspective. If the underlying tree is static, though, that readpixels operation only happens once at the start of the operation, but you are correct that it would be much better if it didn't need to happen at all. > Since this is just one very simple effect, it is actually not good to spend more than approx. 20% CPU (i7) load on it. > I expect 0% (not noticable) for this blurry effect. That would be ideal. We may need new API to get there, but there are also options to consider that may get us there in the short term. In particular, cached nodes - which are already present in the API - may get us closer to that goal. > The ideal implementation from my perspective would be: > 1. the application constructs a JavaFX node tree. > 2. the node tree is rendered mostly in hardware (shader effects and so on on top) to a virtual framebuffer in the GPU space > 3. The virtual framebuffer is drawn by a simple drawVert-call for the background > 4. The virtual framebuffer is drawn once again shaped and shaded (blurry filter) by another drawVert-call If you set the cache hint to true on the underlying tree then this may be approximately what happens in our current implementation. The part I would still need to investigate would be how well the effects machinery (called Decora) can reuse the cached version of the nodes. If it doesn't attempt to reuse the cached version of the nodes then it might end up re-rendering the tree. > I have to correct my assumption that JavaFX renders most of its stuff in software a bit. The wording "rendering" was not correct. > This feeling comes probaly from the massive use of Snapshot. I have not understood the entire core of Prism until now. > In some implementation of snapshot it seems to do the rendering entirely in software. That might only the fallback, but the > ReadPixels-Stuff is still valid. To be clear, snapshot was mainly created for its namesake - to produce static copies of the scene data to be saved as images for putting into documentation. Alternate uses that were considered were for generating thumbnails of scenes for an application that could open/close various scene graph panes. One wouldn't use the Windows "print screen" API in a performance intensive part of one's application either. It is great that it can be used for this particular result, but it was not designed to be performant in that respect. Note that the primary snapshot API is the asynchronous version with the callback to deliver the data. The non-asynchronous version is mostly just a helper around that, but it stalls the rendering pipeline to complete its work. None of that was designed for insertion into a running animation technique. > Tiny-Offtopic: I already meantioned on this list that JFXPanel (Swing) is way below it's expectations. The main reason there is also the use > of the snapshot function instead of letting render JavaFX in it's own heavy weight window. In our small test case a simple List > displayed via JFXPanel was not even to render more than 1 fps and it slowed down the entire Swing-UI. Since I know jogle and it's canvas > implementation, would it be good to have a similar heavy weight JFX canvas in Swing? This would let JFX use it's full hardware rendered power. It doesn't use snapshot per-se, but it does do something similar. Sharing contexts and GPU resources with AWT/Java2D is on a wish list, but architecturally we aren't there. Kevin would know more about our challenges on that front than me... ...jim From james.graham at oracle.com Thu Aug 13 17:40:16 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Aug 2015 10:40:16 -0700 Subject: Blur effect on live scene? In-Reply-To: References: Message-ID: <55CCD680.1070502@oracle.com> What I would do to blur an entire scene is to add the blur to the top level of it. If the stuff on top of the blur is re-rendering a lot, then I'd add setCache(true) to that same top-level node: oldroot.setCache(true); oldroot.setEffect(blur); Group newroot = new Group(newroot, overlay); set(newroot); // Remember to undo effect and cache when removing overlay If the blur radius is going to be animated: oldroot.setCache(true); Group blurroot = new Group(oldroot); blurroot.setEffect(blur); // Possibly set cache on blurroot if overlay animates more // than blur radius... Group newroot = new Group(blurroot, overlay); set(newroot); (now animating the blur radius will hopefully pick up the data from the cached oldroot, but I'd need some testing to make sure we've done our bookkeeping correctly for that case, otherwise we may end up re-rendering the oldroot scene every time anyway.) ...jim On 8/10/2015 4:04 AM, Tobias Bley wrote: > Hi, > > is it possible to set a blur effect on the complete scene or maybe a part of it? I would like to place a pane over another pane (via StackPane) which blurs the underlaying pane? like a ?milk glass effect?? > > Any ideas? > > Best regards, > Tobi > From kevin.rushforth at oracle.com Thu Aug 13 19:33:04 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Aug 2015 12:33:04 -0700 Subject: Blur effect on live scene? In-Reply-To: <55CCCE9B.2080604@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> <55CBE1A1.2030904@oracle.com> <55CCCE9B.2080604@oracle.com> Message-ID: <55CCF0F0.8080502@oracle.com> Seems there are a few different issues here. I'll weigh in on a couple of them. To summarize what Jim has already said: * We always do GPU hardware rendering wherever possible * Node caching was intended as a hint to the system to cache the result of potentially expensive effects into a texture (which is rendered into by the GPU) and re-render that texture when needed. Jim was suggesting that an application might be able to use that mechanism to do something other than its original purpose. * Snapshot was intended to allow an application to take (as the name suggests) a snapshot of a scene or node rendered into an image and return that image to the application. We don't use snapshot internally, rather various "render and then get the results" operations like snapshot, node caching, and rendering to a JFXPanel all use similar mechanisms which boil down to "render to texture" via OpenGL or D3D. We have considered providing new API to allow more of a "live render-to-texture" operation in the future, but haven't thought about it recently. Much of the discussion has been centered on what is possible with the current JavaFX API, but there has also been some discussion on what might be done with a new API. Anyway, to comment on a couple specific points, I have some inline comments below. Jim Graham wrote: > > On 8/13/2015 1:29 AM, Matthias H?nel wrote: >>>>> I'd argue that we sort of do have something like that - it is the >>>>> cache flag. If a Node is cached then we do have a copy of it in a >>>>> texture and that can help make the Blur Effect work more >>>>> efficiently, but there may be some additional copies between >>>>> textures if everything isn't set up right. Still, that is an >>>>> avenue for someone to check to see if there isn't a better way to >>>>> achieve this effect in the short term... >>>> >>>> I am not pretty sure what cache does. Probably some hasmap that >>>> holds objects and they are not instantly destroyed in the graphics >>>> RAM? >>> >>> It is not a hashmap. >>> >>> It is a hint to save the rendering of that node in a buffer: >>> >>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#cacheProperty >>> >>> >>> I don't like the way that this doc comment is worded as it implies >>> that using it on a node that is blurred is unwise, but if the node >>> is animated over even GPU acceleration of the rendering and blurring >>> operations" are going to have some cost that it could save. >> >> That documentation says nodes are cached as Bitmaps. In GPU or in CPU >> space? It is not clear here. I suspect it is in CPU RAM space. >> That will just lead to more copy-tasks from CPU to GPU or not? If >> optimized there is no benefit at all as stated in the docu "note that >> on some platforms such as GPU accelerated platforms there is little >> benefit". > > As I said, the doc comments there are confusing. "bitmap" here, > despite any capitalization, is a general term for "some type of pixel > store". On GPU accelerated platforms, this is a vram texture/FBO. > >> Actually, I would expect that renered Nodes are textures in GPU-VRAM >> to get the most performance out of it. > > Yes, nodes with the cache hint are rendered into VRAM textures and > reused for subsequent frames if the cache hint is set - subject to the > policies of the cacheHint property if any (mainly transform) > properties of the node are changed in the meantime. > >>>> From my current point the major problem with JavaFX is still the >>>> same. >>>> >>>> 1. Has a good API >>>> 2. renders most of its stuff in software, hence does not run >>>> performant >>>> 3. Has good approaches, but the overall sight on the technology is >>>> broken somewhere. >>> >>> I am not sure how you come to the conclusion that it renders most of >>> its stuff in software. It renders quite a lot in hardware. Even >>> the example here of using snapshot to optimize a blurred background >>> - the rendering of the scene is done in hw. It is only copied to >>> main memory because the API requires a persistent image. If you >>> render that image to the screen it is copied back into a texture and >>> reused from that texture unless we run low on vram. There is no >>> rendering in software there, only use of a heap buffer for >>> persistent storage... >> >> Your point is that it uses hardware to render and it just uses >> snapshot to satisfy the API? > > What is "it"? > > JavaFX doesn't "use" snapshot anywhere. It provides the snapshot API > so the developer can use snapshot where the developer wants to, but > JavaFX doesn't invoke the snapshot API on its own. > > In particular, the node cache hint does not use the snapshot API under > the covers. > >> My current understaning is ... what happens in our blurred-effect case? > > To be clear, you are describing what happens in a particular > implementation of the blurred-effect case. The implementation that > uses snapshot, which may be the popular technique in use at this time. > >> 1. the application constructs a JavaFX node tree. >> 2. the node tree is rendered mostly in hardware (shader effects and >> so on on top) to the main framebuffer > > Correct > >> 3. Snapshot calls ReadPixels (or whatever it is called on the >> particular platform) >> 4. JavaFX encapsulates this "new" image with Object > > Technically, snapshot does its own (hardware accelerated) rendering > into a separate GPU texture/FBO and does a read pixels on that > texture. It then encapsulates those pixels into an Image object. > > This snapshot operation need only be done once if the underlying node > tree is static. > >> 5. We draw the "new" image with effects to the OGL context with the >> same node-tree API as we did before on top of the first node-tree. > > Correct. Note that when you render that Image object its pixels are > cached in vram and that vram copy is reused from frame to frame. So, > if you reuse the one snapshot then there was only one trip from vram > to memory and back to vram on the first frame you did this and then > everything should be done in vram for subsequent frames reusing the > same snapshot. > >> That works, but there is too much CPU and memcpy involved for my >> believe. Furthermore ReadPixels takes forever in >> an OpenGL perspective. > > If the underlying tree is static, though, that readpixels operation > only happens once at the start of the operation, but you are correct > that it would be much better if it didn't need to happen at all. > >> Since this is just one very simple effect, it is actually not good to >> spend more than approx. 20% CPU (i7) load on it. >> I expect 0% (not noticable) for this blurry effect. > > That would be ideal. We may need new API to get there, but there are > also options to consider that may get us there in the short term. In > particular, cached nodes - which are already present in the API - may > get us closer to that goal. > >> The ideal implementation from my perspective would be: >> 1. the application constructs a JavaFX node tree. >> 2. the node tree is rendered mostly in hardware (shader effects and >> so on on top) to a virtual framebuffer in the GPU space >> 3. The virtual framebuffer is drawn by a simple drawVert-call for the >> background >> 4. The virtual framebuffer is drawn once again shaped and shaded >> (blurry filter) by another drawVert-call > > If you set the cache hint to true on the underlying tree then this may > be approximately what happens in our current implementation. The part > I would still need to investigate would be how well the effects > machinery (called Decora) can reuse the cached version of the nodes. > If it doesn't attempt to reuse the cached version of the nodes then it > might end up re-rendering the tree. This would an interesting experiment, and would let us know how easily applications could do what they need with the existing API. If there are limitations or performance bottlenecks we can look into fixing them. >> I have to correct my assumption that JavaFX renders most of its stuff >> in software a bit. The wording "rendering" was not correct. >> This feeling comes probaly from the massive use of Snapshot. I have >> not understood the entire core of Prism until now. >> In some implementation of snapshot it seems to do the rendering >> entirely in software. That might only the fallback, but the >> ReadPixels-Stuff is still valid. > > To be clear, snapshot was mainly created for its namesake - to produce > static copies of the scene data to be saved as images for putting into > documentation. Alternate uses that were considered were for > generating thumbnails of scenes for an application that could > open/close various scene graph panes. One wouldn't use the Windows > "print screen" API in a performance intensive part of one's > application either. It is great that it can be used for this > particular result, but it was not designed to be performant in that > respect. Note that the primary snapshot API is the asynchronous > version with the callback to deliver the data. The non-asynchronous > version is mostly just a helper around that, but it stalls the > rendering pipeline to complete its work. None of that was designed > for insertion into a running animation technique. Exactly. >> Tiny-Offtopic: I already meantioned on this list that JFXPanel >> (Swing) is way below it's expectations. The main reason there is also >> the use >> of the snapshot function instead of letting render JavaFX in it's own >> heavy weight window. In our small test case a simple List >> displayed via JFXPanel was not even to render more than 1 fps and it >> slowed down the entire Swing-UI. Since I know jogle and it's canvas >> implementation, would it be good to have a similar heavy weight JFX >> canvas in Swing? This would let JFX use it's full hardware rendered >> power. > > It doesn't use snapshot per-se, but it does do something similar. > Sharing contexts and GPU resources with AWT/Java2D is on a wish list, > but architecturally we aren't there. Kevin would know more about our > challenges on that front than me... I haven't looked recently at what it would take to share resources between Java2D and AWT, but that seems separate from the question of whether we could use a heavy-weight JFXCanvas as opposed to the current lightweight JFXPanel. We haven't considered that since there are limitations with heavyweight components. I am not aware of any performance problems that are as serious as "simple List displayed via JFXPanel was not even to render more than 1 fps". Do you have a test case? I do note that we did have a bug on Mac retina displays that was recently fixed which killed performance. Was that what you were running your 1fps program on? -- Kevin > > ...jim From james.graham at oracle.com Thu Aug 13 21:08:07 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Aug 2015 14:08:07 -0700 Subject: Blur effect on live scene? In-Reply-To: <55CCF0F0.8080502@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> <55CBE1A1.2030904@oracle.com> <55CCCE9B.2080604@oracle.com> <55CCF0F0.8080502@oracle.com> Message-ID: <55CD0737.7070102@oracle.com> On 8/13/2015 12:33 PM, Kevin Rushforth wrote: > * Node caching was intended as a hint to the system to cache the result > of potentially expensive effects into a texture (which is rendered into > by the GPU) and re-render that texture when needed. Jim was suggesting > that an application might be able to use that mechanism to do something > other than its original purpose. I'm not sure my suggestions were fully understood. I didn't mean to imply that the node cache property and hints could be used as a "render to texture and give me the texture" mechanism, but that many cases where the developer might think "what I want is a mechanism to render some scene into a texture so that I could do something with it" really boil down to cases where sprinkling in a few setCache(true) calls might achieve what they want more directly. In the end, we'd rather have a direct mechanism to have the developer tell us what they want to have happen and then we might cache various parts of the scene graph automatically in pursuit of that goal so that the developer doesn't have to think about "well I know this is going to perform badly so I want to start caching my own pixels". The node cache property is sort of a request to "do that pixel caching thing for me", but with limited scope. Sometimes, though, that limited scope is exactly what the application needs. My subsequent mail that gave a few examples of regrouping items with effects and cache properties being set demonstrates how node caching is intended to take care of these details for you... ...jim From kevin.rushforth at oracle.com Thu Aug 13 21:30:56 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Aug 2015 14:30:56 -0700 Subject: Blur effect on live scene? In-Reply-To: <55CD0737.7070102@oracle.com> References: <1C2FCF3D-489C-42D4-99D8-91F4CD89F88A@ultramixer.com> <10ED155F-6224-4712-824B-00F07D0306D2@ultramixer.com> <55C8ED90.2000605@oracle.com> <6DADB1F7-B270-4DAE-99D7-09163F49783C@ultramixer.com> <55CBE1A1.2030904@oracle.com> <55CCCE9B.2080604@oracle.com> <55CCF0F0.8080502@oracle.com> <55CD0737.7070102@oracle.com> Message-ID: <55CD0C90.9050008@oracle.com> Jim Graham wrote: > On 8/13/2015 12:33 PM, Kevin Rushforth wrote: >> * Node caching was intended as a hint to the system to cache the result >> of potentially expensive effects into a texture (which is rendered into >> by the GPU) and re-render that texture when needed. Jim was suggesting >> that an application might be able to use that mechanism to do something >> other than its original purpose. > > I'm not sure my suggestions were fully understood. I didn't mean to > imply that the node cache property and hints could be used as a > "render to texture and give me the texture" mechanism, but that many > cases where the developer might think "what I want is a mechanism to > render some scene into a texture so that I could do something with it" > really boil down to cases where sprinkling in a few setCache(true) > calls might achieve what they want more directly. Yes, that is a more clear way to look at it. > In the end, we'd rather have a direct mechanism to have the developer > tell us what they want to have happen and then we might cache various > parts of the scene graph automatically in pursuit of that goal so that > the developer doesn't have to think about "well I know this is going > to perform badly so I want to start caching my own pixels". The node > cache property is sort of a request to "do that pixel caching thing > for me", but with limited scope. Sometimes, though, that limited > scope is exactly what the application needs. > > My subsequent mail that gave a few examples of regrouping items with > effects and cache properties being set demonstrates how node caching > is intended to take care of these details for you... Hopefully one of our enterprising app developers can try it and report the results. Thanks! -- Kevin > > ...jim From kevin.rushforth at oracle.com Thu Aug 13 22:56:00 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Aug 2015 15:56:00 -0700 Subject: HEADS-UP: Dropping support for some older Linux distros in JDK 9 Message-ID: <55CD2080.9060203@oracle.com> As a heads-up, we are changing our production build environment for JavaFX to Oracle Linux 7 with a dependency on GLIBC_2.14. This means that JavaFX applications will stop running on some older Linux distros, specifically Oracle Linux 6. I filed an issue in JBS [1] to track this change. The reason for this is to support the latest version of GStreamer [2] which requires a newer version of GLib than what is available on OL 6. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8133596 [2] http://openjdk.java.net/jeps/257 From steve.hruda at hexagongeospatial.com Fri Aug 14 13:46:49 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Fri, 14 Aug 2015 13:46:49 +0000 Subject: [PieChart] separator looks blurred since 8u40 Message-ID: Hi, I have a problem since Java 8u40. As you can see at the following link, the PieChart looks blurred if I set the background of the pie?s programmatically. The same works without any problem if I use JDK 8u25. Shows the difference https://drive.google.com/file/d/0B7P_rknS1TWxeXk0Y21aMXduYXM/view?usp=sharing In my application I have to style the Chart without an CSS, therefore I use PieChart.lookupAll to get the correct nodes. The sample code: https://drive.google.com/file/d/0B7P_rknS1TWxZDJVS09IbDlfa3c/view?usp=sharing Is this is an issue or do I something wrong? Thanks in advance, 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 kevin.rushforth at oracle.com Fri Aug 14 13:56:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Aug 2015 06:56:15 -0700 Subject: [PieChart] separator looks blurred since 8u40 In-Reply-To: References: Message-ID: <55CDF37F.5080000@oracle.com> I don't think this issue is anything you are doing wrong. More likely it is a bug in JavaFX. Have you tried this with 8u60? We made changes in the rendering of Region nodes in 8u40 specifically for region borders (which I think is what is used for Pie charts). We made follow-on fixes in 8u60 -- see https://bugs.openjdk.java.net/browse/JDK-8089063 -- that may or may not have addressed this. If this still fails for you with 8u60, please file a bug. -- Kevin Hruda, Steve wrote: > Hi, > I have a problem since Java 8u40. As you can see at the following link, the PieChart looks blurred if I set the background of the pie?s programmatically. > > The same works without any problem if I use JDK 8u25. > > Shows the difference > https://drive.google.com/file/d/0B7P_rknS1TWxeXk0Y21aMXduYXM/view?usp=sharing > > In my application I have to style the Chart without an CSS, therefore I use PieChart.lookupAll to get the correct nodes. > > The sample code: > https://drive.google.com/file/d/0B7P_rknS1TWxZDJVS09IbDlfa3c/view?usp=sharing > > Is this is an issue or do I something wrong? > > Thanks in advance, > 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 steve.hruda at hexagongeospatial.com Fri Aug 14 14:14:22 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Fri, 14 Aug 2015 14:14:22 +0000 Subject: [PieChart] separator looks blurred since 8u40 In-Reply-To: <55CDF37F.5080000@oracle.com> References: <55CDF37F.5080000@oracle.com> Message-ID: Should this fix already included in build 1.8.0_60-ea-b25 ? Because I didn't see any difference https://drive.google.com/file/d/0B7P_rknS1TWxR2JyeHVSLUZ0U2s/view?usp=sharing 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: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] Sent: Friday, August 14, 2015 3:56 PM To: Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: [PieChart] separator looks blurred since 8u40 I don't think this issue is anything you are doing wrong. More likely it is a bug in JavaFX. Have you tried this with 8u60? We made changes in the rendering of Region nodes in 8u40 specifically for region borders (which I think is what is used for Pie charts). We made follow-on fixes in 8u60 -- see https://bugs.openjdk.java.net/browse/JDK-8089063 -- that may or may not have addressed this. If this still fails for you with 8u60, please file a bug. -- Kevin Hruda, Steve wrote: > Hi, > I have a problem since Java 8u40. As you can see at the following link, the PieChart looks blurred if I set the background of the pie?s programmatically. > > The same works without any problem if I use JDK 8u25. > > Shows the difference > https://drive.google.com/file/d/0B7P_rknS1TWxeXk0Y21aMXduYXM/view?usp= > sharing > > In my application I have to style the Chart without an CSS, therefore I use PieChart.lookupAll to get the correct nodes. > > The sample code: > https://drive.google.com/file/d/0B7P_rknS1TWxZDJVS09IbDlfa3c/view?usp= > sharing > > Is this is an issue or do I something wrong? > > Thanks in advance, > 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 kevin.rushforth at oracle.com Fri Aug 14 14:17:12 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Aug 2015 07:17:12 -0700 Subject: [PieChart] separator looks blurred since 8u40 In-Reply-To: References: <55CDF37F.5080000@oracle.com> Message-ID: <55CDF868.1000905@oracle.com> Yes, the fix for JDK-8089063 went in before 8u60-b25, so if you can file a bug that would be great. -- Kevin Hruda, Steve wrote: > Should this fix already included in build 1.8.0_60-ea-b25 ? Because I didn't see any difference > > https://drive.google.com/file/d/0B7P_rknS1TWxR2JyeHVSLUZ0U2s/view?usp=sharing > > > > > 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: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] > Sent: Friday, August 14, 2015 3:56 PM > To: Hruda, Steve > Cc: openjfx-dev at openjdk.java.net > Subject: Re: [PieChart] separator looks blurred since 8u40 > > I don't think this issue is anything you are doing wrong. More likely it is a bug in JavaFX. Have you tried this with 8u60? We made changes in the rendering of Region nodes in 8u40 specifically for region borders (which I think is what is used for Pie charts). We made follow-on fixes in 8u60 -- see https://bugs.openjdk.java.net/browse/JDK-8089063 -- that may or may not have addressed this. > > If this still fails for you with 8u60, please file a bug. > > -- Kevin > > > Hruda, Steve wrote: > >> Hi, >> I have a problem since Java 8u40. As you can see at the following link, the PieChart looks blurred if I set the background of the pie?s programmatically. >> >> The same works without any problem if I use JDK 8u25. >> >> Shows the difference >> https://drive.google.com/file/d/0B7P_rknS1TWxeXk0Y21aMXduYXM/view?usp= >> sharing >> >> In my application I have to style the Chart without an CSS, therefore I use PieChart.lookupAll to get the correct nodes. >> >> The sample code: >> https://drive.google.com/file/d/0B7P_rknS1TWxZDJVS09IbDlfa3c/view?usp= >> sharing >> >> Is this is an issue or do I something wrong? >> >> Thanks in advance, >> 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 steve.hruda at hexagongeospatial.com Fri Aug 14 14:21:37 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Fri, 14 Aug 2015 14:21:37 +0000 Subject: [PieChart] separator looks blurred since 8u40 In-Reply-To: <55CDF868.1000905@oracle.com> References: <55CDF37F.5080000@oracle.com> <55CDF868.1000905@oracle.com> Message-ID: Done ? I field a bug at bugreport.java.com Thanks Kevin! From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] Sent: Friday, August 14, 2015 4:17 PM To: Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: [PieChart] separator looks blurred since 8u40 Yes, the fix for JDK-8089063 went in before 8u60-b25, so if you can file a bug that would be great. -- Kevin Hruda, Steve wrote: Should this fix already included in build 1.8.0_60-ea-b25 ? Because I didn't see any difference https://drive.google.com/file/d/0B7P_rknS1TWxR2JyeHVSLUZ0U2s/view?usp=sharing 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. 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: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] Sent: Friday, August 14, 2015 3:56 PM To: Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: [PieChart] separator looks blurred since 8u40 I don't think this issue is anything you are doing wrong. More likely it is a bug in JavaFX. Have you tried this with 8u60? We made changes in the rendering of Region nodes in 8u40 specifically for region borders (which I think is what is used for Pie charts). We made follow-on fixes in 8u60 -- see https://bugs.openjdk.java.net/browse/JDK-8089063 -- that may or may not have addressed this. If this still fails for you with 8u60, please file a bug. -- Kevin Hruda, Steve wrote: Hi, I have a problem since Java 8u40. As you can see at the following link, the PieChart looks blurred if I set the background of the pie?s programmatically. The same works without any problem if I use JDK 8u25. Shows the difference https://drive.google.com/file/d/0B7P_rknS1TWxeXk0Y21aMXduYXM/view?usp= sharing In my application I have to style the Chart without an CSS, therefore I use PieChart.lookupAll to get the correct nodes. The sample code: https://drive.google.com/file/d/0B7P_rknS1TWxZDJVS09IbDlfa3c/view?usp= sharing Is this is an issue or do I something wrong? Thanks in advance, 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 kevin.rushforth at oracle.com Fri Aug 14 15:04:14 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Aug 2015 08:04:14 -0700 Subject: [PieChart] separator looks blurred since 8u40 In-Reply-To: References: <55CDF37F.5080000@oracle.com> <55CDF868.1000905@oracle.com> Message-ID: <55CE036E.6070509@oracle.com> Sure, and thank you for filing it. We'll take a look at it. -- Kevin Hruda, Steve wrote: > > Done ? I field a bug at bugreport.java.com > > > > Thanks Kevin! > > > > *From:* Kevin Rushforth [mailto:kevin.rushforth at oracle.com] > *Sent:* Friday, August 14, 2015 4:17 PM > *To:* Hruda, Steve > *Cc:* openjfx-dev at openjdk.java.net > *Subject:* Re: [PieChart] separator looks blurred since 8u40 > > > > Yes, the fix for JDK-8089063 went in before 8u60-b25, so if you can > file a bug that would be great. > > -- Kevin > > > Hruda, Steve wrote: > > Should this fix already included in build 1.8.0_60-ea-b25 ? Because I didn't see any difference > > > > https://drive.google.com/file/d/0B7P_rknS1TWxR2JyeHVSLUZ0U2s/view?usp=sharing > > > > > > > > > > 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. > > > > > > > > > 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: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] > > Sent: Friday, August 14, 2015 3:56 PM > > To: Hruda, Steve > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: [PieChart] separator looks blurred since 8u40 > > > > I don't think this issue is anything you are doing wrong. More likely it is a bug in JavaFX. Have you tried this with 8u60? We made changes in the rendering of Region nodes in 8u40 specifically for region borders (which I think is what is used for Pie charts). We made follow-on fixes in 8u60 -- see https://bugs.openjdk.java.net/browse/JDK-8089063 -- that may or may not have addressed this. > > > > If this still fails for you with 8u60, please file a bug. > > > > -- Kevin > > > > > > Hruda, Steve wrote: > > > > Hi, > > I have a problem since Java 8u40. As you can see at the following link, the PieChart looks blurred if I set the background of the pie?s programmatically. > > > > The same works without any problem if I use JDK 8u25. > > > > Shows the difference > > https://drive.google.com/file/d/0B7P_rknS1TWxeXk0Y21aMXduYXM/view?usp= > > sharing > > > > In my application I have to style the Chart without an CSS, therefore I use PieChart.lookupAll to get the correct nodes. > > > > The sample code: > > https://drive.google.com/file/d/0B7P_rknS1TWxZDJVS09IbDlfa3c/view?usp= > > sharing > > > > Is this is an issue or do I something wrong? > > > > Thanks in advance, > > 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 vadim.pakhnushev at oracle.com Fri Aug 14 19:02:41 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 14 Aug 2015 22:02:41 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <55CE3B51.7030805@oracle.com> Reminder, Monday is our weekly sanity testing. Testing assignments were slightly shuffled: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From ooo_saturn7 at mail.ru Sat Aug 15 06:20:33 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Sat, 15 Aug 2015 09:20:33 +0300 Subject: =?UTF-8?B?VGFiIHdpdGggcm91bmRlZCBjb3JuZXJzIHN0cmFuZ2UgYmVoYXZpb3VyIGJ1?= =?UTF-8?B?Zw==?= Message-ID: <1439619633.219810713@f83.i.mail.ru> Hello. I wrote to this mailing list about problem with rounded corners in tabs. They advised me to fire a bug at oracle official site. I did this way on 14 July 2015 (ONE MONTH AGO). And I got: "We are evaluating this report and have assigned it a Review ID: JI-9022330. In the event this report is determined to be a defect or enhancement request, it will be referenced with a new Bug ID and will be listed on Bugs.java.com. For other related issues, please visit our Bug Database at http://bugs.java.com ." On 20 July 2015 I got message from pardeep.k.sharma at oracle.com asking for full tests. I send him all test on 23 July 2015. And nothing from that time.On 28 July 2015 I sent him an email asking what is next but got no answer. What should I do now? How can I understand what with this bug? -- Alex Sviridov From kevin.rushforth at oracle.com Sat Aug 15 12:56:11 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 15 Aug 2015 05:56:11 -0700 Subject: Tab with rounded corners strange behaviour bug In-Reply-To: <1439619633.219810713@f83.i.mail.ru> References: <1439619633.219810713@f83.i.mail.ru> Message-ID: <55CF36EB.6030001@oracle.com> Hi Alex, I'm not sure what happened to your test case. I see that the incident team asked you for a complete test case on July 20 (at my request). Either your response didn't get to them or they missed it. The bug was marked as incomplete and moved to the main JDK project on July 30. It is visible here: https://bugs.openjdk.java.net/browse/JDK-8132683 I can check with Pardeep to see if he just missed your test program, but in the mean time, if you can e-mail me the test case off-list I will attach it myself and reopen the bug. -- Kevin Alex Sviridov wrote: > Hello. > > I wrote to this mailing list about problem with rounded corners in tabs. They advised me to fire a bug at oracle official site. I did this way on 14 July 2015 (ONE MONTH AGO). And I got: > > "We are evaluating this report and have assigned it a Review ID: JI-9022330. In the event this report is determined to be a defect or enhancement request, it will be referenced with a new Bug ID and will be listed on Bugs.java.com. For other related issues, please visit our Bug Database at http://bugs.java.com ." > > On 20 July 2015 I got message from pardeep.k.sharma at oracle.com asking for full tests. I send him all test on 23 July 2015. And nothing from that time.On 28 July 2015 I sent him an email asking what is next but got no answer. > > What should I do now? How can I understand what with this bug? > > > From jskov at zoftcorp.dk Sun Aug 16 08:40:19 2015 From: jskov at zoftcorp.dk (Jesper Skov) Date: Sun, 16 Aug 2015 10:40:19 +0200 Subject: [PATCH] 8130458 : BooleanBinding binding/unbinding leaks In-Reply-To: <55B24891.9070603@oracle.com> References: <55B24891.9070603@oracle.com> Message-ID: Thanks for your reply. I didn't reply at the time, as I was away on vacation. I see you made patches for all types, which is super. I'll look for something else to fix. Cheers, Jesper On Fri, Jul 24, 2015 at 4:15 PM, Vadim Pakhnushev < vadim.pakhnushev at oracle.com> wrote: > Hi Jesper, > > First of all if you want to contribute to OpenJFX you need to sign OCA, as > described here: http://openjdk.java.net/contribute/ > > The change itself looks OK, but we might want to look at the other similar > issues, for example, all objects returned from helper class Bindings will > suffer from this. > That is, in the test case from the 8130458 if you change the code in the > loop to Bindings.not(p) the memory will also grow for the same reason. > > There is a mechanism for dealing with this kind of issues, > ExpressionHelperBase.trim method, which works with WeakListeners. > So I think it's worth to try to wrap BindingHelperObserver in the > WeakListener in the Binding implementations (BooleanBinding) and see if it > helps. > trim implementation is suboptimal though so if for example a lot of > listeners get collected, then there would be a lot of unnecessary array > copying. > > Thanks, > Vadim > > > On 19.07.2015 11:20, Jesper Skov wrote: > >> Hi, >> >> I had a look quick look around in the bugs lists for something to try >> fixing. I happened on this issue. >> >> I am aware that the other primitive binding classes should have similar >> treatment. >> But I wanted to get approval/hints before continuing. >> >> The change adds a new inner class that allows the wrapped binding to be >> unbound when the parent is. >> >> There is no test (hard to test presence/absence of a leak). >> >> Thanks, >> Jesper >> > > From kevin.rushforth at oracle.com Mon Aug 17 19:57:42 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Aug 2015 12:57:42 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <55D23CB6.4070002@oracle.com> From cnewland at chrisnewland.com Tue Aug 18 12:06:57 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 18 Aug 2015 13:06:57 +0100 Subject: OpenJFX / JDK 9 questions Message-ID: <03a07efbac271597747f153eb4c7ab06.squirrel@excalibur.xssl.net> Hi, Please could someone briefly explain the changes to OpenJFX under JDK9 / modularisation / jigsaw? I've been trying to answer some questions about this in the London Java Community (JUG) and have added 8u40 stable binaries to my OpenJFX build server as that was requested: http://108.61.191.178/ I understand work is already happening under JEP253 to sort out the public APIs. Longer term, will OpenJFX ever become a sub-project or module in the OpenJDK repository? Is there any plan for a unified build system for OpenJDK and OpenJFX to produce a binary that runs JavaFX out of the box? Currently the gradle openZip method makes it easy to create builds that unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw (JRE) structure and doesn't work with JDK9. Shall I submit a bug? Cheers, Chris From meyertee at gmail.com Tue Aug 18 14:43:59 2015 From: meyertee at gmail.com (Thomas Meyer) Date: Tue, 18 Aug 2015 16:43:59 +0200 Subject: Multiple imports of CSS files in subdirectories Message-ID: <43F3CB5C-D46A-4512-9173-4B55C63EBFCE@gmail.com> Hi, I?m using @import statements to spilt up my CSS code into multiple files in subdirectories. All imports are listed in one base css file: base.css: @import ?sub/a.css" @import ?sub/b.css" This usage was working fine in JDK 1.8.0_31. Since JDK 1.8.0_45 it?s broken: ?sub/b.css" is resolved relative to ?sub/a.css? leading to errors such as this one (notice the double-?/sub"): com.sun.javafx.css.parser.CSSParser handleImport WARNING: CSS Error parsing file:/myproject/build/classes/main/styles/sub/sub/b.css: Could not import ?sub/b.css? Information on the support for @import is sparse on the CSS-ref. Is this usage discouraged? What others use cases does it serve / how are you using the @import statement? Best wishes, Thomas. From herve.girod at gmail.com Tue Aug 18 15:03:25 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Tue, 18 Aug 2015 17:03:25 +0200 Subject: Multiple imports of CSS files in subdirectories In-Reply-To: <43F3CB5C-D46A-4512-9173-4B55C63EBFCE@gmail.com> References: <43F3CB5C-D46A-4512-9173-4B55C63EBFCE@gmail.com> Message-ID: I think it has been fixed for u60. Sent from my iPhone > On Aug 18, 2015, at 16:43, Thomas Meyer wrote: > > Hi, > > I?m using @import statements to spilt up my CSS code into multiple files in subdirectories. All imports are listed in one base css file: > > base.css: > @import ?sub/a.css" > @import ?sub/b.css" > > This usage was working fine in JDK 1.8.0_31. Since JDK 1.8.0_45 it?s broken: ?sub/b.css" is resolved relative to ?sub/a.css? leading to errors such as this one (notice the double-?/sub"): > > com.sun.javafx.css.parser.CSSParser handleImport > WARNING: CSS Error parsing file:/myproject/build/classes/main/styles/sub/sub/b.css: Could not import ?sub/b.css? > > Information on the support for @import is sparse on the CSS-ref. Is this usage discouraged? What others use cases does it serve / how are you using the @import statement? > > Best wishes, Thomas. From meyertee at gmail.com Tue Aug 18 15:13:35 2015 From: meyertee at gmail.com (Thomas Meyer) Date: Tue, 18 Aug 2015 17:13:35 +0200 Subject: Multiple imports of CSS files in subdirectories In-Reply-To: References: <43F3CB5C-D46A-4512-9173-4B55C63EBFCE@gmail.com> Message-ID: <23360A33-271E-4977-85D1-13FB3AEC0D87@gmail.com> OK, thanks! And sorry, a colleague just reminded me of bugs.openjdk.java.net , I was obviously searching in the wrong bug tracker.. You already reported it: https://bugs.openjdk.java.net/browse/JDK-8093583 > On 18 Aug 2015, at 17:03, Herv? Girod wrote: > > I think it has been fixed for u60. > > Sent from my iPhone > >> On Aug 18, 2015, at 16:43, Thomas Meyer wrote: >> >> Hi, >> >> I?m using @import statements to spilt up my CSS code into multiple files in subdirectories. All imports are listed in one base css file: >> >> base.css: >> @import ?sub/a.css" >> @import ?sub/b.css" >> >> This usage was working fine in JDK 1.8.0_31. Since JDK 1.8.0_45 it?s broken: ?sub/b.css" is resolved relative to ?sub/a.css? leading to errors such as this one (notice the double-?/sub"): >> >> com.sun.javafx.css.parser.CSSParser handleImport >> WARNING: CSS Error parsing file:/myproject/build/classes/main/styles/sub/sub/b.css: Could not import ?sub/b.css? >> >> Information on the support for @import is sparse on the CSS-ref. Is this usage discouraged? What others use cases does it serve / how are you using the @import statement? >> >> Best wishes, Thomas. From ozemale at ozemail.com.au Tue Aug 18 21:41:48 2015 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Wed, 19 Aug 2015 07:41:48 +1000 Subject: OpenJFX / JDK 9 questions In-Reply-To: <03a07efbac271597747f153eb4c7ab06.squirrel@excalibur.xssl.net> References: <03a07efbac271597747f153eb4c7ab06.squirrel@excalibur.xssl.net> Message-ID: <004d01d0d9fe$b05b7a10$11126e30$@ozemail.com.au> Hi Chris, Felix Bembrick asked this same question a while ago and after some time the response was: ------ "Hi Felix, Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization JEP 257: Update JavaFX/Media to Newer Version of GStreamer Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. -- Kevin" ------- -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Chris Newland Sent: Tuesday, August 18, 2015 10:07 PM To: openjfx-dev at openjdk.java.net Subject: OpenJFX / JDK 9 questions Hi, Please could someone briefly explain the changes to OpenJFX under JDK9 / modularisation / jigsaw? I've been trying to answer some questions about this in the London Java Community (JUG) and have added 8u40 stable binaries to my OpenJFX build server as that was requested: http://108.61.191.178/ I understand work is already happening under JEP253 to sort out the public APIs. Longer term, will OpenJFX ever become a sub-project or module in the OpenJDK repository? Is there any plan for a unified build system for OpenJDK and OpenJFX to produce a binary that runs JavaFX out of the box? Currently the gradle openZip method makes it easy to create builds that unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw (JRE) structure and doesn't work with JDK9. Shall I submit a bug? Cheers, Chris From kevin.rushforth at oracle.com Tue Aug 18 22:23:40 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Aug 2015 15:23:40 -0700 Subject: OpenJFX / JDK 9 questions In-Reply-To: <004d01d0d9fe$b05b7a10$11126e30$@ozemail.com.au> References: <03a07efbac271597747f153eb4c7ab06.squirrel@excalibur.xssl.net> <004d01d0d9fe$b05b7a10$11126e30$@ozemail.com.au> Message-ID: <55D3B06C.1020403@oracle.com> Chris' questions are more about the build environment. To answer some of the specific points. > Longer term, will OpenJFX ever become a sub-project or module in the OpenJDK > repository? > Very likely, yes. Long term we would like the openjfx "rt" repository to be a "jfx" repo in the openjdk forest. This is not planned for 9, though. Probably for JDK 10 (but perhaps could be done in a 9 update release). > Is there any plan for a unified build system for OpenJDK and OpenJFX to > produce a binary that runs JavaFX out of the box? > Some of the Jigsaw work is heading in that direction. The current plan is for a JDK configure option to take a set of (pre-built) JavaFX modules and import them into the JDK build, as opposed to the current "overlay the javafx bits at the end" approach that JDK 8 uses. > Currently the gradle openZip method makes it easy to create builds that > unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw (JRE) structure > and doesn't work with JDK9. Shall I submit a bug? We are in the process of making major changes for Jigsaw, so anything we do for the "openZip" task will be a stop-gap until that work is complete. Go ahead and file the bug, though. If nothing else, it will serve as a reminder to test the build with OpenJDK + OpenJFX (without either of the closed bits). -- Kevin John C. Turnbull wrote: > Hi Chris, > > Felix Bembrick asked this same question a while ago and after some time the > response was: > > ------ > "Hi Felix, > > Sorry for the delay. Most of us were still pretty focused on 8u60, but we > are turning our attention to JDK 9 now. > > The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for > FX in JDK 9 are these: > > JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization JEP 257: > Update JavaFX/Media to Newer Version of GStreamer > > Related to Jigasw, we intend to look into new API for heavily used internal > methods / classes since they will no longer be accessible otherwise. We also > plan to update WebKit at least one more time, and will likely do a few RFEs > such as better Hi-DPI support (with API > control) on Mac, Windows, Linux. > > We don't currently plan any other big features for 9, but will consider > additional RFEs if they are important to enough developers and if they fit > into the time frame. > > -- Kevin" > ------- > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > Chris Newland > Sent: Tuesday, August 18, 2015 10:07 PM > To: openjfx-dev at openjdk.java.net > Subject: OpenJFX / JDK 9 questions > > Hi, > > Please could someone briefly explain the changes to OpenJFX under JDK9 / > modularisation / jigsaw? > > I've been trying to answer some questions about this in the London Java > Community (JUG) and have added 8u40 stable binaries to my OpenJFX build > server as that was requested: http://108.61.191.178/ > > I understand work is already happening under JEP253 to sort out the public > APIs. > > Longer term, will OpenJFX ever become a sub-project or module in the OpenJDK > repository? > > Is there any plan for a unified build system for OpenJDK and OpenJFX to > produce a binary that runs JavaFX out of the box? > > Currently the gradle openZip method makes it easy to create builds that > unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw (JRE) structure > and doesn't work with JDK9. Shall I submit a bug? > > Cheers, > > Chris > > > From herve.girod at gmail.com Tue Aug 18 22:36:34 2015 From: herve.girod at gmail.com (Herve Girod) Date: Wed, 19 Aug 2015 00:36:34 +0200 Subject: Multiple imports of CSS files in subdirectories In-Reply-To: <23360A33-271E-4977-85D1-13FB3AEC0D87@gmail.com> References: <43F3CB5C-D46A-4512-9173-4B55C63EBFCE@gmail.com> <23360A33-271E-4977-85D1-13FB3AEC0D87@gmail.com> Message-ID: No problem! 2015-08-18 17:13 GMT+02:00 Thomas Meyer : > OK, thanks! > And sorry, a colleague just reminded me of bugs.openjdk.java.net, I was > obviously searching in the wrong bug tracker.. > You already reported it: https://bugs.openjdk.java.net/browse/JDK-8093583 > > > > On 18 Aug 2015, at 17:03, Herv? Girod wrote: > > I think it has been fixed for u60. > > Sent from my iPhone > > On Aug 18, 2015, at 16:43, Thomas Meyer wrote: > > Hi, > > I?m using @import statements to spilt up my CSS code into multiple files > in subdirectories. All imports are listed in one base css file: > > base.css: > @import ?sub/a.css" > @import ?sub/b.css" > > This usage was working fine in JDK 1.8.0_31. Since JDK 1.8.0_45 it?s > broken: ?sub/b.css" is resolved relative to ?sub/a.css? leading to errors > such as this one (notice the double-?/sub"): > > com.sun.javafx.css.parser.CSSParser handleImport > WARNING: CSS Error parsing > file:/myproject/build/classes/main/styles/sub/sub/b.css: Could not import > ?sub/b.css? > > Information on the support for @import is sparse on the CSS-ref. Is this > usage discouraged? What others use cases does it serve / how are you using > the @import statement? > > Best wishes, Thomas. > > > From paskokv at gmail.com Wed Aug 19 11:45:35 2015 From: paskokv at gmail.com (Konstantin Pasko) Date: Wed, 19 Aug 2015 13:45:35 +0200 Subject: Blurring 1px border Message-ID: Hi guys, I've found a very strange thing about JavaFX and borders. If an element has "*-fx-border-width: 1 1 1 1;*", then the border will be a bit blur (not exactly 1px). But if it's declared as "*-fx-border-width: 0 1 1 1;*", then the border is perfectly sharp (exactly 1px). I've attached java class and css, that shows this effect. As a workaround I defined border as: *-fx-border-width: 0 1 1 1, 1 0 0 0;* But if the border has rounded corners, this workaround (even with border-insets) produces different rounded corners. This is a big problem for us (at least for my UX-designer :) ), because it doesn't look good. Especially when we style TextField, which should have 1px dark border, white background and shadow effect around it -- it looks dirty with this blurring. Do you have any ideas why it's happening? Regards, Konstantin Pasko From vadim.pakhnushev at oracle.com Wed Aug 19 12:01:47 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 19 Aug 2015 15:01:47 +0300 Subject: [9] Review request for 8133839: StringIndexOutOfBoundsException in setter search when using Message-ID: <55D4702B.6000800@oracle.com> Jonathan, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8133839 http://cr.openjdk.java.net/~vadim/8133839/webrev.00/ Thanks, Vadim From kevin.rushforth at oracle.com Wed Aug 19 14:40:25 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Aug 2015 07:40:25 -0700 Subject: Blurring 1px border In-Reply-To: References: Message-ID: <55D49559.8090703@oracle.com> What version of the JDK are you using? We fixed bugs in this area in 8u60, which may (or may not) have fixed this. -- Kevin Konstantin Pasko wrote: > Hi guys, > > I've found a very strange thing about JavaFX and borders. > > If an element has "*-fx-border-width: 1 1 1 1;*", then the border will be a > bit blur (not exactly 1px). > But if it's declared as "*-fx-border-width: 0 1 1 1;*", then the border is > perfectly sharp (exactly 1px). > > I've attached java class and css, that shows this effect. > > As a workaround I defined border as: *-fx-border-width: 0 1 1 1, 1 0 0 0;* > But if the border has rounded corners, this workaround (even with > border-insets) produces different rounded corners. > > This is a big problem for us (at least for my UX-designer :) ), because it > doesn't look good. Especially when we style TextField, which should have > 1px dark border, white background and shadow effect around it -- it looks > dirty with this blurring. > > Do you have any ideas why it's happening? > > > Regards, > Konstantin Pasko > From paskokv at gmail.com Wed Aug 19 15:12:23 2015 From: paskokv at gmail.com (Konstantin Pasko) Date: Wed, 19 Aug 2015 17:12:23 +0200 Subject: Blurring 1px border In-Reply-To: <55D49559.8090703@oracle.com> References: <55D49559.8090703@oracle.com> Message-ID: Hi Kevin, sorry for not mentioning that: it's JDK8u60. I've just double checked and reinstalled it from oracle.com. P.S. I also attache the screenshot. Regards, Konstantin Pasko 2015-08-19 16:40 GMT+02:00 Kevin Rushforth : > What version of the JDK are you using? We fixed bugs in this area in 8u60, > which may (or may not) have fixed this. > > -- Kevin > > > Konstantin Pasko wrote: > >> Hi guys, >> >> I've found a very strange thing about JavaFX and borders. >> >> If an element has "*-fx-border-width: 1 1 1 1;*", then the border will be >> a >> bit blur (not exactly 1px). >> But if it's declared as "*-fx-border-width: 0 1 1 1;*", then the border is >> perfectly sharp (exactly 1px). >> >> I've attached java class and css, that shows this effect. >> >> As a workaround I defined border as: *-fx-border-width: 0 1 1 1, 1 0 0 0;* >> But if the border has rounded corners, this workaround (even with >> border-insets) produces different rounded corners. >> >> This is a big problem for us (at least for my UX-designer :) ), because it >> doesn't look good. Especially when we style TextField, which should have >> 1px dark border, white background and shadow effect around it -- it looks >> dirty with this blurring. >> >> Do you have any ideas why it's happening? >> >> >> Regards, >> Konstantin Pasko >> >> > From kevin.rushforth at oracle.com Wed Aug 19 15:28:32 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Aug 2015 08:28:32 -0700 Subject: Blurring 1px border In-Reply-To: References: <55D49559.8090703@oracle.com> Message-ID: <55D4A0A0.9070509@oracle.com> Thanks for confirming. We have at least one other example of a similar issue that still happens in 8u60: https://bugs.openjdk.java.net/browse/JDK-8133826 Can you please file a new bug? Your issue may or may not be the same as JDK-8133826, so it would be good to have another test case. Thanks. -- Kevin Konstantin Pasko wrote: > Hi Kevin, > > sorry for not mentioning that: it's JDK8u60. > I've just double checked and reinstalled it from oracle.com > . > > P.S. I also attache the screenshot. > > Regards, > Konstantin Pasko > > 2015-08-19 16:40 GMT+02:00 Kevin Rushforth >: > > What version of the JDK are you using? We fixed bugs in this area > in 8u60, which may (or may not) have fixed this. > > -- Kevin > > > Konstantin Pasko wrote: > > Hi guys, > > I've found a very strange thing about JavaFX and borders. > > If an element has "*-fx-border-width: 1 1 1 1;*", then the > border will be a > bit blur (not exactly 1px). > But if it's declared as "*-fx-border-width: 0 1 1 1;*", then > the border is > perfectly sharp (exactly 1px). > > I've attached java class and css, that shows this effect. > > As a workaround I defined border as: *-fx-border-width: 0 1 1 > 1, 1 0 0 0;* > But if the border has rounded corners, this workaround (even with > border-insets) produces different rounded corners. > > This is a big problem for us (at least for my UX-designer :) > ), because it > doesn't look good. Especially when we style TextField, which > should have > 1px dark border, white background and shadow effect around it > -- it looks > dirty with this blurring. > > Do you have any ideas why it's happening? > > > Regards, > Konstantin Pasko > > > > > ------------------------------------------------------------------------ > From vadim.pakhnushev at oracle.com Wed Aug 19 15:50:23 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 19 Aug 2015 18:50:23 +0300 Subject: [9] Review request for 8129401: Bindings.bindContentBidirectional does not work correctly Message-ID: <55D4A5BF.3090008@oracle.com> Chien, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8129401 http://cr.openjdk.java.net/~vadim/8129401/webrev.00/ Thanks, Vadim From philip.race at oracle.com Wed Aug 19 16:56:52 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 19 Aug 2015 09:56:52 -0700 Subject: OpenJFX / JDK 9 questions In-Reply-To: <55D3B06C.1020403@oracle.com> References: <03a07efbac271597747f153eb4c7ab06.squirrel@excalibur.xssl.net> <004d01d0d9fe$b05b7a10$11126e30$@ozemail.com.au> <55D3B06C.1020403@oracle.com> Message-ID: <55D4B554.90007@oracle.com> On 08/18/2015 03:23 PM, Kevin Rushforth wrote: > >> Currently the gradle openZip method makes it easy to create builds that >> unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw (JRE) >> structure >> and doesn't work with JDK9. Shall I submit a bug? > > We are in the process of making major changes for Jigsaw, so anything > we do for the "openZip" task will be a stop-gap until that work is > complete. Go ahead and file the bug, though. If nothing else, it will > serve as a reminder to test the build with OpenJDK + OpenJFX (without > either of the closed bits). As a general FYI broader than this use case, as I understand it, the modular JDK image is intended to be opaque. The tools that have learned over the years the disk layout - eg that there is jre/lib/rt.jar will need to unlearn that. So overlaying on some expected structure is probably not the way to do things in JDK 9. I think you will be expected to use tools to build a custom image as opposed to installing over someone else's image. I am not the authority on this, but if you want to ask any questions about use cases, you should ask on jigsaw-dev. -phil. From tomas.mikula at gmail.com Wed Aug 19 18:49:17 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 19 Aug 2015 14:49:17 -0400 Subject: JEP 253: UI control skins and input mapping discussion In-Reply-To: <55C8053E.9080501@oracle.com> References: <55C3E8BB.6000903@oracle.com> <55C8053E.9080501@oracle.com> Message-ID: I provided my feedback on the input mapping API some 4 months ago here (be warned, it is a *long* discussion) https://bugs.openjdk.java.net/browse/JDK-8091189 I am very disappointed that this API is being pushed forward with all its flaws. It is both overly complex (both conceptually and in terms of the amount of new classes introduced) and at the same time does not cover simple use cases well (or not at all). Note that all my feedback was constructive - suggesting a viable alternative (referring to WellBehavedFX as a proof of concept, which is field tested by its use in RichTextFX). Most importantly, I was arguing that InputMap should be a (minimal) interface, instead of a class (locking us to the particular implementation). InputMap in the current proposal mixes together two concerns that should better be separated: 1. the InputMap API required by Control (turns out it is just one method); and 2. API for the user to construct such objects. Splitting these two concerns would allow alternative an implementation of 2., e.g. an implementation where all controls of the same type (e.g. Button) share the same instance of InputMap, instead of it being recreated for each instance of Button. Another wart is the InputMap#lookupMapping(Object) method (emphasis on *Object*). I think everyone now agrees that Map#get(Object) is a terrible API (although it might have been necessary for backwards compatibility at the time). Aside from the untyped Object thing, the idea that when I want the control to ignore some specific input, I first need to look up all the mappings that match it and remove them is not going to work (simply because the same mapping that matches the input to be ignored can also match some other input that should not be ignored). User code that is using lookup is also not going to be forward compatible, because the default mappings installed by the controls themselves may change in a newer JavaFX version, thus the return value of lookupMapping can be different in different JavaFX versions. "Specificity" seems like an unnecessary "feature" to me that I can't see anyone putting into a good use. I cannot predict the effect of adding a mapping without knowing what mappings with what specificity are already in the InputMap. As a consequence, when as a user of JavaFX controls I want to add a mapping, I need to be aware of what mappings are already installed by the control itself (or its skin). Even if I knew all that, it can change in a future version of JavaFX, so my code is not going to be forward compatible. I just picked a few things. I encourage anyone interested to read the above mentioned long discussion (relevant part starts from 2015). Regards, Tomas On Sun, Aug 9, 2015 at 9:58 PM, Jonathan Giles wrote: > The plan is for this kind of detail to be included in the javadoc > documentation. > > Thanks, > > -- Jonathan > > > On 7/08/2015 10:36 p.m., Mike Hearn wrote: > >> I don't know much about skins and how they work, as I haven't implemented >> custom controls. My only knowledge comes from rummaging around inside the >> code to find some hacky way to get a particular effect, often via CSS. >> >> I was hoping to read about the skins infrastructure, what it's for, how >> it works etc in the jfx.s.c.skins package description but no such luck. Is >> the plan for the JavaDocs to give a high level description of skinning, how >> to implement it in your own code etc, or are there plans for other articles >> to describe this? >> > > From jonathan.giles at oracle.com Wed Aug 19 23:00:23 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 20 Aug 2015 11:00:23 +1200 Subject: JEP 253: UI control skins and input mapping discussion In-Reply-To: References: <55C3E8BB.6000903@oracle.com> <55C8053E.9080501@oracle.com> Message-ID: <55D50A87.9090207@oracle.com> Tomas, As it stands there exists two approaches being proposed (my one and yours). The purpose of my job is to create new API that benefits the community - your disappointment that I'm doing that is itself disappointing to me! :-) I couldn't progress our discussion in JDK-8091189 any further without undertaking the task of porting all existing UI controls to use the new API, so that I could understand the implications of my proposed approach. This has now been done and I'm reporting back to the community my findings. I am not pushing my API forward any more than I am surfacing it for discussion. As I said in JavaFX Jira (now JBS), it would be really beneficial to have clarity around how WellBehavedFX would be used in JavaFX - I seem to recall we both agreed there was significant API in WellBehavedFX that wouldn't (and shouldn't) be part of an InputMap proposal. Whilst I appreciate it is a lot to ask, I think there needs to be some effort put into creating essentially another sandbox of openjfx that introduces WellBehavedFX in the way you envisage. Porting a small number of UI controls to use this would make it far more clear to me, and others who are interested in this, what your vision is. Otherwise we end up with long philosophical discussions and not enough code (which removes any confusion). -- Jonathan On 20/08/2015 6:49 a.m., Tomas Mikula wrote: > I provided my feedback on the input mapping API some 4 months ago > here (be warned, it is a *long* discussion) > https://bugs.openjdk.java.net/browse/JDK-8091189 > > I am very disappointed that this API is being pushed forward with all > its flaws. It is both overly complex (both conceptually and in terms > of the amount of new classes introduced) and at the same time does not > cover simple use cases well (or not at all). Note that all my feedback > was constructive - suggesting a viable alternative (referring to > WellBehavedFX as a proof of concept, which is field tested by its use > in RichTextFX). > > Most importantly, I was arguing that InputMap should be a (minimal) > interface, instead of a class (locking us to the particular > implementation). InputMap in the current proposal mixes together two > concerns that should better be separated: 1. the InputMap API required > by Control (turns out it is just one method); and 2. API for the user > to construct such objects. > > Splitting these two concerns would allow alternative an implementation > of 2., e.g. an implementation where all controls of the same type > (e.g. Button) share the same instance of InputMap, instead of it being > recreated for each instance of Button. > > Another wart is the InputMap#lookupMapping(Object) method (emphasis on > *Object*). I think everyone now agrees that Map#get(Object) is a > terrible API (although it might have been necessary for backwards > compatibility at the time). Aside from the untyped Object thing, the > idea that when I want the control to ignore some specific input, I > first need to look up all the mappings that match it and remove them > is not going to work (simply because the same mapping that matches the > input to be ignored can also match some other input that should not be > ignored). User code that is using lookup is also not going to be > forward compatible, because the default mappings installed by the > controls themselves may change in a newer JavaFX version, thus the > return value of lookupMapping can be different in different JavaFX > versions. > > "Specificity" seems like an unnecessary "feature" to me that I can't > see anyone putting into a good use. I cannot predict the effect of > adding a mapping without knowing what mappings with what specificity > are already in the InputMap. As a consequence, when as a user of > JavaFX controls I want to add a mapping, I need to be aware of what > mappings are already installed by the control itself (or its skin). > Even if I knew all that, it can change in a future version of JavaFX, > so my code is not going to be forward compatible. > > I just picked a few things. I encourage anyone interested to read the > above mentioned long discussion (relevant part starts from 2015). > > Regards, > Tomas > > On Sun, Aug 9, 2015 at 9:58 PM, Jonathan Giles > > wrote: > > The plan is for this kind of detail to be included in the javadoc > documentation. > > Thanks, > > -- Jonathan > > > On 7/08/2015 10:36 p.m., Mike Hearn wrote: > > I don't know much about skins and how they work, as I haven't > implemented custom controls. My only knowledge comes from > rummaging around inside the code to find some hacky way to get > a particular effect, often via CSS. > > I was hoping to read about the skins infrastructure, what it's > for, how it works etc in the jfx.s.c.skins package description > but no such luck. Is the plan for the JavaDocs to give a high > level description of skinning, how to implement it in your own > code etc, or are there plans for other articles to describe this? > > > From tomas.mikula at gmail.com Wed Aug 19 23:59:17 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 19 Aug 2015 19:59:17 -0400 Subject: JEP 253: UI control skins and input mapping discussion In-Reply-To: <55D50A87.9090207@oracle.com> References: <55C3E8BB.6000903@oracle.com> <55C8053E.9080501@oracle.com> <55D50A87.9090207@oracle.com> Message-ID: Hi Jonathan, On Wed, Aug 19, 2015 at 7:00 PM, Jonathan Giles wrote: > Tomas, > > As it stands there exists two approaches being proposed (my one and > yours). The purpose of my job is to create new API that benefits the > community - your disappointment that I'm doing that is itself disappointing > to me! :-) > My disappointment comes from not addressing the issues I have raised. > I couldn't progress our discussion in JDK-8091189 any further without > undertaking the task of porting all existing UI controls to use the new > API, so that I could understand the implications of my proposed approach. > This has now been done and I'm reporting back to the community my findings. > I am not pushing my API forward any more than I am surfacing it for > discussion. > > As I said in JavaFX Jira (now JBS), it would be really beneficial to have > clarity around how WellBehavedFX would be used in JavaFX - I seem to recall > we both agreed there was significant API in WellBehavedFX that wouldn't > (and shouldn't) be part of an InputMap proposal. > That was the "template" part, i.e. the part which enables you to share an input map across all instances of the same control. I'm not saying this should or shouldn't be part of proposal. I'm saying the proposal should not close doors to such implementations (by third parties or in future JavaFX versions). > Whilst I appreciate it is a lot to ask, I think there needs to be some > effort put into creating essentially another sandbox of openjfx that > introduces WellBehavedFX in the way you envisage. Porting a small number of > UI controls to use this would make it far more clear to me, and others who > are interested in this, what your vision is. Otherwise we end up with long > philosophical discussions and not enough code (which removes any confusion). > I don't have the bandwidth to port JavaFX controls. However, we can write down a list of use-cases and present user code for them side by side (e.g. a document on GitHub, BitBucket, ... to which both of us and possibly other people have write access). These can include all the cases that you encountered while porting JavaFX controls. Metrics on the implementation (like the API surface) will be easy to calculate (I can restructure WellBehavedFX to put the non-essential stuff into a separate package). Regards, Tomas > > > -- Jonathan > > > On 20/08/2015 6:49 a.m., Tomas Mikula wrote: > > I provided my feedback on the input mapping API some 4 months ago here (be > warned, it is a *long* discussion) > https://bugs.openjdk.java.net/browse/JDK-8091189 > > I am very disappointed that this API is being pushed forward with all its > flaws. It is both overly complex (both conceptually and in terms of the > amount of new classes introduced) and at the same time does not cover > simple use cases well (or not at all). Note that all my feedback was > constructive - suggesting a viable alternative (referring to WellBehavedFX > as a proof of concept, which is field tested by its use in RichTextFX). > > Most importantly, I was arguing that InputMap should be a (minimal) > interface, instead of a class (locking us to the particular > implementation). InputMap in the current proposal mixes together two > concerns that should better be separated: 1. the InputMap API required by > Control (turns out it is just one method); and 2. API for the user to > construct such objects. > > Splitting these two concerns would allow alternative an implementation of > 2., e.g. an implementation where all controls of the same type (e.g. > Button) share the same instance of InputMap, instead of it being recreated > for each instance of Button. > > Another wart is the InputMap#lookupMapping(Object) method (emphasis on > *Object*). I think everyone now agrees that Map#get(Object) is a terrible > API (although it might have been necessary for backwards compatibility at > the time). Aside from the untyped Object thing, the idea that when I want > the control to ignore some specific input, I first need to look up all the > mappings that match it and remove them is not going to work (simply because > the same mapping that matches the input to be ignored can also match some > other input that should not be ignored). User code that is using lookup is > also not going to be forward compatible, because the default mappings > installed by the controls themselves may change in a newer JavaFX version, > thus the return value of lookupMapping can be different in different JavaFX > versions. > > "Specificity" seems like an unnecessary "feature" to me that I can't see > anyone putting into a good use. I cannot predict the effect of adding a > mapping without knowing what mappings with what specificity are already in > the InputMap. As a consequence, when as a user of JavaFX controls I want to > add a mapping, I need to be aware of what mappings are already installed by > the control itself (or its skin). Even if I knew all that, it can change in > a future version of JavaFX, so my code is not going to be forward > compatible. > > I just picked a few things. I encourage anyone interested to read the > above mentioned long discussion (relevant part starts from 2015). > > Regards, > Tomas > > On Sun, Aug 9, 2015 at 9:58 PM, Jonathan Giles < > jonathan.giles at oracle.com> wrote: > >> The plan is for this kind of detail to be included in the javadoc >> documentation. >> >> Thanks, >> >> -- Jonathan >> >> >> On 7/08/2015 10:36 p.m., Mike Hearn wrote: >> >>> I don't know much about skins and how they work, as I haven't >>> implemented custom controls. My only knowledge comes from rummaging around >>> inside the code to find some hacky way to get a particular effect, often >>> via CSS. >>> >>> I was hoping to read about the skins infrastructure, what it's for, how >>> it works etc in the jfx.s.c.skins package description but no such luck. Is >>> the plan for the JavaDocs to give a high level description of skinning, how >>> to implement it in your own code etc, or are there plans for other articles >>> to describe this? >>> >> >> > > From jonathan.giles at oracle.com Thu Aug 20 00:15:39 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 19 Aug 2015 17:15:39 -0700 (PDT) Subject: JEP 253: UI control skins and input mapping discussion Message-ID: Tomas, I hope you'll agree that throughout our long discussion on JBS we both improved our implementations based on our discussion. To say that I haven't addressed your issues isn't fair - I worked with you to understand your issues and I addressed many of them as my InputMap implementation and API iterated. We have fundamentally different views on how to implement this, so I can't bend over and completely change my approach to your approach - or else we'd not be doing a proper job of exploring the domain. I'm not saying one approach is right and the other is wrong - I'm working on my idea of how to approach this, and as I said, I invite you to do the same. In regard to 'closing doors' - I don't think anything I've done up to now has closed doors. I believe that WellBehavedFX will continue to be able to work in the current approach I have implemented (it just hooks into EventHandlers, right?) - it just won't make use of any of it! Nothing I'm creating is being forced down anyones throats - it is an implementation and API that is optional. As it stands, the sandbox repo I'm working in has all controls using it, but that doesn't mean controls such as your rich text editor are forced to use it, and I imagine that they will continue to work well with your WellBehavedFX API and implementation. Am I misunderstanding what you're saying? -- Jonathan From tomas.mikula at gmail.com Thu Aug 20 01:09:45 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 19 Aug 2015 21:09:45 -0400 Subject: JEP 253: UI control skins and input mapping discussion In-Reply-To: References: Message-ID: On Wed, Aug 19, 2015 at 8:15 PM, Jonathan Giles wrote: > Tomas, I hope you'll agree that throughout our long discussion on JBS we > both improved our implementations based on our discussion. To say that I > haven't addressed your issues isn't fair - I worked with you to understand > your issues and I addressed many of them as my InputMap implementation and > API iterated. We have fundamentally different views on how to implement > this, so I can't bend over and completely change my approach to your > approach - or else we'd not be doing a proper job of exploring the domain. I never meant it to sound like you (or JavaFX) should adopt my approach. I was just pointing out some flaws with the proposal, and in an attempt to also be constructive, I was referring to WellBehavedFX as an evidence that they indeed can be resolved. > I'm not saying one approach is right and the other is wrong - I'm working > on my idea of how to approach this, and as I said, I invite you to do the > same. In regard to 'closing doors' - I don't think anything I've done up to > now has closed doors. I believe that WellBehavedFX will continue to be able > to work in the current approach I have implemented (it just hooks into > EventHandlers, right?) - it just won't make use of any of it! By the same argument, neither is JavaFX closing doors to anyone who wants to implement their own UI toolkit. They just won't make use of any of it! :D More seriously though, no, the two mechanisms cannot coexist well on the same control: they both hook into event handlers and 1) the order in which event handlers are invoked is undefined and 2) all applicable event handlers are invoked, regardless of whether some of them consumed the event. In fact, if there was enough control over event handlers, there would be little motivation for any of this input mapping stuff. Since there can only be one mechanism in place, it better cover 99.99% of use cases. > Nothing I'm creating is being forced down anyones throats - it is an > implementation and API that is optional. As it stands, the sandbox repo I'm > working in has all controls using it, but that doesn't mean controls such > as your rich text editor are forced to use it, and I imagine that they will > continue to work well with your WellBehavedFX API and implementation. Am I > misunderstanding what you're saying? -- Jonathan If my control uses WellBehavedFX, and in JDK 9 there will be the new InputMap API, users (especially new ones) will try to use that API to customize input mappings (because, well, that is the JavaFX way to do it, right?). Except the two can interact in unpredictable ways (see above). Now if you say that they should study the control and the ways how to interact with it, that argument does not extend to generic code, where the type of node is known to be only Control (or Node), not the concrete custom control. So custom control authors will be forced to switch to the new API. So again, it better cover 99.99% of use cases. Regards, Tomas From cnewland at chrisnewland.com Thu Aug 20 07:38:56 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Thu, 20 Aug 2015 08:38:56 +0100 Subject: OpenJFX / JDK 9 questions In-Reply-To: <55D4B554.90007@oracle.com> References: <03a07efbac271597747f153eb4c7ab06.squirrel@excalibur.xssl.net> <004d01d0d9fe$b05b7a10$11126e30$@ozemail.com.au> <55D3B06C.1020403@oracle.com> <55D4B554.90007@oracle.com> Message-ID: Thanks Kevin, Phil. I find it encouraging that there is a plan to include jfx as part of the jdk forest as that will lead to a smoother build process. Hopefully there will still be a mechanism to add OpenJFX to other JDKs (Zulu etc.) in a post-Jigsaw world. I filed a bug just as a reminder: Review ID: JI-9023645 and I'll ask over on jigsaw-dev about possible future mechanisms for adding to a JDK9 installation. Cheers, Chris On Wed, August 19, 2015 17:56, Phil Race wrote: > On 08/18/2015 03:23 PM, Kevin Rushforth wrote: > >> >>> Currently the gradle openZip method makes it easy to create builds >>> that unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw >>> (JRE) >>> structure and doesn't work with JDK9. Shall I submit a bug? >> >> We are in the process of making major changes for Jigsaw, so anything >> we do for the "openZip" task will be a stop-gap until that work is >> complete. Go ahead and file the bug, though. If nothing else, it will >> serve as a reminder to test the build with OpenJDK + OpenJFX (without >> either of the closed bits). > > As a general FYI broader than this use case, as I understand it, the > modular JDK image is intended to be opaque. The tools that have learned over > the years the disk layout - eg that there is jre/lib/rt.jar will need to > unlearn that. So overlaying on some expected structure is probably not the > way to do things in JDK 9. I think you will be expected to use tools to > build a custom image as opposed to installing over someone else's image. I > am not the authority on this, but if you want to ask any questions about > use cases, you should ask on jigsaw-dev. > > -phil. > > From steve.hruda at hexagongeospatial.com Thu Aug 20 16:07:31 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Thu, 20 Aug 2015 16:07:31 +0000 Subject: [JDK8u60] [regression] [WebView] Load single page application from jar Message-ID: Hi, our java application uses JavaFX?s WebView to load a single page application which should be available while the user is offline. The single page application will be delivered by a jar file. This case works without any problem by using JDK8u45, but something changed in case of JDK8u60. Our relative referenced javascript files (inside the same package) will not be loaded by the WebView and therefore our application doesn?t work. Regards, Steve Steve Hruda, MSc Scrum Master, GeoMedia Smart Client T: +43 1.9610567.4676 F: +43 1.9610567.4601 E: steve.hruda at hexagongeospatial.com Hexagon Geospatial Margaretenstra?e 70/I/1 1050 Wien, Austria hexagongeospatial.com 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 kevin.rushforth at oracle.com Thu Aug 20 16:36:25 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Aug 2015 09:36:25 -0700 Subject: [JDK8u60] [regression] [WebView] Load single page application from jar In-Reply-To: References: Message-ID: <55D60209.2090104@oracle.com> Please file a bug and include a test case that reproduces the bug. -- Kevin Hruda, Steve wrote: > Hi, > our java application uses JavaFX?s WebView to load a single page application which should be available while the user is offline. > > The single page application will be delivered by a jar file. This case works without any problem by using JDK8u45, but something changed in case of JDK8u60. > Our relative referenced javascript files (inside the same package) will not be loaded by the WebView and therefore our application doesn?t work. > > Regards, > Steve > > Steve Hruda, MSc > Scrum Master, GeoMedia Smart Client > T: +43 1.9610567.4676 F: +43 1.9610567.4601 > E: steve.hruda at hexagongeospatial.com > > Hexagon Geospatial > Margaretenstra?e 70/I/1 > 1050 Wien, Austria > hexagongeospatial.com > > > > > 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 info at cuhka.com Thu Aug 20 19:42:52 2015 From: info at cuhka.com (info at cuhka.com) Date: Thu, 20 Aug 2015 15:42:52 -0400 Subject: Touch Screen X-axis flipped on Udoo/3M Touchscreen =?UTF-8?Q?EX=5FII?= Message-ID: I have got the first incarnation of my JavaFX app running on my Udoo board, a FreeScale based ARM. It is using the sw pipeline, not the Vivante yet, but there is another problem first. When I connect a mouse the mouse coordinates are interpreted correctly, but the touch events, or touch position is incorrect. When I run X11 both mouse and touch is correct. The Y axis follows the screen correctly, however the X axis seems to be flipped. I've run the app with flipXY, but that is incorrect as it flips both X & Y. I've also tried to set the minX and maxX the other way around, hoping that the LinuxTouchTransform would calculate the transform for X as -1, it doesn't unfortunately. I don't know of another property to set. Is there any? If not, how can I contribute to the JavaFX project so that I can solve this? Maurice. From vadim.pakhnushev at oracle.com Fri Aug 21 14:30:13 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 21 Aug 2015 17:30:13 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <55D735F5.7080300@oracle.com> 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 PDT until 1pm PDT. Happy testing! Thanks, Vadim From frederic at barachant.com Sat Aug 22 10:53:28 2015 From: frederic at barachant.com (=?utf-8?Q?fr=C3=A9d=C3=A9ric_Barachant?=) Date: Sat, 22 Aug 2015 12:53:28 +0200 Subject: status of the web components Message-ID: <01635BE7-C9B3-47F1-A792-2EE309738CB7@barachant.com> Hello. I am aware that the web components are not included in the arm port of javafx. For some projects i am possibly about to conduct, i am considering putting some resources on this, at least to understand feasability, before going forward. Can you someone please point me to a recap of what was done (or not done) and why? Also can you please describe what would be the known (rough) steps to be able to implement? Best, From kevin.rushforth at oracle.com Mon Aug 24 20:01:03 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Aug 2015 13:01:03 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <55DB77FF.6020103@oracle.com> From sven.reimers at gmail.com Tue Aug 25 13:34:20 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 25 Aug 2015 15:34:20 +0200 Subject: Usage of internal API's in charts Message-ID: Hi, What about things like com.sun.javafx.charts.ChartLayoutAnimator ? Actually there may not be too many users of this, but if you try to write your own axis implementation (e.g. LogarithmicAxis) you may need access to this - correct? Should we revisit every possible extension point in JavaFX and make sure all necessary implementations can be accessed via javafx.* packages? Thanks. Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven From kevin.rushforth at oracle.com Tue Aug 25 14:27:08 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Aug 2015 07:27:08 -0700 Subject: Usage of internal API's in charts In-Reply-To: References: Message-ID: <55DC7B3C.4020708@oracle.com> Sven Reimers wrote: > Hi, > > What about things like > > com.sun.javafx.charts.ChartLayoutAnimator ? > > Actually there may not be too many users of this, but if you try to write > your own axis implementation (e.g. LogarithmicAxis) you may need access to > this - correct? > I'll let Jonathan answer this. > Should we revisit every possible extension point in JavaFX and make sure > all necessary implementations can be accessed via javafx.* packages? > Yes. Although not all of them will be address in JDK 9, it will be helpful to know what they are and what the use case is. -- Kevin > Thanks. > > Sven > > From jonathan.giles at oracle.com Tue Aug 25 20:24:53 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 26 Aug 2015 08:24:53 +1200 Subject: Usage of internal API's in charts In-Reply-To: <55DC7B3C.4020708@oracle.com> References: <55DC7B3C.4020708@oracle.com> Message-ID: <55DCCF15.3000200@oracle.com> >> Hi, >> >> What about things like >> >> com.sun.javafx.charts.ChartLayoutAnimator ? >> >> Actually there may not be too many users of this, but if you try to >> write >> your own axis implementation (e.g. LogarithmicAxis) you may need >> access to >> this - correct? > > I'll let Jonathan answer this. ChartsLayoutAnimator didn't appear once on my jdeps analysis from a few weeks back, so it hasn't been on my radar as a possible candidate for making public. I don't imagine this will be something we try to bring out in JDK 9, but if it is something that is generally useful and important a bug should be filed for it. > >> Should we revisit every possible extension point in JavaFX and make sure >> all necessary implementations can be accessed via javafx.* packages? > > Yes. Although not all of them will be address in JDK 9, it will be > helpful to know what they are and what the use case is. I agree with Kevin - half the battle is just knowing what is generally useful. It would be wise to have an umbrella issue in JBS that tracks all 'make XXX public' issues. If we get a few of these kind of issues filed I'll make an umbrella issue. -- Jonathan From sven.reimers at gmail.com Tue Aug 25 21:16:29 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 25 Aug 2015 23:16:29 +0200 Subject: Usage of internal API's in charts In-Reply-To: <55DCCF15.3000200@oracle.com> References: <55DC7B3C.4020708@oracle.com> <55DCCF15.3000200@oracle.com> Message-ID: The reason this haas not shown up is that nobody has tried to extends charts maybe... Will think more about and try to file bugs Sven On Tue, Aug 25, 2015 at 10:24 PM, Jonathan Giles wrote: > > Hi, >>> >>> What about things like >>> >>> com.sun.javafx.charts.ChartLayoutAnimator ? >>> >>> Actually there may not be too many users of this, but if you try to write >>> your own axis implementation (e.g. LogarithmicAxis) you may need access >>> to >>> this - correct? >>> >> >> I'll let Jonathan answer this. >> > ChartsLayoutAnimator didn't appear once on my jdeps analysis from a few > weeks back, so it hasn't been on my radar as a possible candidate for > making public. I don't imagine this will be something we try to bring out > in JDK 9, but if it is something that is generally useful and important a > bug should be filed for it. > >> >> Should we revisit every possible extension point in JavaFX and make sure >>> all necessary implementations can be accessed via javafx.* packages? >>> >> >> Yes. Although not all of them will be address in JDK 9, it will be >> helpful to know what they are and what the use case is. >> > > I agree with Kevin - half the battle is just knowing what is generally > useful. It would be wise to have an umbrella issue in JBS that tracks all > 'make XXX public' issues. If we get a few of these kind of issues filed > I'll make an umbrella issue. > > -- Jonathan > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From info at cuhka.com Wed Aug 26 17:08:43 2015 From: info at cuhka.com (info at cuhka.com) Date: Wed, 26 Aug 2015 13:08:43 -0400 Subject: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up =?UTF-8?Q?JAVA=5FTOOL=5FOPTIONS?= Message-ID: <436335714153929fdf24bcbb4161be91@cuhka.com> The gradle build tries to find the version of the used Java JDK by running 'java -version', skipping the first line and expects to find the version in the second line. However, on Linux (Ubuntu) the first line of *any* Java invocation is "Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar"[1], thus failing at detection of the version, aborting the build. The 'Pickup up...' line is a standard feature of the JDK and a legacy that doesn't seem to be removed soon[2]. I guess the build script needs to accommodate for this. Proposed fix: // Determine the verion of Java in JDK_HOME. It looks like this: // // $ java -version // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar // java version "1.7.0_45" // Java(TM) SE Runtime Environment (build 1.7.0_45-b18) // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) // // The first line is optional, we need to parse the third line def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-version").start().getErrorStream())); try { String v = inStream.readLine(); if (v != null) { if (v.startsWith("Picked up")) { inStream.readLine(); } v = inStream.readLine(); [1] https://community.oracle.com/thread/1239778?start=0&tstart=0 [2] https://bugs.openjdk.java.net/browse/JDK-8039152 From pedro.duquevieira at gmail.com Wed Aug 26 17:18:50 2015 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 26 Aug 2015 18:18:50 +0100 Subject: Usage of internal API's in charts Message-ID: I've also extended charts and have also been confronted with internal APIs. -- Pedro Duque Vieira From chien.yang at oracle.com Wed Aug 26 18:43:10 2015 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 26 Aug 2015 11:43:10 -0700 Subject: Code Review Request For JDK-8088670: Remove use of internal classes methods from toys Message-ID: <55DE08BE.3050306@oracle.com> Hi Dave, Jonathan and Kevin, Please review the proposed fix mentioned in the JIRA: JIRA: https://bugs.openjdk.java.net/browse/JDK-8088670 Thanks, - Chien From david.dehaven at oracle.com Wed Aug 26 18:53:19 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 26 Aug 2015 11:53:19 -0700 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats Message-ID: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> I am proposing we deprecate support for the VP6 video encoding format and the FXM/FLV file format in JFXMedia for Java 9. The current intention is to completely remove support for these components in the Java 10 timeframe. Note that this is only deprecation, Java 9 will still support playback of VP6 video in FXM or FLV containers. The reasons in favor of deprecation: - Use of VP6 on the web has lost favor, it was superseded fairly quickly by H.264/AVC in Flash 9 and Adobe generally recommends using H.264/AVC over it. It's not even recommended for compatibility as as their "Sorenson Spark" H.263 variant has a much longer history in Flash. - Tools for generating VP6 are non-trivial, even Adobe products no longer support generating VP6 content out of the box, you have to install add-ons. While there are free tools, none are particularly elegant or easy to use, or produce sub-optimal results. We've heard no end of complaints from the community about the lack of tools for VP6, so it seems a logical decision to migrate away from it. - We have had (many) requests to add external codec support, if (that's a big IF, please do NOT take this as any sort of promise or even the hope of a promise!) we were to implement such a feature and if you absolutely had to rely on VP6 then you would be able to provide one yourself. - The vp6 codec is the LAST closed source component in media, once removed JFXMedia will be 100% open source. I think we can all agree this is a good thing and something I personally look forward to achieving. The one and only reason I can think of for NOT deprecating VP6: - It is currently the only format (supported by JFXMedia) which supports an alpha channel, though I have had thoughts on how to address that in a way that would allow the use of practically any media format. While compelling for some use cases, it is a very niche use case and thus cannot outweigh the benefits. So, this is a call out to any who may be using VP6, please speak up now so we can discuss it or forever hold your peace. For reference, the list of supported formats in JFXMedia are in the JavaDoc for javafx.scene.Media: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html#SupportedMediaTypes -DrD- From david.dehaven at oracle.com Wed Aug 26 19:38:25 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 26 Aug 2015 12:38:25 -0700 Subject: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: <436335714153929fdf24bcbb4161be91@cuhka.com> References: <436335714153929fdf24bcbb4161be91@cuhka.com> Message-ID: <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> > The gradle build tries to find the version of the used Java JDK by running 'java -version', skipping the first line and expects to find the version in the second line. > > However, on Linux (Ubuntu) the first line of *any* Java invocation is "Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar"[1], thus failing at detection of the version, aborting the build. > > The 'Pickup up...' line is a standard feature of the JDK and a legacy that doesn't seem to be removed soon[2]. > > I guess the build script needs to accommodate for this. > > Proposed fix: > > // Determine the verion of Java in JDK_HOME. It looks like this: > // > // $ java -version > // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar > // java version "1.7.0_45" > // Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > // > // The first line is optional, we need to parse the third line > def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-version").start().getErrorStream())); > try { > String v = inStream.readLine(); > > if (v != null) { > if (v.startsWith("Picked up")) { > inStream.readLine(); > } > > v = inStream.readLine(); Why not just use "java -fullversion" instead? $ java -fullversion java full version "1.8.0_60-ea-b14" $ JAVA_TOOL_OPTIONS="-Xmx512M" java -fullversion java full version "1.8.0_60-ea-b14" $ java -version java version "1.8.0_60-ea" Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) $ JAVA_TOOL_OPTIONS="-Xmx512M" java -version Picked up JAVA_TOOL_OPTIONS: -Xmx512M java version "1.8.0_60-ea" Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) It's a lot less stuff to parse. Also, "java -fullversion" does not start the VM, so should be faster. -DrD- From swpalmer at gmail.com Wed Aug 26 20:25:23 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 26 Aug 2015 16:25:23 -0400 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> Message-ID: <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> +1 for deprecation of VP6 and clearing the way to open sourcing of JFXMedia. On a related note, you will soon need to support H.265/HEVC. HEVC apparently also supports an alpha channel, so it may also address that concern. (See http://www.itu.int/rec/T-REC-H.265-201504-I/en) All of this might be much easier to handle if JDK-8091063 is addressed (the open sourcing of JFXMedia may assist with this). https://bugs.openjdk.java.net/browse/JDK-8091063 The brilliant guy that filed that issue nearly seven years ago was on to something :-) Then legacy formats could be provided in optional downloads and new formats can be supported without the need to integrate them within the JRE code. Regards, Scott > On Aug 26, 2015, at 2:53 PM, David DeHaven wrote: > > > I am proposing we deprecate support for the VP6 video encoding format and the FXM/FLV file format in JFXMedia for Java 9. The current intention is to completely remove support for these components in the Java 10 timeframe. Note that this is only deprecation, Java 9 will still support playback of VP6 video in FXM or FLV containers. > > The reasons in favor of deprecation: > - Use of VP6 on the web has lost favor, it was superseded fairly quickly by H.264/AVC in Flash 9 and Adobe generally recommends using H.264/AVC over it. It's not even recommended for compatibility as as their "Sorenson Spark" H.263 variant has a much longer history in Flash. > - Tools for generating VP6 are non-trivial, even Adobe products no longer support generating VP6 content out of the box, you have to install add-ons. While there are free tools, none are particularly elegant or easy to use, or produce sub-optimal results. We've heard no end of complaints from the community about the lack of tools for VP6, so it seems a logical decision to migrate away from it. > - We have had (many) requests to add external codec support, if (that's a big IF, please do NOT take this as any sort of promise or even the hope of a promise!) we were to implement such a feature and if you absolutely had to rely on VP6 then you would be able to provide one yourself. > - The vp6 codec is the LAST closed source component in media, once removed JFXMedia will be 100% open source. I think we can all agree this is a good thing and something I personally look forward to achieving. > > > The one and only reason I can think of for NOT deprecating VP6: > - It is currently the only format (supported by JFXMedia) which supports an alpha channel, though I have had thoughts on how to address that in a way that would allow the use of practically any media format. > > > While compelling for some use cases, it is a very niche use case and thus cannot outweigh the benefits. So, this is a call out to any who may be using VP6, please speak up now so we can discuss it or forever hold your peace. > > > For reference, the list of supported formats in JFXMedia are in the JavaDoc for javafx.scene.Media: > https://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html#SupportedMediaTypes > > -DrD- > From info at cuhka.com Wed Aug 26 20:43:04 2015 From: info at cuhka.com (info at cuhka.com) Date: Wed, 26 Aug 2015 16:43:04 -0400 Subject: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up =?UTF-8?Q?JAVA=5FTOOL=5FOPTIONS?= In-Reply-To: <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> References: <436335714153929fdf24bcbb4161be91@cuhka.com> <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> Message-ID: I was not aware of the existence of the -fullversion option. It is not listed at the Oracle site, afaik. Can it be assumed to be present in non-OpenJDK, non-Oracle JDKs? David DeHaven schreef op 2015-08-26 15:38: >> The gradle build tries to find the version of the used Java JDK by >> running 'java -version', skipping the first line and expects to find >> the version in the second line. >> >> However, on Linux (Ubuntu) the first line of *any* Java invocation is >> "Picked up JAVA_TOOL_OPTIONS: >> -javaagent:/usr/share/java/jayatanaag.jar"[1], thus failing at >> detection of the version, aborting the build. >> >> The 'Pickup up...' line is a standard feature of the JDK and a legacy >> that doesn't seem to be removed soon[2]. >> >> I guess the build script needs to accommodate for this. >> >> Proposed fix: >> >> // Determine the verion of Java in JDK_HOME. It looks like this: >> // >> // $ java -version >> // Picked up JAVA_TOOL_OPTIONS: >> -javaagent:/usr/share/java/jayatanaag.jar >> // java version "1.7.0_45" >> // Java(TM) SE Runtime Environment (build 1.7.0_45-b18) >> // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) >> // >> // The first line is optional, we need to parse the third line >> def inStream = new java.io.BufferedReader(new >> java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, >> "-version").start().getErrorStream())); >> try { >> String v = inStream.readLine(); >> >> if (v != null) { >> if (v.startsWith("Picked up")) { >> inStream.readLine(); >> } >> >> v = inStream.readLine(); > > Why not just use "java -fullversion" instead? > > $ java -fullversion > java full version "1.8.0_60-ea-b14" > > $ JAVA_TOOL_OPTIONS="-Xmx512M" java -fullversion > java full version "1.8.0_60-ea-b14" > > $ java -version > java version "1.8.0_60-ea" > Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) > > $ JAVA_TOOL_OPTIONS="-Xmx512M" java -version > Picked up JAVA_TOOL_OPTIONS: -Xmx512M > java version "1.8.0_60-ea" > Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) > > It's a lot less stuff to parse. Also, "java -fullversion" does not > start the VM, so should be faster. > > -DrD- From kevin.rushforth at oracle.com Wed Aug 26 21:52:11 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Aug 2015 14:52:11 -0700 Subject: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> References: <436335714153929fdf24bcbb4161be91@cuhka.com> <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> Message-ID: <55DE350B.2090705@oracle.com> David DeHaven wrote: >> The gradle build tries to find the version of the used Java JDK by running 'java -version', skipping the first line and expects to find the version in the second line. >> >> However, on Linux (Ubuntu) the first line of *any* Java invocation is "Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar"[1], thus failing at detection of the version, aborting the build. >> >> The 'Pickup up...' line is a standard feature of the JDK and a legacy that doesn't seem to be removed soon[2]. >> >> I guess the build script needs to accommodate for this. >> >> Proposed fix: >> >> // Determine the verion of Java in JDK_HOME. It looks like this: >> // >> // $ java -version >> // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar >> // java version "1.7.0_45" >> // Java(TM) SE Runtime Environment (build 1.7.0_45-b18) >> // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) >> // >> // The first line is optional, we need to parse the third line >> def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-version").start().getErrorStream())); >> try { >> String v = inStream.readLine(); >> >> if (v != null) { >> if (v.startsWith("Picked up")) { >> inStream.readLine(); >> } >> >> v = inStream.readLine(); >> > > Why not just use "java -fullversion" instead? > > $ java -fullversion > java full version "1.8.0_60-ea-b14" > > $ JAVA_TOOL_OPTIONS="-Xmx512M" java -fullversion > java full version "1.8.0_60-ea-b14" > > $ java -version > java version "1.8.0_60-ea" > Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) > > $ JAVA_TOOL_OPTIONS="-Xmx512M" java -version > Picked up JAVA_TOOL_OPTIONS: -Xmx512M > java version "1.8.0_60-ea" > Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) > > It's a lot less stuff to parse. Also, "java -fullversion" does not start the VM, so should be faster. > That makes sense as long as the output has everything we need. I need to make changes in this area anyway for JDK 9 in support of the new version string (JEP 223). See: https://bugs.openjdk.java.net/browse/JDK-8133750 So this would seems like another good change to do, either as part of that fix or separately. -- Kevin > -DrD- > > From david.dehaven at oracle.com Wed Aug 26 22:10:59 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 26 Aug 2015 15:10:59 -0700 Subject: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: References: <436335714153929fdf24bcbb4161be91@cuhka.com> <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> Message-ID: I can't comment on non-Oracle JDKs, but It's in libjli so anything based on OpenJDK should support it. -DrD- > I was not aware of the existence of the -fullversion option. It is not listed at the Oracle site, afaik. Can it be assumed to be present in non-OpenJDK, non-Oracle JDKs? > > David DeHaven schreef op 2015-08-26 15:38: >>> The gradle build tries to find the version of the used Java JDK by running 'java -version', skipping the first line and expects to find the version in the second line. >>> However, on Linux (Ubuntu) the first line of *any* Java invocation is "Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar"[1], thus failing at detection of the version, aborting the build. >>> The 'Pickup up...' line is a standard feature of the JDK and a legacy that doesn't seem to be removed soon[2]. >>> I guess the build script needs to accommodate for this. >>> Proposed fix: >>> // Determine the verion of Java in JDK_HOME. It looks like this: >>> // >>> // $ java -version >>> // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar >>> // java version "1.7.0_45" >>> // Java(TM) SE Runtime Environment (build 1.7.0_45-b18) >>> // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) >>> // >>> // The first line is optional, we need to parse the third line >>> def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-version").start().getErrorStream())); >>> try { >>> String v = inStream.readLine(); >>> if (v != null) { >>> if (v.startsWith("Picked up")) { >>> inStream.readLine(); >>> } >>> v = inStream.readLine(); >> Why not just use "java -fullversion" instead? >> $ java -fullversion >> java full version "1.8.0_60-ea-b14" >> $ JAVA_TOOL_OPTIONS="-Xmx512M" java -fullversion >> java full version "1.8.0_60-ea-b14" >> $ java -version >> java version "1.8.0_60-ea" >> Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) >> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) >> $ JAVA_TOOL_OPTIONS="-Xmx512M" java -version >> Picked up JAVA_TOOL_OPTIONS: -Xmx512M >> java version "1.8.0_60-ea" >> Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) >> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) >> It's a lot less stuff to parse. Also, "java -fullversion" does not >> start the VM, so should be faster. >> -DrD- > From david.dehaven at oracle.com Wed Aug 26 22:26:52 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 26 Aug 2015 15:26:52 -0700 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> Message-ID: > +1 for deprecation of VP6 and clearing the way to open sourcing of JFXMedia. > > On a related note, you will soon need to support H.265/HEVC. HEVC apparently also supports an alpha channel, so it may also address that concern. (See http://www.itu.int/rec/T-REC-H.265-201504-I/en) 3D support too! Not sure how we'd handle that though... > All of this might be much easier to handle if JDK-8091063 is addressed (the open sourcing of JFXMedia may assist with this). > https://bugs.openjdk.java.net/browse/JDK-8091063 > > The brilliant guy that filed that issue nearly seven years ago was on to something :-) > > Then legacy formats could be provided in optional downloads and new formats can be supported without the need to integrate them within the JRE code. Yes, that would be wonderful! -DrD- From kevin.rushforth at oracle.com Wed Aug 26 22:42:51 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Aug 2015 15:42:51 -0700 Subject: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: References: <436335714153929fdf24bcbb4161be91@cuhka.com> <8D8F00D0-F3B8-4F73-B758-63CA273F6E82@oracle.com> Message-ID: <55DE40EB.3020105@oracle.com> I will also note that OpenJFX depends on OpenJDK, so I am fine using "-fullversion" as long as it works in both OpenJDK and Oracle JDK builds, and both before and after the version string changes in JEP-223. -- Kevin David DeHaven wrote: > I can't comment on non-Oracle JDKs, but It's in libjli so anything based on OpenJDK should support it. > > -DrD- > > >> I was not aware of the existence of the -fullversion option. It is not listed at the Oracle site, afaik. Can it be assumed to be present in non-OpenJDK, non-Oracle JDKs? >> >> David DeHaven schreef op 2015-08-26 15:38: >> >>>> The gradle build tries to find the version of the used Java JDK by running 'java -version', skipping the first line and expects to find the version in the second line. >>>> However, on Linux (Ubuntu) the first line of *any* Java invocation is "Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar"[1], thus failing at detection of the version, aborting the build. >>>> The 'Pickup up...' line is a standard feature of the JDK and a legacy that doesn't seem to be removed soon[2]. >>>> I guess the build script needs to accommodate for this. >>>> Proposed fix: >>>> // Determine the verion of Java in JDK_HOME. It looks like this: >>>> // >>>> // $ java -version >>>> // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar >>>> // java version "1.7.0_45" >>>> // Java(TM) SE Runtime Environment (build 1.7.0_45-b18) >>>> // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) >>>> // >>>> // The first line is optional, we need to parse the third line >>>> def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-version").start().getErrorStream())); >>>> try { >>>> String v = inStream.readLine(); >>>> if (v != null) { >>>> if (v.startsWith("Picked up")) { >>>> inStream.readLine(); >>>> } >>>> v = inStream.readLine(); >>>> >>> Why not just use "java -fullversion" instead? >>> $ java -fullversion >>> java full version "1.8.0_60-ea-b14" >>> $ JAVA_TOOL_OPTIONS="-Xmx512M" java -fullversion >>> java full version "1.8.0_60-ea-b14" >>> $ java -version >>> java version "1.8.0_60-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) >>> $ JAVA_TOOL_OPTIONS="-Xmx512M" java -version >>> Picked up JAVA_TOOL_OPTIONS: -Xmx512M >>> java version "1.8.0_60-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode) >>> It's a lot less stuff to parse. Also, "java -fullversion" does not >>> start the VM, so should be faster. >>> -DrD- >>> > > From chien.yang at oracle.com Thu Aug 27 00:45:35 2015 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 26 Aug 2015 17:45:35 -0700 Subject: Code Review Request For JDK-8130376: Incorrect LayoutFlags adjustment when adding unmanaged children to SceneGraph Message-ID: <55DE5DAF.2010104@oracle.com> Hi Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8130376 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8130376/webrev.00/ Thanks, - Chien From sven.reimers at gmail.com Thu Aug 27 06:08:25 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 27 Aug 2015 08:08:25 +0200 Subject: Usage of internal API's in charts In-Reply-To: References: Message-ID: Ok. That what I assumed. Shall we try to compile a list with needed API's? -Sven Am 26.08.2015 19:19 schrieb "Pedro Duque Vieira" < pedro.duquevieira at gmail.com>: > I've also extended charts and have also been confronted with internal APIs. > > -- > Pedro Duque Vieira > From mp at jugs.org Thu Aug 27 06:29:02 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Thu, 27 Aug 2015 08:29:02 +0200 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> Message-ID: <55DEAE2E.1080300@jugs.org> Am 26.08.15 um 22:25 schrieb Scott Palmer: > > Then legacy formats could be provided in optional downloads and new formats can be supported without the need to integrate them within the JRE code. > > To me this sounds again like a Java/JavaFX specific solution which, to my opinion, is a dead-end road. I think it would be much more important that JavaFX can directly use all system installed codecs. I simply don't understand why it is possible to install a codec pack on a machine and almost all software, with the exception of JavaFX, is able to immediately use that and only JavaFX based applications are not. Michael From kirill.kirichenko at oracle.com Thu Aug 27 11:18:28 2015 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Thu, 27 Aug 2015 14:18:28 +0300 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <55DEAE2E.1080300@jugs.org> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> Message-ID: <55DEF204.3010007@oracle.com> On 27.08.2015 9:29, Dr. Michael Paus wrote: > To me this sounds again like a Java/JavaFX specific solution which, to > my opinion, is a dead-end road. I think it would be much more important > that JavaFX can directly use all system installed codecs. I simply don't > understand why it is possible to install a codec pack on a machine and > almost all software, with the exception of JavaFX, is able to > immediately use that and only JavaFX based applications are not. Although this is an off-topic I'll answer to your question. Security and testing are the reasons. It's virtually impossible to test every possible codec on every possible platform. Many of them are proprietary so we don't control their code/can't fix their bugs. And all blame that JavaFX can't play this/can't play that will fall on our heads. And it can open many potential security vulnerabilities. From swpalmer at gmail.com Thu Aug 27 11:39:45 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 27 Aug 2015 07:39:45 -0400 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <55DEAE2E.1080300@jugs.org> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> Message-ID: <7D06C101-528D-40A9-BCF3-4ED175605E8C@gmail.com> > On Aug 27, 2015, at 2:29 AM, Dr. Michael Paus wrote: > > Am 26.08.15 um 22:25 schrieb Scott Palmer: >> >> Then legacy formats could be provided in optional downloads and new formats can be supported without the need to integrate them within the JRE code. >> >> > To me this sounds again like a Java/JavaFX specific solution which, to my opinion, is a dead-end road. I think it would be much more important that JavaFX can directly use all system installed codecs. I simply don't understand why it is possible to install a codec pack on a machine and almost all software, with the exception of JavaFX, is able to immediately use that and only JavaFX based applications are not. > > Michael I agree that codecs that are usable by the system?s default media framework should work. However, I believe that is already supported in most cases, is it not? There still needs to be a guarantee that certain specific codecs will work wherever JFXMEdia is supported. Otherwise you lose a significant bit of cross-platform compatibility. Media assets that you ship with your application need to be able to play, regardless of how the end user has configured their specific codec environment. Scott From berry120 at gmail.com Thu Aug 27 12:49:28 2015 From: berry120 at gmail.com (Michael Berry) Date: Thu, 27 Aug 2015 13:49:28 +0100 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <7D06C101-528D-40A9-BCF3-4ED175605E8C@gmail.com> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> <7D06C101-528D-40A9-BCF3-4ED175605E8C@gmail.com> Message-ID: +1 for deprecation - I haven't used VP6 in a long while, and would value the whole thing being open source more than its inclusion. Out of interest, is this anything to do with JEP 257? I started looking at this with Kirill's guidance a year or so ago, but sadly many other things had to take precedence so I didn't really have the time. Michael On 27 August 2015 at 12:39, Scott Palmer wrote: > > > On Aug 27, 2015, at 2:29 AM, Dr. Michael Paus wrote: > > > > Am 26.08.15 um 22:25 schrieb Scott Palmer: > >> > >> Then legacy formats could be provided in optional downloads and new > formats can be supported without the need to integrate them within the JRE > code. > >> > >> > > To me this sounds again like a Java/JavaFX specific solution which, to > my opinion, is a dead-end road. I think it would be much more important > that JavaFX can directly use all system installed codecs. I simply don't > understand why it is possible to install a codec pack on a machine and > almost all software, with the exception of JavaFX, is able to immediately > use that and only JavaFX based applications are not. > > > > Michael > > I agree that codecs that are usable by the system?s default media > framework should work. However, I believe that is already supported in > most cases, is it not? > It's not - JavaFX can decode the audio / video / container formats that it knows about through its GStreamer plugins, and nothing else (unless you compile them in yourself, which isn't all that hard.) > > There still needs to be a guarantee that certain specific codecs will work > wherever JFXMEdia is supported. Otherwise you lose a significant bit of > cross-platform compatibility. Media assets that you ship with your > application need to be able to play, regardless of how the end user has > configured their specific codec environment. > > Scott > -- Thanks, Michael From mp at jugs.org Thu Aug 27 12:55:37 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Thu, 27 Aug 2015 14:55:37 +0200 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <55DEF204.3010007@oracle.com> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> <55DEF204.3010007@oracle.com> Message-ID: <55DF08C9.8040400@jugs.org> Am 27.08.15 um 13:18 schrieb Kirill Kirichenko: > On 27.08.2015 9:29, Dr. Michael Paus wrote: >> To me this sounds again like a Java/JavaFX specific solution which, to >> my opinion, is a dead-end road. I think it would be much more important >> that JavaFX can directly use all system installed codecs. I simply don't >> understand why it is possible to install a codec pack on a machine and >> almost all software, with the exception of JavaFX, is able to >> immediately use that and only JavaFX based applications are not. > > Although this is an off-topic I'll answer to your question. > > Security and testing are the reasons. > It's virtually impossible to test every possible codec on every > possible platform. Many of them are proprietary so we don't control > their code/can't fix their bugs. And all blame that JavaFX can't play > this/can't play that will fall on our heads. > And it can open many potential security vulnerabilities. 1. Why do you consider my comment off-topic? It's a direct response to a statement made by Scott Palmer. 2. Why do you want to control other peoples code? Actually, if you were just using the system APIs it should be completely transparent to you whether the user has installed additional codecs on his system or not. 3. How do you explain to your customers that a JavaFX-based application cannot even play a .mov file on a Mac whereas every other media-aware application can? From info at cuhka.com Thu Aug 27 13:56:46 2015 From: info at cuhka.com (info at cuhka.com) Date: Thu, 27 Aug 2015 13:56:46 +0000 Subject: [PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS Message-ID: <20150827135646.Horde.fBVbpKpoc6DZPvB-pRcb6Q4@dime187.dizinc.com> I've adapted the build.gradle to use java -fullversion instead of java -version, parsing the result with a regexp. diff -r 9b5fc7c1e5e6 build.gradle --- a/build.gradle Fri Aug 07 18:35:42 2015 -0700 +++ b/build.gradle Thu Aug 27 15:52:11 2015 +0200 @@ -719,29 +719,27 @@ if (!file(JAVAH).exists()) throw new Exception("Missing or incorrect path to 'javah': '$JAVAH'. Perhaps bad JDK_HOME? $JDK_HOME") if (!file(JAVADOC).exists()) throw new Exception("Missing or incorrect path to 'javadoc': '$JAVADOC'. Perhaps bad JDK_HOME? $JDK_HOME") - + // Determine the verion of Java in JDK_HOME. It looks like this: // -// $ java -version -// java version "1.7.0_45" -// Java(TM) SE Runtime Environment (build 1.7.0_45-b18) -// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) -// -// We need to parse the second line -def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-version").start().getErrorStream())); +// $ java -fullversion +// for OpenJDK: openjdk full version "1.8.0_45-internal-b14" +// for Oracle JDK: java full version "1.8.0_45-b14" + +def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, "-fullversion").start().getErrorStream())); try { - if (inStream.readLine() != null) { - String v = inStream.readLine(); - if (v != null) { - int ib = v.indexOf(" (build "); - if (ib != -1) { - String ver = v.substring(ib + 8, v.size() - 1); - - defineProperty("jdkRuntimeVersion", ver) - defineProperty("jdkVersion", jdkRuntimeVersion.split("-")[0]) - defineProperty("jdkBuildNumber", jdkRuntimeVersion.substring(jdkRuntimeVersion.lastIndexOf("-b") + 2)) - } - } + def v = inStream.readLine(); + + if (v != null) { + def pattern = java.util.regex.Pattern.compile("^[^\"]*\"((\\d+(?:\\.\\d+)*)_(\\d+))(?:-\\w+)?(?:-b(\\d+))\"\$") + def matcher = pattern.matcher(v) + + if (matcher.matches()) { + defineProperty("jdkVersion", matcher.group(1)) + defineProperty("jdkRuntimeVersion", matcher.group(2)) + defineProperty("jdkUpdate", matcher.group(3)) + defineProperty("jdkBuildNumber", matcher.group(4)) + } } } finally { inStream.close(); From kevin.rushforth at oracle.com Thu Aug 27 14:54:34 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Aug 2015 07:54:34 -0700 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> <7D06C101-528D-40A9-BCF3-4ED175605E8C@gmail.com> Message-ID: <55DF24AA.3010209@oracle.com> It's not directly related to JEP 257, no. Just some outstanding cleanup. Btw, speaking of JEP 257, we plan to integrate that to 9-dev today. -- Kevin Michael Berry wrote: > +1 for deprecation - I haven't used VP6 in a long while, and would value > the whole thing being open source more than its inclusion. > > Out of interest, is this anything to do with JEP 257? I started looking at > this with Kirill's guidance a year or so ago, but sadly many other things > had to take precedence so I didn't really have the time. > > Michael > > On 27 August 2015 at 12:39, Scott Palmer wrote: > > >>> On Aug 27, 2015, at 2:29 AM, Dr. Michael Paus wrote: >>> >>> Am 26.08.15 um 22:25 schrieb Scott Palmer: >>> >>>> Then legacy formats could be provided in optional downloads and new >>>> >> formats can be supported without the need to integrate them within the JRE >> code. >> >>>> >>> To me this sounds again like a Java/JavaFX specific solution which, to >>> >> my opinion, is a dead-end road. I think it would be much more important >> that JavaFX can directly use all system installed codecs. I simply don't >> understand why it is possible to install a codec pack on a machine and >> almost all software, with the exception of JavaFX, is able to immediately >> use that and only JavaFX based applications are not. >> >>> Michael >>> >> I agree that codecs that are usable by the system?s default media >> framework should work. However, I believe that is already supported in >> most cases, is it not? >> >> > > It's not - JavaFX can decode the audio / video / container formats that it > knows about through its GStreamer plugins, and nothing else (unless you > compile them in yourself, which isn't all that hard.) > > > >> There still needs to be a guarantee that certain specific codecs will work >> wherever JFXMEdia is supported. Otherwise you lose a significant bit of >> cross-platform compatibility. Media assets that you ship with your >> application need to be able to play, regardless of how the end user has >> configured their specific codec environment. >> >> Scott >> >> > > > > From david.dehaven at oracle.com Thu Aug 27 18:53:19 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 27 Aug 2015 11:53:19 -0700 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> <7D06C101-528D-40A9-BCF3-4ED175605E8C@gmail.com> Message-ID: <79681EDF-2CA3-4198-BC46-1F05BD7CB5EF@oracle.com> > +1 for deprecation - I haven't used VP6 in a long while, and would value > the whole thing being open source more than its inclusion. > > Out of interest, is this anything to do with JEP 257? I started looking at > this with Kirill's guidance a year or so ago, but sadly many other things > had to take precedence so I didn't really have the time. No, that's unrelated. I suspect we'll hear something about that soon... Oh, I see Kevin let the cat out of the bag. Well, there you go :) >> I agree that codecs that are usable by the system?s default media >> framework should work. However, I believe that is already supported in >> most cases, is it not? >> > > It's not - JavaFX can decode the audio / video / container formats that it > knows about through its GStreamer plugins, and nothing else (unless you > compile them in yourself, which isn't all that hard.) Not entirely true... on the Mac, GStreamer does not support HLS, that gets routed through QTKit (for <= 10.7) or AVFoundation (10.8+). With VP6 gone there will actually be no need for GStreamer on Mac at all. It *used* to be the case that we allowed anything the native platform provided, in the previous media stack (JMC if anyone was paying attention). The big issue, as Kirill pointed out, was it was very difficult to support due to the vast combinations of operating systems and codecs/media formats and (more importantly) there are security implications. There are internal discussions ongoing about how we're approaching this problem. The security aspects only affect webstart and plugin, standalone applications aren't as much of a concern (except from a supportability standpoint) so maybe some compromise can be reached. I would actually favor allowing formats supplied by the underlying native platform over trying to figure out how to provide a pluggable codec interface, but it needs to be done in a way that's sustainable and does not expose security vulnerabilities. Again, I'm not promising anything, just know that complaints and requests have been heard and are being taken into consideration. -DrD- From berry120 at gmail.com Thu Aug 27 20:36:36 2015 From: berry120 at gmail.com (Michael Berry) Date: Thu, 27 Aug 2015 21:36:36 +0100 Subject: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats In-Reply-To: <79681EDF-2CA3-4198-BC46-1F05BD7CB5EF@oracle.com> References: <79CF1E8C-8453-4711-9E21-A6B0BCFF5726@oracle.com> <1C54190B-A575-4A58-8FC5-E2A69CF4126A@gmail.com> <55DEAE2E.1080300@jugs.org> <7D06C101-528D-40A9-BCF3-4ED175605E8C@gmail.com> <79681EDF-2CA3-4198-BC46-1F05BD7CB5EF@oracle.com> Message-ID: On 27 August 2015 at 19:53, David DeHaven wrote: > > > +1 for deprecation - I haven't used VP6 in a long while, and would value > > the whole thing being open source more than its inclusion. > > > > Out of interest, is this anything to do with JEP 257? I started looking > at > > this with Kirill's guidance a year or so ago, but sadly many other things > > had to take precedence so I didn't really have the time. > > No, that's unrelated. I suspect we'll hear something about that soon... > Oh, I see Kevin let the cat out of the bag. Well, there you go :) > Awesome, that's good to hear! > > > >> I agree that codecs that are usable by the system?s default media > >> framework should work. However, I believe that is already supported in > >> most cases, is it not? > >> > > > > It's not - JavaFX can decode the audio / video / container formats that > it > > knows about through its GStreamer plugins, and nothing else (unless you > > compile them in yourself, which isn't all that hard.) > > Not entirely true... on the Mac, GStreamer does not support HLS, that gets > routed through QTKit (for <= 10.7) or AVFoundation (10.8+). With VP6 gone > there will actually be no need for GStreamer on Mac at all. > Sorry, my mistake - I'm used to the media stack on Windows where this is (I think) always the case. > > > It *used* to be the case that we allowed anything the native platform > provided, in the previous media stack (JMC if anyone was paying attention). > > The big issue, as Kirill pointed out, was it was very difficult to support > due to the vast combinations of operating systems and codecs/media formats > and (more importantly) there are security implications. > Perhaps a political issue as oppose to a technical one, but (on the support side of things rather than the security side) would "best efforts" here with a warning that it might not work 100% reliably be better than not at all? > > There are internal discussions ongoing about how we're approaching this > problem. The security aspects only affect webstart and plugin, standalone > applications aren't as much of a concern (except from a supportability > standpoint) so maybe some compromise can be reached. > Without wishing to drag this further off topic (perhaps it should be split into a separate discussion!), from memory at the moment the Java code won't allow any format down to the native layer (gstreamer) unless it matches one of the types it's aware of. Would it be possible to remove this hard requirement (perhaps with a flag?) If this was done then it would probably be a small bit of boilerplate in the native layer to pass the stream down to the relevant plugin. If it doesn't exist then we haven't lost anything, if it does then the stream can be played without an issue. This wouldn't change anything by default, but it would mean that anyone could then drag custom gstreamer plugins into the correct JRE directory and have them work straight off. Considering that many applications bundle a JRE anyway these days, that would make it trivial for those who wanted to to support any other codec / container type that GStreamer offered, and would (presumably) remove the support / legal burden on Oracle of distributing and maintaining these plugins. Hopefully that ticks the sustainability and security boxes? Michael > I would actually favor allowing formats supplied by the underlying native > platform over trying to figure out how to provide a pluggable codec > interface, but it needs to be done in a way that's sustainable and does not > expose security vulnerabilities. > Again, I'm not promising anything, just know that complaints and requests > have been heard and are being taken into consideration. > > -DrD- > > -- Thanks, Michael From jonathan.giles at oracle.com Thu Aug 27 22:41:45 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 28 Aug 2015 10:41:45 +1200 Subject: JEP 253 Update: new JavaDoc ready for review Message-ID: <55DF9229.2000104@oracle.com> Hi all, As promised the other week here is an updated javadoc export of the proposed APIs for JEP 253. It includes the APIs for the third subproject (new CSS APIs), and it also _removes_ the APIs for the second subproject (InputMap APIs). The URL for the JavaDoc is here: http://jonathangiles.net/javafx/jdk9/jep253/6/ The CSS APIs are ready for review, but we are the first to admit that the javadoc is incomplete. We plan to do a big javadoc push on these docs in the next week, but we didn't want to hold up the first review until then. If you have questions on certain API, please let us know - at the very least it may inform our javadoc efforts! The InputMap API has been removed as we have decided now is not the right time to move that forward. For one it has not yet been met with universal community praise :-), but for two it doesn't feel right to release it without the behaviors themselves becoming public. I worried that without the behaviors being public that the InputMap was a bit of a 'map to nowhere'. My hope is that we can resolve this in an update release of JDK 9. The plan now is to remove the second subproject from JEP 253 to have it correctly tracking our intentions, so I will be doing that in the coming week. However, all is not lost! The InputMap continues to live on inside our behaviors code, and will continue to form the basis for future iterations and investigations. It already is a much nicer approach than we had previously for our behaviors, so I'm quite happy that even though we haven't scored the points for new public API, we've scored code quality points at least. We look forward to your feedback, -- Jonathan From kevin.rushforth at oracle.com Fri Aug 28 01:25:16 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Aug 2015 18:25:16 -0700 Subject: Just pushed the updated GStreamer for JEP 257 Message-ID: <55DFB87C.7090400@oracle.com> I just pushed the changeset for JEP 257 [1] [2] on behalf of Alexander Matveev to the openjfx 9-dev repo. If you have any questions about the new GStreamer, please let Alexander or Kirill know. This will be in next week's early access build of JDK 9 (build 80). As previously announced [3] this means that JavaFX for JDK 9 will no longer build or run on some older Linux distros. -- Kevin [1] http://openjdk.java.net/jeps/257 [2] https://bugs.openjdk.java.net/browse/JDK-8043352 [3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-August/017722.html From kevin.rushforth at oracle.com Fri Aug 28 01:55:07 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Aug 2015 18:55:07 -0700 Subject: CFV: New OpenJFX Committer: Alexander Matveev Message-ID: <55DFBF7B.2040408@oracle.com> I hereby nominate Alexander Matveev [1] to OpenJFX Committer. Alexander was an initial member of JavaFX team at Oracle when the OpenJFX project was created, and was on the initial list of approved committers [2]. His status as OpenJFX committer was not recorded at that time on the Census. This CVF is intended to correct this oversight. Alexander's changes prior to JavaFX becoming open-source were significant (which is why he was on the initial list of committers). In particular, Alexander, along with the rest of the media team, contributed much of the code that went into the open-source changeset that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: hg log -r aee256fde55 Counting his contribution to that changeset, Alexander now also has the requisite number of changes in the open-source repo to become a committer. hg log -M -u "matvee" Votes are due by September 10, 2015. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks, -- Kevin [1] http://openjdk.java.net/census#almatvee [2] http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From vadim.pakhnushev at oracle.com Fri Aug 28 06:42:56 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 28 Aug 2015 09:42:56 +0300 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <55E002F0.9020805@oracle.com> Vote: yes On 28.08.2015 4:55, Kevin Rushforth wrote: > I hereby nominate Alexander Matveev [1] to OpenJFX Committer. > > Alexander was an initial member of JavaFX team at Oracle when the > OpenJFX project was created, and was on the initial list of approved > committers [2]. His status as OpenJFX committer was not recorded at > that time on the Census. This CVF is intended to correct this oversight. > > Alexander's changes prior to JavaFX becoming open-source were > significant (which is why he was on the initial list of committers). > In particular, Alexander, along with the rest of the media team, > contributed much of the code that went into the open-source changeset > that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: > > hg log -r aee256fde55 > > Counting his contribution to that changeset, Alexander now also has > the requisite number of changes in the open-source repo to become a > committer. > > hg log -M -u "matvee" > > Votes are due by September 10, 2015. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [5]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#almatvee > > [2] > http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From kirill.kirichenko at oracle.com Fri Aug 28 07:48:18 2015 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Fri, 28 Aug 2015 10:48:18 +0300 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <55E01242.2050003@oracle.com> Vote: yes. On 28.08.2015 4:55, Kevin Rushforth wrote: > I hereby nominate Alexander Matveev [1] to OpenJFX Committer. > > Alexander was an initial member of JavaFX team at Oracle when the > OpenJFX project was created, and was on the initial list of approved > committers [2]. His status as OpenJFX committer was not recorded at that > time on the Census. This CVF is intended to correct this oversight. > > Alexander's changes prior to JavaFX becoming open-source were > significant (which is why he was on the initial list of committers). In > particular, Alexander, along with the rest of the media team, > contributed much of the code that went into the open-source changeset > that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: > > hg log -r aee256fde55 > > Counting his contribution to that changeset, Alexander now also has the > requisite number of changes in the open-source repo to become a committer. > > hg log -M -u "matvee" > > Votes are due by September 10, 2015. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#almatvee > > [2] > http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From kirill.kirichenko at oracle.com Fri Aug 28 07:52:18 2015 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Fri, 28 Aug 2015 10:52:18 +0300 Subject: Just pushed the updated GStreamer for JEP 257 In-Reply-To: <55DFB87C.7090400@oracle.com> References: <55DFB87C.7090400@oracle.com> Message-ID: <55E01332.80802@oracle.com> Congratulations Alexander, Kevin ant to all involved. This is a great milestone which opens opportunities to use newer gstreamer plugins in Media. On 28.08.2015 4:25, Kevin Rushforth wrote: > I just pushed the changeset for JEP 257 [1] [2] on behalf of Alexander > Matveev to the openjfx 9-dev repo. If you have any questions about the > new GStreamer, please let Alexander or Kirill know. This will be in next > week's early access build of JDK 9 (build 80). > > As previously announced [3] this means that JavaFX for JDK 9 will no > longer build or run on some older Linux distros. > > -- Kevin > > [1] http://openjdk.java.net/jeps/257 > [2] https://bugs.openjdk.java.net/browse/JDK-8043352 > [3] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-August/017722.html > From artem.ananiev at oracle.com Fri Aug 28 12:10:24 2015 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 28 Aug 2015 15:10:24 +0300 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <55E04FB0.6070209@oracle.com> Vote: yes Artem On 08/28/15 4:55 AM, Kevin Rushforth wrote: > I hereby nominate Alexander Matveev [1] to OpenJFX Committer. > > Alexander was an initial member of JavaFX team at Oracle when the > OpenJFX project was created, and was on the initial list of approved > committers [2]. His status as OpenJFX committer was not recorded at that > time on the Census. This CVF is intended to correct this oversight. > > Alexander's changes prior to JavaFX becoming open-source were > significant (which is why he was on the initial list of committers). In > particular, Alexander, along with the rest of the media team, > contributed much of the code that went into the open-source changeset > that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: > > hg log -r aee256fde55 > > Counting his contribution to that changeset, Alexander now also has the > requisite number of changes in the open-source repo to become a committer. > > hg log -M -u "matvee" > > Votes are due by September 10, 2015. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#almatvee > > [2] > http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From alexander.zvegintsev at oracle.com Fri Aug 28 12:21:26 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 28 Aug 2015 15:21:26 +0300 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <55E05246.6090101@oracle.com> Vote: yes Thanks, Alexander. On 08/28/2015 04:55 AM, Kevin Rushforth wrote: > I hereby nominate Alexander Matveev [1] to OpenJFX Committer. > > Alexander was an initial member of JavaFX team at Oracle when the > OpenJFX project was created, and was on the initial list of approved > committers [2]. His status as OpenJFX committer was not recorded at > that time on the Census. This CVF is intended to correct this oversight. > > Alexander's changes prior to JavaFX becoming open-source were > significant (which is why he was on the initial list of committers). > In particular, Alexander, along with the rest of the media team, > contributed much of the code that went into the open-source changeset > that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: > > hg log -r aee256fde55 > > Counting his contribution to that changeset, Alexander now also has > the requisite number of changes in the open-source repo to become a > committer. > > hg log -M -u "matvee" > > Votes are due by September 10, 2015. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [5]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#almatvee > > [2] > http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From David.Hill at Oracle.com Fri Aug 28 13:15:03 2015 From: David.Hill at Oracle.com (David Hill) Date: Fri, 28 Aug 2015 09:15:03 -0400 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <55E05ED7.2050106@Oracle.com> On 8/27/15, 9:55 PM, Kevin Rushforth wrote: > I hereby nominate Alexander Matveev [1] to OpenJFX Committer. VOTE: YES > > Alexander was an initial member of JavaFX team at Oracle when the OpenJFX project was created, and was on the initial list of approved committers [2]. His status as OpenJFX committer was not recorded at that time on the Census. This CVF is intended to correct this oversight. > > Alexander's changes prior to JavaFX becoming open-source were significant (which is why he was on the initial list of committers). In particular, Alexander, along with the rest of the media team, contributed much of the code that went into the open-source changeset that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: > > hg log -r aee256fde55 > > Counting his contribution to that changeset, Alexander now also has the requisite number of changes in the open-source repo to become a committer. > > hg log -M -u "matvee" > > Votes are due by September 10, 2015. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#almatvee > > [2] http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > -- 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 vadim.pakhnushev at oracle.com Fri Aug 28 19:27:26 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 28 Aug 2015 22:27:26 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <55E0B61E.7000505@oracle.com> 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 PDT until 1pm PDT. Happy testing! Thanks, Vadim From sven.reimers at gmail.com Fri Aug 28 20:42:18 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 28 Aug 2015 22:42:18 +0200 Subject: Failure building openjfx 9-dev against jdk9 build fails Message-ID: Hi, I get the following error trying to compile latest 9-dev from openjfx against latest jdk9: :swing:compileJava [ant:javac] /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: error: cannot find symbol [ant:javac] if (ctx != null) ctx.removeNotify(); [ant:javac] ^ [ant:javac] symbol: method removeNotify() [ant:javac] location: variable ctx of type DropTargetContext [ant:javac] /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: error: cannot find symbol [ant:javac] ctx.addNotify(FXDropTargetContextPeer.this); [ant:javac] ^ [ant:javac] symbol: method addNotify(FXDnD.FXDropTargetContextPeer) [ant:javac] location: variable ctx of type DropTargetContext [ant:javac] /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: error: cannot find symbol [ant:javac] if (ctx != null) ctx.removeNotify(); [ant:javac] ^ [ant:javac] symbol: method removeNotify() [ant:javac] location: variable ctx of type DropTargetContext [ant:javac] /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: error: cannot find symbol [ant:javac] if (ctx != null) ctx.removeNotify(); [ant:javac] ^ [ant:javac] symbol: method removeNotify() [ant:javac] location: variable ctx of type DropTargetContext [ant:javac] Note: Some input files use or override a deprecated API. [ant:javac] Note: Recompile with -Xlint:deprecation for details. [ant:javac] Note: /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java uses unchecked or unsafe operations. [ant:javac] Note: Recompile with -Xlint:unchecked for details. [ant:javac] 4 errors Reason seems to be the change http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e Could not find the issue in the JBS - maybe may jira fu was not good enough... So should we build 9-dev against jdk8u-60? Seems I must have missed something -Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From kevin.rushforth at oracle.com Fri Aug 28 20:55:51 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Aug 2015 13:55:51 -0700 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: References: Message-ID: <55E0CAD7.2010904@oracle.com> We still use JDK 8u40 as our boot JDK for building FX 9-dev, but it should work against JDK 9-dev as well. Did you remember to remove jfxrt.jar from your JDK 9? The build.gradle script doesn't know to look for it in $JDK_HOME/lib and warn you if you forget -- it only looks in $JDK_HOME/jre/lib/ext which is where it is in JDK 8. -- Kevin Sven Reimers wrote: > Hi, > > I get the following error trying to compile latest 9-dev from openjfx > against latest jdk9: > > :swing:compileJava > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: > error: cannot find symbol > [ant:javac] if (ctx != null) ctx.removeNotify(); > [ant:javac] ^ > [ant:javac] symbol: method removeNotify() > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: > error: cannot find symbol > [ant:javac] > ctx.addNotify(FXDropTargetContextPeer.this); > [ant:javac] ^ > [ant:javac] symbol: method addNotify(FXDnD.FXDropTargetContextPeer) > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: > error: cannot find symbol > [ant:javac] if (ctx != null) ctx.removeNotify(); > [ant:javac] ^ > [ant:javac] symbol: method removeNotify() > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: > error: cannot find symbol > [ant:javac] if (ctx != null) ctx.removeNotify(); > [ant:javac] ^ > [ant:javac] symbol: method removeNotify() > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] Note: Some input files use or override a deprecated API. > [ant:javac] Note: Recompile with -Xlint:deprecation for details. > [ant:javac] Note: > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java > uses unchecked or unsafe operations. > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > [ant:javac] 4 errors > > Reason seems to be the change > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e > > Could not find the issue in the JBS - maybe may jira fu was not good > enough... > > So should we build 9-dev against jdk8u-60? > > Seems I must have missed something > > -Sven > > From kevin.rushforth at oracle.com Fri Aug 28 21:00:34 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Aug 2015 14:00:34 -0700 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: <55E0CAD7.2010904@oracle.com> References: <55E0CAD7.2010904@oracle.com> Message-ID: <55E0CBF2.1060504@oracle.com> I just tried it -- it's a real failure, which is odd since I thought I had built with JDK 9 more recently than that. I will file a bug. -- Kevin Kevin Rushforth wrote: > We still use JDK 8u40 as our boot JDK for building FX 9-dev, but it > should work against JDK 9-dev as well. > > Did you remember to remove jfxrt.jar from your JDK 9? The build.gradle > script doesn't know to look for it in $JDK_HOME/lib and warn you if > you forget -- it only looks in $JDK_HOME/jre/lib/ext which is where it > is in JDK 8. > > -- Kevin > > > Sven Reimers wrote: >> Hi, >> >> I get the following error trying to compile latest 9-dev from openjfx >> against latest jdk9: >> >> :swing:compileJava >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: >> >> error: cannot find symbol >> [ant:javac] if (ctx != null) ctx.removeNotify(); >> [ant:javac] ^ >> [ant:javac] symbol: method removeNotify() >> [ant:javac] location: variable ctx of type DropTargetContext >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: >> >> error: cannot find symbol >> [ant:javac] >> ctx.addNotify(FXDropTargetContextPeer.this); >> [ant:javac] ^ >> [ant:javac] symbol: method addNotify(FXDnD.FXDropTargetContextPeer) >> [ant:javac] location: variable ctx of type DropTargetContext >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: >> >> error: cannot find symbol >> [ant:javac] if (ctx != null) ctx.removeNotify(); >> [ant:javac] ^ >> [ant:javac] symbol: method removeNotify() >> [ant:javac] location: variable ctx of type DropTargetContext >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: >> >> error: cannot find symbol >> [ant:javac] if (ctx != null) ctx.removeNotify(); >> [ant:javac] ^ >> [ant:javac] symbol: method removeNotify() >> [ant:javac] location: variable ctx of type DropTargetContext >> [ant:javac] Note: Some input files use or override a deprecated API. >> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >> [ant:javac] Note: >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java >> >> uses unchecked or unsafe operations. >> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >> [ant:javac] 4 errors >> >> Reason seems to be the change >> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e >> >> Could not find the issue in the JBS - maybe may jira fu was not good >> enough... >> >> So should we build 9-dev against jdk8u-60? >> >> Seems I must have missed something >> >> -Sven >> >> From sven.reimers at gmail.com Fri Aug 28 21:12:48 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 28 Aug 2015 23:12:48 +0200 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: <55E0CBF2.1060504@oracle.com> References: <55E0CAD7.2010904@oracle.com> <55E0CBF2.1060504@oracle.com> Message-ID: Thanks... seems it is broken for some time already, if I got the correct commit... It was my own local jdk build - I wanted to build openjdk from source and then openjfx on top of that to work around this issue.. Falling back to use a stripped down jdk8 now.. (building JDK 8 on a Mac with a newer XCode gets messy, so I thought I gor for 9) -Sven On Fri, Aug 28, 2015 at 11:00 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I just tried it -- it's a real failure, which is odd since I thought I had > built with JDK 9 more recently than that. I will file a bug. > > -- Kevin > > > > Kevin Rushforth wrote: > >> We still use JDK 8u40 as our boot JDK for building FX 9-dev, but it >> should work against JDK 9-dev as well. >> >> Did you remember to remove jfxrt.jar from your JDK 9? The build.gradle >> script doesn't know to look for it in $JDK_HOME/lib and warn you if you >> forget -- it only looks in $JDK_HOME/jre/lib/ext which is where it is in >> JDK 8. >> >> -- Kevin >> >> >> Sven Reimers wrote: >> >>> Hi, >>> >>> I get the following error trying to compile latest 9-dev from openjfx >>> against latest jdk9: >>> >>> :swing:compileJava >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: >>> >>> error: cannot find symbol >>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>> [ant:javac] ^ >>> [ant:javac] symbol: method removeNotify() >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: >>> >>> error: cannot find symbol >>> [ant:javac] >>> ctx.addNotify(FXDropTargetContextPeer.this); >>> [ant:javac] ^ >>> [ant:javac] symbol: method addNotify(FXDnD.FXDropTargetContextPeer) >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: >>> >>> error: cannot find symbol >>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>> [ant:javac] ^ >>> [ant:javac] symbol: method removeNotify() >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: >>> >>> error: cannot find symbol >>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>> [ant:javac] ^ >>> [ant:javac] symbol: method removeNotify() >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] Note: Some input files use or override a deprecated API. >>> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >>> [ant:javac] Note: >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java >>> >>> uses unchecked or unsafe operations. >>> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >>> [ant:javac] 4 errors >>> >>> Reason seems to be the change >>> >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e >>> >>> Could not find the issue in the JBS - maybe may jira fu was not good >>> enough... >>> >>> So should we build 9-dev against jdk8u-60? >>> >>> Seems I must have missed something >>> >>> -Sven >>> >>> >>> >> -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From kevin.rushforth at oracle.com Fri Aug 28 21:28:49 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Aug 2015 14:28:49 -0700 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: <55E0CBF2.1060504@oracle.com> References: <55E0CAD7.2010904@oracle.com> <55E0CBF2.1060504@oracle.com> Message-ID: <55E0D291.3030409@oracle.com> I just looked, and saw that this was discussed on the awt-dev mailing list about 4 or 5 months ago when JDK-8074763 was reviewed. I even raised this as a concern, but then promptly forgot about it. I just filed https://bugs.openjdk.java.net/browse/JDK-8134709 to track this. Thank you for reporting it. -- Kevin Kevin Rushforth wrote: > I just tried it -- it's a real failure, which is odd since I thought I > had built with JDK 9 more recently than that. I will file a bug. > > -- Kevin > > > Kevin Rushforth wrote: >> We still use JDK 8u40 as our boot JDK for building FX 9-dev, but it >> should work against JDK 9-dev as well. >> >> Did you remember to remove jfxrt.jar from your JDK 9? The >> build.gradle script doesn't know to look for it in $JDK_HOME/lib and >> warn you if you forget -- it only looks in $JDK_HOME/jre/lib/ext >> which is where it is in JDK 8. >> >> -- Kevin >> >> >> Sven Reimers wrote: >>> Hi, >>> >>> I get the following error trying to compile latest 9-dev from openjfx >>> against latest jdk9: >>> >>> :swing:compileJava >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: >>> >>> error: cannot find symbol >>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>> [ant:javac] ^ >>> [ant:javac] symbol: method removeNotify() >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: >>> >>> error: cannot find symbol >>> [ant:javac] >>> ctx.addNotify(FXDropTargetContextPeer.this); >>> [ant:javac] ^ >>> [ant:javac] symbol: method addNotify(FXDnD.FXDropTargetContextPeer) >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: >>> >>> error: cannot find symbol >>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>> [ant:javac] ^ >>> [ant:javac] symbol: method removeNotify() >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: >>> >>> error: cannot find symbol >>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>> [ant:javac] ^ >>> [ant:javac] symbol: method removeNotify() >>> [ant:javac] location: variable ctx of type DropTargetContext >>> [ant:javac] Note: Some input files use or override a deprecated API. >>> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >>> [ant:javac] Note: >>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java >>> >>> uses unchecked or unsafe operations. >>> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >>> [ant:javac] 4 errors >>> >>> Reason seems to be the change >>> >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e >>> >>> Could not find the issue in the JBS - maybe may jira fu was not good >>> enough... >>> >>> So should we build 9-dev against jdk8u-60? >>> >>> Seems I must have missed something >>> >>> -Sven >>> >>> From kevin.rushforth at oracle.com Fri Aug 28 21:30:56 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Aug 2015 14:30:56 -0700 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: References: <55E0CAD7.2010904@oracle.com> <55E0CBF2.1060504@oracle.com> Message-ID: <55E0D310.3070401@oracle.com> You got the correct commit. I even dug up the e-mail thread where I raised this as a concern. -- Kevin, feeling rather embarrassed to have completely let this one slip... Sven Reimers wrote: > Thanks... seems it is broken for some time already, if I got the > correct commit... > > It was my own local jdk build - I wanted to build openjdk from source > and then openjfx on top of that to work around this issue.. > > Falling back to use a stripped down jdk8 now.. (building JDK 8 on a > Mac with a newer XCode gets messy, so I thought I gor for 9) > > -Sven > > On Fri, Aug 28, 2015 at 11:00 PM, Kevin Rushforth > > wrote: > > I just tried it -- it's a real failure, which is odd since I > thought I had built with JDK 9 more recently than that. I will > file a bug. > > -- Kevin > > > > Kevin Rushforth wrote: > > We still use JDK 8u40 as our boot JDK for building FX 9-dev, > but it should work against JDK 9-dev as well. > > Did you remember to remove jfxrt.jar from your JDK 9? The > build.gradle script doesn't know to look for it in > $JDK_HOME/lib and warn you if you forget -- it only looks in > $JDK_HOME/jre/lib/ext which is where it is in JDK 8. > > -- Kevin > > > Sven Reimers wrote: > > Hi, > > I get the following error trying to compile latest 9-dev > from openjfx > against latest jdk9: > > :swing:compileJava > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: > > error: cannot find symbol > [ant:javac] if (ctx != null) > ctx.removeNotify(); > [ant:javac] ^ > [ant:javac] symbol: method removeNotify() > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: > > error: cannot find symbol > [ant:javac] > ctx.addNotify(FXDropTargetContextPeer.this); > [ant:javac] ^ > [ant:javac] symbol: method > addNotify(FXDnD.FXDropTargetContextPeer) > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: > > error: cannot find symbol > [ant:javac] if (ctx != null) > ctx.removeNotify(); > [ant:javac] ^ > [ant:javac] symbol: method removeNotify() > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: > > error: cannot find symbol > [ant:javac] if (ctx != null) > ctx.removeNotify(); > [ant:javac] ^ > [ant:javac] symbol: method removeNotify() > [ant:javac] location: variable ctx of type DropTargetContext > [ant:javac] Note: Some input files use or override a > deprecated API. > [ant:javac] Note: Recompile with -Xlint:deprecation for > details. > [ant:javac] Note: > /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java > > uses unchecked or unsafe operations. > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > [ant:javac] 4 errors > > Reason seems to be the change > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e > > Could not find the issue in the JBS - maybe may jira fu > was not good > enough... > > So should we build 9-dev against jdk8u-60? > > Seems I must have missed something > > -Sven > > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > * Blog: https://www.java.net//blog/sven > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From david.dehaven at oracle.com Fri Aug 28 21:32:26 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 28 Aug 2015 14:32:26 -0700 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <6C1998AF-1EA9-4F58-8382-2DFDEAFE95D9@oracle.com> Vote: YES -DrD- > On Aug 27, 2015, at 6:55 PM, Kevin Rushforth wrote: > > I hereby nominate Alexander Matveev [1] to OpenJFX Committer. > > Alexander was an initial member of JavaFX team at Oracle when the OpenJFX project was created, and was on the initial list of approved committers [2]. His status as OpenJFX committer was not recorded at that time on the Census. This CVF is intended to correct this oversight. > > Alexander's changes prior to JavaFX becoming open-source were significant (which is why he was on the initial list of committers). In particular, Alexander, along with the rest of the media team, contributed much of the code that went into the open-source changeset that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: > > hg log -r aee256fde55 > > Counting his contribution to that changeset, Alexander now also has the requisite number of changes in the open-source repo to become a committer. > > hg log -M -u "matvee" > > Votes are due by September 10, 2015. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#almatvee > > [2] http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From sven.reimers at gmail.com Fri Aug 28 21:39:21 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 28 Aug 2015 23:39:21 +0200 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: <55E0D310.3070401@oracle.com> References: <55E0CAD7.2010904@oracle.com> <55E0CBF2.1060504@oracle.com> <55E0D310.3070401@oracle.com> Message-ID: Seems fixing it in openjfx/9-dev (switch to reset() method from remove..) will enforce usage of JDK9 ... Thanks -Sven On Fri, Aug 28, 2015 at 11:30 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > You got the correct commit. I even dug up the e-mail thread where I raised > this as a concern. > > -- Kevin, feeling rather embarrassed to have completely let this one > slip... > > > > Sven Reimers wrote: > > Thanks... seems it is broken for some time already, if I got the correct > commit... > > It was my own local jdk build - I wanted to build openjdk from source and > then openjfx on top of that to work around this issue.. > > Falling back to use a stripped down jdk8 now.. (building JDK 8 on a Mac > with a newer XCode gets messy, so I thought I gor for 9) > > -Sven > > On Fri, Aug 28, 2015 at 11:00 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I just tried it -- it's a real failure, which is odd since I thought I >> had built with JDK 9 more recently than that. I will file a bug. >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >>> We still use JDK 8u40 as our boot JDK for building FX 9-dev, but it >>> should work against JDK 9-dev as well. >>> >>> Did you remember to remove jfxrt.jar from your JDK 9? The build.gradle >>> script doesn't know to look for it in $JDK_HOME/lib and warn you if you >>> forget -- it only looks in $JDK_HOME/jre/lib/ext which is where it is in >>> JDK 8. >>> >>> -- Kevin >>> >>> >>> Sven Reimers wrote: >>> >>>> Hi, >>>> >>>> I get the following error trying to compile latest 9-dev from openjfx >>>> against latest jdk9: >>>> >>>> :swing:compileJava >>>> [ant:javac] >>>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: >>>> >>>> error: cannot find symbol >>>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>>> [ant:javac] ^ >>>> [ant:javac] symbol: method removeNotify() >>>> [ant:javac] location: variable ctx of type DropTargetContext >>>> [ant:javac] >>>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: >>>> >>>> error: cannot find symbol >>>> [ant:javac] >>>> ctx.addNotify(FXDropTargetContextPeer.this); >>>> [ant:javac] ^ >>>> [ant:javac] symbol: method addNotify(FXDnD.FXDropTargetContextPeer) >>>> [ant:javac] location: variable ctx of type DropTargetContext >>>> [ant:javac] >>>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: >>>> >>>> error: cannot find symbol >>>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>>> [ant:javac] ^ >>>> [ant:javac] symbol: method removeNotify() >>>> [ant:javac] location: variable ctx of type DropTargetContext >>>> [ant:javac] >>>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: >>>> >>>> error: cannot find symbol >>>> [ant:javac] if (ctx != null) ctx.removeNotify(); >>>> [ant:javac] ^ >>>> [ant:javac] symbol: method removeNotify() >>>> [ant:javac] location: variable ctx of type DropTargetContext >>>> [ant:javac] Note: Some input files use or override a deprecated API. >>>> [ant:javac] Note: Recompile with -Xlint:deprecation for details. >>>> [ant:javac] Note: >>>> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java >>>> >>>> uses unchecked or unsafe operations. >>>> [ant:javac] Note: Recompile with -Xlint:unchecked for details. >>>> [ant:javac] 4 errors >>>> >>>> Reason seems to be the change >>>> >>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e >>>> >>>> Could not find the issue in the JBS - maybe may jira fu was not good >>>> enough... >>>> >>>> So should we build 9-dev against jdk8u-60? >>>> >>>> Seems I must have missed something >>>> >>>> -Sven >>>> >>>> >>>> >>> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > * Blog: https://www.java.net//blog/sven > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From kevin.rushforth at oracle.com Fri Aug 28 21:51:20 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Aug 2015 14:51:20 -0700 Subject: Failure building openjfx 9-dev against jdk9 build fails In-Reply-To: References: <55E0CAD7.2010904@oracle.com> <55E0CBF2.1060504@oracle.com> <55E0D310.3070401@oracle.com> Message-ID: <55E0D7D8.8030709@oracle.com> Yes, unless we do it via reflection, which we have done in similar situations. If it's only the one method call then we might do that, and file a bug to remove the reflection later. Otherwise we will just wait until we switch to using JDK 9 as the boot JDK (and this could accelerate that). -- Kevin Sven Reimers wrote: > Seems fixing it in openjfx/9-dev (switch to reset() method from > remove..) will enforce usage of JDK9 ... > > Thanks > > -Sven > > On Fri, Aug 28, 2015 at 11:30 PM, Kevin Rushforth > > wrote: > > You got the correct commit. I even dug up the e-mail thread where > I raised this as a concern. > > -- Kevin, feeling rather embarrassed to have completely let this > one slip... > > > > Sven Reimers wrote: >> Thanks... seems it is broken for some time already, if I got the >> correct commit... >> >> It was my own local jdk build - I wanted to build openjdk from >> source and then openjfx on top of that to work around this issue.. >> >> Falling back to use a stripped down jdk8 now.. (building JDK 8 on >> a Mac with a newer XCode gets messy, so I thought I gor for 9) >> >> -Sven >> >> On Fri, Aug 28, 2015 at 11:00 PM, Kevin Rushforth >> > >> wrote: >> >> I just tried it -- it's a real failure, which is odd since I >> thought I had built with JDK 9 more recently than that. I >> will file a bug. >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >> We still use JDK 8u40 as our boot JDK for building FX >> 9-dev, but it should work against JDK 9-dev as well. >> >> Did you remember to remove jfxrt.jar from your JDK 9? The >> build.gradle script doesn't know to look for it in >> $JDK_HOME/lib and warn you if you forget -- it only looks >> in $JDK_HOME/jre/lib/ext which is where it is in JDK 8. >> >> -- Kevin >> >> >> Sven Reimers wrote: >> >> Hi, >> >> I get the following error trying to compile latest >> 9-dev from openjfx >> against latest jdk9: >> >> :swing:compileJava >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:480: >> >> error: cannot find symbol >> [ant:javac] if (ctx != null) >> ctx.removeNotify(); >> [ant:javac] ^ >> [ant:javac] symbol: method removeNotify() >> [ant:javac] location: variable ctx of type >> DropTargetContext >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:489: >> >> error: cannot find symbol >> [ant:javac] >> ctx.addNotify(FXDropTargetContextPeer.this); >> [ant:javac] ^ >> [ant:javac] symbol: method >> addNotify(FXDnD.FXDropTargetContextPeer) >> [ant:javac] location: variable ctx of type >> DropTargetContext >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:511: >> >> error: cannot find symbol >> [ant:javac] if (ctx != null) >> ctx.removeNotify(); >> [ant:javac] ^ >> [ant:javac] symbol: method removeNotify() >> [ant:javac] location: variable ctx of type >> DropTargetContext >> [ant:javac] >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java:520: >> >> error: cannot find symbol >> [ant:javac] if (ctx != null) >> ctx.removeNotify(); >> [ant:javac] ^ >> [ant:javac] symbol: method removeNotify() >> [ant:javac] location: variable ctx of type >> DropTargetContext >> [ant:javac] Note: Some input files use or override a >> deprecated API. >> [ant:javac] Note: Recompile with -Xlint:deprecation >> for details. >> [ant:javac] Note: >> /Users/sven/oss/openjfx/9-dev/modules/swing/src/main/java/javafx/embed/swing/FXDnD.java >> >> uses unchecked or unsafe operations. >> [ant:javac] Note: Recompile with -Xlint:unchecked for >> details. >> [ant:javac] 4 errors >> >> Reason seems to be the change >> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e1888730a57e >> >> Could not find the issue in the JBS - maybe may jira >> fu was not good >> enough... >> >> So should we build 9-dev against jdk8u-60? >> >> Seems I must have missed something >> >> -Sven >> >> >> >> >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * Java Champion >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> * Duke's Choice Award Winner 2009 >> * Blog: https://www.java.net//blog/sven >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > * Blog: https://www.java.net//blog/sven > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From tobi at ultramixer.com Fri Aug 28 22:04:19 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Sat, 29 Aug 2015 00:04:19 +0200 Subject: Prism: implementation of node scale? Message-ID: Hi, does anybody know where the node scaling is implemented in prism es2 pipeline? I would like to fix the ?scale bug on iOS? (scaling of nodes not possible on iOS). Best regards, Tobi From philip.race at oracle.com Fri Aug 28 22:04:21 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 28 Aug 2015 15:04:21 -0700 Subject: CFV: New OpenJFX Committer: Alexander Matveev In-Reply-To: <55DFBF7B.2040408@oracle.com> References: <55DFBF7B.2040408@oracle.com> Message-ID: <55E0DAE5.8080702@oracle.com> Vote: yes From alexander.matveev at oracle.com Sat Aug 29 01:05:45 2015 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 28 Aug 2015 18:05:45 -0700 Subject: [9] Review request for 8131066: JavaFX MediaPlayer crashes on dispose with certain MP4s Message-ID: <55E10569.20702@oracle.com> Hi David, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8131066 http://cr.openjdk.java.net/~almatvee/8131066/webrev.00/ Crash happens, because AVPlayer was trying to notify AVFMediaPlayer about frame change after AVFMediaPlayer was released. Fixed by unregistering notification callback before AVFMediaPlayer is released. Thanks, Alexander From info at cuhka.com Sat Aug 29 09:34:29 2015 From: info at cuhka.com (Maurice le Rutte) Date: Sat, 29 Aug 2015 11:34:29 +0200 Subject: [PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: <20150827135646.Horde.fBVbpKpoc6DZPvB-pRcb6Q4@dime187.dizinc.com> Message-ID: <7d4726a6-a4e7-4cc1-a228-e765a1a762c9@email.android.com> Since I haven't received any additional feedback, should I push this patch? Op 27 aug. 2015 15:56 schreef info at cuhka.com: > > I've adapted the build.gradle to use java -fullversion instead of java? > -version, parsing the result with a regexp. > > diff -r 9b5fc7c1e5e6 build.gradle > --- a/build.gradle Fri Aug 07 18:35:42 2015 -0700 > +++ b/build.gradle Thu Aug 27 15:52:11 2015 +0200 > @@ -719,29 +719,27 @@ > ? if (!file(JAVAH).exists()) throw new Exception("Missing or incorrect? > path to 'javah': '$JAVAH'. Perhaps bad JDK_HOME? $JDK_HOME") > ? if (!file(JAVADOC).exists()) throw new Exception("Missing or? > incorrect path to 'javadoc': '$JAVADOC'. Perhaps bad JDK_HOME?? > $JDK_HOME") > > - > + > ? // Determine the verion of Java in JDK_HOME. It looks like this: > ? // > -// $ java -version > -// java version "1.7.0_45" > -// Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > -// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > -// > -// We need to parse the second line > -def inStream = new java.io.BufferedReader(new? > java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,? > "-version").start().getErrorStream())); > +// $ java -fullversion > +// for OpenJDK: openjdk full version "1.8.0_45-internal-b14" > +// for Oracle JDK: java full version "1.8.0_45-b14" > + > +def inStream = new java.io.BufferedReader(new? > java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,? > "-fullversion").start().getErrorStream())); > ? try { > -??? if (inStream.readLine() != null) { > -??????? String v = inStream.readLine(); > -??????? if (v != null) { > -??????????? int ib = v.indexOf(" (build "); > -??????????? if (ib != -1) { > -??????????????? String ver = v.substring(ib + 8, v.size() - 1); > - > -??????????????? defineProperty("jdkRuntimeVersion", ver) > -??????????????? defineProperty("jdkVersion", jdkRuntimeVersion.split("-")[0]) > -??????????????? defineProperty("jdkBuildNumber",? > jdkRuntimeVersion.substring(jdkRuntimeVersion.lastIndexOf("-b") + 2)) > -??????????? } > -??????? } > +??? def v = inStream.readLine(); > + > +??? if (v != null) { > + def pattern =? > java.util.regex.Pattern.compile("^[^\"]*\"((\\d+(?:\\.\\d+)*)_(\\d+))(?:-\\w+)?(?:-b(\\d+))\"\$") > + def matcher = pattern.matcher(v) > + > + if (matcher.matches()) { > +??????????? defineProperty("jdkVersion", matcher.group(1)) > +??????????? defineProperty("jdkRuntimeVersion", matcher.group(2)) > +??????????? defineProperty("jdkUpdate", matcher.group(3)) > +??????????? defineProperty("jdkBuildNumber", matcher.group(4)) > + } > ????? } > ? } finally { > ????? inStream.close(); > From kevin.rushforth at oracle.com Sat Aug 29 16:04:51 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 29 Aug 2015 09:04:51 -0700 Subject: [PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: <7d4726a6-a4e7-4cc1-a228-e765a1a762c9@email.android.com> References: <7d4726a6-a4e7-4cc1-a228-e765a1a762c9@email.android.com> Message-ID: <55E1D823.1070300@oracle.com> Hi Maurice, No, you cannot simply push this patch. Please refer to the OpenJDK Wiki [1] for information on contributing patches to OpenJFX. Additional information on Submitting OpenJFX bugs [2] and Code Review policies [3] are also on the Wiki. I note that simple patches such as this can be accepted without an OCA being signed (although if you want to contribute a non-trivial patch you will need to sign the OCA). Everything starts out with a bug report, which you can submit if you like. However, in this case, I am likely to just fix this as part of fixing JDK-8133750 [4] since the version detection logic also needs to be modified for the new Java version string JEP as described in that bug report. So: Either I can add your information to JDK-8133750 or you can file a new bug and I will link them together and fix them at the same time. -- Kevin [1] http://openjdk.java.net/contribute/ [2] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report [3] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews [4] https://bugs.openjdk.java.net/browse/JDK-8133750 Maurice le Rutte wrote: > Since I haven't received any additional feedback, should I push this patch? > > Op 27 aug. 2015 15:56 schreef info at cuhka.com: > >> I've adapted the build.gradle to use java -fullversion instead of java >> -version, parsing the result with a regexp. >> >> diff -r 9b5fc7c1e5e6 build.gradle >> --- a/build.gradle Fri Aug 07 18:35:42 2015 -0700 >> +++ b/build.gradle Thu Aug 27 15:52:11 2015 +0200 >> @@ -719,29 +719,27 @@ >> if (!file(JAVAH).exists()) throw new Exception("Missing or incorrect >> path to 'javah': '$JAVAH'. Perhaps bad JDK_HOME? $JDK_HOME") >> if (!file(JAVADOC).exists()) throw new Exception("Missing or >> incorrect path to 'javadoc': '$JAVADOC'. Perhaps bad JDK_HOME? >> $JDK_HOME") >> >> - >> + >> // Determine the verion of Java in JDK_HOME. It looks like this: >> // >> -// $ java -version >> -// java version "1.7.0_45" >> -// Java(TM) SE Runtime Environment (build 1.7.0_45-b18) >> -// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) >> -// >> -// We need to parse the second line >> -def inStream = new java.io.BufferedReader(new >> java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, >> "-version").start().getErrorStream())); >> +// $ java -fullversion >> +// for OpenJDK: openjdk full version "1.8.0_45-internal-b14" >> +// for Oracle JDK: java full version "1.8.0_45-b14" >> + >> +def inStream = new java.io.BufferedReader(new >> java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA, >> "-fullversion").start().getErrorStream())); >> try { >> - if (inStream.readLine() != null) { >> - String v = inStream.readLine(); >> - if (v != null) { >> - int ib = v.indexOf(" (build "); >> - if (ib != -1) { >> - String ver = v.substring(ib + 8, v.size() - 1); >> - >> - defineProperty("jdkRuntimeVersion", ver) >> - defineProperty("jdkVersion", jdkRuntimeVersion.split("-")[0]) >> - defineProperty("jdkBuildNumber", >> jdkRuntimeVersion.substring(jdkRuntimeVersion.lastIndexOf("-b") + 2)) >> - } >> - } >> + def v = inStream.readLine(); >> + >> + if (v != null) { >> + def pattern = >> java.util.regex.Pattern.compile("^[^\"]*\"((\\d+(?:\\.\\d+)*)_(\\d+))(?:-\\w+)?(?:-b(\\d+))\"\$") >> + def matcher = pattern.matcher(v) >> + >> + if (matcher.matches()) { >> + defineProperty("jdkVersion", matcher.group(1)) >> + defineProperty("jdkRuntimeVersion", matcher.group(2)) >> + defineProperty("jdkUpdate", matcher.group(3)) >> + defineProperty("jdkBuildNumber", matcher.group(4)) >> + } >> } >> } finally { >> inStream.close(); >> >> From info at cuhka.com Sat Aug 29 19:47:32 2015 From: info at cuhka.com (info at cuhka.com) Date: Sat, 29 Aug 2015 19:47:32 +0000 Subject: [PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS In-Reply-To: <55E1D823.1070300@oracle.com> References: <7d4726a6-a4e7-4cc1-a228-e765a1a762c9@email.android.com> <55E1D823.1070300@oracle.com> Message-ID: <20150829194732.Horde.NlLlsxfqEUTvuV2I0t7CMQ1@dime187.dizinc.com> Citeren Kevin Rushforth : > Either I can add your information to JDK-8133750 or you can file a > new bug and I will link them together and fix them at the same time. I'd prefer the former over the latter. Maurice. From robert.zenz at sibvisions.com Mon Aug 31 08:00:28 2015 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Mon, 31 Aug 2015 08:00:28 +0000 Subject: JEP 253 Update: new JavaDoc ready for review In-Reply-To: <55DF9229.2000104@oracle.com> References: <55DF9229.2000104@oracle.com> Message-ID: <55E40993.5070702@sibvisions.com> On 28.08.2015 00:41, Jonathan Giles wrote: > ...but for two it doesn't feel right to release it without the behaviors > themselves becoming public. I worried that without the behaviors being > public that the InputMap was a bit of a 'map to nowhere'. My hope is > that we can resolve this in an update release of JDK 9. The plan now is > to remove the second subproject from JEP 253 to have it correctly > tracking our intentions, so I will be doing that in the coming week. Sorry if that was already discussed/mentioned, I only skim the list from time to time. Does that mean that behaviors will not be public in JDK 9 (therefor inaccessible because of Jigsaw), but it might make it into an update for JDK 9? From jonathan.giles at oracle.com Mon Aug 31 08:06:38 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 31 Aug 2015 20:06:38 +1200 Subject: JEP 253 Update: new JavaDoc ready for review In-Reply-To: <55E40993.5070702@sibvisions.com> References: <55DF9229.2000104@oracle.com> <55E40993.5070702@sibvisions.com> Message-ID: <4DA49834-9F32-414C-8F80-D7AB3BB3C200@oracle.com> That is correct. The feasibility of doing this in a JDK 9 update release is another issue entirely, so the main point is that it will be at some point after the first JDK 9 release, but no guarantees when. -- Jonathan Sent from a touch device. Please excuse my brevity. On 31 August 2015 20:00:28 GMT+12:00, Robert Zenz wrote: >On 28.08.2015 00:41, Jonathan Giles wrote: >> ...but for two it doesn't feel right to release it without the >behaviors >> themselves becoming public. I worried that without the behaviors >being >> public that the InputMap was a bit of a 'map to nowhere'. My hope is >> that we can resolve this in an update release of JDK 9. The plan now >is >> to remove the second subproject from JEP 253 to have it correctly >> tracking our intentions, so I will be doing that in the coming week. > >Sorry if that was already discussed/mentioned, I only skim the list >from >time to time. Does that mean that behaviors will not be public in JDK 9 >(therefor inaccessible because of Jigsaw), but it might make it into an >update for JDK 9? From vadim.pakhnushev at oracle.com Mon Aug 31 12:37:47 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 31 Aug 2015 15:37:47 +0300 Subject: WebKit on Mac build problem Message-ID: <55E44A9B.4080808@oracle.com> Hi, I'm getting consistent build error while linking WebKit on Mac using latest XCode 6.4. Undefined symbols for architecture x86_64: "JSC::Structure::putWillGrowOutOfLineStorage()", referenced from: JSC::JSObject::putDirectWithoutTransition(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int) in libJavaScriptCoreJava.a(MapConstructor.o) JSC::JSObject::putDirectWithoutTransition(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int) in libJavaScriptCoreJava.a(SetConstructor.o) JSC::JSObject::putDirectWithoutTransition(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int) in libJavaScriptCoreJava.a(WeakMapConstructor.o) JSC::JSObject::putDirectWithoutTransition(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int) in libJavaScriptCoreJava.a(MapIteratorConstructor.o) JSC::JSObject::putDirectWithoutTransition(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int) in libJavaScriptCoreJava.a(SetIteratorConstructor.o) JSC::JSObject::putDirectWithoutTransition(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int) in libJavaScriptCoreJava.a(ArgumentsIteratorConstructor.o) bool JSC::JSObject::putDirectInternal<(JSC::JSObject::PutMode)1>(JSC::VM&, JSC::PropertyName, JSC::JSValue, unsigned int, JSC::PutPropertySlot&, JSC::JSCell*) in libJavaScriptCoreJava.a(JSPromiseFunctions.o) ... ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [../lib/libjfxwebkit.dylib] Error 1 If I build with -PCONF=DebugNative, the build completes. This happens on 8u-dev. Could this be a compiler problem? The method is declared in Structure.h: bool putWillGrowOutOfLineStorage(); And it's defined in StructureInlines.h: inline bool Structure::putWillGrowOutOfLineStorage() Does anybody has any advice? Thanks, Vadim From kevin.rushforth at oracle.com Mon Aug 31 12:46:05 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 31 Aug 2015 05:46:05 -0700 Subject: WebKit on Mac build problem In-Reply-To: <55E44A9B.4080808@oracle.com> References: <55E44A9B.4080808@oracle.com> Message-ID: <55E44C8D.90504@oracle.com> I haven't tried on XCode 6 myself, only XCode 5.5. -- Kevin Vadim Pakhnushev wrote: > Hi, > I'm getting consistent build error while linking WebKit on Mac using > latest XCode 6.4. > > Undefined symbols for architecture x86_64: > "JSC::Structure::putWillGrowOutOfLineStorage()", referenced from: > JSC::JSObject::putDirectWithoutTransition(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int) in > libJavaScriptCoreJava.a(MapConstructor.o) > JSC::JSObject::putDirectWithoutTransition(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int) in > libJavaScriptCoreJava.a(SetConstructor.o) > JSC::JSObject::putDirectWithoutTransition(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int) in > libJavaScriptCoreJava.a(WeakMapConstructor.o) > JSC::JSObject::putDirectWithoutTransition(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int) in > libJavaScriptCoreJava.a(MapIteratorConstructor.o) > JSC::JSObject::putDirectWithoutTransition(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int) in > libJavaScriptCoreJava.a(SetIteratorConstructor.o) > JSC::JSObject::putDirectWithoutTransition(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int) in > libJavaScriptCoreJava.a(ArgumentsIteratorConstructor.o) > bool > JSC::JSObject::putDirectInternal<(JSC::JSObject::PutMode)1>(JSC::VM&, > JSC::PropertyName, JSC::JSValue, unsigned int, JSC::PutPropertySlot&, > JSC::JSCell*) in libJavaScriptCoreJava.a(JSPromiseFunctions.o) > ... > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [../lib/libjfxwebkit.dylib] Error 1 > > If I build with -PCONF=DebugNative, the build completes. > This happens on 8u-dev. > > Could this be a compiler problem? > The method is declared in Structure.h: bool > putWillGrowOutOfLineStorage(); > And it's defined in StructureInlines.h: inline bool > Structure::putWillGrowOutOfLineStorage() > > Does anybody has any advice? > > Thanks, > Vadim From David.Hill at Oracle.com Mon Aug 31 14:47:53 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 31 Aug 2015 10:47:53 -0400 Subject: review for http://cr.openjdk.java.net/~ddhill/8134760/ Message-ID: <55E46919.2050502@Oracle.com> Kevin, Here is the first of a chain of refactors for JavaFX unit tests. The webrev is pretty useless as it shows all moves as a add/remove and is huge. In short, I added a bunch of "shims" allowing all of the junit tests to be moved to a new package tree "test.*" Tested on Mac and Linux so far. Bug: Refactor Javafx base module tests for clear separation of tests webrev: http://cr.openjdk.java.net/~ddhill/8134760/ -- 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 vgrazi at gmail.com Mon Aug 31 14:51:19 2015 From: vgrazi at gmail.com (Victor Grazi) Date: Mon, 31 Aug 2015 10:51:19 -0400 Subject: Change to digest emails Message-ID: Is there any way to modify my email subscription to send me digest emails just once per day? Thanks Victor From james.graham at oracle.com Mon Aug 31 19:13:54 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 31 Aug 2015 12:13:54 -0700 Subject: Prism: implementation of node scale? In-Reply-To: References: Message-ID: <55E4A772.6000807@oracle.com> Hi Tobias, I'm not sure what problem you are fixing here, but "node scaling" is not something the pipelines implement. They support a transform in the Graphics object and the NGNode code is responsible for setting up that transform in its render methods. What aspect of scaling is not working on iOS? ...jim On 8/28/2015 3:04 PM, Tobias Bley wrote: > Hi, > > does anybody know where the node scaling is implemented in prism es2 pipeline? I would like to fix the ?scale bug on iOS? (scaling of nodes not possible on iOS). > > Best regards, > Tobi > From kevin.rushforth at oracle.com Mon Aug 31 19:37:50 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 31 Aug 2015 12:37:50 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <55E4AD0E.4090704@oracle.com>