From james.graham at oracle.com Tue Aug 1 00:09:23 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 31 Jul 2017 17:09:23 -0700 Subject: [10] Review request for 8183530: JavaFX charts peg rendering thread as more data is added Message-ID: <995afe43-6b8b-71ce-bcc2-ab16ec9ff321@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8183530 webrev: http://cr.openjdk.java.net/~flar/JDK-8183530/webrev.03/ ...jim From openjfx at jyloo.com Tue Aug 1 07:26:43 2017 From: openjfx at jyloo.com (Wolfgang Zitzelsberger) Date: Tue, 1 Aug 2017 09:26:43 +0200 Subject: How to access Modena resources? Message-ID: <9db9ce8e-1352-db72-91d4-ad5b1ddf8d37@jyloo.com> For some custom controls we extend the Modena theme by providing an additional CSS file. In this file we have references to some image files of Modena just like below. .details-dialog .message-icon{ -fx-image: url("/com/sun/javafx/scene/control/skin/modena/dialog-information.png"); } However, because the package is not open this does not work in Java 9 - see also https://stackoverflow.com/questions/45414557/modena-css-resource-loading-fails-on-java-9 - Wolfgang From adam at adamish.com Tue Aug 1 14:08:45 2017 From: adam at adamish.com (adam at adamish.com) Date: Tue, 01 Aug 2017 07:08:45 -0700 Subject: CSS style class rendering bug Message-ID: (https://stackoverflow.com/questions/45440102/javafx-css-class-not-removed-when-node-disconnected) I appeared to have discovered a case in JavaFX (8u144, running on Windows 7) where a TextField is rendered using the wrong style class. This only appears to happen in the following situation ?* style class removed whilst Node not attached to Scene AND ?* parent `GridPane` has a style-class assigned, even if that class doesn't have content. I've separated the issue from a larger application into the following contrived example: ??? public class RenderBug extends Application { ??? ??????? private static final String ERROR = "error"; ??? ??????? public static void main(String[] args) { ??????????? launch(args); ??????? } ??? ??????? @Override ??????? public void start(Stage primaryStage) throws Exception { ??????????? TextField field = new TextField(); ??????????? GridPane grid = new GridPane(); ??????????? grid.getStyleClass().add("some-random-class"); ??????????? grid.add(field, 0, 0); ??? ??????????? StackPane stack = new StackPane(grid); ??? ??????????? Scene scene = new Scene(stack); ??????????? scene.getStylesheets().add("/foo.css"); ??????????? primaryStage.setWidth(300); ??????????? primaryStage.setHeight(300); ??????????? primaryStage.setScene(scene); ??????????? primaryStage.show(); ??? ??????????? Timeline line = new Timeline(); ??? ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(4), event -> { ??????????????? field.getStyleClass().add(ERROR); ??????????? })); ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(5), event -> { ??????????????? stack.getChildren().remove(grid); ??????????? })); ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(6), event -> { ??????????????? field.getStyleClass().remove(ERROR); ??????????? })); ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(7), event -> { ??????????????? stack.getChildren().add(grid); ??????????????? System.out.println(field.getStyleClass()); ??????????? })); ??? ??????????? line.play(); ??????? } ??? ??? } foo.css ??? .text-field.error { ??? ??? -fx-background-color: red; ??? } ??? ??? .some-random-class { ??? ??? /** no content required */ ??? } Screenshot. At this point TextField is red, even though the class "error" has been removed. Even interacting with the field, resizing window etc. does not fix the issue. [![TextField shown with red][1]][1] Is this a genuine bug? or am I doing something wrong? I can't find any documentation to hint that style-classes cannot or shouldn't be updated "offline" ? [1]: https://i.stack.imgur.com/ZPEYi.png From david.grieve at oracle.com Tue Aug 1 15:02:30 2017 From: david.grieve at oracle.com (David Grieve) Date: Tue, 1 Aug 2017 11:02:30 -0400 Subject: CSS style class rendering bug In-Reply-To: References: Message-ID: <7759942a-25e7-b3f6-d586-6a2fa66f4979@oracle.com> Smells like a bug to me. On 8/1/17 10:08 AM, adam at adamish.com wrote: > (https://stackoverflow.com/questions/45440102/javafx-css-class-not-removed-when-node-disconnected) > > I appeared to have discovered a case in JavaFX (8u144, running on > Windows 7) where a TextField is rendered using the wrong style class. > > This only appears to happen in the following situation > > * style class removed whilst Node not attached to Scene AND > * parent `GridPane` has a style-class assigned, even if that class > doesn't have content. > > I've separated the issue from a larger application into the following > contrived example: > > public class RenderBug extends Application { > > private static final String ERROR = "error"; > > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception > { > TextField field = new TextField(); > GridPane grid = new GridPane(); > grid.getStyleClass().add("some-random-class"); > grid.add(field, 0, 0); > > StackPane stack = new StackPane(grid); > > Scene scene = new Scene(stack); > scene.getStylesheets().add("/foo.css"); > primaryStage.setWidth(300); > primaryStage.setHeight(300); > primaryStage.setScene(scene); > primaryStage.show(); > > Timeline line = new Timeline(); > > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(4), event -> { > field.getStyleClass().add(ERROR); > })); > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(5), event -> { > stack.getChildren().remove(grid); > })); > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(6), event -> { > field.getStyleClass().remove(ERROR); > })); > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(7), event -> { > stack.getChildren().add(grid); > > System.out.println(field.getStyleClass()); > })); > > line.play(); > } > > } > > foo.css > > .text-field.error { > -fx-background-color: red; > } > > .some-random-class { > /** no content required */ > } > > Screenshot. At this point TextField is red, even though the class > "error" has been removed. Even interacting with the field, resizing > window etc. does not fix the issue. > > [![TextField shown with red][1]][1] > > Is this a genuine bug? or am I doing something wrong? I can't find any > documentation to hint that style-classes cannot or shouldn't be > updated "offline" > > [1]: https://i.stack.imgur.com/ZPEYi.png > > From kevin.rushforth at oracle.com Tue Aug 1 15:11:04 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Aug 2017 08:11:04 -0700 Subject: CSS style class rendering bug In-Reply-To: <7759942a-25e7-b3f6-d586-6a2fa66f4979@oracle.com> References: <7759942a-25e7-b3f6-d586-6a2fa66f4979@oracle.com> Message-ID: <59809A08.70309@oracle.com> Agreed. Can you file a bug here? http://bugreport.java.com/ -- Kevin David Grieve wrote: > Smells like a bug to me. > > > On 8/1/17 10:08 AM, adam at adamish.com wrote: >> (https://stackoverflow.com/questions/45440102/javafx-css-class-not-removed-when-node-disconnected) >> >> >> I appeared to have discovered a case in JavaFX (8u144, running on >> Windows 7) where a TextField is rendered using the wrong style class. >> >> This only appears to happen in the following situation >> >> * style class removed whilst Node not attached to Scene AND >> * parent `GridPane` has a style-class assigned, even if that class >> doesn't have content. >> >> I've separated the issue from a larger application into the following >> contrived example: >> >> public class RenderBug extends Application { >> private static final String ERROR = "error"; >> public static void main(String[] args) { >> launch(args); >> } >> @Override >> public void start(Stage primaryStage) throws Exception >> { >> TextField field = new TextField(); >> GridPane grid = new GridPane(); >> grid.getStyleClass().add("some-random-class"); >> grid.add(field, 0, 0); >> StackPane stack = new StackPane(grid); >> Scene scene = new Scene(stack); >> scene.getStylesheets().add("/foo.css"); >> primaryStage.setWidth(300); >> primaryStage.setHeight(300); >> primaryStage.setScene(scene); >> primaryStage.show(); >> Timeline line = new Timeline(); >> line.getKeyFrames().add(new >> KeyFrame(Duration.seconds(4), event -> { >> field.getStyleClass().add(ERROR); >> })); >> line.getKeyFrames().add(new >> KeyFrame(Duration.seconds(5), event -> { >> stack.getChildren().remove(grid); >> })); >> line.getKeyFrames().add(new >> KeyFrame(Duration.seconds(6), event -> { >> field.getStyleClass().remove(ERROR); >> })); >> line.getKeyFrames().add(new >> KeyFrame(Duration.seconds(7), event -> { >> stack.getChildren().add(grid); >> System.out.println(field.getStyleClass()); >> })); >> line.play(); >> } >> } >> >> foo.css >> >> .text-field.error { >> -fx-background-color: red; >> } >> .some-random-class { >> /** no content required */ >> } >> >> Screenshot. At this point TextField is red, even though the class >> "error" has been removed. Even interacting with the field, resizing >> window etc. does not fix the issue. >> >> [![TextField shown with red][1]][1] >> >> Is this a genuine bug? or am I doing something wrong? I can't find any >> documentation to hint that style-classes cannot or shouldn't be >> updated "offline" >> >> [1]: https://i.stack.imgur.com/ZPEYi.png >> >> > From hjohn at xs4all.nl Tue Aug 1 20:56:05 2017 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 1 Aug 2017 22:56:05 +0200 Subject: Supposedly lazy binding gets evaluated right away Message-ID: My understanding of Bindings has always been that they're supposedly only evaluated when actually used (ie. get() is called on them). Javadoc for Binding claims (emphasis mine): "All bindings in the JavaFX runtime are calculated **lazily**. That means, if a dependency changes, the result of a binding is not immediately recalculated, but it is marked as invalid. Next time the value of an invalid binding is requested, it is recalculated." So, when I create a binding, I donot expect it to be evaluated. This holds true in certain cases. However, when I then create a binding that refers another binding, it *DOES* get evaluated at creation time. Please help me understand why this is happening... The attached code shows an example of this happening (a WARNING is logged, and with a different log configuration you can see an exception logged as well, see at end): Exception while evaluating select-binding [muted] Property 'muted' in ObjectProperty [value: null] is null The problem seems to be this line of code in com.sun.javafx.binding.ExpressionHelper#addListener which calls getValue but discards the result (a red flag IMHO): observable.getValue(); // validate observable This is breaking the lazy binding and triggers a chain of "get" calls without the binding being used -- and for what? To discard the result... The reason why my property is still "null" is because in a complicated framework you may still be in the process of setting up bindings. In my case the "playerProperty" is actually set up after the creation of another class that creates bindings based on this. However that class gets this WARNING log + stacktrace while only doing binding setups. Note the property is never null when it is actually used (ie, displayed somewhere). If the binding was really lazy, then no null should ever be encountered. --John The code: public static void main(String[] args) { ObjectProperty playerProperty = new SimpleObjectProperty<>(); BooleanBinding mutedProperty = Bindings.selectBoolean(playerProperty, "muted"); new StringBinding() { { bind(mutedProperty); } @Override protected String computeValue() { return "irrelevant"; } }; // optional, bind playerProperty to something that isn't null } public static class Player { private final BooleanProperty mutedProperty = new SimpleBooleanProperty(); public BooleanProperty mutedProperty() { return mutedProperty; } } } The stacktrace: java.lang.NullPointerException at com.sun.javafx.binding.SelectBinding$SelectBindingHelper.getObservableValue(SelectBinding.java:481) at com.sun.javafx.binding.SelectBinding$AsBoolean.computeValue(SelectBinding.java:139) at javafx.beans.binding.BooleanBinding.get(BooleanBinding.java:157) at javafx.beans.binding.BooleanExpression.getValue(BooleanExpression.java:56) at javafx.beans.binding.BooleanBinding.getValue(BooleanBinding.java:60) at com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:54) at javafx.beans.binding.BooleanBinding.addListener(BooleanBinding.java:76) at javafx.beans.binding.StringBinding.bind(StringBinding.java:102) at hs.mediasystem.ext.media.newstyle.BindingBug$1.(BindingBug.java:37) at hs.mediasystem.ext.media.newstyle.BindingBug.main(BindingBug.java:35) From alexander.matveev at oracle.com Tue Aug 1 23:41:45 2017 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 1 Aug 2017 16:41:45 -0700 Subject: [10] Review request for 8185691: MediaPlayer reports error with HTTP Live Streams instead of EOS Message-ID: <293ea616-02a3-cdc6-7993-4a2efcb4727c@oracle.com> Hi Kevin and David, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8185691 Fixed issue when error was send instead of EOS for HTTP Live Streaming. Thanks, Alexander From ambarish.rapte at oracle.com Wed Aug 2 05:43:07 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 1 Aug 2017 22:43:07 -0700 (PDT) Subject: Review request for 8181930 : Adding a null icon to a Stage prevents application startup Message-ID: <69aebe27-ed51-488b-a96f-6a756ac5ee8b@default> Hi Chien, Hi Kevin, Request you to review the fix for JDK 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8181930 Webrev: http://cr.openjdk.java.net/~arapte/fx/8181930/webrev.00/ Regards, Ambarish From robert.fisher.ext at zeiss.com Wed Aug 2 08:18:23 2017 From: robert.fisher.ext at zeiss.com (Fisher, Robert [ext]) Date: Wed, 2 Aug 2017 08:18:23 +0000 Subject: CSS style class rendering bug In-Reply-To: References: Message-ID: <025E25CA98F8AE46BE306AB33F6A38D50BD94F1C@adefue01sms003> Could be the same as this bug here which was a regression in 8u102: https://bugs.openjdk.java.net/browse/JDK-8183100 A workaround is to call Node#impl_reapplyCSS on the parent *after* putting the child back in the scene. But this isn't public API and is removed in Java 9, so you can alternatively just add and remove a dummy style class i.e. field.getStyleClass().add("blah") field.getStyleClass().remove("blah") which may still work in 9. Cheers, Rob -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of adam at adamish.com Sent: Dienstag, 1. August 2017 16:09 To: openjfx-dev at openjdk.java.net Subject: CSS style class rendering bug (https://stackoverflow.com/questions/45440102/javafx-css-class-not-removed-when-node-disconnected) I appeared to have discovered a case in JavaFX (8u144, running on Windows 7) where a TextField is rendered using the wrong style class. This only appears to happen in the following situation ?* style class removed whilst Node not attached to Scene AND ?* parent `GridPane` has a style-class assigned, even if that class doesn't have content. I've separated the issue from a larger application into the following contrived example: ??? public class RenderBug extends Application { ??? ??????? private static final String ERROR = "error"; ??? ??????? public static void main(String[] args) { ??????????? launch(args); ??????? } ??? ??????? @Override ??????? public void start(Stage primaryStage) throws Exception { ??????????? TextField field = new TextField(); ??????????? GridPane grid = new GridPane(); ??????????? grid.getStyleClass().add("some-random-class"); ??????????? grid.add(field, 0, 0); ??? ??????????? StackPane stack = new StackPane(grid); ??? ??????????? Scene scene = new Scene(stack); ??????????? scene.getStylesheets().add("/foo.css"); ??????????? primaryStage.setWidth(300); ??????????? primaryStage.setHeight(300); ??????????? primaryStage.setScene(scene); ??????????? primaryStage.show(); ??? ??????????? Timeline line = new Timeline(); ??? ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(4), event -> { ??????????????? field.getStyleClass().add(ERROR); ??????????? })); ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(5), event -> { ??????????????? stack.getChildren().remove(grid); ??????????? })); ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(6), event -> { ??????????????? field.getStyleClass().remove(ERROR); ??????????? })); ??????????? line.getKeyFrames().add(new KeyFrame(Duration.seconds(7), event -> { ??????????????? stack.getChildren().add(grid); ??????????????? System.out.println(field.getStyleClass()); ??????????? })); ??? ??????????? line.play(); ??????? } ??? ??? } foo.css ??? .text-field.error { ??? ??? -fx-background-color: red; ??? } ??? ??? .some-random-class { ??? ??? /** no content required */ ??? } Screenshot. At this point TextField is red, even though the class "error" has been removed. Even interacting with the field, resizing window etc. does not fix the issue. [![TextField shown with red][1]][1] Is this a genuine bug? or am I doing something wrong? I can't find any documentation to hint that style-classes cannot or shouldn't be updated "offline" ? [1]: https://i.stack.imgur.com/ZPEYi.png From kevin.rushforth at oracle.com Wed Aug 2 15:03:18 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Aug 2017 08:03:18 -0700 Subject: CSS style class rendering bug In-Reply-To: <025E25CA98F8AE46BE306AB33F6A38D50BD94F1C@adefue01sms003> References: <025E25CA98F8AE46BE306AB33F6A38D50BD94F1C@adefue01sms003> Message-ID: <5981E9B6.6080906@oracle.com> Yes, this might be the same bug. The incident triage team independently confirmed that this is a regression introduced in 8u102. Btw, the bug is now available on bugs.openjdk.java.net here: https://bugs.openjdk.java.net/browse/JDK-8185709 -- Kevin Fisher, Robert [ext] wrote: > Could be the same as this bug here which was a regression in 8u102: > > https://bugs.openjdk.java.net/browse/JDK-8183100 > > A workaround is to call Node#impl_reapplyCSS on the parent *after* putting the child back in the scene. But this isn't public API and is removed in Java 9, so you can alternatively just add and remove a dummy style class i.e. > > field.getStyleClass().add("blah") > field.getStyleClass().remove("blah") > > which may still work in 9. > > Cheers, > Rob > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of adam at adamish.com > Sent: Dienstag, 1. August 2017 16:09 > To: openjfx-dev at openjdk.java.net > Subject: CSS style class rendering bug > > (https://stackoverflow.com/questions/45440102/javafx-css-class-not-removed-when-node-disconnected) > > I appeared to have discovered a case in JavaFX (8u144, running on Windows 7) where a TextField is rendered using the wrong style class. > > This only appears to happen in the following situation > > * style class removed whilst Node not attached to Scene AND > * parent `GridPane` has a style-class assigned, even if that class doesn't have content. > > I've separated the issue from a larger application into the following contrived example: > > public class RenderBug extends Application { > > private static final String ERROR = "error"; > > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > TextField field = new TextField(); > GridPane grid = new GridPane(); > grid.getStyleClass().add("some-random-class"); > grid.add(field, 0, 0); > > StackPane stack = new StackPane(grid); > > Scene scene = new Scene(stack); > scene.getStylesheets().add("/foo.css"); > primaryStage.setWidth(300); > primaryStage.setHeight(300); > primaryStage.setScene(scene); > primaryStage.show(); > > Timeline line = new Timeline(); > > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(4), event -> { > field.getStyleClass().add(ERROR); > })); > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(5), event -> { > stack.getChildren().remove(grid); > })); > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(6), event -> { > field.getStyleClass().remove(ERROR); > })); > line.getKeyFrames().add(new > KeyFrame(Duration.seconds(7), event -> { > stack.getChildren().add(grid); > > System.out.println(field.getStyleClass()); > })); > > line.play(); > } > > } > > foo.css > > .text-field.error { > -fx-background-color: red; > } > > .some-random-class { > /** no content required */ > } > > Screenshot. At this point TextField is red, even though the class "error" has been removed. Even interacting with the field, resizing window etc. does not fix the issue. > > [![TextField shown with red][1]][1] > > Is this a genuine bug? or am I doing something wrong? I can't find any documentation to hint that style-classes cannot or shouldn't be updated "offline" > > [1]: https://i.stack.imgur.com/ZPEYi.png > > > From jonathan.giles at oracle.com Thu Aug 3 04:00:42 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 3 Aug 2017 16:00:42 +1200 Subject: [Review request] 8091673: Runtime should have a published focus traversal API for use in custom controls Message-ID: <91095e01-f3ca-3620-0676-127b04a1ed18@oracle.com> Kevin, Phil, Could you please review the webrev below, which aims to provide new public API for focus traversal in JavaFX. https://bugs.openjdk.java.net/browse/JDK-8091673 http://cr.openjdk.java.net/~jgiles/8091673.1 -- -- Jonathan From jonathan.giles at oracle.com Thu Aug 3 04:00:44 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 3 Aug 2017 16:00:44 +1200 Subject: [Review request] 8178519: Consider removing two-level focus support from UI controls Message-ID: <503b356e-9e67-95b0-43a7-4167e8955ccd@oracle.com> Kevin, Phil, Could you please review the webrev below, which aims to remove the unused two-level focus code that presently ships in JDK 9 and earlier releases. https://bugs.openjdk.java.net/browse/JDK-8178519 http://cr.openjdk.java.net/~jgiles/8178519/ Thanks, -- -- Jonathan From prasanta.sadhukhan at oracle.com Thu Aug 3 09:01:08 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 3 Aug 2017 14:31:08 +0530 Subject: [10] RFR: JDK-8133329: Drag and Drop of files in a SwingNode fails Message-ID: <1b2b34f0-00cc-f9e4-2f9b-dd3410ea268f@oracle.com> Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8133329/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8133329 More information in JBS. Regards Prasanta From ambarish.rapte at oracle.com Thu Aug 3 18:04:53 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 3 Aug 2017 11:04:53 -0700 (PDT) Subject: Review request for : JDK-8092206 : TabPane renders content of all tabs even only one is active Message-ID: <8ef75236-4561-4d89-a39b-d19e074dc0cc@default> Hi Kevin, Hi Jonathan, Request you to review the fix, Bug: https://bugs.openjdk.java.net/browse/JDK-8092206 Webrev: http://cr.openjdk.java.net/~arapte/fx/8092206/webrev.04/ Regards, Ambarish From james.graham at oracle.com Thu Aug 3 21:27:18 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 3 Aug 2017 14:27:18 -0700 Subject: [10] RFR: JDK-8133329: Drag and Drop of files in a SwingNode fails In-Reply-To: <1b2b34f0-00cc-f9e4-2f9b-dd3410ea268f@oracle.com> References: <1b2b34f0-00cc-f9e4-2f9b-dd3410ea268f@oracle.com> Message-ID: <0197eebc-9640-aea7-ca81-49538c10d482@oracle.com> I noticed a "FIXME" comment in there. Didn't we do a pass a while back and convert all of them into JBS entries? The new code simply repeats what was done for the existing Exception which is what has the "FIXME" comment so I would use this opportunity to upgrade that FIXME into an actual bug entry. Also, perhaps we could use the multi-catch syntax here instead of creating a new catch? ...jim On 8/3/17 2:01 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix > http://cr.openjdk.java.net/~psadhukhan/fx/8133329/webrev.00/ > for issue > https://bugs.openjdk.java.net/browse/JDK-8133329 > More information in JBS. > > Regards > Prasanta From jonathan.giles at oracle.com Fri Aug 4 00:33:34 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 4 Aug 2017 12:33:34 +1200 Subject: [Review request] 8185767: Fix broken links in Javadocs Message-ID: Jon, Kevin and / or Phil, Please review the webrev below. It improves the JavaFX javadocs such that there are (hopefully) no bad links any longer. https://bugs.openjdk.java.net/browse/JDK-8185767 http://cr.openjdk.java.net/~jgiles/8185767/ Thanks, -- -- Jonathan From prasanta.sadhukhan at oracle.com Fri Aug 4 04:20:54 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 4 Aug 2017 09:50:54 +0530 Subject: [10] RFR: JDK-8133329: Drag and Drop of files in a SwingNode fails In-Reply-To: <0197eebc-9640-aea7-ca81-49538c10d482@oracle.com> References: <1b2b34f0-00cc-f9e4-2f9b-dd3410ea268f@oracle.com> <0197eebc-9640-aea7-ca81-49538c10d482@oracle.com> Message-ID: <7465720a-0685-479b-3e5b-d5a9897e8ed3@oracle.com> On 8/4/2017 2:57 AM, Jim Graham wrote: > I noticed a "FIXME" comment in there. Didn't we do a pass a while > back and convert all of them into JBS entries? > > The new code simply repeats what was done for the existing Exception > which is what has the "FIXME" comment so I would use this opportunity > to upgrade that FIXME into an actual bug entry. > > Also, perhaps we could use the multi-catch syntax here instead of > creating a new catch? > Ok. I have put it as a mult-catch in this webrev http://cr.openjdk.java.net/~psadhukhan/fx/8133329/webrev.01/ Regards Prasanta > ...jim > > On 8/3/17 2:01 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix >> http://cr.openjdk.java.net/~psadhukhan/fx/8133329/webrev.00/ >> for issue >> https://bugs.openjdk.java.net/browse/JDK-8133329 >> More information in JBS. >> >> Regards >> Prasanta From avik.niyogi at oracle.com Fri Aug 4 06:11:24 2017 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 4 Aug 2017 11:41:24 +0530 Subject: Review Request 8176813: Mac: Failure to exit full-screen programmatically in some cases Message-ID: <4A3F8634-BF83-4B92-98C1-DE58EEFE210C@oracle.com> Please review the webrev below which tries to fix the issue of GetApplication processed for Null values. Any alternatives or suggestions are welcome. This fixes the issue presented by the description. https://bugs.openjdk.java.net/browse/JDK-8176813 http://cr.openjdk.java.net/~aniyogi/8176813/webrev.00/ With Regards, Avik Niyogi From openjfx at jyloo.com Fri Aug 4 14:32:40 2017 From: openjfx at jyloo.com (Wolfgang Zitzelsberger) Date: Fri, 4 Aug 2017 16:32:40 +0200 Subject: Skin fields visibility changed from protected to no modifier in Java9 Message-ID: <2a0fd48e-c5cd-a8ff-745e-ab8cade46b29@jyloo.com> In some Skins (e.g. MenuButtonSkinBar, TabPaneSkin, TextFieldSkin) the visibility of protected fields has been changed so they can't be accessed any longer without reflection. Skin classes are public in Java 9, that's fine - however, limiting visibility makes things even worse. Because of Jigsaw a user is now forced to add related "-add-opens" arguments. Additionally, there is no way to access Modena resources because the package is not opened - see also https://stackoverflow.com/questions/45414557/modena-css-resource-loading-fails-on-java-9 I wonder why you are that restrictive? - Wolfgang From jonathan.giles at oracle.com Fri Aug 4 19:19:57 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 5 Aug 2017 07:19:57 +1200 Subject: Skin fields visibility changed from protected to no modifier in Java9 In-Reply-To: <2a0fd48e-c5cd-a8ff-745e-ab8cade46b29@jyloo.com> References: <2a0fd48e-c5cd-a8ff-745e-ab8cade46b29@jyloo.com> Message-ID: I can appreciate your desire to have more access to skin internals. As I was going through JEP 253 to make these APIs public I tried to be as clear as possible - at conferences, on openjfx-dev, via Twitter, etc - that developers urgently need to tell me what they want, as I couldn't just do a bulk copy/paste of existing skin code into public API. In cases where developers did communicate their requirements, I tried my best to accommodate these requirements into JDK 9. JDK 9 is now no longer my focus, but the next JDK release is, and so, as always, I encourage people to get their requests in early while we still have an open feature development window. JBS is the right place for these reports. The same goes for access to modena resources. We simply need to know the issues being experienced and we will try our best to make them go away in instances where they prevent some valid use case from being possible. This means bug reports into JBS. -- Jonathan On 5/08/17 2:32 AM, Wolfgang Zitzelsberger wrote: > In some Skins (e.g. MenuButtonSkinBar, TabPaneSkin, TextFieldSkin) the > visibility of protected fields has been changed so they can't be > accessed any longer without reflection. Skin classes are public in > Java 9, that's fine - however, limiting visibility makes things even > worse. Because of Jigsaw a user is now forced to add related > "-add-opens" arguments. > > Additionally, there is no way to access Modena resources because the > package is not opened - see also > https://stackoverflow.com/questions/45414557/modena-css-resource-loading-fails-on-java-9 > > I wonder why you are that restrictive? > > - Wolfgang > > From james.graham at oracle.com Sat Aug 5 00:06:10 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 4 Aug 2017 17:06:10 -0700 Subject: [10] RFR: JDK-8133329: Drag and Drop of files in a SwingNode fails In-Reply-To: <7465720a-0685-479b-3e5b-d5a9897e8ed3@oracle.com> References: <1b2b34f0-00cc-f9e4-2f9b-dd3410ea268f@oracle.com> <0197eebc-9640-aea7-ca81-49538c10d482@oracle.com> <7465720a-0685-479b-3e5b-d5a9897e8ed3@oracle.com> Message-ID: This looks good... +1 ...jim On 8/3/17 9:20 PM, Prasanta Sadhukhan wrote: > > > On 8/4/2017 2:57 AM, Jim Graham wrote: >> I noticed a "FIXME" comment in there. Didn't we do a pass a while back and convert all of them into JBS entries? >> >> The new code simply repeats what was done for the existing Exception which is what has the "FIXME" comment so I would >> use this opportunity to upgrade that FIXME into an actual bug entry. >> >> Also, perhaps we could use the multi-catch syntax here instead of creating a new catch? >> > Ok. I have put it as a mult-catch in this webrev > http://cr.openjdk.java.net/~psadhukhan/fx/8133329/webrev.01/ > > Regards > Prasanta >> ...jim >> >> On 8/3/17 2:01 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix >>> http://cr.openjdk.java.net/~psadhukhan/fx/8133329/webrev.00/ >>> for issue >>> https://bugs.openjdk.java.net/browse/JDK-8133329 >>> More information in JBS. >>> >>> Regards >>> Prasanta > From arunprasad.rajkumar at oracle.com Mon Aug 7 09:09:11 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 7 Aug 2017 14:39:11 +0530 Subject: [10] Review request: 8185804: rpath is not set properly in OSX build Message-ID: Hi, Please review the simple fix for the following bug, https://bugs.openjdk.java.net/browse/JDK-8185804 Detailed analysis and fix is updated as JBS comment. Thanks, Arun From murali.billa at oracle.com Mon Aug 7 10:26:58 2017 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 7 Aug 2017 03:26:58 -0700 (PDT) Subject: [10] Review request for 8183928: [Linux] Remove Warnings [-Wunused-parameter] In-Reply-To: References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> Message-ID: <8ff1fe45-0844-4811-943a-3f76e4f9c71c@default> ? Hi, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8183928 ? Webrev: http://cr.openjdk.java.net/~mbilla/8183928/webrev.00/ ? Thanks, Murali From murali.billa at oracle.com Mon Aug 7 14:01:20 2017 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 7 Aug 2017 07:01:20 -0700 (PDT) Subject: [10] Review request for 8182977: NullPointerException with HTMLEditor when changing the scene graph In-Reply-To: <8ff1fe45-0844-4811-943a-3f76e4f9c71c@default> References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> <8ff1fe45-0844-4811-943a-3f76e4f9c71c@default> Message-ID: <667f16a9-820e-4d63-ac76-09b08b8629d1@default> ? Hi, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8182977 ? Webrev: http://cr.openjdk.java.net/~mbilla/8182977/webrev.00/ ? Thanks, Murali From prasanta.sadhukhan at oracle.com Tue Aug 8 09:43:03 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 Aug 2017 15:13:03 +0530 Subject: [10] RFR JDK-8185792: Entering accents in a textfield on a JFXPanel produces NPE Message-ID: <338c6674-c5c3-1b80-bc40-d06b7ba279fc@oracle.com> Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8185792/webrev.00/ for an fx issue https://bugs.openjdk.java.net/browse/JDK-8185792 More info in JBS. Regards Prasanta From prasanta.sadhukhan at oracle.com Tue Aug 8 10:16:52 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 8 Aug 2017 15:46:52 +0530 Subject: [10] RFR JDK-8185890:Intermittent NPE in JLightweightFrame when updating cursor aceoss multiple graphics devices Message-ID: <1301ef66-ff14-e7c7-2d4e-2be4e2b9051b@oracle.com> Hi All, Please review this patch http://cr.openjdk.java.net/~psadhukhan/fx/8185890/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8185890 More info in JBS. Regards Prasanta From manajit.halder at oracle.com Tue Aug 8 11:22:27 2017 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 8 Aug 2017 16:52:27 +0530 Subject: Review Request: JDK-8185954: Mac: JavaFx TextArea doesn't display the Emoji and Symbols on dropping them on the text area Message-ID: Hi All, Kindly review the following JavaFx fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8185954 Webrev: http://cr.openjdk.java.net/~mhalder/fx/8185954/webrev.02/ Note: This fix is related to issue https://bugs.openjdk.java.net/browse/JDK-8176319 . Regards, Manajit From jonathan.gibbons at oracle.com Fri Aug 4 01:02:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 03 Aug 2017 18:02:13 -0700 Subject: [Review request] 8185767: Fix broken links in Javadocs In-Reply-To: References: Message-ID: <5983C795.2090804@oracle.com> I've scanned through it, and it looks generally OK to me. -- Jon On 08/03/2017 05:33 PM, Jonathan Giles wrote: > Jon, Kevin and / or Phil, > > Please review the webrev below. It improves the JavaFX javadocs such > that there are (hopefully) no bad links any longer. > > https://bugs.openjdk.java.net/browse/JDK-8185767 > http://cr.openjdk.java.net/~jgiles/8185767/ > > Thanks, > From kevin.rushforth at oracle.com Tue Aug 8 16:22:38 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 08 Aug 2017 09:22:38 -0700 Subject: [10] RFR JDK-8185890:Intermittent NPE in JLightweightFrame when updating cursor aceoss multiple graphics devices In-Reply-To: <1301ef66-ff14-e7c7-2d4e-2be4e2b9051b@oracle.com> References: <1301ef66-ff14-e7c7-2d4e-2be4e2b9051b@oracle.com> Message-ID: <5989E54E.9020400@oracle.com> I think this should be reviewed on the swing-dev list, since the stack trace and proposed fix are both entirely in Swing code. -- Kevin Prasanta Sadhukhan wrote: > Hi All, > > Please review this patch > http://cr.openjdk.java.net/~psadhukhan/fx/8185890/webrev.00/ > for issue > https://bugs.openjdk.java.net/browse/JDK-8185890 > > More info in JBS. > > Regards > Prasanta From murali.billa at oracle.com Tue Aug 8 18:14:54 2017 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 8 Aug 2017 11:14:54 -0700 (PDT) Subject: [10] Review request for 8185970: Possible crash due to use-after-free In-Reply-To: <667f16a9-820e-4d63-ac76-09b08b8629d1@default> References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> <8ff1fe45-0844-4811-943a-3f76e4f9c71c@default> <667f16a9-820e-4d63-ac76-09b08b8629d1@default> Message-ID: ? Hi, Please review the below fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8185970 ? Webrev: http://cr.openjdk.java.net/~mbilla/8185970/webrev.00/ ? Thanks, Murali From prasanta.sadhukhan at oracle.com Wed Aug 9 07:38:44 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 Aug 2017 13:08:44 +0530 Subject: [10] RFR JDK-8088874:AssertionError in javafx.embed.swing.SwingDnD.endDnD Message-ID: <0d09bd71-fdb5-b7c8-d3b7-1d547f77ce74@oracle.com> Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8088874/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8088874 More info in JBS. Regards Prasanta From prasanta.sadhukhan at oracle.com Wed Aug 9 08:54:32 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 Aug 2017 14:24:32 +0530 Subject: [10] RFR JDK-8156592:JFXPanel should use the new FocusEvent.getCause() API Message-ID: Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8156592/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8156592 More info in JBS. Regards Prasanta From guru.hb at oracle.com Thu Aug 10 04:17:03 2017 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 10 Aug 2017 09:47:03 +0530 Subject: [webkit][10] 8185940: Web native compiled files not removed during gradle clean In-Reply-To: References: Message-ID: <189550C6-8A2B-4481-9C9A-D3B004375B21@oracle.com> Hi Arun, Murali, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8185940 WebRev : http://cr.openjdk.java.net/~ghb/8185940/webrev.00 Thanks, Guru From guru.hb at oracle.com Thu Aug 10 08:33:02 2017 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 10 Aug 2017 14:03:02 +0530 Subject: [webkit][10] Review request: 8186061: libjfxwebkit.dylib ld warning libicudata.a was built for newer OSX version Message-ID: <8E4ABDC7-B8A5-4A99-8E68-6A75DB3D78CE@oracle.com> Hi Arun, Murali, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8186061 webrev : http://cr.openjdk.java.net/~ghb/8186061/webrev.00/ Thanks, Guru From ajit.ghaisas at oracle.com Thu Aug 10 12:45:04 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 10 Aug 2017 05:45:04 -0700 (PDT) Subject: [10] Review request : JDK-8090462 : CSS performance: Link style helpers together to avoid going through parent chain looking for parent style helpers Message-ID: <8be2f805-9142-495c-8d7a-df32f0fb9941@default> Hi Jonathan, Request you to review following change : Issue : https://bugs.openjdk.java.net/browse/JDK-8090462 Fix : http://cr.openjdk.java.net/~aghaisas/fx/e8090462/webrev.2/ Regards, Ajit From david.grieve at oracle.com Thu Aug 10 14:15:21 2017 From: david.grieve at oracle.com (David Grieve) Date: Thu, 10 Aug 2017 10:15:21 -0400 Subject: [10] Review request : JDK-8090462 : CSS performance: Link style helpers together to avoid going through parent chain looking for parent style helpers In-Reply-To: <8be2f805-9142-495c-8d7a-df32f0fb9941@default> References: <8be2f805-9142-495c-8d7a-df32f0fb9941@default> Message-ID: <2d56cbd6-3cb9-e998-ce04-0edb71a790ec@oracle.com> Ajit, I have provided some comments in the bug. On 8/10/17 8:45 AM, Ajit Ghaisas wrote: > Hi Jonathan, > > Request you to review following change : > > Issue : https://bugs.openjdk.java.net/browse/JDK-8090462 > > Fix : http://cr.openjdk.java.net/~aghaisas/fx/e8090462/webrev.2/ > > Regards, > Ajit From prasanta.sadhukhan at oracle.com Fri Aug 11 08:13:55 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 11 Aug 2017 13:43:55 +0530 Subject: [10] RFR JDK-8087914: [JFXPanel] Clicking on Menu in JFXPanel ignored if another swing component has focus Message-ID: <2bd9cb5d-7d1a-c696-b50f-0388faa909eb@oracle.com> Hi All, Please review this fx fix http://cr.openjdk.java.net/~psadhukhan/fx/8087914/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8087914 More info in JBS. Regards Prasanta From prasanta.sadhukhan at oracle.com Mon Aug 14 06:00:20 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 14 Aug 2017 11:30:20 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode Message-ID: <97e15491-ee19-7c1d-c813-2bfe006f57b2@oracle.com> Hi All, Please review this fix http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ for an fx issue https://bugs.openjdk.java.net/browse/JDK-8088132 More info in JBS. Regards Prasanta From sergey.bylokhov at oracle.com Mon Aug 14 16:37:37 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Aug 2017 09:37:37 -0700 (PDT) Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode Message-ID: Hi, Prasanta, Kevin. I have two notes. - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread. - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager. ----- prasanta.sadhukhan at oracle.com wrote: > Hi All, > > Please review this fix > http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ > for an fx issue > https://bugs.openjdk.java.net/browse/JDK-8088132 > > More info in JBS. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Wed Aug 16 10:33:29 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 16 Aug 2017 16:03:29 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: References: Message-ID: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com> Hi Sergey, AFAIK, FX singleThread feature is supported but experimental feature. I have modified webrev to include DefaultKeyboardFocusManager too http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.01/ I do not think there is any problem in skipping code which works with EDT as for example, in SequencedEvent#dispatch() it says Dispatches the nested event after all previous nested events have beendispatched or disposed Now, since here FX App thread itself is the dispatch thread, we can be sure the events are dispatched in sequence and dispose is checked below after EDT. I have tested with couple of singleThread testcase without any issue. Regards Prasanta On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: > Hi, Prasanta, Kevin. > > I have two notes. > - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread. > - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager. > > ----- prasanta.sadhukhan at oracle.com wrote: > >> Hi All, >> >> Please review this fix >> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >> for an fx issue >> https://bugs.openjdk.java.net/browse/JDK-8088132 >> >> More info in JBS. >> >> Regards >> Prasanta From chris.bensen at oracle.com Wed Aug 16 16:12:44 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 16 Aug 2017 09:12:44 -0700 Subject: [10] Review request: 8186237 Refactor jdk.packager to legacy package Message-ID: <95917350-FB94-4F30-8D44-0F1FFB0C8E78@oracle.com> Victor, Please review this refactor to get ready for the new CLI. JIRA: https://bugs.openjdk.java.net/browse/JDK-8186237 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8186237/webrev.00/ Chris From prasanta.sadhukhan at oracle.com Thu Aug 17 10:41:12 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 17 Aug 2017 16:11:12 +0530 Subject: [10] RFR JDK-8089005:JFXPanel.setScene(Scene) uses bad synchronization pattern Message-ID: <38cf9764-97fa-c173-42ef-fd28d251dc16@oracle.com> Hi All, Please review fx fix http://cr.openjdk.java.net/~psadhukhan/fx/8089005/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8089005 More info in JBS. Regards Prasanta From ajit.ghaisas at oracle.com Thu Aug 17 11:07:41 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 17 Aug 2017 04:07:41 -0700 (PDT) Subject: [10] Review Request : JDK-8173301 : Provide API to exclude parts of the SceneGraph from being processed by the CSS-Engine Message-ID: Hi, It is a proposed API that developers can leverage to gain performance improvements by skipping CSS processing on selective Nodes. JBS API request : https://bugs.openjdk.java.net/browse/JDK-8173301 Webrev : http://cr.openjdk.java.net/~aghaisas/fx/e8173301/webrev.0/ Request you to review. Regards, Ajit From manajit.halder at oracle.com Fri Aug 18 09:05:01 2017 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 18 Aug 2017 14:35:01 +0530 Subject: Review Request: JDK-8185954: Mac: JavaFx TextArea doesn't display the Emoji and Symbols on dropping them on the text area In-Reply-To: References: Message-ID: Hi Phil, Please review the fix. Regards, Manajit > On 08-Aug-2017, at 4:52 PM, Manajit Halder wrote: > > Hi All, > > Kindly review the following JavaFx fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185954 > Webrev: http://cr.openjdk.java.net/~mhalder/fx/8185954/webrev.02/ > > Note: This fix is related to issue https://bugs.openjdk.java.net/browse/JDK-8176319 . > > Regards, > Manajit From philip.race at oracle.com Fri Aug 18 21:02:06 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 18 Aug 2017 14:02:06 -0700 Subject: Review Request: JDK-8185954: Mac: JavaFx TextArea doesn't display the Emoji and Symbols on dropping them on the text area In-Reply-To: References: Message-ID: <599755CE.8090605@oracle.com> Well... you had asked me what to do about the Emoji in the context of 8176319 and I said to include it in that fix as you had there .. so I don't know what this separate bug and webrev is about. Seems like you should close it as a dup. and return to the previous bug ? -phil. On 8/18/17, 2:05 AM, Manajit Halder wrote: > Hi Phil, > > Please review the fix. > > Regards, > Manajit > >> On 08-Aug-2017, at 4:52 PM, Manajit Halder wrote: >> >> Hi All, >> >> Kindly review the following JavaFx fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185954 >> Webrev: http://cr.openjdk.java.net/~mhalder/fx/8185954/webrev.02/ >> >> Note: This fix is related to issue https://bugs.openjdk.java.net/browse/JDK-8176319. >> >> Regards, >> Manajit From prasanta.sadhukhan at oracle.com Mon Aug 21 09:49:54 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 21 Aug 2017 15:19:54 +0530 Subject: [10] RFR JDK-8089351:JFXPanel: non-serializable value stored into instance field of a serializable class Message-ID: <0beabead-1f31-bd2b-ca04-fc1effcf7ba4@oracle.com> Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8089351/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8089351 More info in JBS. Regards Prasanta From manajit.halder at oracle.com Mon Aug 21 16:26:59 2017 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 21 Aug 2017 21:56:59 +0530 Subject: Review Request: JDK-8185954: Mac: JavaFx TextArea doesn't display the Emoji and Symbols on dropping them on the text area In-Reply-To: <599755CE.8090605@oracle.com> References: <599755CE.8090605@oracle.com> Message-ID: Hi Phil, There are 2 issues here: 1) JDK-8176319: Problem in displaying Character Viewer. The fix is not resolving this issue. It is resolving the next issue. This issue is observed on OS X 10.9 and 10.10.5. 2) JDK-8185954: Problem in displaying the characters in the TextArea. Character viewer is getting displayed. Observed on OS X 10.12.5. The proposed fix resolves this issue. If I return to the previous bug then I need to fix both the problems as part of the same issue (JDK-8176319). Hence I created JDK-8185954 which is for the proposed fix. Regards, Manajit > On 19-Aug-2017, at 2:32 AM, Philip Race wrote: > > > Well... you had asked me what to do about the Emoji in the context of 8176319 > and I said to include it in that fix as you had there .. so I don't know what this separate bug > and webrev is about. > Seems like you should close it as a dup. and return to the previous bug ? > > -phil. > > On 8/18/17, 2:05 AM, Manajit Halder wrote: >> Hi Phil, >> >> Please review the fix. >> >> Regards, >> Manajit >> >>> On 08-Aug-2017, at 4:52 PM, Manajit Halder wrote: >>> >>> Hi All, >>> >>> Kindly review the following JavaFx fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185954 >>> Webrev: http://cr.openjdk.java.net/~mhalder/fx/8185954/webrev.02/ >>> >>> Note: This fix is related to issue https://bugs.openjdk.java.net/browse/JDK-8176319. >>> >>> Regards, >>> Manajit From rajath.kamath at oracle.com Tue Aug 22 09:53:47 2017 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Tue, 22 Aug 2017 02:53:47 -0700 (PDT) Subject: [webkit][10] Review request - 8185314: Remove unused third-party python scripts from WebKit sources Message-ID: Hi Guru\Arun, Please review this simple cleanup of unused third-party library download scripts. JBS : https://bugs.openjdk.java.net/browse/JDK-8185314 WebRev : http://cr.openjdk.java.net/~ghb/rkamath/8185314/webrev.00/ Thanks, Rajath From guru.hb at oracle.com Wed Aug 23 05:54:19 2017 From: guru.hb at oracle.com (Guru Hb) Date: Wed, 23 Aug 2017 11:24:19 +0530 Subject: [webkit][10] Review request: 8170955: HTML5 canvas shadow properties should not be affected by transform Message-ID: Hi Arun & Murali, Please review the fix for : JBS : https://bugs.openjdk.java.net/browse/JDK-8170955 webrev : http://cr.openjdk.java.net/~ghb/8170955/webrev.00/ Thanks, Guru From prasanta.sadhukhan at oracle.com Wed Aug 23 08:27:01 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 23 Aug 2017 13:57:01 +0530 Subject: [10] RFR JDK-8089962:[FXDnD]: in removeDropTarget the isDropTargetListenerInstalled field isn't reset Message-ID: Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8089962/webrev.00/ for issue https://bugs.openjdk.java.net/browse/JDK-8089962 More info in JBS. Regards Prasanta From prasanta.sadhukhan at oracle.com Wed Aug 23 08:39:38 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 23 Aug 2017 14:09:38 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com> References: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com> Message-ID: <26f687c6-4ae7-81dc-31f8-72c1516f72db@oracle.com> Any feedback on this? Regards Prasanta On 8/16/2017 4:03 PM, Prasanta Sadhukhan wrote: > > Hi Sergey, > > AFAIK, FX singleThread feature is supported but experimental feature. > I have modified webrev to include DefaultKeyboardFocusManager too > http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.01/ > > I do not think there is any problem in skipping code which works with > EDT as for example, in SequencedEvent#dispatch() it says > Dispatches the nested event after all previous nested events have > beendispatched or disposed > Now, since here FX App thread itself is the dispatch thread, we can be > sure the events are dispatched in sequence and dispose is checked > below after EDT. > > I have tested with couple of singleThread testcase without any issue. > > Regards > Prasanta > On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >> Hi, Prasanta, Kevin. >> >> I have two notes. >> - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread. >> - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager. >> >> -----prasanta.sadhukhan at oracle.com wrote: >> >>> Hi All, >>> >>> Please review this fix >>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>> for an fx issue >>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>> >>> More info in JBS. >>> >>> Regards >>> Prasanta > From Sergey.Bylokhov at oracle.com Wed Aug 23 16:01:07 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Aug 2017 09:01:07 -0700 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com> References: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com> Message-ID: Hi, Prasanta. On 16.08.2017 3:33, Prasanta Sadhukhan wrote: > Now, since here FX App thread itself is the dispatch thread, we can be > sure the events are dispatched in sequence and dispose is checked below > after EDT. Why we can sure about this? If the SequencedEvents were created in one order but dispatch() for each were called in other order then the sequenced will not be preserved? > > I have tested with couple of singleThread testcase without any issue. > > Regards > Prasanta > On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >> Hi, Prasanta, Kevin. >> >> I have two notes. >> - Does this option is really supported? If it is supported we should evaluate all usage of EventDispatchThread because in this mode the dispatch thread is not EDT. For example I am not sure that we can skip the code which expects EventDispatchThread. >> - We have the similar pattern: "EventQueue.isDispatchThread() -> cast(EventDispatchThread)" in some other places like in DefaultKeyboardFocusManager. >> >> -----prasanta.sadhukhan at oracle.com wrote: >> >>> Hi All, >>> >>> Please review this fix >>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>> for an fx issue >>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>> >>> More info in JBS. >>> >>> Regards >>> Prasanta > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Aug 24 05:18:24 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 24 Aug 2017 10:48:24 +0530 Subject: [10] RFR JDK-8144504:Multiple SwingNode in JFXPanel in JFrame Cause Extreme Performance Degradation Message-ID: <68454367-79dd-a8ce-56f3-776f722bb2dc@oracle.com> Hi All, Please review a fix cr.openjdk.java.net/~psadhukhan/fx/8144504/webrev.00/ for an issue https://bugs.openjdk.java.net/browse/JDK-8144504 More info in JBS. Regards Prasanta From johnvalrose at gmail.com Fri Aug 25 00:12:03 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 25 Aug 2017 10:12:03 +1000 Subject: WebView and WebGL Message-ID: I have a couple of questions about the implementation of WebView within JavaFX. I understand that, at present, it is based on WebKit but does not support WebGL. For our requirements, WebGL support is essential and I expect that other developers would appreciate support of this kind as well. It appears that WebGL support will not be implemented until Java 10 at the earliest, or, perhaps even later. As we know, this could be several years away so I would like to offer my time to work on implementing WebGL support ASAP so that it can be released to the community as part of an incremental Java 9 release. How do you feel about this suggestion? Also, could you please let me know that if the current WebView is just a wrapper around WebKit and uses native WebKit rendering, or is it actually using the JavaFX API itself to do the rendering within the JavaFX rendering pipeline? *Graciously,* *John-Val Rose* *Chief Scientist/Architect* *Rosethorn Technology* *Australia* From mp at jugs.org Fri Aug 25 07:34:47 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 25 Aug 2017 09:34:47 +0200 Subject: WebView and WebGL In-Reply-To: References: Message-ID: I also find it important to get WebGL support into WebView as soon as possible but I fear that this is not such an easy task because there are a few things to consider. From my point of view, for example, it would not make much sense to implement WebGL exclusively in the context of the WebView. JavaFX itself also needs some high-performance, cross-platform low-level rendering engine which should be compatible with WebGL in a similar way as the JavaFX Canvas is compatible with the HTML 5 Canvas. But once you have such a cross-platform, GL compatible rendering engine you have to ask yourself why JavaFX still needs different internal Prism renderer implementations and would not just use the one cross platform engine. All this needs careful consideration. Michael Am 25.08.17 um 02:12 schrieb John-Val Rose: > I have a couple of questions about the implementation of WebView within > JavaFX. > > I understand that, at present, it is based on WebKit but does not support > WebGL. For our requirements, WebGL support is essential and I expect that > other developers would appreciate support of this kind as well. > > It appears that WebGL support will not be implemented until Java 10 at the > earliest, or, perhaps even later. As we know, this could be several years > away so I would like to offer my time to work on implementing WebGL support > ASAP so that it can be released to the community as part of an incremental > Java 9 release. > > How do you feel about this suggestion? > > Also, could you please let me know that if the current WebView is just a > wrapper around WebKit and uses native WebKit rendering, or is it actually > using the JavaFX API itself to do the rendering within the JavaFX rendering > pipeline? > > *Graciously,* > > *John-Val Rose* > *Chief Scientist/Architect* > *Rosethorn Technology* > *Australia* From johnvalrose at gmail.com Fri Aug 25 10:32:05 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 25 Aug 2017 20:32:05 +1000 Subject: WebView and WebGL In-Reply-To: References: Message-ID: <92E69301-09B4-494E-9B50-12CD5FA82E24@gmail.com> I agree with you Michael. So let's open a discussion as a community and actually get coding. It won't happen otherwise... (At least not for 4 years or so) > On 25 Aug 2017, at 17:34, Michael Paus wrote: > > I also find it important to get WebGL support into WebView as soon as possible > but I fear that this is not such an easy task because there are a few things > to consider. From my point of view, for example, it would not make much sense > to implement WebGL exclusively in the context of the WebView. JavaFX > itself also needs some high-performance, cross-platform low-level rendering > engine which should be compatible with WebGL in a similar way as the JavaFX > Canvas is compatible with the HTML 5 Canvas. But once you have such a > cross-platform, GL compatible rendering engine you have to ask yourself why > JavaFX still needs different internal Prism renderer implementations and would > not just use the one cross platform engine. All this needs careful consideration. > > Michael > >> Am 25.08.17 um 02:12 schrieb John-Val Rose: >> I have a couple of questions about the implementation of WebView within >> JavaFX. >> >> I understand that, at present, it is based on WebKit but does not support >> WebGL. For our requirements, WebGL support is essential and I expect that >> other developers would appreciate support of this kind as well. >> >> It appears that WebGL support will not be implemented until Java 10 at the >> earliest, or, perhaps even later. As we know, this could be several years >> away so I would like to offer my time to work on implementing WebGL support >> ASAP so that it can be released to the community as part of an incremental >> Java 9 release. >> >> How do you feel about this suggestion? >> >> Also, could you please let me know that if the current WebView is just a >> wrapper around WebKit and uses native WebKit rendering, or is it actually >> using the JavaFX API itself to do the rendering within the JavaFX rendering >> pipeline? >> >> *Graciously,* >> >> *John-Val Rose* >> *Chief Scientist/Architect* >> *Rosethorn Technology* >> *Australia* > > From nlisker at gmail.com Fri Aug 25 16:22:06 2017 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 25 Aug 2017 19:22:06 +0300 Subject: WebView and WebGL Message-ID: It has been suggested already in https://bugs.openjdk.java.net/browse/JDK-8091035. From mp at jugs.org Fri Aug 25 16:59:42 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 25 Aug 2017 18:59:42 +0200 Subject: WebView and WebGL In-Reply-To: References: Message-ID: Am 25.08.17 um 18:22 schrieb Nir Lisker: > It has been suggested already in > https://bugs.openjdk.java.net/browse/JDK-8091035. I am well aware of these suggestions but did you look at the creation date? From johnvalrose at gmail.com Fri Aug 25 18:28:29 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 26 Aug 2017 04:28:29 +1000 Subject: WebView and WebGL In-Reply-To: References: Message-ID: <12A3769E-7F56-4258-86EB-4A65772EFD78@gmail.com> This *is* the problem: 7 years since a formal issue is raised and still we have nothing. As I said, WebGL support won't happen unless *we* make it happen and I'm in a position where I have both a need and time to work on it. I'm sure others would help too. Once someone from Oracle responds to my original questions, we will have a better idea of what the future holds. > On 26 Aug 2017, at 02:22, Nir Lisker wrote: > > It has been suggested already in > https://bugs.openjdk.java.net/browse/JDK-8091035. From jonathan.giles at oracle.com Fri Aug 25 19:06:46 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 26 Aug 2017 07:06:46 +1200 Subject: WebView and WebGL In-Reply-To: References: Message-ID: All, WebGL is something that is currently in the planning pipeline with a relatively high priority. This means it is not under active development yet, but we already have engineers working on the research towards this feature. Once this is concluded and the scope of the work better understood, a JEP will be filed to engage the community on this project, and notification will be sent to the openjfx-dev mailing list. In reference to the question on whether WebView uses WebKit rendering or JavaFX rendering, I believe the answer is the latter. -- Jonathan On 25/08/17 12:12 PM, John-Val Rose wrote: > I have a couple of questions about the implementation of WebView within > JavaFX. > > I understand that, at present, it is based on WebKit but does not support > WebGL. For our requirements, WebGL support is essential and I expect that > other developers would appreciate support of this kind as well. > > It appears that WebGL support will not be implemented until Java 10 at the > earliest, or, perhaps even later. As we know, this could be several years > away so I would like to offer my time to work on implementing WebGL support > ASAP so that it can be released to the community as part of an incremental > Java 9 release. > > How do you feel about this suggestion? > > Also, could you please let me know that if the current WebView is just a > wrapper around WebKit and uses native WebKit rendering, or is it actually > using the JavaFX API itself to do the rendering within the JavaFX rendering > pipeline? > > *Graciously,* > > *John-Val Rose* > *Chief Scientist/Architect* > *Rosethorn Technology* > *Australia* From fbrunnerlist at gmx.ch Fri Aug 25 19:23:15 2017 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 25 Aug 2017 21:23:15 +0200 Subject: Module dependencies Message-ID: <4033357.qVPV4hCstz@andor> Hi, I'm still new to the Jigsaw module system, but I've found some documentation which is strange: The Javadoc states that javafx.base depends on java.base: http://download.java.net/java/jdk9/docs/api/javafx.base-summary.html But when we look at the source code, we see that javafx.base depends on java.desktop: http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/module-info.java This sounds more logical as javafx.base depends on the package java.beans which is in the java.desktop module, e.g.: http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java So I guess, the info in the Javadoc, which was generated, I think, is misleading! That said, as far as I remember, one of the original goals of JavaFX regarding to Java SE 8 Compact Profiles/ Java SE 9 modules was to be able to generate a tailored JRE, which only includes the JavaFX stack without the AWT/ Swing stack. With the module dependency from javafx.base to java.desktop this won't be possible now, I think. This is really bad news for JavaFX on mobiles and embedded systems, but also for desktop applications which ship with a tailored, embedded JRE. Are there any plans to make JavaFX available without the AWT/ Swing stack? Will it be possible to change the module dependencies once they are published? (Depending on how transitive dependencies are handled and regarded, this could be a breaking change.) Kind regards, Florian From info at michaelhoffer.de Fri Aug 25 19:41:10 2017 From: info at michaelhoffer.de (Michael Hoffer) Date: Fri, 25 Aug 2017 21:41:10 +0200 Subject: WebView and WebGL In-Reply-To: References: Message-ID: Hi Jonathan, hi all, I would like to bring up the "WritableImage backed by DirectBuffer" discussion again: I did my own experiments with WebGL and native rendering. I posted them a while ago here on the mailing list (https://github.com/miho/VFXWebKit & https://youtu.be/FlIrY1SlNM4). I came to the conclusion that the most generic and most important feature that we need for JavaFX is efficient native buffer support (basically WritableImage backed by DirectBuffer). This allows for plugging in almost any external rendering technology and does not involve large API redesigns. Adding OpenGL and/or WebGL could be done as community projects. I find it particularly elegant to spawn separate render processes for doing OpenGL/WebGL. This is basically what modern browsers do. WebKit is a very complex piece of software that isn't easy to handle. In the past I had too many bad experiences with WebKit and JavaFX. WebKit could easily tear down the whole JVM. None of the safety-belts usually provided by Java will help in such a case. I would like to suggest that we do a JavaFX meeting at JavaOne for discussing this topic. Anyone interested? Regards, Michael -- Dr. rer. nat. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Oracle Developer Champion 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 2017-08-25 21:06 GMT+02:00 Jonathan Giles : > All, > > WebGL is something that is currently in the planning pipeline with a > relatively high priority. This means it is not under active development > yet, but we already have engineers working on the research towards this > feature. Once this is concluded and the scope of the work better > understood, a JEP will be filed to engage the community on this project, > and notification will be sent to the openjfx-dev mailing list. > > In reference to the question on whether WebView uses WebKit rendering or > JavaFX rendering, I believe the answer is the latter. > > -- Jonathan > > > > On 25/08/17 12:12 PM, John-Val Rose wrote: > >> I have a couple of questions about the implementation of WebView within >> JavaFX. >> >> I understand that, at present, it is based on WebKit but does not support >> WebGL. For our requirements, WebGL support is essential and I expect that >> other developers would appreciate support of this kind as well. >> >> It appears that WebGL support will not be implemented until Java 10 at the >> earliest, or, perhaps even later. As we know, this could be several years >> away so I would like to offer my time to work on implementing WebGL >> support >> ASAP so that it can be released to the community as part of an incremental >> Java 9 release. >> >> How do you feel about this suggestion? >> >> Also, could you please let me know that if the current WebView is just a >> wrapper around WebKit and uses native WebKit rendering, or is it actually >> using the JavaFX API itself to do the rendering within the JavaFX >> rendering >> pipeline? >> >> *Graciously,* >> >> *John-Val Rose* >> *Chief Scientist/Architect* >> *Rosethorn Technology* >> *Australia* >> > > From kevin.rushforth at oracle.com Fri Aug 25 19:43:43 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 25 Aug 2017 12:43:43 -0700 Subject: Module dependencies In-Reply-To: <4033357.qVPV4hCstz@andor> References: <4033357.qVPV4hCstz@andor> Message-ID: <59A07DEF.2060406@oracle.com> The implementation of javafx.base depends on java.desktop, but nothing in the API of javafx.base depends on java.desktop. So javafx.base (currently) requires java.desktop, but not transitively. This means that it would be possible to remove this dependency in a future version without breaking compatibility. FWIW, the javafx.graphics module is in the same state: it requires java.desktop, but not transitively. -- Kevin Florian Brunner wrote: > Hi, > > I'm still new to the Jigsaw module system, but I've found some documentation which is strange: > The Javadoc states that javafx.base depends on java.base: > http://download.java.net/java/jdk9/docs/api/javafx.base-summary.html > > But when we look at the source code, we see that javafx.base depends on java.desktop: > http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/module-info.java > > This sounds more logical as javafx.base depends on the package java.beans which is in the java.desktop module, e.g.: > http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java > http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java > > So I guess, the info in the Javadoc, which was generated, I think, is misleading! > > That said, as far as I remember, one of the original goals of JavaFX regarding to Java SE 8 Compact Profiles/ Java SE 9 modules was to be able to generate a tailored JRE, which only includes the JavaFX stack without the AWT/ Swing stack. With the module dependency from javafx.base to java.desktop this won't be possible now, I think. > This is really bad news for JavaFX on mobiles and embedded systems, but also for desktop applications which ship with a tailored, embedded JRE. > > Are there any plans to make JavaFX available without the AWT/ Swing stack? > Will it be possible to change the module dependencies once they are published? (Depending on how transitive dependencies are handled and regarded, this could be a breaking change.) > > Kind regards, > Florian > > From bourges.laurent at gmail.com Fri Aug 25 20:09:38 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 25 Aug 2017 22:09:38 +0200 Subject: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 Message-ID: Hi, Please review Marlin/FX upgrades that provide an efficient path clipper in Stroker (float / double variants) fixing the bug JDK-8184429 Marlin2D patch (jdk10): http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.0/ MarlinFX patch (openjfx10): http://cr.openjdk.java.net/~lbourges/marlinFX/marlin-080.0/ Path Clipper in (D)Stroker: - it uses outcode computation (cohen - sutherland) for segment edges (2 for lines, 3 for quads, 4 for cubics) - it opens the path when a segment is invisible ie special moveTo() and ignore invisible joins; it does not compute any intersection (line / curve), it just skips useless segment for better performance and accuracy - the ClosedPathDetector is needed to infer if the path is closed or not (call to closePath) to produce caps when appropriate. It reuses the former PolyStack (moved into Helper classes) to store the forward segments - the clip rectangle is adjusted either in Stroker but also in Transformer2D to take into account the mitter limit, stroker width and also the Renderer offset That's why it can not be applied to closed paths (fill operations) as the path must remain closed in such case (concave polygon). This could be implemented later as it needs to insert corner points when needed to avoid artefacts; so the algorithm seem more complicated to me. Marlin2D / FX Patches are slightly different to handle the Renderer offsets. I tested these patches against my MapBench test with a small clip and several affine transforms: it does not produce any artefact (0 pixel difference between clip=true/false) PS: I also improved the accuracy of Renderer's AFD by using the kaham compensated-sum approach (later patch) Cheers, Laurent Bourg?s From johnvalrose at gmail.com Fri Aug 25 20:59:19 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 26 Aug 2017 06:59:19 +1000 Subject: WebView and WebGL In-Reply-To: References: Message-ID: Thanks for your input Jonathan - it's great to know that planning is happening. I'll be around if those involved ever wish to speak with me regarding how much time/effort I can contribute. On the subject of rendering, is there some way to confirm for certain that it is using the JavaFX API and not native WebKit rendering? This is of importance to me in relation to a slightly different issue. Thanks to both Michaels too for your informative input. Graciously, John-Val Rose > On 26 Aug 2017, at 05:41, Michael wrote: > > Hi Jonathan, hi all, > > I would like to bring up the "WritableImage backed by DirectBuffer" > discussion again: > > I did my own experiments with WebGL and native rendering. I posted them a > while ago here on the mailing list (https://github.com/miho/VFXWebKit & > https://youtu.be/FlIrY1SlNM4). I came to the conclusion that the most > generic and most important feature that we need for JavaFX is efficient > native buffer support (basically WritableImage backed by DirectBuffer). > This allows for plugging in almost any external rendering technology and > does not involve large API redesigns. Adding OpenGL and/or WebGL could be > done as community projects. > > I find it particularly elegant to spawn separate render processes for doing > OpenGL/WebGL. This is basically what modern browsers do. WebKit is a very > complex piece of software that isn't easy to handle. In the past I had too > many bad experiences with WebKit and JavaFX. WebKit could easily tear down > the whole JVM. None of the safety-belts usually provided by Java will help > in such a case. > > I would like to suggest that we do a JavaFX meeting at JavaOne for > discussing this topic. Anyone interested? > > Regards, > Michael > > > -- > Dr. rer. nat. Michael Hoffer > > Twitter: @mihosoft > Webpage: www.mihosoft.eu > > Oracle Developer Champion > > 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 > > 2017-08-25 21:06 GMT+02:00 Jonathan Giles : > >> All, >> >> WebGL is something that is currently in the planning pipeline with a >> relatively high priority. This means it is not under active development >> yet, but we already have engineers working on the research towards this >> feature. Once this is concluded and the scope of the work better >> understood, a JEP will be filed to engage the community on this project, >> and notification will be sent to the openjfx-dev mailing list. >> >> In reference to the question on whether WebView uses WebKit rendering or >> JavaFX rendering, I believe the answer is the latter. >> >> -- Jonathan >> >> >> >>> On 25/08/17 12:12 PM, John-Val Rose wrote: >>> >>> I have a couple of questions about the implementation of WebView within >>> JavaFX. >>> >>> I understand that, at present, it is based on WebKit but does not support >>> WebGL. For our requirements, WebGL support is essential and I expect that >>> other developers would appreciate support of this kind as well. >>> >>> It appears that WebGL support will not be implemented until Java 10 at the >>> earliest, or, perhaps even later. As we know, this could be several years >>> away so I would like to offer my time to work on implementing WebGL >>> support >>> ASAP so that it can be released to the community as part of an incremental >>> Java 9 release. >>> >>> How do you feel about this suggestion? >>> >>> Also, could you please let me know that if the current WebView is just a >>> wrapper around WebKit and uses native WebKit rendering, or is it actually >>> using the JavaFX API itself to do the rendering within the JavaFX >>> rendering >>> pipeline? >>> >>> *Graciously,* >>> >>> *John-Val Rose* >>> *Chief Scientist/Architect* >>> *Rosethorn Technology* >>> *Australia* >>> >> >> From james.graham at oracle.com Sat Aug 26 00:22:18 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 25 Aug 2017 17:22:18 -0700 Subject: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: Message-ID: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> Hi Laurent, I'm just reading through the code now to get a handle on the nature of the changes...(and starting with the 2D version)... [D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != 0)? [D]Dasher.java - why is there a new goto_starting() which is only used from one place? To be able to add final to the parameters? [D]Dasher.java, line 268ish - why move the call to out.moveto() down a line? [D]Stroker.java, line 170ish - you added final to the float params, but not the double [D]Stroker.java, line 196ish - why are ROUND treated differently. You have a question on that as well in a comment. [D]Stroker.java, line 196ish - CAP_SQUARE would require more than lw/2 padding. I think it needs lw*sqrt(2)/2 padding. I would think the padding would be (max of the CAP/JOIN values below): CAP_BUTT - lw/2 CAP_ROUND - lw/2 CAP_SQUARE - lw/2 * sqrt(2) JOIN_BEVEL - lw/2 JOIN_ROUND - lw/2 JOIN_MITER - max(lw/2, miter_limit * lw) In other words: - lw/2 by default - if CAP_SQUARE then multiply that by sqrt(2) - if JOIN_MITER then max it with limit I'm still looking through the management of the closed path detection coordinates, but I thought I'd get at least these questions out first before the weekend... ...jim On 8/25/17 1:09 PM, Laurent Bourg?s wrote: > Hi, > > Please review Marlin/FX upgrades that provide an efficient path clipper in > Stroker (float / double variants) fixing the bug JDK-8184429 > > > Marlin2D patch (jdk10): > http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.0/ > MarlinFX patch (openjfx10): > http://cr.openjdk.java.net/~lbourges/marlinFX/marlin-080.0/ > > Path Clipper in (D)Stroker: > - it uses outcode computation (cohen - sutherland) for segment edges (2 for > lines, 3 for quads, 4 for cubics) > - it opens the path when a segment is invisible ie special moveTo() and > ignore invisible joins; it does not compute any intersection (line / > curve), it just skips useless segment for better performance and accuracy > - the ClosedPathDetector is needed to infer if the path is closed or not > (call to closePath) to produce caps when appropriate. It reuses the former > PolyStack (moved into Helper classes) to store the forward segments > - the clip rectangle is adjusted either in Stroker but also in > Transformer2D to take into account the mitter limit, stroker width and also > the Renderer offset > > That's why it can not be applied to closed paths (fill operations) as the > path must remain closed in such case (concave polygon). > This could be implemented later as it needs to insert corner points when > needed to avoid artefacts; so the algorithm seem more complicated to me. > > Marlin2D / FX Patches are slightly different to handle the Renderer offsets. > > I tested these patches against my MapBench test with a small clip and > several affine transforms: it does not produce any artefact (0 pixel > difference between clip=true/false) > > PS: I also improved the accuracy of Renderer's AFD by using the kaham > compensated-sum approach (later patch) > > Cheers, > Laurent Bourg?s > From stnordstrom at gmail.com Sat Aug 26 13:15:33 2017 From: stnordstrom at gmail.com (Sten Nordstrom) Date: Sat, 26 Aug 2017 13:15:33 +0000 Subject: WebView and WebGL In-Reply-To: References: Message-ID: Hi Michael, all, Just want to state my support for Michael's "Direct backed WritableImage". Having a way to do natively-backed rendering is IMO the most important feature still missing from FX. This is an area where QT is still way ahead with it's OpenGL/OpenGL ES integration. Having something like a direct-WritableImage implementation would also make it easier to implement a video viewer using native decoder libs. Personally I find this approach much more powerful than the existing FX 3D and media streaming features, which are (especially 3D) limited in their capabilities. I will be at JavaOne this year, so if there is any interest in meeting up and talking JavaFX I'm in! Best regards, Sten Nordstr?m On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: > Hi Jonathan, hi all, > > I would like to bring up the "WritableImage backed by DirectBuffer" > discussion again: > From swpalmer at gmail.com Sat Aug 26 13:46:06 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 26 Aug 2017 09:46:06 -0400 Subject: WebView and WebGL In-Reply-To: References: Message-ID: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> +1 ... to Any high performance way to get images from native code to the screen in a JavaFX app. I filed an enhancement request many years ago for a method to supply portions of the media pipeline for the media player APIs. I've also been asking for some way to get at a native surface context. Be it DirectX, OpenGL, Metal,... even just a native window handle. Scott > On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: > > Hi Michael, all, > > Just want to state my support for Michael's "Direct backed WritableImage". > Having a way to do natively-backed rendering is IMO the most important > feature still missing from FX. This is an area where QT is still way ahead > with it's OpenGL/OpenGL ES integration. > > Having something like a direct-WritableImage implementation would also make > it easier to implement a video viewer using native decoder libs. Personally > I find this approach much more powerful than the existing FX 3D and media > streaming features, which are (especially 3D) limited in their > capabilities. > > I will be at JavaOne this year, so if there is any interest in meeting up > and talking JavaFX I'm in! > > Best regards, > > Sten Nordstr?m > >> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >> >> Hi Jonathan, hi all, >> >> I would like to bring up the "WritableImage backed by DirectBuffer" >> discussion again: >> From prasanta.sadhukhan at oracle.com Mon Aug 28 08:53:50 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 28 Aug 2017 14:23:50 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: References: <23734583-9a2e-be4a-a18c-fd1d08a8d23c@oracle.com> Message-ID: <7452f5e1-a764-37e9-d757-2600afc964bb@oracle.com> I have incorporated the logic to make sure the events are dispatched in sequence, ie if the event is not first in sequence, then it will made to wait till it is the first event or till it is disposed. Modified webrev http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ Regards Prasanta On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >> Now, since here FX App thread itself is the dispatch thread, we can >> be sure the events are dispatched in sequence and dispose is checked >> below after EDT. > > Why we can sure about this? If the SequencedEvents were created in one > order but dispatch() for each were called in other order then the > sequenced will not be preserved? > >> >> I have tested with couple of singleThread testcase without any issue. >> >> Regards >> Prasanta >> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta, Kevin. >>> >>> I have two notes. >>> ? - Does this option is really supported? If it is supported we >>> should evaluate all usage of EventDispatchThread because in this >>> mode the dispatch thread is not EDT. For example I am not sure that >>> we can skip the code which expects EventDispatchThread. >>> ? - We have the similar pattern: "EventQueue.isDispatchThread() -> >>> cast(EventDispatchThread)" in some other places like in >>> DefaultKeyboardFocusManager. >>> >>> -----prasanta.sadhukhan at oracle.com? wrote: >>> >>>> Hi All, >>>> >>>> Please review this fix >>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>> for an fx issue >>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>> >>>> More info in JBS. >>>> >>>> Regards >>>> Prasanta >> > > From bourges.laurent at gmail.com Mon Aug 28 21:09:00 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 28 Aug 2017 23:09:00 +0200 Subject: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> Message-ID: Hi Jim, Thanks for your comments, it helped refining the webrev. Here are my answers: 2017-08-26 2:22 GMT+02:00 Jim Graham : > [D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != > 0)? > As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx != 0) as it looks more obvious. For me, (firstSegIdx > 0) indicates that the sign has a particular meaning and that firstSegIdx may be negative. > [D]Dasher.java - why is there a new goto_starting() which is only used > from one place? To be able to add final to the parameters? > For inlining purposes, the JITWatch jarscan tool reported that this (hotspot) method is larger than 325 byte codes so I wanted to split it in smaller parts. > [D]Dasher.java, line 268ish - why move the call to out.moveto() down a > line? > To set the needsMoveTo flag just below the condition: if (needsMoveTo) { needsMoveTo = false; ...} > [D]Stroker.java, line 170ish - you added final to the float params, but > not the double > Fixed. I also fixed all (D)PathConsumer2D methods overriden in Dasher, Stroker & Renderer. > [D]Stroker.java, line 196ish - why are ROUND treated differently. You > have a question on that as well in a comment. > I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control points (cubics) to approximate a circle. I fixed the constant estimation according to the math formula. > [D]Stroker.java, line 196ish - CAP_SQUARE would require more than lw/2 > padding. I think it needs lw*sqrt(2)/2 padding. > Exactly, good point ! I would think the padding would be (max of the CAP/JOIN values below): > CAP_BUTT - lw/2 > CAP_ROUND - lw/2 > CAP_SQUARE - lw/2 * sqrt(2) > JOIN_BEVEL - lw/2 > JOIN_ROUND - lw/2 > JOIN_MITER - max(lw/2, miter_limit * lw) > > In other words: > - lw/2 by default > - if CAP_SQUARE then multiply that by sqrt(2) > - if JOIN_MITER then max it with limit > I agree your new rules. I fixed the (D)Stroker init() methods according the latter rules and tested again. Probably I should write a new Clip test rendering Z shapes with all (cap / join) combinations and their bounds aligned to the Stroker's outside clip rules. Here is an updated webrev (Marlin2D only): http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/ PS: I can send you an updated MarlinFX patch (when you need it). Cheers, Laurent > I'm still looking through the management of the closed path detection > coordinates, but I thought I'd get at least these questions out first > before the weekend... > > ...jim > > On 8/25/17 1:09 PM, Laurent Bourg?s wrote: > >> Hi, >> >> Please review Marlin/FX upgrades that provide an efficient path clipper in >> Stroker (float / double variants) fixing the bug JDK-8184429 >> >> >> >> Marlin2D patch (jdk10): >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.0/ >> MarlinFX patch (openjfx10): >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlin-080.0/ >> >> Path Clipper in (D)Stroker: >> - it uses outcode computation (cohen - sutherland) for segment edges (2 >> for >> lines, 3 for quads, 4 for cubics) >> - it opens the path when a segment is invisible ie special moveTo() and >> ignore invisible joins; it does not compute any intersection (line / >> curve), it just skips useless segment for better performance and accuracy >> - the ClosedPathDetector is needed to infer if the path is closed or not >> (call to closePath) to produce caps when appropriate. It reuses the former >> PolyStack (moved into Helper classes) to store the forward segments >> - the clip rectangle is adjusted either in Stroker but also in >> Transformer2D to take into account the mitter limit, stroker width and >> also >> the Renderer offset >> >> That's why it can not be applied to closed paths (fill operations) as the >> path must remain closed in such case (concave polygon). >> This could be implemented later as it needs to insert corner points when >> needed to avoid artefacts; so the algorithm seem more complicated to me. >> >> Marlin2D / FX Patches are slightly different to handle the Renderer >> offsets. >> >> I tested these patches against my MapBench test with a small clip and >> several affine transforms: it does not produce any artefact (0 pixel >> difference between clip=true/false) >> >> PS: I also improved the accuracy of Renderer's AFD by using the kaham >> compensated-sum approach (later patch) >> >> Cheers, >> Laurent Bourg?s >> >> -- -- Laurent Bourg?s From james.graham at oracle.com Tue Aug 29 00:58:55 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 28 Aug 2017 17:58:55 -0700 Subject: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> Message-ID: <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> Hi Laurent, On 8/28/17 2:09 PM, Laurent Bourg?s wrote: > Hi Jim, > > Thanks for your comments, it helped refining the webrev. > > Here are my answers: > > 2017-08-26 2:22 GMT+02:00 Jim Graham >: > > [D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != 0)? > > As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx!= 0) as it looks more obvious. > For me, (firstSegIdx > 0) indicates that the sign has a particular meaning and that firstSegIdxmay be negative. Interesting, I'm used to != 0 being only used in contexts where the value might have some specific reason for being negative, but I can see why you did that. > [D]Stroker.java, line 196ish - why are ROUND treated differently.? You have a question on that as well in a comment. > > I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control points (cubics) to approximate a circle. I > fixed the constant estimation according to the math formula. The control points don't control how far the path gets from the line, though - that measurement is arbitrary compared to the clipping operation. The correct distance from the vertex to the edge of the drawn path is lw/2. > I agree your new rules. > I fixed the (D)Stroker init() methods according the latter rules and tested again. Looks good. > Probably I should write a new Clip test rendering Z shapes with all? (cap / join) combinations and their bounds aligned > to the Stroker's outside clip rules. > > Here is an updated webrev (Marlin2D only): > http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/ > > PS: I can send you an updated MarlinFX patch (when you need it). Not yet until I've had a chance to review the guts of the algorithm. So far I've only looked at a few boundary changes. I'll get to that soon... ...jim From sergey.bylokhov at oracle.com Wed Aug 30 06:11:56 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Aug 2017 23:11:56 -0700 (PDT) Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode Message-ID: Hi, Prasanta. Can you please provide some description on how the SecondaryLoop will work when it will run on Appkit thread? Is it possible to get a deadlock here, since appkit will be blocked? > sequence, ie if the event is not first in sequence, then it will made > to > wait till it is the first event or till it is disposed. Note that the new code (unlike lines 139-150) also waits 1 second, so we can get a situation when only one event will be dispatched per second, which is not we want to do. I am not sure how often we create SequencedEvent but creating one thread per dispatch look inefficient. > > Modified webrev > http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ > > Regards > Prasanta > On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: > > Hi, Prasanta. > > > > On 16.08.2017 3:33, Prasanta Sadhukhan wrote: > >> Now, since here FX App thread itself is the dispatch thread, we can > > >> be sure the events are dispatched in sequence and dispose is > checked > >> below after EDT. > > > > Why we can sure about this? If the SequencedEvents were created in > one > > order but dispatch() for each were called in other order then the > > sequenced will not be preserved? > > > >> > >> I have tested with couple of singleThread testcase without any > issue. > >> > >> Regards > >> Prasanta > >> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: > >>> Hi, Prasanta, Kevin. > >>> > >>> I have two notes. > >>> ? - Does this option is really supported? If it is supported we > >>> should evaluate all usage of EventDispatchThread because in this > >>> mode the dispatch thread is not EDT. For example I am not sure > that > >>> we can skip the code which expects EventDispatchThread. > >>> ? - We have the similar pattern: "EventQueue.isDispatchThread() -> > > >>> cast(EventDispatchThread)" in some other places like in > >>> DefaultKeyboardFocusManager. > >>> > >>> -----prasanta.sadhukhan at oracle.com? wrote: > >>> > >>>> Hi All, > >>>> > >>>> Please review this fix > >>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ > >>>> for an fx issue > >>>> https://bugs.openjdk.java.net/browse/JDK-8088132 > >>>> > >>>> More info in JBS. > >>>> > >>>> Regards > >>>> Prasanta > >> > > > > From prasanta.sadhukhan at oracle.com Wed Aug 30 08:11:33 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 30 Aug 2017 13:41:33 +0530 Subject: [10] RFR: JDK-8129747:SwingFXUtils.fromFXImage seems to have a bug inside Message-ID: Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8129747/webrev.00/ for fx issue https://bugs.openjdk.java.net/browse/JDK-8129747 More info in JBS. Regards Prasanta From bourges.laurent at gmail.com Thu Aug 31 07:43:56 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 31 Aug 2017 09:43:56 +0200 Subject: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> Message-ID: Jim, FYI I am working on a more general clipper for filled shapes (only non zero winding rule) that ignores useless segments on left / right sides but leaves the path closed for filling primitives. It is more tricky... to handle turning points (corners) but I think it could be applied later to the Stroker case to avoid opening the path (and require ClosedPathDetector). Should I look at the Area class that performs such clipping but is known to be extremely slow ? If you think it is useful, I could optimize it as I did in Marlin (array caching...). What is your opinion ? Is Area used in the java2d pipeline ? That would improve the overall performance. PS: I wonder if curves should be subdivided at inflexion / root points in this (too) basic fill pipeline to improve cubic / quad accuracy (as it is the case in Stroker) and have monotonic curves. I studied AFD accuracy (inc/dec thresholds) but did not try curve subdivision to guarantee the special point accuracy (cups...) Hope you will have time soon to look at the webrev, your feedback may help a lot. Cheers, Laurent Le 29 ao?t 2017 2:58 AM, "Jim Graham" a ?crit : Hi Laurent, On 8/28/17 2:09 PM, Laurent Bourg?s wrote: > Hi Jim, > > Thanks for your comments, it helped refining the webrev. > > Here are my answers: > > 2017-08-26 2:22 GMT+02:00 Jim Graham james.graham at oracle.com>>: > > > [D]Dasher.java - why the changes from (firstSegIdx > 0) to > (firstSegIdx != 0)? > > As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx!= 0) as > it looks more obvious. > > For me, (firstSegIdx > 0) indicates that the sign has a particular meaning > and that firstSegIdxmay be negative. > Interesting, I'm used to != 0 being only used in contexts where the value might have some specific reason for being negative, but I can see why you did that. [D]Stroker.java, line 196ish - why are ROUND treated differently. You > have a question on that as well in a comment. > > I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control > points (cubics) to approximate a circle. I fixed the constant estimation > according to the math formula. > The control points don't control how far the path gets from the line, though - that measurement is arbitrary compared to the clipping operation. The correct distance from the vertex to the edge of the drawn path is lw/2. I agree your new rules. > I fixed the (D)Stroker init() methods according the latter rules and > tested again. > Looks good. Probably I should write a new Clip test rendering Z shapes with all (cap / > join) combinations and their bounds aligned to the Stroker's outside clip > rules. > > Here is an updated webrev (Marlin2D only): > http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/ > > PS: I can send you an updated MarlinFX patch (when you need it). > Not yet until I've had a chance to review the guts of the algorithm. So far I've only looked at a few boundary changes. I'll get to that soon... ...jim From james.graham at oracle.com Thu Aug 31 19:45:13 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 31 Aug 2017 12:45:13 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> Message-ID: <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> Hi Laurent, Area is overkill for this as it tries to find exact intersection points of arbitrary geometry. You simply need something that will trace accurately around the outside of a clip to get from an exit point back to an entry point. That is a much simpler operation. The performance issues with Area, btw, have nothing to do with array caching, they have to do with the numerical instabilities in performing an operation which boils down to be numerically equivalent to solving a 9th order equation. While you are welcome to investigate that, it will involve a much different set of techniques than what was applied to Marlin... :( Also, I thought that the Renderer already did basic clipping along the lines that you indicate. It does that on a per-segment basis, but all it would take is a simple test at the top of quadTo() and curveTo() to completely reject all curves that lie outside the fill region (and simply shadow any part that is entirely to the left so that we maintain the proper crossings count)... ...jim On 8/31/17 12:43 AM, Laurent Bourg?s wrote: > Jim, > > FYI I am working on a more general clipper for filled shapes (only non zero winding rule) that ignores useless segments > on left / right sides but leaves the path closed for filling primitives. > > It is more tricky... to handle turning points (corners) but I think it could be applied later to the Stroker case to > avoid opening the path (and require ClosedPathDetector). > > Should I look at the Area class that performs such clipping but is known to be extremely slow ? If you think it is > useful, I could optimize it as I did in Marlin (array caching...). What is your opinion ? Is Area used in the java2d > pipeline ? That would improve the overall performance. > > PS: I wonder if curves should be subdivided at inflexion / root points in this (too) basic fill pipeline to improve > cubic / quad accuracy (as it is the case in Stroker) and have monotonic curves. > I studied AFD accuracy (inc/dec thresholds) but did not try curve subdivision to guarantee the special point accuracy > (cups...) > > Hope you will have time soon to look at the webrev, your feedback may help a lot. > > Cheers, > Laurent > > Le?29 ao?t 2017 2:58 AM, "Jim Graham" > a ?crit?: > > Hi Laurent, > > > On 8/28/17 2:09 PM, Laurent Bourg?s wrote: > > Hi Jim, > > Thanks for your comments, it helped refining the webrev. > > Here are my answers: > > 2017-08-26 2:22 GMT+02:00 Jim Graham > >>: > > > ? ? [D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != 0)? > > As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx!= 0) as it looks more obvious. > > For me, (firstSegIdx > 0) indicates that the sign has a particular meaning and that firstSegIdxmay be negative. > > > Interesting, I'm used to != 0 being only used in contexts where the value might have some specific reason for being > negative, but I can see why you did that. > > > ? ? [D]Stroker.java, line 196ish - why are ROUND treated differently.? You have a question on that as well in a > comment. > > I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control points (cubics) to approximate a > circle. I fixed the constant estimation according to the math formula. > > > The control points don't control how far the path gets from the line, though - that measurement is arbitrary > compared to the clipping operation.? The correct distance from the vertex to the edge of the drawn path is lw/2. > > > I agree your new rules. > I fixed the (D)Stroker init() methods according the latter rules and tested again. > > > Looks good. > > > Probably I should write a new Clip test rendering Z shapes with all? (cap / join) combinations and their bounds > aligned to the Stroker's outside clip rules. > > Here is an updated webrev (Marlin2D only): > http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/ > > > PS: I can send you an updated MarlinFX patch (when you need it). > > > Not yet until I've had a chance to review the guts of the algorithm.? So far I've only looked at a few boundary > changes.? I'll get to that soon... > > ? ? ? ? ? ? ? ? ? ? ? ? ...jim > > From chris.bensen at oracle.com Thu Aug 31 19:58:55 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 31 Aug 2017 12:58:55 -0700 Subject: [10] Review request: 8187059 Update VS Projects Message-ID: Victor, Please review this change to upgrade the native projects to the latest version of VS 2017: JIRA: https://bugs.openjdk.java.net/browse/JDK-8187059 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8187059/webrev.00/ Chris From james.graham at oracle.com Thu Aug 31 20:02:20 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 31 Aug 2017 13:02:20 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> Message-ID: <0efaa797-20b6-e67a-db3e-42e2a83a269d@oracle.com> To be clear, all that would be needed in cubicTo would be: if (y0 > bot && y1 > bot && y2 > bot && y3 > bot) { xy0 = xy3; return; } if (y0 < top && y1 < top && y2 < top && y3 < top) { xy0 = xy3; return; } if (x0 > rgt && x1 > rgt && x2 > rgt && x3 > rgt) { xy0 = xy3; return; } if (x0 < lft && x1 < lft && x2 < lft && x3 < lft) { // Needed to keep incoming crossings counts from the left accurate addLine(x0, y0, x3, y3); x0 = x3; y0 = y3; return; } // (Or this could be expressed as nested ifs: if (y0 < bot || ... || y3 < bot) { if (y0 > top || ... || y3 > top) { if (x0 < rgt || ... || x3 < rgt) { if (x0 > lft || ... || x3 > lft) { DDA stuff } else { addLine(x0,y0,x3,y3); } } } } x0 = x3; y0 = y3; Can a pre-filter save any more work than that? Note that if any coordinate isn't trivially rejected by these tests then you are going to have to do some kind of work to follow the curve to figure out which pieces are in or out and I think that the DDA stuff is just as good as any other technique for accomplishing that and since we have to do the DDA stuff anyway, we can just piggy-back off of that. When it calls addLine(), we will reject each of its pieces individually... ...jim On 8/31/17 12:45 PM, Jim Graham wrote: > Hi Laurent, > > Area is overkill for this as it tries to find exact intersection points of arbitrary geometry.?? You simply need > something that will trace accurately around the outside of a clip to get from an exit point back to an entry point. That > is a much simpler operation. > > The performance issues with Area, btw, have nothing to do with array caching, they have to do with the numerical > instabilities in performing an operation which boils down to be numerically equivalent to solving a 9th order equation. > While you are welcome to investigate that, it will involve a much different set of techniques than what was applied to > Marlin...? :( > > Also, I thought that the Renderer already did basic clipping along the lines that you indicate.? It does that on a > per-segment basis, but all it would take is a simple test at the top of quadTo() and curveTo() to completely reject all > curves that lie outside the fill region (and simply shadow any part that is entirely to the left so that we maintain the > proper crossings count)... > > ??????????? ...jim > > On 8/31/17 12:43 AM, Laurent Bourg?s wrote: >> Jim, >> >> FYI I am working on a more general clipper for filled shapes (only non zero winding rule) that ignores useless >> segments on left / right sides but leaves the path closed for filling primitives. >> >> It is more tricky... to handle turning points (corners) but I think it could be applied later to the Stroker case to >> avoid opening the path (and require ClosedPathDetector). >> >> Should I look at the Area class that performs such clipping but is known to be extremely slow ? If you think it is >> useful, I could optimize it as I did in Marlin (array caching...). What is your opinion ? Is Area used in the java2d >> pipeline ? That would improve the overall performance. >> >> PS: I wonder if curves should be subdivided at inflexion / root points in this (too) basic fill pipeline to improve >> cubic / quad accuracy (as it is the case in Stroker) and have monotonic curves. >> I studied AFD accuracy (inc/dec thresholds) but did not try curve subdivision to guarantee the special point accuracy >> (cups...) >> >> Hope you will have time soon to look at the webrev, your feedback may help a lot. >> >> Cheers, >> Laurent >> >> Le?29 ao?t 2017 2:58 AM, "Jim Graham" > a ?crit?: >> >> ??? Hi Laurent, >> >> >> ??? On 8/28/17 2:09 PM, Laurent Bourg?s wrote: >> >> ??????? Hi Jim, >> >> ??????? Thanks for your comments, it helped refining the webrev. >> >> ??????? Here are my answers: >> >> ??????? 2017-08-26 2:22 GMT+02:00 Jim Graham >> ??????? >>: >> >> >> ???????? ? ? [D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != 0)? >> >> ??????? As firstSegIdx is initialized to 0, I prefer testing (firstSegIdx!= 0) as it looks more obvious. >> >> ??????? For me, (firstSegIdx > 0) indicates that the sign has a particular meaning and that firstSegIdxmay be negative. >> >> >> ??? Interesting, I'm used to != 0 being only used in contexts where the value might have some specific reason for being >> ??? negative, but I can see why you did that. >> >> >> ???????? ? ? [D]Stroker.java, line 196ish - why are ROUND treated differently.? You have a question on that as well in a >> ??????? comment. >> >> ??????? I found the answer: C = 4/3 * (SQRT(2) - 1) is used to compute the control points (cubics) to approximate a >> ??????? circle. I fixed the constant estimation according to the math formula. >> >> >> ??? The control points don't control how far the path gets from the line, though - that measurement is arbitrary >> ??? compared to the clipping operation.? The correct distance from the vertex to the edge of the drawn path is lw/2. >> >> >> ??????? I agree your new rules. >> ??????? I fixed the (D)Stroker init() methods according the latter rules and tested again. >> >> >> ??? Looks good. >> >> >> ??????? Probably I should write a new Clip test rendering Z shapes with all? (cap / join) combinations and their bounds >> ??????? aligned to the Stroker's outside clip rules. >> >> ??????? Here is an updated webrev (Marlin2D only): >> ??????? http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.1/ >> ??????? >> >> ??????? PS: I can send you an updated MarlinFX patch (when you need it). >> >> >> ??? Not yet until I've had a chance to review the guts of the algorithm.? So far I've only looked at a few boundary >> ??? changes.? I'll get to that soon... >> >> ???? ? ? ? ? ? ? ? ? ? ? ? ? ...jim >> >> From bourges.laurent at gmail.com Thu Aug 31 20:34:06 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 31 Aug 2017 22:34:06 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> Message-ID: Hi Jim, I am answering your first message: Area is overkill for this as it tries to find exact intersection points of arbitrary geometry. You simply need something that will trace accurately around the outside of a clip to get from an exit point back to an entry point. That is a much simpler operation. OK, I started such approach but as it skips segments on the left side, it will not preserve crossing counts for the even-odd winding rule, I suppose. The key point is to reduce the edges / crossings processed by the Renderer in the left and right sides of the clip at every scanlines. For example, it will be worth when rendering a large text as a transformed shapes as many letter (closed paths) will be out the L/R sides... Top/Bottom clipping in Renderer already ignores such edges (except for curves). Moreover I agree Marlin does not need a proper path clipper (intersections) but just needs skipping useless segments like a path simplifier as I did in the Stroker. Another case: you provided a Test class using a path made with 10000 line segments on the left side. If it is converted by createStrokedShape(), then the Renderer will again deal with thousands crossings and it will be slow again. Also, I thought that the Renderer already did basic clipping along the lines that you indicate. It does that on a per-segment basis, but all it would take is a simple test at the top of quadTo() and curveTo() to completely reject all curves that lie outside the fill region (and simply shadow any part that is entirely to the left so that we maintain the proper crossings count)... Agreed but closed subpaths can also be ignored on either left or right sides like circles, letters... What do you mean by shadow any part on the left ? For the Even-odd filling rule, I think it needs exact segment intersections on the left side, so I am focused on the Non-zero filling rule for now. Finally I tried two approach: - basic subpath outside test (derived from the ClosedPathDetector) to ignore closed sub-paths outside of the clip. - more general clipper that follows the path, detect enter/exit the clip but it needs to insert/remove corner points. I am improving this latter approach. Thanks for your advices, Laurent From james.graham at oracle.com Thu Aug 31 23:15:05 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 31 Aug 2017 16:15:05 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> Message-ID: <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> First, consider what is handled inside the guts of the Renderer process. - It doesn't need to process any segments above or below the clip, they have no impact on the rendered pieces inside the clip - It needs to process segments that are out-left only in so far as it needs to come up with a proper crossings count for the first pixel inside the clip, nothing else about that geometry matters - It needs to process segments inside the left-right part of the clip on any scanline it is computing and it needs to know the X locations of each crossing and how the crossing count affects insideness and outsideness - It can stop processing when it reaches the right edge of the clip as the crossings out there have no impact on anything that will be rendered All of this is already computed on a segment-by-segment basis inside addLine(). The only thing missing for curves is that they might be rejected in their entirety, or we might be able to pare them down to only the pieces that need to be processed. Currently they will be rejected as they feed their pieces to addLine() and it rejects each segment in turn, but we might be able to short circuit the process by looking at their control points up front before we run DDA on them. If a curve is entirely out/below/right, then Renderer can outright reject it and doesn't need to deal with connecting pieces of the path, it is only concerned about what ends up in its list of segments - nothing else. A pre-filter noticing the same thing about that segment will know that the result that it wants is for the Renderer to ignore it, but it will need to deal with complicated logic of how to omit that segment in a way that the sub-path/close-path logic of the Renderer is managed correctly. In other words, it has work to do because it isn't simply inside the Renderer where we can drop path pieces on the floor with impunity. If a curve is more complicated in how it interacts with the top/bot/left/right clip coordinates, then it might still be rejected, or it might need to be partially rendered. Something is going to need to do some computation to figure that out. If we try to do those computations before we get to the Renderer, then whatever computations we use to do that will likely be just as complicated as the DDA work done inside the Renderer. That work as a "pre-filter" will also be complicated in that it will then need to express its results as a "simplified, but connected" path rather than simply dropping pieces on the floor as the Renderer can do. Now, it is possible that we could sub-divide a curve that has no simple out-code rejection criteria - for example a curve that starts above the clip, but horizontally "over" it, extends around the upper-right corner of the clip to a position that is to the right of the clip, but within its vertical bounds. Such a curve would not be rejected by any "all Yright" tests. It might be true that you could cut it at some point on the curve (and you might even be lucky enough that a midpoint cut would suffice) and each half of the curve would then pass the rejection criteria, but you'd have to analyze the curve to figure that out. It is just as likely that while the control points follow the pattern I outlined at the start of this paragraph, the actual traced outline goes inside the clip. You won't know until you perform some calculations. In the meantime, the Renderer already does a pretty fast DDA subsection of the curve and those pieces are then rejected by addLine() each in turn. How sure can you be that you can find a computation for such curves that will be successful in enough cases that you will save time over DDA? How often are curves even in this particular situation in the first place? If only .1% of curves ever benefit from this analysis then you might slow down the common case to be slightly faster in a rare case. Finally, if there is some calculation that could be performed on such "not immediately rejectable, but possibly outside" curves to simplify their processing, the best place for those calculations is still in the Renderer where its response to finding a piece of a curve that is trivially rejectable is to just skip it, rather than a pre-filter which will have to worry about how to connect the path around the skipped pieces. So, in the end, I don't see any situation - including any calculation that you think could help reject pieces faster - that would be better served as a filter run ahead of Renderer that can't be more optimally done by adding code to the Renderer and simply dropping pieces on the floor...? On 8/31/17 1:34 PM, Laurent Bourg?s wrote: > Another case: you provided a Test class using a path made with 10000 line segments on the left side. If it is converted > by createStrokedShape(), then the Renderer will again deal with thousands crossings and it will be slow again. Such a case will already be handled by the clipping in the Stroker, though - work that you've already done in these webrevs. > Also, I thought that the Renderer already did basic clipping along the lines that you indicate.? It does that on a > per-segment basis, but all it would take is a simple test at the top of quadTo() and curveTo() to completely reject > all curves that lie outside the fill region (and simply shadow any part that is entirely to the left so that we > maintain the proper crossings count)... > > Agreed but closed subpaths can also be ignored on either left or right sides like circles, letters... > What do you mean by shadow any part on the left ? The only thing that is interesting about pieces of the path that are to the left of the clip are how they contribute to the winding count at the left edge of the clip. They can all be replaced by segments that simply have the same Y range and a fixed X coordinate of left-epsilon (actually, even epsilon==0 works fine). This can be accomplished using addLine(Ystart, clipLeftX, Yend, clipLeftX). It makes the inner loop process a segment to compute the count, though, but you need that count somehow. > For the Even-odd filling rule, I think it needs exact segment intersections on the left side, so I am focused on the > Non-zero filling rule for now. They are identical. All that matters is that you have the proper starting winding count as you enter the clip from the left. They could be replaced by either a segment with the same "Y range" as I mention above, or they could be replaced by having a value in the segments list that is "starting count", so if you have a segment that is out-left and it goes from Y=10 to Y=20, you simply add (or subtract for reversed lines) one to the "starting count" field for all scanlines from 10->20. > Finally I tried two approach: > - basic subpath outside test (derived from the ClosedPathDetector) to ignore closed sub-paths outside of the clip. > - more general clipper that follows the path, detect enter/exit the clip but it needs to insert/remove corner points. I > am improving this latter approach. Consider that your filter that works ahead of the Renderer will need to deal with the following issues: - detecting if the segments are out-top/bottom/right and drop them - A filter will then need to worry how to connect those paths back to the rest - Renderer can just drop them, end of story - detecting if the segments are out-left and manage the winding counts - A filter will need to manage that plus it will have to connect the paths - Renderer can just do addLine() or adjust "scanline-starting-count", end of story - worrying about paths that loop around the entire clip, perhaps winding several times around the clip before they dive back into the clip rectangle - A filter has to construct a meaningful path to represent that same outcome - Renderer just discards all pieces that aren't out-left and just manages the "starting count" for just the out-left parts If you look at it, you will find that a clip filter for filling paths is a super-set of, with more work required than, proper early rejection logic inside the Renderer fooTo() methods... ...jim From james.graham at oracle.com Thu Aug 31 23:37:57 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 31 Aug 2017 16:37:57 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: I had another thought here. If you have some plan where you can identify incoming paths as "probably benefiting from more aggressive clipping logic" vs others that are classified as "most likely will have little to no clipping" and you want to avoid the overhead of having the early-rejection clipping logic on all paths, then a simple tweak to the design of the Renderer would make it much easier. Right now Renderer is both a "bag of segments with a scan-line sampling loop" and it is also a PathConsumer2D. If you want to insert something ahead of it, it makes logical sense to have that delegating class communicate downstream to the Renderer via PathConsumer2D. But, we could remove the PathConsumer2D from Renderer and turn it into just a "bag of segments" that is managed by an external PathConsumer2D helper class. Basically, take all of the PC2D methods in Renderer and move them into an UnclippedFiller class - just cut and paste. The new class will need a pointer to a Renderer object and it will only call r.addLine() and r.fooBreakIntoLines*() calls. It would actually be a very small class since the PC2D interface was such a tiny portion of what Renderer implemented. The new helper class will manage all sub-path/moveto/close-path awareness on its own with the Renderer being unaware of such distinctions. This should be computationally identical to the Renderer we have now - no new methods are inserted, they are just moved to a different class. But by separating out the PC2D methods into a separate class, we have the flexibility to have different ways for the PC2D chain to interact with the Renderer. This would let us create an analogous sister class - ClippedFiller - that does the same thing, but adds some early rejection computations as well. This is a simpler design than what you are attempting now because its output is only "segments to add to the bag of segments", not "well-behaved PC2D paths". But, if there is no easy way to identify paths up front as "we should pre-clip this" or "not" then this isn't really needed - just add the necessary logic to Renderer instead... ...jim On 8/31/17 4:15 PM, Jim Graham wrote: > First, consider what is handled inside the guts of the Renderer process. > > - It doesn't need to process any segments above or below the clip, they have no impact on the rendered pieces inside the > clip > - It needs to process segments that are out-left only in so far as it needs to come up with a proper crossings count for > the first pixel inside the clip, nothing else about that geometry matters > - It needs to process segments inside the left-right part of the clip on any scanline it is computing and it needs to > know the X locations of each crossing and how the crossing count affects insideness and outsideness > - It can stop processing when it reaches the right edge of the clip as the crossings out there have no impact on > anything that will be rendered > > All of this is already computed on a segment-by-segment basis inside addLine(). > > The only thing missing for curves is that they might be rejected in their entirety, or we might be able to pare them > down to only the pieces that need to be processed.? Currently they will be rejected as they feed their pieces to > addLine() and it rejects each segment in turn, but we might be able to short circuit the process by looking at their > control points up front before we run DDA on them. > > If a curve is entirely out/below/right, then Renderer can outright reject it and doesn't need to deal with connecting > pieces of the path, it is only concerned about what ends up in its list of segments - nothing else.? A pre-filter > noticing the same thing about that segment will know that the result that it wants is for the Renderer to ignore it, but > it will need to deal with complicated logic of how to omit that segment in a way that the sub-path/close-path logic of > the Renderer is managed correctly.? In other words, it has work to do because it isn't simply inside the Renderer where > we can drop path pieces on the floor with impunity. > > If a curve is more complicated in how it interacts with the top/bot/left/right clip coordinates, then it might still be > rejected, or it might need to be partially rendered.? Something is going to need to do some computation to figure that > out.? If we try to do those computations before we get to the Renderer, then whatever computations we use to do that > will likely be just as complicated as the DDA work done inside the Renderer.? That work as a "pre-filter" will also be > complicated in that it will then need to express its results as a "simplified, but connected" path rather than simply > dropping pieces on the floor as the Renderer can do. > > Now, it is possible that we could sub-divide a curve that has no simple out-code rejection criteria - for example a > curve that starts above the clip, but horizontally "over" it, extends around the upper-right corner of the clip to a > position that is to the right of the clip, but within its vertical bounds.? Such a curve would not be rejected by any > "all Yright" tests.? It might be true that you could cut it at some point on the curve (and you might > even be lucky enough that a midpoint cut would suffice) and each half of the curve would then pass the rejection > criteria, but you'd have to analyze the curve to figure that out.? It is just as likely that while the control points > follow the pattern I outlined at the start of this paragraph, the actual traced outline goes inside the clip.? You won't > know until you perform some calculations.? In the meantime, the Renderer already does a pretty fast DDA subsection of > the curve and those pieces are then rejected by addLine() each in turn.? How sure can you be that you can find a > computation for such curves that will be successful in enough cases that you will save time over DDA?? How often are > curves even in this particular situation in the first place?? If only .1% of curves ever benefit from this analysis then > you might slow down the common case to be slightly faster in a rare case. > > Finally, if there is some calculation that could be performed on such "not immediately rejectable, but possibly outside" > curves to simplify their processing, the best place for those calculations is still in the Renderer where its response > to finding a piece of a curve that is trivially rejectable is to just skip it, rather than a pre-filter which will have > to worry about how to connect the path around the skipped pieces. > > So, in the end, I don't see any situation - including any calculation that you think could help reject pieces faster - > that would be better served as a filter run ahead of Renderer that can't be more optimally done by adding code to the > Renderer and simply dropping pieces on the floor...? > > On 8/31/17 1:34 PM, Laurent Bourg?s wrote: >> Another case: you provided a Test class using a path made with 10000 line segments on the left side. If it is >> converted by createStrokedShape(), then the Renderer will again deal with thousands crossings and it will be slow again. > > Such a case will already be handled by the clipping in the Stroker, though - work that you've already done in these > webrevs. > >> ??? Also, I thought that the Renderer already did basic clipping along the lines that you indicate.? It does that on a >> ??? per-segment basis, but all it would take is a simple test at the top of quadTo() and curveTo() to completely reject >> ??? all curves that lie outside the fill region (and simply shadow any part that is entirely to the left so that we >> ??? maintain the proper crossings count)... >> >> Agreed but closed subpaths can also be ignored on either left or right sides like circles, letters... >> What do you mean by shadow any part on the left ? > > The only thing that is interesting about pieces of the path that are to the left of the clip are how they contribute to > the winding count at the left edge of the clip.? They can all be replaced by segments that simply have the same Y range > and a fixed X coordinate of left-epsilon (actually, even epsilon==0 works fine).? This can be accomplished using > addLine(Ystart, clipLeftX, Yend, clipLeftX).? It makes the inner loop process a segment to compute the count, though, > but you need that count somehow. > >> For the Even-odd filling rule, I think it needs exact segment intersections on the left side, so I am focused on the >> Non-zero filling rule for now. > > They are identical.? All that matters is that you have the proper starting winding count as you enter the clip from the > left.? They could be replaced by either a segment with the same "Y range" as I mention above, or they could be replaced > by having a value in the segments list that is "starting count", so if you have a segment that is out-left and it goes > from Y=10 to Y=20, you simply add (or subtract for reversed lines) one to the "starting count" field for all scanlines > from 10->20. > >> Finally I tried two approach: >> - basic subpath outside test (derived from the ClosedPathDetector) to ignore closed sub-paths outside of the clip. >> - more general clipper that follows the path, detect enter/exit the clip but it needs to insert/remove corner points. >> I am improving this latter approach. > > Consider that your filter that works ahead of the Renderer will need to deal with the following issues: > > - detecting if the segments are out-top/bottom/right and drop them > ?? - A filter will then need to worry how to connect those paths back to the rest > ?? - Renderer can just drop them, end of story > - detecting if the segments are out-left and manage the winding counts > ?? - A filter will need to manage that plus it will have to connect the paths > ?? - Renderer can just do addLine() or adjust "scanline-starting-count", end of story > - worrying about paths that loop around the entire clip, perhaps winding several times around the clip before they dive > back into the clip rectangle > ?? - A filter has to construct a meaningful path to represent that same outcome > ?? - Renderer just discards all pieces that aren't out-left and > ???? just manages the "starting count" for just the out-left parts > > If you look at it, you will find that a clip filter for filling paths is a super-set of, with more work required than, > proper early rejection logic inside the Renderer fooTo() methods... > > ??????????????? ...jim From james.graham at oracle.com Thu Aug 31 23:55:19 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 31 Aug 2017 16:55:19 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: <9ea129dd-b50c-9c55-efd8-c0e9e09547b9@oracle.com> I want to elaborate on winding count issues for segments to the left of the clip for both winding modes. All curves have the property that the winding count of any sample point to the right of them is identical to the winding count of a line from their starting point to their ending point. Consider a quad. If it is monotonic, then the observation should be fairly obvious as the curve only ever has one crossing for any scanline and only the X location of that crossing varies and it only varies within the bounds of the X coordinates of all of 3 defining points. Once you are to the right of all 3 X coordinates, the winding count is uniformly a single value over the entire Y range of the (monotonic) quad. Consider a quad with a vertical reversal. If one of the endpoints is higher than the other, then in the area between the Y coordinates of the endpoints it will increase or decrease the winding count by only 1, and the sign of that winding count change will be identical to a segment that connects the two endpoints. For the rest of the quad, the part where it doubles back on itself, those 2 parts of the path cancel each other out. You either have a downward portion that curves into an upward portion, or vice versa. In both cases, that portion has a resulting winding count of 0 because the direction of those 2 parts of the curve are opposite. A cubic is more complicated with more cases to consider, but if you diagram it out you can see that the winding count contribution off to the right of the cubic will be identical in all cases to the winding count contribution of a line segment joining the two endpoints. You can have up to 3 reversals, but all reversals that are above or below the end points will be paired with each other and all reversals within the Y range of the end points will either result in 1 or 3 competing pieces and the 1 or the majority of the 3 will be in the same direction/sign as the direction/sign of the segment between the endpoints. If there are 3 then 2 will cancel out and the remaining one will be the same direction as the endpoint line segment. So, all path segments, regardless of line/quad/cubic that lie entirely to the left of the clip have identical winding count to a simple line segment. And with the proper winding count computed, the winding mode has no impact, the same winding count is appropriate and accurate whether the entire path is EO or NZ... ...jim On 8/31/17 4:15 PM, Jim Graham wrote: >> For the Even-odd filling rule, I think it needs exact segment intersections on the left side, so I am focused on the >> Non-zero filling rule for now. > > They are identical.? All that matters is that you have the proper starting winding count as you enter the clip from the > left.? They could be replaced by either a segment with the same "Y range" as I mention above, or they could be replaced > by having a value in the segments list that is "starting count", so if you have a segment that is out-left and it goes > from Y=10 to Y=20, you simply add (or subtract for reversed lines) one to the "starting count" field for all scanlines > from 10->20.