From kevin.rushforth at oracle.com Tue May 2 00:21:49 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 May 2017 17:21:49 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline Message-ID: <5907D11D.20609@oracle.com> This review is being cross-posted to both openjfx-dev and jigsaw-dev. Please review the proposed fix for: https://bugs.openjdk.java.net/browse/JDK-8177566 http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ Details of the fix as well as notes to reviewers are in the bug report [1] (e.g., I've also generated separate webrevs for the fix itself, the doc changes, and the test changes). -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 From Alan.Bateman at oracle.com Tue May 2 13:04:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 May 2017 14:04:52 +0100 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5907D11D.20609@oracle.com> References: <5907D11D.20609@oracle.com> Message-ID: On 02/05/2017 01:21, Kevin Rushforth wrote: > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 > http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ > > Details of the fix as well as notes to reviewers are in the bug report > [1] (e.g., I've also generated separate webrevs for the fix itself, > the doc changes, and the test changes). Overall I think the approach is okay but I wonder how easy it will be for joe developer to understand. By this I mean the description in the javadoc is lengthy and I wonder if it might be better to split up the two "solutions" so that it the choice is clearer. Related is that the IAE thrown by MethodHelper.invoke could make it clear that the package is not exported. -Alan. From kevin.rushforth at oracle.com Tue May 2 15:09:39 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 02 May 2017 08:09:39 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: References: <5907D11D.20609@oracle.com> Message-ID: <5908A133.4020808@oracle.com> I presume you are talking about the short description I added to the beans classes and to the select binding methods (and, for that matter, the *PropertyValueFactory classes)? I agree that it does seem a bit terse, so you are right that developers may have a hard time understanding it. Without duplicating the "deploying an application as a module" section from the Introduction to FXML -- which would seem out of place in a JavaBeansXXXX class description or a selectXXXX() method description -- can you think of a good way to make it more clear? Btw, the following is the IAE exception that will be thrown: java.lang.IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base This is basically the same IAE message that would happen if we were to invoke the method directly. -- Kevin Alan Bateman wrote: > On 02/05/2017 01:21, Kevin Rushforth wrote: > >> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >> >> Please review the proposed fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8177566 >> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >> >> Details of the fix as well as notes to reviewers are in the bug >> report [1] (e.g., I've also generated separate webrevs for the fix >> itself, the doc changes, and the test changes). > Overall I think the approach is okay but I wonder how easy it will be > for joe developer to understand. By this I mean the description in the > javadoc is lengthy and I wonder if it might be better to split up the > two "solutions" so that it the choice is clearer. Related is that the > IAE thrown by MethodHelper.invoke could make it clear that the package > is not exported. > > -Alan. From David.Hill at Oracle.com Tue May 2 15:52:48 2017 From: David.Hill at Oracle.com (David Hill) Date: Tue, 02 May 2017 11:52:48 -0400 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: References: <5907D11D.20609@oracle.com> Message-ID: <5908AB50.8080504@Oracle.com> Current: All classes and properties used in a select-binding have to be declared public. Additionally, if any class is in a named module, then the module must |open| the containing package for that class to at least the |javafx.base| module (or |export| the containing package unconditionally). Suggestion: All classes and properties used in a select-binding have to be declared public. If any class is in a named module, then the module or package containing the class needs to be open or include |javafx.base in the export list.| any better ? On 5/2/17, 9:04 AM, Alan Bateman wrote: > On 02/05/2017 01:21, Kevin Rushforth wrote: > >> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >> >> Please review the proposed fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8177566 >> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >> >> Details of the fix as well as notes to reviewers are in the bug report [1] (e.g., I've also generated separate webrevs for the fix itself, the doc changes, and the test changes). > Overall I think the approach is okay but I wonder how easy it will be for joe developer to understand. By this I mean the description in the javadoc is lengthy and I wonder if it might be better to split up the two "solutions" so that it the choice is clearer. Related is that the IAE thrown by MethodHelper.invoke could make it clear that the package is not exported. > > -Alan. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Tue May 2 16:04:07 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 02 May 2017 09:04:07 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5908AB50.8080504@Oracle.com> References: <5907D11D.20609@oracle.com> <5908AB50.8080504@Oracle.com> Message-ID: <5908ADF7.5020803@oracle.com> David Hill wrote: > > Current: > All classes and properties used in a select-binding have to be > declared public. Additionally, if any class is in a named module, then > the module must |open| > > the containing package for that class to at least the |javafx.base| > module (or |export| > > the containing package unconditionally). > > Suggestion: > > All classes and properties used in a select-binding have to be > declared public. If any class is in a named module, then the module or > package containing the class needs to be open or include |javafx.base > in the export list.| > > any better ? > It might read better, but is now incorrect. It is not sufficient for a module to *export* the package to javafx.base. Nor is it required that the module be *open* unconditionally. Rather it must *open* the package to javafx.base. The alternative is to export it unconditionally as public API of the app: WORKS: module foo.app { opens com.foo to javafx.base; } WORKS: module foo.app { exports com.foo; } WORKS (but overkill): module foo.app { opens com.foo; } FAILS: module foo.app { exports com.foo to javafx.base; } FAILS: module foo.app { /* does not export or open com.foo */ } -- Kevin > > > On 5/2/17, 9:04 AM, Alan Bateman wrote: >> On 02/05/2017 01:21, Kevin Rushforth wrote: >> >>> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >>> >>> Please review the proposed fix for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177566 >>> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >>> >>> Details of the fix as well as notes to reviewers are in the bug >>> report [1] (e.g., I've also generated separate webrevs for the fix >>> itself, the doc changes, and the test changes). >> Overall I think the approach is okay but I wonder how easy it will be >> for joe developer to understand. By this I mean the description in >> the javadoc is lengthy and I wonder if it might be better to split up >> the two "solutions" so that it the choice is clearer. Related is that >> the IAE thrown by MethodHelper.invoke could make it clear that the >> package is not exported. >> >> -Alan. > > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey the world." > -- George Santayana (1863 - 1952) > From Thorsten_Fischer at gmx.de Tue May 2 18:51:34 2017 From: Thorsten_Fischer at gmx.de (Thorsten_Fischer at gmx.de) Date: Tue, 2 May 2017 20:51:34 +0200 Subject: Should there be getter methods in LabeledSkinBase? Message-ID: <0MKcdH-1d7Y2M0WIh-001vRd@mail.gmx.com> Hi there, I?m currently working on creating a new JavaFX control with jdk 9 (latest ea release). Now I have a question regarding the ?LabeledSkinBase? class. (I?d like implement something similar to a TitledPane and the corresponding Skin class extends from LabeledSkinBase). I?d really like to rely on some parts of LabeledSkinBase (like the JDK?s TitledPaneSkin class does in its update() method), but I cannot access the package protected declared fields, like ?LabeledText text". Why are there no getters implemented for them? This means, that your own shipped controls may rely on the LabeledSkinBase class and I sadly cannot. On a field like "Node graphic" I can work around myself with getSkinnable().getGraphic() but imho this als would be cleaner with specific getters supplied. This applies also to utility methods of LabeledSkinBase, like isIgnoreGraphic(). I know that even with JDK-8077916 (making UI controls Skins public API) your goal was to make only the minimal necessary API public, but in this case I cannot reuse this class at all.. Or do I miss something? Are there public alternatives? Should I even use this class? Would be nice if someone can give his/her opinion on this one. Thank you in advance, Thorsten From kevin.rushforth at oracle.com Tue May 2 19:44:24 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 02 May 2017 12:44:24 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5908ADF7.5020803@oracle.com> References: <5907D11D.20609@oracle.com> <5908AB50.8080504@Oracle.com> <5908ADF7.5020803@oracle.com> Message-ID: <5908E198.302@oracle.com> Is this any better? It adds an example module-info.java file to JavaBeanXXX as is done in the FXML class. ------------------------------------------------------------------------------------------ NOTE: If the Java Bean class is in a named module, then it must be reflectively accessible to the javafx.base module. A class is reflectively accessible if the module "opens" the containing package to at least the javafx.base module. For example, if com.foo.MyBeanClass is in the foo.app module, the module-info.java might look like this: module foo.app { opens com.foo to javafx.base; } Alternatively, a class is also reflectively accessible if the module "exports" the containing package unconditionally. ------------------------------------------------------------------------------------------ Comments? -- Kevin Kevin Rushforth wrote: > > > David Hill wrote: >> >> Current: >> All classes and properties used in a select-binding have to be >> declared public. Additionally, if any class is in a named module, >> then the module must |open| >> >> the containing package for that class to at least the |javafx.base| >> module (or |export| >> >> the containing package unconditionally). >> >> Suggestion: >> >> All classes and properties used in a select-binding have to be >> declared public. If any class is in a named module, then the module >> or package containing the class needs to be open or include >> |javafx.base in the export list.| >> >> any better ? >> > > It might read better, but is now incorrect. It is not sufficient for a > module to *export* the package to javafx.base. Nor is it required that > the module be *open* unconditionally. Rather it must *open* the > package to javafx.base. The alternative is to export it > unconditionally as public API of the app: > > WORKS: module foo.app { opens com.foo to javafx.base; } > WORKS: module foo.app { exports com.foo; } > WORKS (but overkill): module foo.app { opens com.foo; } > > FAILS: module foo.app { exports com.foo to javafx.base; } > FAILS: module foo.app { /* does not export or open com.foo */ } > > > -- Kevin > > > > > > >> >> >> On 5/2/17, 9:04 AM, Alan Bateman wrote: >>> On 02/05/2017 01:21, Kevin Rushforth wrote: >>> >>>> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >>>> >>>> Please review the proposed fix for: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8177566 >>>> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >>>> >>>> Details of the fix as well as notes to reviewers are in the bug >>>> report [1] (e.g., I've also generated separate webrevs for the fix >>>> itself, the doc changes, and the test changes). >>> Overall I think the approach is okay but I wonder how easy it will >>> be for joe developer to understand. By this I mean the description >>> in the javadoc is lengthy and I wonder if it might be better to >>> split up the two "solutions" so that it the choice is clearer. >>> Related is that the IAE thrown by MethodHelper.invoke could make it >>> clear that the package is not exported. >>> >>> -Alan. >> >> >> -- >> David Hill >> Java Embedded Development >> >> "A man's feet should be planted in his country, but his eyes should >> survey the world." >> -- George Santayana (1863 - 1952) >> From mandy.chung at oracle.com Tue May 2 20:59:13 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 May 2017 13:59:13 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5907D11D.20609@oracle.com> References: <5907D11D.20609@oracle.com> Message-ID: Hi Kevin, > On May 1, 2017, at 5:21 PM, Kevin Rushforth wrote: > > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 > http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ First pass of comment: javafx.base/src/main/java/com/sun/javafx/property/PropertyReference.java 196 try { 197 return (ReadOnlyProperty)MethodHelper.invoke(propertyGetter, bean, (Object[])null); 198 } catch (Exception ex) { 199 throw new RuntimeException(ex); 200 } Do you have an example exception thrown if the package is not open to javafx.base? IAE is thrown by MethodHelper.invoke. Are you detecting this and throw an exception with friendlier message? javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java javafx.web/src/main/java/com/sun/webkit/MethodHelper.java 45 public static Object invoke(Method m, Object obj, Object[] params) To avoid 3 ModuleHelper classes, the invoke method can take the callerModule argument to replace this line: 56 final Module thisModule = MethodHelper.class.getModule(); javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java There are a few other public methods which I think JavaFX doesn?t need and can be removed. Mandy From kevin.rushforth at oracle.com Tue May 2 21:22:49 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 02 May 2017 14:22:49 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: References: <5907D11D.20609@oracle.com> Message-ID: <5908F8A9.1000205@oracle.com> inline Mandy Chung wrote: > Hi Kevin, > > >> On May 1, 2017, at 5:21 PM, Kevin Rushforth wrote: >> >> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >> >> Please review the proposed fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8177566 >> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >> > > First pass of comment: > > javafx.base/src/main/java/com/sun/javafx/property/PropertyReference.java > 196 try { > 197 return (ReadOnlyProperty)MethodHelper.invoke(propertyGetter, bean, (Object[])null); > > 198 } catch (Exception ex) { > 199 throw new RuntimeException(ex); > 200 } > > Do you have an example exception thrown if the package is not > open to javafx.base? IAE is thrown by MethodHelper.invoke. > Are you detecting this and throw an exception with friendlier > message? > Here is the message: IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base It is roughly the same message that any similar illegal access would generate (e.g., we get similar error messages when FXML tries to call setAccessible for a field annotated with @FXML if the module is not "open" to javafx.fxml). > javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java > javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java > javafx.web/src/main/java/com/sun/webkit/MethodHelper.java > 45 public static Object invoke(Method m, Object obj, Object[] params) > > To avoid 3 ModuleHelper classes, the invoke method can take > the callerModule argument to replace this line: > 56 final Module thisModule = MethodHelper.class.getModule(); > I'm fairly certain that won't work. Module::addOpens is caller sensitive and will only work when called from the module in question. > javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java > There are a few other public methods which I think JavaFX doesn?t > need and can be removed. > Yes, I could do this to reduce the public footprint of the class. To minimize the diffs between the original and our copy, I might just comment out the "public". That would also make it easier to add them back in a future version (e.g., to eventually get rid of all dependency on sun.reflect.misc). Thoughts? -- Kevin > Mandy From jonathan.giles at oracle.com Tue May 2 21:32:40 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 3 May 2017 09:32:40 +1200 Subject: Should there be getter methods in LabeledSkinBase? In-Reply-To: <0MKcdH-1d7Y2M0WIh-001vRd@mail.gmx.com> References: <0MKcdH-1d7Y2M0WIh-001vRd@mail.gmx.com> Message-ID: <88ebf72b-331f-0614-1a4d-0eb245216b23@oracle.com> Thorsten, Your reference to JDK-8077916 is correct here. Our first goal was to simply get the skins into the public API in a minimal form. In some cases there was then follow-up feedback from the community regarding missing API, and there were improvements made. Your feedback here is the same, and should be turned into a jira issue for follow-up discussion (did you want to do this - if not, I can do it). For JDK 9 the ship has (essentially) sailed and we can't improve the API for LabeledSkinBase like you would like. One alternate approach is to consider composing your skin with a Label, rather than having it extend LabeledSkinBase. In the fullness of time, I would love to see these skin classes in more public use, but I can appreciate we need to do a push in the JDK 10 timeframe to fill out these gaps. Any feedback here from the community is much appreciated - file Jira issues and the API will be discussed and considered with a high priority. -- Jonathan On 3/05/17 6:51 AM, Thorsten_Fischer at gmx.de wrote: > Hi there, > > I?m currently working on creating a new JavaFX control with jdk 9 (latest ea release). Now I have a question regarding the ?LabeledSkinBase? class. (I?d like implement something similar to a TitledPane and the corresponding Skin class extends from LabeledSkinBase). > > I?d really like to rely on some parts of LabeledSkinBase (like the JDK?s TitledPaneSkin class does in its update() method), but I cannot access the package protected declared fields, like ?LabeledText text". Why are there no getters implemented for them? This means, that your own shipped controls may rely on the LabeledSkinBase class and I sadly cannot. On a field like "Node graphic" I can work around myself with getSkinnable().getGraphic() but imho this als would be cleaner with specific getters supplied. This applies also to utility methods of LabeledSkinBase, like isIgnoreGraphic(). > > I know that even with JDK-8077916 (making UI controls Skins public API) your goal was to make only the minimal necessary API public, but in this case I cannot reuse this class at all.. Or do I miss something? Are there public alternatives? Should I even use this class? Would be nice if someone can give his/her opinion on this one. > > Thank you in advance, > Thorsten > From mandy.chung at oracle.com Tue May 2 21:45:46 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 May 2017 14:45:46 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5908F8A9.1000205@oracle.com> References: <5907D11D.20609@oracle.com> <5908F8A9.1000205@oracle.com> Message-ID: > On May 2, 2017, at 2:22 PM, Kevin Rushforth wrote: > > Here is the message: > > IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base > It would be better to emit a more informative message e.g. ?javafx.base cannot access class com.foo (in module foo.app). Either exports com.foo unqualifiedly or open com.foo to javafx.base?. Also in MethodUtil::invoke 61 if (!module.isExported(packageName)) { You can do this check only if module.isNamed. > It is roughly the same message that any similar illegal access would generate (e.g., we get similar error messages when FXML tries to call setAccessible for a field annotated with @FXML if the module is not "open" to javafx.fxml). > >> javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java >> javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java >> javafx.web/src/main/java/com/sun/webkit/MethodHelper.java >> 45 public static Object invoke(Method m, Object obj, Object[] params) >> >> To avoid 3 ModuleHelper classes, the invoke method can take >> the callerModule argument to replace this line: >> 56 final Module thisModule = MethodHelper.class.getModule(); >> > > I'm fairly certain that won't work. Module::addOpens is caller sensitive and will only work when called from the module in question. > You are right. Wont?t work. >> javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java >> There are a few other public methods which I think JavaFX doesn?t >> need and can be removed. >> > > Yes, I could do this to reduce the public footprint of the class. To minimize the diffs between the original and our copy, I might just comment out the "public". That would also make it easier to add them back in a future version (e.g., to eventually get rid of all dependency on sun.reflect.misc). Thoughts? I will leave it up to you. Mandy From kevin.rushforth at oracle.com Wed May 3 14:48:43 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 May 2017 07:48:43 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: References: <5907D11D.20609@oracle.com> <5908F8A9.1000205@oracle.com> Message-ID: <5909EDCB.3030808@oracle.com> OK, I'll create a more informative message. I think it will be more clear in the message to just say that it needs to "open" the package to javafx.base, since that would be the recommendation for a package that isn't already exported unconditionally. I'll send out a new webrev this morning with all feedback incorporated. -- Kevin Mandy Chung wrote: >> On May 2, 2017, at 2:22 PM, Kevin Rushforth wrote: >> >> Here is the message: >> >> IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base >> >> > > It would be better to emit a more informative message e.g. ?javafx.base cannot access class com.foo (in module foo.app). Either exports com.foo unqualifiedly or open com.foo to javafx.base?. Also in MethodUtil::invoke > 61 if (!module.isExported(packageName)) { > You can do this check only if module.isNamed. > > >> It is roughly the same message that any similar illegal access would generate (e.g., we get similar error messages when FXML tries to call setAccessible for a field annotated with @FXML if the module is not "open" to javafx.fxml). >> >> >>> javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java >>> javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java >>> javafx.web/src/main/java/com/sun/webkit/MethodHelper.java >>> 45 public static Object invoke(Method m, Object obj, Object[] params) >>> >>> To avoid 3 ModuleHelper classes, the invoke method can take >>> the callerModule argument to replace this line: >>> 56 final Module thisModule = MethodHelper.class.getModule(); >>> >>> >> I'm fairly certain that won't work. Module::addOpens is caller sensitive and will only work when called from the module in question. >> >> > > You are right. Wont?t work. > >>> javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java >>> There are a few other public methods which I think JavaFX doesn?t >>> need and can be removed. >>> >>> >> Yes, I could do this to reduce the public footprint of the class. To minimize the diffs between the original and our copy, I might just comment out the "public". That would also make it easier to add them back in a future version (e.g., to eventually get rid of all dependency on sun.reflect.misc). Thoughts? >> > > I will leave it up to you. > Mandy > > From kevin.rushforth at oracle.com Wed May 3 14:57:08 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 May 2017 07:57:08 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5909EDCB.3030808@oracle.com> References: <5907D11D.20609@oracle.com> <5908F8A9.1000205@oracle.com> <5909EDCB.3030808@oracle.com> Message-ID: <5909EFC4.8070006@oracle.com> Forgot to respond to this: > Also in MethodUtil::invoke > 61 if (!module.isExported(packageName)) { > You can do this check only if module.isNamed. No, this check will work fine on an unnamed module. Module::isExported and Module::isOpen always return true for Module::unnamed. -- Kevin Kevin Rushforth wrote: > OK, I'll create a more informative message. I think it will be more > clear in the message to just say that it needs to "open" the package > to javafx.base, since that would be the recommendation for a package > that isn't already exported unconditionally. I'll send out a new > webrev this morning with all feedback incorporated. > > -- Kevin > > > Mandy Chung wrote: >>> On May 2, 2017, at 2:22 PM, Kevin Rushforth >>> wrote: >>> >>> Here is the message: >>> >>> IllegalAccessException: class com.sun.javafx.property.MethodHelper >>> cannot access class com.foo (in module foo.app) because module >>> foo.app does not open com.foo to javafx.base >>> >> >> It would be better to emit a more informative message e.g. >> ?javafx.base cannot access class com.foo (in module foo.app). Either >> exports com.foo unqualifiedly or open com.foo to javafx.base?. Also >> in MethodUtil::invoke >> 61 if (!module.isExported(packageName)) { >> You can do this check only if module.isNamed. >> >> >>> It is roughly the same message that any similar illegal access would >>> generate (e.g., we get similar error messages when FXML tries to >>> call setAccessible for a field annotated with @FXML if the module is >>> not "open" to javafx.fxml). >>> >>> >>>> javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java >>>> javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java >>>> javafx.web/src/main/java/com/sun/webkit/MethodHelper.java >>>> 45 public static Object invoke(Method m, Object obj, Object[] >>>> params) >>>> >>>> To avoid 3 ModuleHelper classes, the invoke method can take >>>> the callerModule argument to replace this line: 56 final >>>> Module thisModule = MethodHelper.class.getModule(); >>>> >>> I'm fairly certain that won't work. Module::addOpens is caller >>> sensitive and will only work when called from the module in question. >>> >>> >> >> You are right. Wont?t work. >> >>>> javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java >>>> There are a few other public methods which I think JavaFX doesn?t >>>> need and can be removed. >>>> >>> Yes, I could do this to reduce the public footprint of the class. To >>> minimize the diffs between the original and our copy, I might just >>> comment out the "public". That would also make it easier to add them >>> back in a future version (e.g., to eventually get rid of all >>> dependency on sun.reflect.misc). Thoughts? >>> >> >> I will leave it up to you. >> Mandy >> >> From kevin.rushforth at oracle.com Wed May 3 23:30:07 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 May 2017 16:30:07 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5907D11D.20609@oracle.com> References: <5907D11D.20609@oracle.com> Message-ID: <590A67FF.40408@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8177566 Here is the updated webrev with (I hope) all comments addressed: http://cr.openjdk.java.net/~kcr/8177566/webrev.01/complete-webrev/ For those who reviewed the earlier webrev, I have prepared delta webrevs. * Delta webrev for the fix itself (just a slight change to the error message, plus I hid the unused public methods in MethodUtil) : http://cr.openjdk.java.net/~kcr/8177566/webrev.01/delta-fix-only.00/ * No changes in the tests * Delta webrev for the doc changes: http://cr.openjdk.java.net/~kcr/8177566/webrev.01/delta-doc-only.00/ * The sparse javadocs are also updated here: http://cr.openjdk.java.net/~kcr/8177566/webrev.01/javadoc/ -- Kevin Kevin Rushforth wrote: > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 > http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ > > Details of the fix as well as notes to reviewers are in the bug report > [1] (e.g., I've also generated separate webrevs for the fix itself, > the doc changes, and the test changes). > > -- Kevin > > [1] > https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 > > From mandy.chung at oracle.com Thu May 4 00:05:28 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 May 2017 17:05:28 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <590A67FF.40408@oracle.com> References: <5907D11D.20609@oracle.com> <590A67FF.40408@oracle.com> Message-ID: Looks good. "Deploying an Application as a Module? section is duplicated in several JavaBean*Property classes. One alternative is to move it to the package summary. I have no objection to leave it as is. Mandy > On May 3, 2017, at 4:30 PM, Kevin Rushforth wrote: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8177566 > > Here is the updated webrev with (I hope) all comments addressed: > > http://cr.openjdk.java.net/~kcr/8177566/webrev.01/complete-webrev/ > > For those who reviewed the earlier webrev, I have prepared delta webrevs. > > * Delta webrev for the fix itself (just a slight change to the error message, plus I hid the unused public methods in MethodUtil) : > > http://cr.openjdk.java.net/~kcr/8177566/webrev.01/delta-fix-only.00/ > > * No changes in the tests > > * Delta webrev for the doc changes: > > http://cr.openjdk.java.net/~kcr/8177566/webrev.01/delta-doc-only.00/ > > * The sparse javadocs are also updated here: > > http://cr.openjdk.java.net/~kcr/8177566/webrev.01/javadoc/ > > -- Kevin > > > Kevin Rushforth wrote: >> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >> >> Please review the proposed fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8177566 >> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >> >> Details of the fix as well as notes to reviewers are in the bug report [1] (e.g., I've also generated separate webrevs for the fix itself, the doc changes, and the test changes). >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 >> From kevin.rushforth at oracle.com Thu May 4 00:14:14 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 May 2017 17:14:14 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: References: <5907D11D.20609@oracle.com> <590A67FF.40408@oracle.com> Message-ID: <590A7256.30406@oracle.com> Mandy Chung wrote: > Looks good. > Thank you for your help on this and for your review. > "Deploying an Application as a Module? section is duplicated in several > JavaBean*Property classes. One alternative is to move it to the package > summary. I have no objection to leave it as is. > I think I'll keep it as is for the JavaBean*Property classes. Especially since we don't have anything currently in the package summary. There might be other detailed information that could go there, too. -- Kevin > Mandy > > > >> On May 3, 2017, at 4:30 PM, Kevin Rushforth wrote: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177566 >> >> Here is the updated webrev with (I hope) all comments addressed: >> >> http://cr.openjdk.java.net/~kcr/8177566/webrev.01/complete-webrev/ >> >> For those who reviewed the earlier webrev, I have prepared delta webrevs. >> >> * Delta webrev for the fix itself (just a slight change to the error message, plus I hid the unused public methods in MethodUtil) : >> >> http://cr.openjdk.java.net/~kcr/8177566/webrev.01/delta-fix-only.00/ >> >> * No changes in the tests >> >> * Delta webrev for the doc changes: >> >> http://cr.openjdk.java.net/~kcr/8177566/webrev.01/delta-doc-only.00/ >> >> * The sparse javadocs are also updated here: >> >> http://cr.openjdk.java.net/~kcr/8177566/webrev.01/javadoc/ >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >> >>> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >>> >>> Please review the proposed fix for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177566 >>> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >>> >>> Details of the fix as well as notes to reviewers are in the bug report [1] (e.g., I've also generated separate webrevs for the fix itself, the doc changes, and the test changes). >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 >>> >>> > > From ajit.ghaisas at oracle.com Thu May 4 09:26:00 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 4 May 2017 02:26:00 -0700 (PDT) Subject: [10] Review request : JDK-8089984 : [Accessibility,CSS] Progress Indicator's Label is not visible in High Contrast Message-ID: <6a405cda-5a9e-4b10-89b7-47106522aa18@default> Hi Jonathan, Request you to review following fix : Bug : https://bugs.openjdk.java.net/browse/JDK-8089984 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8089984/webrev.0/ Regards, Ajit From greggwon at cox.net Thu May 4 15:29:14 2017 From: greggwon at cox.net (Gregg Wonderly) Date: Thu, 4 May 2017 10:29:14 -0500 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: References: <5907D11D.20609@oracle.com> <5908F8A9.1000205@oracle.com> Message-ID: <8BB9D503-D6BC-4948-A73F-D22FF5A6835E@cox.net> If there is not already such an exception, it would seem like a good idea to have an exception that formats such a message from constructor parameters providing the details so that it?s the same everywhere, and so that it can be changed in once place if needed. Gregg > On May 3, 2017, at 9:48 AM, Kevin Rushforth wrote: > > OK, I'll create a more informative message. I think it will be more clear in the message to just say that it needs to "open" the package to javafx.base, since that would be the recommendation for a package that isn't already exported unconditionally. I'll send out a new webrev this morning with all feedback incorporated. > > -- Kevin > > > Mandy Chung wrote: >>> On May 2, 2017, at 2:22 PM, Kevin Rushforth wrote: >>> >>> Here is the message: >>> >>> IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base >>> >> >> It would be better to emit a more informative message e.g. ?javafx.base cannot access class com.foo (in module foo.app). Either exports com.foo unqualifiedly or open com.foo to javafx.base?. Also in MethodUtil::invoke >> 61 if (!module.isExported(packageName)) { >> You can do this check only if module.isNamed. >> >> >>> It is roughly the same message that any similar illegal access would generate (e.g., we get similar error messages when FXML tries to call setAccessible for a field annotated with @FXML if the module is not "open" to javafx.fxml). >>> >>> >>>> javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java >>>> javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java >>>> javafx.web/src/main/java/com/sun/webkit/MethodHelper.java >>>> 45 public static Object invoke(Method m, Object obj, Object[] params) >>>> >>>> To avoid 3 ModuleHelper classes, the invoke method can take >>>> the callerModule argument to replace this line: 56 final Module thisModule = MethodHelper.class.getModule(); >>>> >>> I'm fairly certain that won't work. Module::addOpens is caller sensitive and will only work when called from the module in question. >>> >>> >> >> You are right. Wont?t work. >> >>>> javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java >>>> There are a few other public methods which I think JavaFX doesn?t >>>> need and can be removed. >>>> >>> Yes, I could do this to reduce the public footprint of the class. To minimize the diffs between the original and our copy, I might just comment out the "public". That would also make it easier to add them back in a future version (e.g., to eventually get rid of all dependency on sun.reflect.misc). Thoughts? >>> >> >> I will leave it up to you. >> Mandy >> >> From kevin.rushforth at oracle.com Thu May 4 15:37:52 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 04 May 2017 08:37:52 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <8BB9D503-D6BC-4948-A73F-D22FF5A6835E@cox.net> References: <5907D11D.20609@oracle.com> <5908F8A9.1000205@oracle.com> <8BB9D503-D6BC-4948-A73F-D22FF5A6835E@cox.net> Message-ID: <590B4AD0.4050705@oracle.com> This seems like something that could be useful, although at this point in the release we would more likely do it for JDK 10. I do note that including the class that made the illegal access is generally a good idea when that class is attempting the access on its own behalf. For frameworks such as JavaFX beans or FXML, we are making the request on behalf of an application, it wasn't as helpful to have the class itself be in the error message (which was Mandy's main point). So there are at least two cases to consider if we end up creating such a utility method. Thanks. -- Kevin Gregg Wonderly wrote: > If there is not already such an exception, it would seem like a good idea to have an exception that formats such a message from constructor parameters providing the details so that it?s the same everywhere, and so that it can be changed in once place if needed. > > Gregg > > >> On May 3, 2017, at 9:48 AM, Kevin Rushforth wrote: >> >> OK, I'll create a more informative message. I think it will be more clear in the message to just say that it needs to "open" the package to javafx.base, since that would be the recommendation for a package that isn't already exported unconditionally. I'll send out a new webrev this morning with all feedback incorporated. >> >> -- Kevin >> >> >> Mandy Chung wrote: >> >>>> On May 2, 2017, at 2:22 PM, Kevin Rushforth wrote: >>>> >>>> Here is the message: >>>> >>>> IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot access class com.foo (in module foo.app) because module foo.app does not open com.foo to javafx.base >>>> >>>> >>> It would be better to emit a more informative message e.g. ?javafx.base cannot access class com.foo (in module foo.app). Either exports com.foo unqualifiedly or open com.foo to javafx.base?. Also in MethodUtil::invoke >>> 61 if (!module.isExported(packageName)) { >>> You can do this check only if module.isNamed. >>> >>> >>> >>>> It is roughly the same message that any similar illegal access would generate (e.g., we get similar error messages when FXML tries to call setAccessible for a field annotated with @FXML if the module is not "open" to javafx.fxml). >>>> >>>> >>>> >>>>> javafx.base/src/main/java/com/sun/javafx/property/MethodHelper.java >>>>> javafx.fxml/src/main/java/com/sun/javafx/fxml/MethodHelper.java >>>>> javafx.web/src/main/java/com/sun/webkit/MethodHelper.java >>>>> 45 public static Object invoke(Method m, Object obj, Object[] params) >>>>> >>>>> To avoid 3 ModuleHelper classes, the invoke method can take >>>>> the callerModule argument to replace this line: 56 final Module thisModule = MethodHelper.class.getModule(); >>>>> >>>>> >>>> I'm fairly certain that won't work. Module::addOpens is caller sensitive and will only work when called from the module in question. >>>> >>>> >>>> >>> You are right. Wont?t work. >>> >>> >>>>> javafx.base/src/main/java/com/sun/javafx/reflect/MethodUtil.java >>>>> There are a few other public methods which I think JavaFX doesn?t >>>>> need and can be removed. >>>>> >>>>> >>>> Yes, I could do this to reduce the public footprint of the class. To minimize the diffs between the original and our copy, I might just comment out the "public". That would also make it easier to add them back in a future version (e.g., to eventually get rid of all dependency on sun.reflect.misc). Thoughts? >>>> >>>> >>> I will leave it up to you. >>> Mandy >>> >>> >>> > > From kevin.rushforth at oracle.com Thu May 4 18:37:09 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 04 May 2017 11:37:09 -0700 Subject: API docs for javafx.* modules are now included with the JDK 9 API docs Message-ID: <590B74D5.3040207@oracle.com> Some of you may have noticed already that the API docs for javafx.* modules are now included as part of the JDK 9 API docs on java.net: http://download.java.net/java/jdk9/docs/api/ The search box also works as expected to find JavaFX classes as well an any classes in the rest of the JDK. Hopefully this new unified bundle will make it easier to navigate. -- Kevin From tom.schindl at bestsolution.at Thu May 4 21:22:07 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 4 May 2017 23:22:07 +0200 Subject: javafx.scene.shape.Path (memory) inefficient PathElements Message-ID: Hi, We are currently working on a PDF-Rendering library in JavaFX and we need to draw glyphs using the JavaFX Path API (there are multiple reasons why we don't use the Text-Node and or Canvas). When drawing a page full of Text this means that we have a Path-Object with gazillions of MoveTo and CubicCurveTo elements who sum up to 30MB just to represent them in the SG because PathElements store their information in properties and forcefully intialize them in their constructor. The only public API to work around this problem is to construct a StringBuffer and use SVGPath which means: * it takes time to construct the SVG-Path-String * it takes time to parse the SVG-Path-String in JavaFX As an experiment (and because we are still on Java8 we can easily do that) was that we created our own Shape-Subclass who: * uses floats (there's no reason to use double in the SG when the backing API - Path2D - is float based) * passes the floats directly to the Path2D/NGPath API Guess what: We now need 2.5MB / page which means 27.5MB is the overhead added by the current Path-API - ouch! I think a fairly low hanging memory optimization for the PathElement would be to create properties lazy (only if someone access the property). For MoveTo this would mean the following minimal change (eg for the x-value): private DoubleProperty x; private double _x; public final void setX(double value) { if (x != null) { xProperty().set(value); } else { _x = value; u(); } } public final double getX() { return x == null ? _x : x.get(); } public final DoubleProperty xProperty() { if (x == null) { x = new DoublePropertyBase(_x) { @Override public void invalidated() { u(); } @Override public Object getBean() { return MoveTo.this; } @Override public String getName() { return "x"; } }; } return x; } I guess 99% of the code out there never access the Property so the small footprint added by the primitive field is justifiable. This still has the overhead of all the needless PathElement objects hanging around so another idea is to have a 3rd SG-Path-Type who strictly uses the float-Primitives with a similar API to Path2D (in fact it only acts as a public API to Path2D). Thoughts? Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From james.graham at oracle.com Thu May 4 21:33:37 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 4 May 2017 14:33:37 -0700 Subject: javafx.scene.shape.Path (memory) inefficient PathElements In-Reply-To: References: Message-ID: Hi Tom, Those look like good suggestions. I would file bugs in JBS and create them separately: - Bug for lazy property creation in path elements - Feature request for lower-memory paths Did you benchmark how much the lazy properties, on their own, would save your application? ...jim On 5/4/17 2:22 PM, Tom Schindl wrote: > Hi, > > We are currently working on a PDF-Rendering library in JavaFX and we > need to draw glyphs using the JavaFX Path API (there are multiple > reasons why we don't use the Text-Node and or Canvas). > > When drawing a page full of Text this means that we have a Path-Object > with gazillions of MoveTo and CubicCurveTo elements who sum up to 30MB > just to represent them in the SG because PathElements store their > information in properties and forcefully intialize them in their > constructor. > > The only public API to work around this problem is to construct a > StringBuffer and use SVGPath which means: > * it takes time to construct the SVG-Path-String > * it takes time to parse the SVG-Path-String in JavaFX > > As an experiment (and because we are still on Java8 we can easily do > that) was that we created our own Shape-Subclass who: > * uses floats (there's no reason to use double in the SG when the > backing API - Path2D - is float based) > * passes the floats directly to the Path2D/NGPath API > > Guess what: We now need 2.5MB / page which means 27.5MB is the overhead > added by the current Path-API - ouch! > > I think a fairly low hanging memory optimization for the PathElement > would be to create properties lazy (only if someone access the property). > > For MoveTo this would mean the following minimal change (eg for the > x-value): > > private DoubleProperty x; > private double _x; > > public final void setX(double value) { > if (x != null) { > xProperty().set(value); > } else { > _x = value; > u(); > } > } > > public final double getX() { > return x == null ? _x : x.get(); > } > > public final DoubleProperty xProperty() { > if (x == null) { > x = new DoublePropertyBase(_x) { > > @Override > public void invalidated() { > u(); > } > > @Override > public Object getBean() { > return MoveTo.this; > } > > @Override > public String getName() { > return "x"; > } > }; > } > return x; > } > > I guess 99% of the code out there never access the Property so the small > footprint added by the primitive field is justifiable. > > This still has the overhead of all the needless PathElement objects > hanging around so another idea is to have a 3rd SG-Path-Type who > strictly uses the float-Primitives with a similar API to Path2D (in fact > it only acts as a public API to Path2D). > > Thoughts? > > Tom > From jonathan.giles at oracle.com Thu May 4 23:19:29 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 5 May 2017 11:19:29 +1200 Subject: Commit on focus loss in ListView, TreeView, TableView, and TreeTableView Message-ID: <41a9795d-6520-756d-f978-97ef873ee2ea@oracle.com> Hi all, In the next week I have two topics to discuss, both with similar names but related to quite different functionality. The topic for today is adding the necessary API to the JavaFX UI control Cell class to enable support for 'commit on focus loss', that is, the ability to automatically commit a user-input value (into, say, a TextField inside a Cell) back into the backing data structure when the cell (or its content) looses focus. The topic for _next_ week relates to a new focus traversal API I plan to propose, related to focus traversal over all nodes in the scenegraph. At present, the cells used in ListView, TreeView, TableView, and TreeTableView all support the concept of switching between a normal state and an editing state. Due to the way cells were built, when the editing state was enabled, the developer was simply entitled to change the controls displayed to the user. The cell is never made aware of what the editing controls were, and as such has no way to know what the user has entered. Today, when focus is lost, this results in a cancel edit event being fired, the user input is dismissed, and the cell returns to its non-editing state displaying the previous data. This is less than ideal, and is what we are trying to fix here. Unfortunately, there is no way to enable this 'for free'. If we used heuristics and looked at the nodes in the cell when in the editing state, it would be error-prone. For one, what if the cell has, say, multiple TextFields? Even in the simple cases, what if the data model was not String-based, and required some conversion from String to T? What if the user had a custom cell for editing that could not be understood by the Cell? We'd have no choice but to offer some form of fallback API to support this. Therefore, my proposal is to flip this around - we introduce a single new method on the Cell class, as shown below, and then retrofit our custom cell factories (most notably the TextField*Cell classes) to implement this method, providing the commit-on-focus-loss behavior that is expected. /** * Developers of custom cell implementations should override this method when * the cell provides editing functionality, with this method returning the * user input after the user has interacted with the editing components. * The form of the returned data (wrapped in an {@link Optional}) should * be the same as the form of the underlying data model, hence the * use of the {@code T} generic type. If no value is available, or if the * value to be returned is invalid, {@code Optional.empty()} should be returned * to indicate that the commit should not proceed.. * * @return The value provided by the user into this cell when it was in its * editing state, in the form of the underlying data model. If the value * is invalid or unable to be determined, {@code Optional.empty()} should * be returned. * @since 10 */ protected Optional getEditorValue() { return Optional.empty(); } As noted, this method is already overridden by the pre-built TextField*Cell classes (so by default, users of TextFieldListCell, TextFieldTreeCell, TextFieldTableCell, and TextFieldTreeTableCell get commit on focus loss by default). Developers of custom cells who want commit on focus loss to be enabled will have to override this method. I will work to ensure that this new method is well-understood and widely known, and that all relevant documentation I can change will be changed to mention this. As part of this work, I have also developed a test app - HelloCommitOnFocusLoss - that tests this new functionality on ListView, TreeView, TableView, and TreeTableView. In all tests that I have implemented so far, I can see that commit on focus loss works in cases where the user clicks on a new row, and when they give focus to another node (by both mouse and tab key). I am happy to extend this test application with any test cases people fear may not be supported, and then we can find gaps in this implementation (or, hopefully, be pleasantly surprised that these cases are already being met). Discussion can take place in the Jira issue at [1], and the webrev with my proposed changes is at [2], although note that I have yet to develop enough unit tests for this change - as I wanted to discuss the API first. Your feedback now is much appreciated. [1] https://bugs.openjdk.java.net/browse/JDK-8089514 [2] http://cr.openjdk.java.net/~jgiles/8089514.1/ Thanks, -- Jonathan From bourges.laurent at gmail.com Fri May 5 07:45:10 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 5 May 2017 09:45:10 +0200 Subject: javafx.scene.shape.Path (memory) inefficient PathElements In-Reply-To: References: Message-ID: Hi, There is a Path2d class (double) in the javafx.graphics package used internally by prism but it is not directly accessible from the public scene API. Maybe a new public Shape implementation only wrapping a Path2d would help ? I could try making a prototype for OpenJFX10. In dec 2016, I integrated MarlinFX which uses double-precision to convert path elements so it is worth to keep double values for path coordinates. >> >> As an experiment (and because we are still on Java8 we can easily do >> that) was that we created our own Shape-Subclass who: >> * uses floats (there's no reason to use double in the SG when the >> backing API - Path2D - is float based) >> * passes the floats directly to the Path2D/NGPath API >> >> Guess what: We now need 2.5MB / page which means 27.5MB is the overhead >> added by the current Path-API - ouch! >> > Excellent proof of concept. For OpenJFX10, I except Value Types will be ready and such path elements would be the perfect candidate for Java array of structs ie packed point/segment/curve values. That would be awesome and should reduce the memory footprint to its minimum. Jim do you think that the Vahalla project would be give us such benefits ? Cheers, Laurent From semyon.sadetsky at oracle.com Sat May 6 03:28:13 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 5 May 2017 20:28:13 -0700 Subject: [10] Review request for 8179597: Handle cut and paste of 1, 2 and 4 byte characters Message-ID: <9f05f710-cc14-96eb-832f-1e1e898aa350@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8179597 webrev: http://cr.openjdk.java.net/~ssadetsky/8179597/webrev.00/ --Semyon From jmartine_1026 at yahoo.com Sun May 7 04:03:19 2017 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sun, 7 May 2017 04:03:19 +0000 (UTC) Subject: PathTransition jitter In-Reply-To: <58F0CEC5.4040401@oracle.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> <1104912949.277882.1492174200192@mail.yahoo.com> <58F0CEC5.4040401@oracle.com> Message-ID: <625366570.3956468.1494129799752@mail.yahoo.com> Looks like I am unable to update the Jira ticket so I guess I'll update the bug in here. Kevin mentioned that there is some relief if "-Djavafx.animation.fullspeed=true" VM option is used.? I notice that it does improve but not remove the problem.? Also,?the jitter?is not limited to PathTransition.? In the example below the problem is reproduced by using?Timeline and no PathTransition. Since?like this is not just an issue with PathTransition, would it be possible to bump up the priority on this?? The Jira mentions the fix is scheduled for Java 10.? Does this affect all animation in JavaFX?? Is there anyway to move objects on the screen without jitter? ??? private void pathJitterBug(Stage primaryStage) { //??????? Circle circle = new Circle(30, Color.RED); //??????? Path path = new Path(); //??????? path.getElements().add(new MoveTo(100, 100)); //??????? path.getElements().add(new LineTo(500, 100)); //??????? path.getElements().add(new LineTo(500, 500)); //??????? path.getElements().add(new LineTo(100, 500)); //??????? path.getElements().add(new LineTo(100, 100)); // //??????? PathTransition pathTransition = new PathTransition(Duration.seconds(10), path, circle); //??????? pathTransition.setCycleCount(Animation.INDEFINITE); //??????? pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); //??????? pathTransition.playFromStart(); ??????? // ??????? Circle circle2 = new Circle(20, Color.BLUE); ??????? Timeline tl = new Timeline( ??????????????? new KeyFrame(Duration.ZERO, new KeyValue(circle2.centerXProperty(), 125), new KeyValue(circle2.centerYProperty(), 125)), ??????????????? new KeyFrame(Duration.seconds(5), new KeyValue(circle2.centerXProperty(), 425), new KeyValue(circle2.centerYProperty(), 425)) ??????? ); ??????? tl.setCycleCount(Timeline.INDEFINITE); ??????? tl.setAutoReverse(true); ??????? tl.playFromStart(); ??????? // ??????? Circle circle3 = new Circle(20, Color.GREEN); ??????? Timeline tl2 = new Timeline( ??????????????? new KeyFrame(Duration.ZERO, new KeyValue(circle3.centerXProperty(), 425), new KeyValue(circle3.centerYProperty(), 125)), ??????????????? new KeyFrame(Duration.seconds(5), new KeyValue(circle3.centerXProperty(), 125), new KeyValue(circle3.centerYProperty(), 425)) ??????? ); ??????? tl2.setCycleCount(Timeline.INDEFINITE); ??????? tl2.setAutoReverse(true); ??????? tl2.playFromStart(); ??????? // ??????? Group root = new Group(); //??????? root.getChildren().addAll(circle, circle2, circle3); ??????? root.getChildren().addAll(circle2, circle3); ??????? Scene scene = new Scene(root, 600, 600); ??????? primaryStage.setTitle("Hello World!"); ??????? primaryStage.setScene(scene); ??????? primaryStage.show(); ??? } From: Kevin Rushforth To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" ; Lord Chaos Sent: Friday, April 14, 2017 9:29 AM Subject: Re: PathTransition jitter And here is the direct link in JBS: https://bugs.openjdk.java.net/browse/JDK-8178805 -- Kevin Jose Martinez wrote: > Thank you Kevin. > For those interested here is the bug report:? http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 > > > > >? ? ? From: Kevin Rushforth >? To: Jose Martinez > Cc: "openjfx-dev at openjdk.java.net" >? Sent: Thursday, April 13, 2017 7:49 AM >? Subject: Re: PathTransition jitter >? ? > One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in June 2015. You can find the ones you filed using this query: > > https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx > > -- Kevin > > > Jose Martinez wrote: >? In case it helps, below is the original workaround that was provided.? This workaround no longer has any affect. > public class FixedPane extends Group {? ? @Override >? ? public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { >? ? ? ? ? if (!tx.isTranslateOrIdentity()) { >? ? ? ? ? ? ? super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); >? ? ? ? ? } >? ? ? ? ? return super.impl_computeGeomBounds(bounds, tx); >? ? } > } > Forgot to include:? using a Windows 10 and Geforce gtx GPU. > >? ? ? From: Tom Eugelink >? To: openjfx-dev at openjdk.java.net >? Sent: Thursday, April 13, 2017 3:15 AM >? Subject: Re: PathTransition jitter >? ? > I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) > > Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. > > > On 13-4-2017 08:46, Michael Paus wrote: >? ? >? It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. > > Am 13.04.17 um 04:25 schrieb Jose Martinez: >? ? ? >? Many moons ago I complained about jittery PathTransition animation.? A bug was openned and I was provided a workaround. This was with Java 7.? I revisted the old project that lead to that initial complain, this time with Java 8.? The problem seems to be back.? I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. > Below is the test code to reproduce.? I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them.? The ImageViewstutters through the PathTransition.? I have a new laptop with 6th gen I7 and plenty of ram.? I do not think it is the hardware.? This used to besmooth like butter.? Anyone else experiencing this or can make any suggestions? > >? ? ? @Override >? ? ? public void start(Stage primaryStage) {? ? ? ? String rocketImgStr= > "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph > CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz > 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N > 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAga > kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 > NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm > letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >? ? ? ? ? Base64.Decoder decoder = Base64.getDecoder(); >? ? ? ? ? ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); >? ? ? ? ? Path path = new Path(); >? ? ? ? ? path.getElements().add(new MoveTo(100, 100)); >? ? ? ? ? path.getElements().add(new LineTo(500, 100)); >? ? ? ? ? path.getElements().add(new LineTo(500, 500)); >? ? ? ? ? path.getElements().add(new LineTo(100, 500)); >? ? ? ? ? path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); >? ? ? ? ? pathTransition.setCycleCount(Animation.INDEFINITE); > pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >? ? ? ? ? pathTransition.playFromStart();? ? ? ? Group root = new Group(); >? ? ? ? ? root.getChildren().add(iv); >? ? ? ? ? Scene scene = new Scene(root, 600, 600); >? ? ? ? ? primaryStage.setTitle("Hello World!"); >? ? ? ? ? primaryStage.setScene(scene); >? ? ? ? ? primaryStage.show(); >? ? ? } > > thanks, > jose > >? ? ? ? >? ? ? >? ? >? > > >? ? >? From peter.levart at gmail.com Sun May 7 08:37:34 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 7 May 2017 10:37:34 +0200 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <5907D11D.20609@oracle.com> References: <5907D11D.20609@oracle.com> Message-ID: <1f806cdc-a241-04aa-6e4b-0b11abb1f0a9@gmail.com> Hi Kevin, On 05/02/2017 02:21 AM, Kevin Rushforth wrote: > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 > http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ > > Details of the fix as well as notes to reviewers are in the bug report > [1] (e.g., I've also generated separate webrevs for the fix itself, > the doc changes, and the test changes). > > -- Kevin > > [1] > https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 > I think it is very unusual to handle unqualified exports as something special, different from qualified exports. I know what the reasoning is: if a package is exported unconditionally (to everyone) then it is part of public API and so the trampoline may access members of that package on behalf of anyone. But such reasoning is just a consequence of the lack of a finer-grained (per-module) access support in JavaFX. I know it is too much to ask for JDK 9, but could JavaFX in say JDK 10, given current API, somehow determine on whose behalf it is making the trampoline access? If it could, then the trampoline could allow qualified exports to be effective too. Regards, Peter From Ignatiamus at gmail.com Sun May 7 09:57:51 2017 From: Ignatiamus at gmail.com (Hermann Maier) Date: Sun, 7 May 2017 11:57:51 +0200 Subject: PathTransition jitter In-Reply-To: <625366570.3956468.1494129799752@mail.yahoo.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> <1104912949.277882.1492174200192@mail.yahoo.com> <58F0CEC5.4040401@oracle.com> <625366570.3956468.1494129799752@mail.yahoo.com> Message-ID: I can reproduce the problem as well on my system with (X)Ubuntu 16.04 64-Bit and Mesa 12.0.6, with JDK 8u131. Also, the CPU usage of the Java process and the Xorg process is increasing constantly until the application gets completely laggy and unusable (like every application that is using some JavaFX animation under Linux with the hardware renderer). This bug is already known [1], the resource leak is happening on my system too and it's very annoying (e.g. I made a game with JavaFX and realized this too late?). Thus I would suggest that raising the priority of that bug would be appropriate? However, when I use the Software Renderer there's nothing like described above, so it's really likely related to Mesa/Xorg. Cheers [1] https://bugs.openjdk.java.net/browse/JDK-8161914 Am 07.05.2017 um 06:03 schrieb Jose Martinez: > Looks like I am unable to update the Jira ticket so I guess I'll update the bug in here. > Kevin mentioned that there is some relief if "-Djavafx.animation.fullspeed=true" VM option is used. I notice that it does improve but not remove the problem. Also, the jitter is not limited to PathTransition. In the example below the problem is reproduced by using Timeline and no PathTransition. > Since like this is not just an issue with PathTransition, would it be possible to bump up the priority on this? The Jira mentions the fix is scheduled for Java 10. Does this affect all animation in JavaFX? Is there anyway to move objects on the screen without jitter? > > private void pathJitterBug(Stage primaryStage) { > // Circle circle = new Circle(30, Color.RED); > // Path path = new Path(); > // path.getElements().add(new MoveTo(100, 100)); > // path.getElements().add(new LineTo(500, 100)); > // path.getElements().add(new LineTo(500, 500)); > // path.getElements().add(new LineTo(100, 500)); > // path.getElements().add(new LineTo(100, 100)); > // > // PathTransition pathTransition = new PathTransition(Duration.seconds(10), path, circle); > // pathTransition.setCycleCount(Animation.INDEFINITE); > // pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); > // pathTransition.playFromStart(); > // > Circle circle2 = new Circle(20, Color.BLUE); > Timeline tl = new Timeline( > new KeyFrame(Duration.ZERO, new KeyValue(circle2.centerXProperty(), 125), new KeyValue(circle2.centerYProperty(), 125)), > new KeyFrame(Duration.seconds(5), new KeyValue(circle2.centerXProperty(), 425), new KeyValue(circle2.centerYProperty(), 425)) > ); > tl.setCycleCount(Timeline.INDEFINITE); > tl.setAutoReverse(true); > tl.playFromStart(); > // > Circle circle3 = new Circle(20, Color.GREEN); > Timeline tl2 = new Timeline( > new KeyFrame(Duration.ZERO, new KeyValue(circle3.centerXProperty(), 425), new KeyValue(circle3.centerYProperty(), 125)), > new KeyFrame(Duration.seconds(5), new KeyValue(circle3.centerXProperty(), 125), new KeyValue(circle3.centerYProperty(), 425)) > ); > tl2.setCycleCount(Timeline.INDEFINITE); > tl2.setAutoReverse(true); > tl2.playFromStart(); > // > Group root = new Group(); > // root.getChildren().addAll(circle, circle2, circle3); > root.getChildren().addAll(circle2, circle3); > Scene scene = new Scene(root, 600, 600); > primaryStage.setTitle("Hello World!"); > primaryStage.setScene(scene); > primaryStage.show(); > } > > > From: Kevin Rushforth > To: Jose Martinez > Cc: "openjfx-dev at openjdk.java.net" ; Lord Chaos > Sent: Friday, April 14, 2017 9:29 AM > Subject: Re: PathTransition jitter > > And here is the direct link in JBS: > > https://bugs.openjdk.java.net/browse/JDK-8178805 > > -- Kevin > > > Jose Martinez wrote: >> Thank you Kevin. >> For those interested here is the bug report: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 >> >> >> >> >> From: Kevin Rushforth >> To: Jose Martinez >> Cc: "openjfx-dev at openjdk.java.net" >> Sent: Thursday, April 13, 2017 7:49 AM >> Subject: Re: PathTransition jitter >> >> One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in June 2015. You can find the ones you filed using this query: >> >> https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx >> >> -- Kevin >> >> >> Jose Martinez wrote: >> In case it helps, below is the original workaround that was provided. This workaround no longer has any affect. >> public class FixedPane extends Group { @Override >> public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { >> if (!tx.isTranslateOrIdentity()) { >> super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); >> } >> return super.impl_computeGeomBounds(bounds, tx); >> } >> } >> Forgot to include: using a Windows 10 and Geforce gtx GPU. >> >> From: Tom Eugelink >> To: openjfx-dev at openjdk.java.net >> Sent: Thursday, April 13, 2017 3:15 AM >> Subject: Re: PathTransition jitter >> >> I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) >> >> Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. >> >> >> On 13-4-2017 08:46, Michael Paus wrote: >> >> It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. >> >> Am 13.04.17 um 04:25 schrieb Jose Martinez: >> >> Many moons ago I complained about jittery PathTransition animation. A bug was openned and I was provided a workaround. This was with Java 7. I revisted the old project that lead to that initial complain, this time with Java 8. The problem seems to be back. I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. >> Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them. The ImageViewstutters through the PathTransition. I have a new laptop with 6th gen I7 and plenty of ram. I do not think it is the hardware. This used to besmooth like butter. Anyone else experiencing this or can make any suggestions? >> >> @Override >> public void start(Stage primaryStage) { String rocketImgStr= >> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph >> CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz >> 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N >> 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAga >> kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 >> NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm >> letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >> Base64.Decoder decoder = Base64.getDecoder(); >> ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); >> Path path = new Path(); >> path.getElements().add(new MoveTo(100, 100)); >> path.getElements().add(new LineTo(500, 100)); >> path.getElements().add(new LineTo(500, 500)); >> path.getElements().add(new LineTo(100, 500)); >> path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); >> pathTransition.setCycleCount(Animation.INDEFINITE); >> pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >> pathTransition.playFromStart(); Group root = new Group(); >> root.getChildren().add(iv); >> Scene scene = new Scene(root, 600, 600); >> primaryStage.setTitle("Hello World!"); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } >> >> thanks, >> jose >> >> >> >> >> >> >> >> >> > > > > From itaisha at gmail.com Sun May 7 11:16:06 2017 From: itaisha at gmail.com (Itai) Date: Sun, 7 May 2017 14:16:06 +0300 Subject: PathTransition jitter In-Reply-To: References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> <1104912949.277882.1492174200192@mail.yahoo.com> <58F0CEC5.4040401@oracle.com> <625366570.3956468.1494129799752@mail.yahoo.com> Message-ID: Hermann - I believe this bug is due to a combination of Mesa and X.org - it seems to be resolved by using Mesa>=13.0 *and* X.org>=1.18.4 . Since this is a Linux-only bug, I don't think it's the same as the TransitionPath jitter, as it reportedly happens on Windows as well. On Sun, May 7, 2017 at 12:57 PM, Hermann Maier wrote: > I can reproduce the problem as well on my system with (X)Ubuntu 16.04 > 64-Bit and Mesa 12.0.6, with JDK 8u131. > Also, the CPU usage of the Java process and the Xorg process is increasing > constantly until the application gets completely laggy and unusable (like > every application that is using some JavaFX animation under Linux with the > hardware renderer). This bug is already known [1], the resource leak is > happening on my system too and it's very annoying (e.g. I made a game with > JavaFX and realized this too late?). Thus I would suggest that raising the > priority of that bug would be appropriate? > However, when I use the Software Renderer there's nothing like described > above, so it's really likely related to Mesa/Xorg. > > > Cheers > > [1] https://bugs.openjdk.java.net/browse/JDK-8161914 > > Am 07.05.2017 um 06:03 schrieb Jose Martinez: > > Looks like I am unable to update the Jira ticket so I guess I'll update > the bug in here. > > Kevin mentioned that there is some relief if > "-Djavafx.animation.fullspeed=true" VM option is used. I notice that it > does improve but not remove the problem. Also, the jitter is not limited > to PathTransition. In the example below the problem is reproduced by using > Timeline and no PathTransition. > > Since like this is not just an issue with PathTransition, would it be > possible to bump up the priority on this? The Jira mentions the fix is > scheduled for Java 10. Does this affect all animation in JavaFX? Is there > anyway to move objects on the screen without jitter? > > > > private void pathJitterBug(Stage primaryStage) { > > // Circle circle = new Circle(30, Color.RED); > > // Path path = new Path(); > > // path.getElements().add(new MoveTo(100, 100)); > > // path.getElements().add(new LineTo(500, 100)); > > // path.getElements().add(new LineTo(500, 500)); > > // path.getElements().add(new LineTo(100, 500)); > > // path.getElements().add(new LineTo(100, 100)); > > // > > // PathTransition pathTransition = new > PathTransition(Duration.seconds(10), path, circle); > > // pathTransition.setCycleCount(Animation.INDEFINITE); > > // pathTransition.setOrientation(PathTransition.OrientationType > .ORTHOGONAL_TO_TANGENT); > > // pathTransition.playFromStart(); > > // > > Circle circle2 = new Circle(20, Color.BLUE); > > Timeline tl = new Timeline( > > new KeyFrame(Duration.ZERO, new > KeyValue(circle2.centerXProperty(), 125), new > KeyValue(circle2.centerYProperty(), 125)), > > new KeyFrame(Duration.seconds(5), new > KeyValue(circle2.centerXProperty(), 425), new > KeyValue(circle2.centerYProperty(), 425)) > > ); > > tl.setCycleCount(Timeline.INDEFINITE); > > tl.setAutoReverse(true); > > tl.playFromStart(); > > // > > Circle circle3 = new Circle(20, Color.GREEN); > > Timeline tl2 = new Timeline( > > new KeyFrame(Duration.ZERO, new > KeyValue(circle3.centerXProperty(), 425), new > KeyValue(circle3.centerYProperty(), 125)), > > new KeyFrame(Duration.seconds(5), new > KeyValue(circle3.centerXProperty(), 125), new > KeyValue(circle3.centerYProperty(), 425)) > > ); > > tl2.setCycleCount(Timeline.INDEFINITE); > > tl2.setAutoReverse(true); > > tl2.playFromStart(); > > // > > Group root = new Group(); > > // root.getChildren().addAll(circle, circle2, circle3); > > root.getChildren().addAll(circle2, circle3); > > Scene scene = new Scene(root, 600, 600); > > primaryStage.setTitle("Hello World!"); > > primaryStage.setScene(scene); > > primaryStage.show(); > > } > > > > > > From: Kevin Rushforth > > To: Jose Martinez > > Cc: "openjfx-dev at openjdk.java.net" ; Lord > Chaos > > Sent: Friday, April 14, 2017 9:29 AM > > > Subject: Re: PathTransition jitter > > > > And here is the direct link in JBS: > > > > https://bugs.openjdk.java.net/browse/JDK-8178805 > > > > -- Kevin > > > > > > Jose Martinez wrote: > >> Thank you Kevin. > >> For those interested here is the bug report: > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 > >> > >> > >> > >> > >> From: Kevin Rushforth > >> To: Jose Martinez > >> Cc: "openjfx-dev at openjdk.java.net" > >> Sent: Thursday, April 13, 2017 7:49 AM > >> Subject: Re: PathTransition jitter > >> > >> One more thing: all bugs were transfered from the old JavaFX JIRA > intoJBS in June 2015. You can find the ones you filed using this query: > >> > >> https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx > >> > >> -- Kevin > >> > >> > >> Jose Martinez wrote: > >> In case it helps, below is the original workaround that was provided. > This workaround no longer has any affect. > >> public class FixedPane extends Group { @Override > >> public BaseBounds impl_computeGeomBounds(BaseBounds bounds, > BaseTransform tx) { > >> if (!tx.isTranslateOrIdentity()) { > >> super.impl_computeGeomBounds(bounds, > BaseTransform.IDENTITY_TRANSFORM); > >> } > >> return super.impl_computeGeomBounds(bounds, tx); > >> } > >> } > >> Forgot to include: using a Windows 10 and Geforce gtx GPU. > >> > >> From: Tom Eugelink > >> To: openjfx-dev at openjdk.java.net > >> Sent: Thursday, April 13, 2017 3:15 AM > >> Subject: Re: PathTransition jitter > >> > >> I'm seeing some very small irregularities; short hesitations and then > small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz > Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) > >> > >> Slowing the animation to 8 instead of 4 seconds, make these hiccups > better visible. They're most definitely there. > >> > >> > >> On 13-4-2017 08:46, Michael Paus wrote: > >> > >> It runs perfectly smooth on my old MacBook Pro from 2012 with JDK > 8u152 ea. > >> > >> Am 13.04.17 um 04:25 schrieb Jose Martinez: > >> > >> Many moons ago I complained about jittery PathTransition animation. > A bug was openned and I was provided a workaround. This was with Java 7. I > revisted the old project that lead to that initial complain, this time with > Java 8. The problem seems to be back. I could not find the old bugreport, > since I think the JavaFX team is not using the same bug trackingsite. > >> Below is the test code to reproduce. I tried it using JDK 8_64 u5, > u11, u25, u112, u121 and the problem occurs with all of them. The > ImageViewstutters through the PathTransition. I have a new laptop with 6th > gen I7 and plenty of ram. I do not think it is the hardware. This used to > besmooth like butter. Anyone else experiencing this or can make any > suggestions? > >> > >> @Override > >> public void start(Stage primaryStage) { String > rocketImgStr= > >> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAs > YAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVN > nVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8i > giAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwf > ACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsA > HvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYC > dmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhE > AGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUp > AAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4o > zkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t > 6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZr > IPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/P > f14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41 > EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWH > TA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCA > AARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzb > AdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph > >> CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgx > UopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQ > ZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNj > y7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0 > EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMy > J7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPk > G+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2h > tlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX > 6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgq > tip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtV > qp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gs > IWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0 > TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1F > u1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+ > 6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzw > dL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZ > LTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz > >> 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna > 0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+ > 6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2D > PjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60v > Wdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+ > VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/ > MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzr > bZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mG > Lw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5 > qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1 > weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtG > I2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq > 9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2Qqb > oVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0 > dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoL > BtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG > 4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N > >> 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLd > tWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvtt > Xa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/ > p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaR > ptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19f > i753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV > 7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/ > 1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+ > 3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L > 96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/ > erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/ > 2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAg > OkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/ > e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuK > gJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/ > er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+K > PeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQ > fwXxAGQD8Aeg5ssGIQGzgXLApUJAga > >> kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3 > DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xd > fClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLI > tUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltb > V45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/ > 39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2K > VColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywO > BoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZIm > L4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD > 4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv913 > 36rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+ > 2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi > 8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtX > C4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvso > Gkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWh > Rj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6 > F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 > >> NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j > 2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV > 5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0 > fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5 > WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQy > SXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGK > FSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+ > orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUND > Q8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/ > bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwD > sTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/Wye > vVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+ > 4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvv > ZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqq > OuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5Jq > RZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJ > E3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm > >> letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0 > mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE > 6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJ > IkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9N > fWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++s > hsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+ > 6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2O > x2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6 > DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/ > JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+ > CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; > >> Base64.Decoder decoder = Base64.getDecoder(); > >> ByteArrayInputStream rocketInputStream = new > ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new > ImageView(new Image(rocketInputStream)); > >> Path path = new Path(); > >> path.getElements().add(new MoveTo(100, 100)); > >> path.getElements().add(new LineTo(500, 100)); > >> path.getElements().add(new LineTo(500, 500)); > >> path.getElements().add(new LineTo(100, 500)); > >> path.getElements().add(new LineTo(100, 100)); PathTransition > pathTransition = new PathTransition(Duration.seconds(4), path, iv); > >> pathTransition.setCycleCount(Animation.INDEFINITE); > >> pathTransition.setOrientation(PathTransition.OrientationType > .ORTHOGONAL_TO_TANGENT); > >> pathTransition.playFromStart(); Group root = new > Group(); > >> root.getChildren().add(iv); > >> Scene scene = new Scene(root, 600, 600); > >> primaryStage.setTitle("Hello World!"); > >> primaryStage.setScene(scene); > >> primaryStage.show(); > >> } > >> > >> thanks, > >> jose > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > From jmartine_1026 at yahoo.com Sun May 7 15:42:08 2017 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sun, 7 May 2017 15:42:08 +0000 (UTC) Subject: PathTransition jitter In-Reply-To: <625366570.3956468.1494129799752@mail.yahoo.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> <1104912949.277882.1492174200192@mail.yahoo.com> <58F0CEC5.4040401@oracle.com> <625366570.3956468.1494129799752@mail.yahoo.com> Message-ID: <694206415.4133867.1494171728025@mail.yahoo.com> In previous post I mentioned Kevin, I meant Jim.? In the last update from Jim for this bug, he mentioned that it could be related to synchronization and frame rate vs rendering.? https://bugs.openjdk.java.net/browse/JDK-8178805 I tried to run tests to prove this out, but was not able to notice any anomalies with either the frame rate nor the MasterTimer.? The method used to test the MasterTimer by passing it an AnimationTimer that stores the delta time.? A hiccup in the MasterTimer should be noticed?from the AnimationTimer by storing the delta times and plotting them.? While gathering those times, might as well collect the instant FPS and plot those as well.? Would the synchronization issue be notied through either of these methods or am I off the mark here?? The program in the link below does what I mentioned.? When you run it either wait for the program to plot the points or click on the black background to force the points to draw on the screen (red is delta time?from the MasterTimer and light green is the FPS).? I like to wait till the jitter happens then click the background right away.? After running many tests I do not see any hiccups in the plots that match the noticed occurrences of jitter.? Does this mean that it could be a render issue? https://pastebin.com/XjiqE9yu From: Jose Martinez To: Kevin Rushforth Cc: "openjfx-dev at openjdk.java.net" ; Lord Chaos Sent: Sunday, May 7, 2017 12:03 AM Subject: Re: PathTransition jitter Looks like I am unable to update the Jira ticket so I guess I'll update the bug in here. Kevin mentioned that there is some relief if "-Djavafx.animation.fullspeed=true" VM option is used.? I notice that it does improve but not remove the problem.? Also,?the jitter?is not limited to PathTransition.? In the example below the problem is reproduced by using?Timeline and no PathTransition. Since?like this is not just an issue with PathTransition, would it be possible to bump up the priority on this?? The Jira mentions the fix is scheduled for Java 10.? Does this affect all animation in JavaFX?? Is there anyway to move objects on the screen without jitter? ??? private void pathJitterBug(Stage primaryStage) { //??????? Circle circle = new Circle(30, Color.RED); //??????? Path path = new Path(); //??????? path.getElements().add(new MoveTo(100, 100)); //??????? path.getElements().add(new LineTo(500, 100)); //??????? path.getElements().add(new LineTo(500, 500)); //??????? path.getElements().add(new LineTo(100, 500)); //??????? path.getElements().add(new LineTo(100, 100)); // //??????? PathTransition pathTransition = new PathTransition(Duration.seconds(10), path, circle); //??????? pathTransition.setCycleCount(Animation.INDEFINITE); //??????? pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); //??????? pathTransition.playFromStart(); ??????? // ??????? Circle circle2 = new Circle(20, Color.BLUE); ??????? Timeline tl = new Timeline( ??????????????? new KeyFrame(Duration.ZERO, new KeyValue(circle2.centerXProperty(), 125), new KeyValue(circle2.centerYProperty(), 125)), ??????????????? new KeyFrame(Duration.seconds(5), new KeyValue(circle2.centerXProperty(), 425), new KeyValue(circle2.centerYProperty(), 425)) ??????? ); ??????? tl.setCycleCount(Timeline.INDEFINITE); ??????? tl.setAutoReverse(true); ??????? tl.playFromStart(); ??????? // ??????? Circle circle3 = new Circle(20, Color.GREEN); ??????? Timeline tl2 = new Timeline( ??????????????? new KeyFrame(Duration.ZERO, new KeyValue(circle3.centerXProperty(), 425), new KeyValue(circle3.centerYProperty(), 125)), ??????????????? new KeyFrame(Duration.seconds(5), new KeyValue(circle3.centerXProperty(), 125), new KeyValue(circle3.centerYProperty(), 425)) ??????? ); ??????? tl2.setCycleCount(Timeline.INDEFINITE); ??????? tl2.setAutoReverse(true); ??????? tl2.playFromStart(); ??????? // ??????? Group root = new Group(); //??????? root.getChildren().addAll(circle, circle2, circle3); ??????? root.getChildren().addAll(circle2, circle3); ??????? Scene scene = new Scene(root, 600, 600); ??????? primaryStage.setTitle("Hello World!"); ??????? primaryStage.setScene(scene); ??????? primaryStage.show(); ??? } From: Kevin Rushforth To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" ; Lord Chaos Sent: Friday, April 14, 2017 9:29 AM Subject: Re: PathTransition jitter And here is the direct link in JBS: https://bugs.openjdk.java.net/browse/JDK-8178805 -- Kevin Jose Martinez wrote: > Thank you Kevin. > For those interested here is the bug report:? http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 > > > > >? ? ? From: Kevin Rushforth >? To: Jose Martinez > Cc: "openjfx-dev at openjdk.java.net" >? Sent: Thursday, April 13, 2017 7:49 AM >? Subject: Re: PathTransition jitter >? ? > One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in June 2015. You can find the ones you filed using this query: > > https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx > > -- Kevin > > > Jose Martinez wrote: >? In case it helps, below is the original workaround that was provided.? This workaround no longer has any affect. > public class FixedPane extends Group {? ? @Override >? ? public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { >? ? ? ? ? if (!tx.isTranslateOrIdentity()) { >? ? ? ? ? ? ? super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); >? ? ? ? ? } >? ? ? ? ? return super.impl_computeGeomBounds(bounds, tx); >? ? } > } > Forgot to include:? using a Windows 10 and Geforce gtx GPU. > >? ? ? From: Tom Eugelink >? To: openjfx-dev at openjdk.java.net >? Sent: Thursday, April 13, 2017 3:15 AM >? Subject: Re: PathTransition jitter >? ? > I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) > > Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. > > > On 13-4-2017 08:46, Michael Paus wrote: >? ? >? It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. > > Am 13.04.17 um 04:25 schrieb Jose Martinez: >? ? ? >? Many moons ago I complained about jittery PathTransition animation.? A bug was openned and I was provided a workaround. This was with Java 7.? I revisted the old project that lead to that initial complain, this time with Java 8.? The problem seems to be back.? I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. > Below is the test code to reproduce.? I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them.? The ImageViewstutters through the PathTransition.? I have a new laptop with 6th gen I7 and plenty of ram.? I do not think it is the hardware.? This used to besmooth like butter.? Anyone else experiencing this or can make any suggestions? > >? ? ? @Override >? ? ? public void start(Stage primaryStage) {? ? ? ? String rocketImgStr= > "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph > CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz > 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N > 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAga > kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 > NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm > letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >? ? ? ? ? Base64.Decoder decoder = Base64.getDecoder(); >? ? ? ? ? ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); >? ? ? ? ? Path path = new Path(); >? ? ? ? ? path.getElements().add(new MoveTo(100, 100)); >? ? ? ? ? path.getElements().add(new LineTo(500, 100)); >? ? ? ? ? path.getElements().add(new LineTo(500, 500)); >? ? ? ? ? path.getElements().add(new LineTo(100, 500)); >? ? ? ? ? path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); >? ? ? ? ? pathTransition.setCycleCount(Animation.INDEFINITE); > pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >? ? ? ? ? pathTransition.playFromStart();? ? ? ? Group root = new Group(); >? ? ? ? ? root.getChildren().add(iv); >? ? ? ? ? Scene scene = new Scene(root, 600, 600); >? ? ? ? ? primaryStage.setTitle("Hello World!"); >? ? ? ? ? primaryStage.setScene(scene); >? ? ? ? ? primaryStage.show(); >? ? ? } > > thanks, > jose > >? ? ? ? >? ? ? >? ? >? > > >? ? >? From Ignatiamus at gmail.com Mon May 8 05:55:26 2017 From: Ignatiamus at gmail.com (Hermann Maier) Date: Mon, 8 May 2017 07:55:26 +0200 Subject: PathTransition jitter In-Reply-To: References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> <1104912949.277882.1492174200192@mail.yahoo.com> <58F0CEC5.4040401@oracle.com> <625366570.3956468.1494129799752@mail.yahoo.com> Message-ID: Thank you very much, Itai, for this straight tip, because testing some JavaFX applcations with (X)Ubuntu 17.04 (Mesa 17.0.1 and Xorg>1.18.4) didn't show any bad behavior like the aforementioned resource leak. So the only question remaining is why nobody mentioned this as a possible solution to JDK-8161914 on it's JBS page? Anyway, I don't intend lead this off-topic, so I can only confirm the jittering issue. Cheers, Hermann Am 07.05.2017 um 13:16 schrieb Itai: > Hermann - I believe this bug is due to a combination of Mesa and X.org - it > seems to be resolved by using Mesa>=13.0 *and* X.org>=1.18.4 . Since this > is a Linux-only bug, I don't think it's the same as the TransitionPath > jitter, as it reportedly happens on Windows as well. > > On Sun, May 7, 2017 at 12:57 PM, Hermann Maier wrote: > >> I can reproduce the problem as well on my system with (X)Ubuntu 16.04 >> 64-Bit and Mesa 12.0.6, with JDK 8u131. >> Also, the CPU usage of the Java process and the Xorg process is increasing >> constantly until the application gets completely laggy and unusable (like >> every application that is using some JavaFX animation under Linux with the >> hardware renderer). This bug is already known [1], the resource leak is >> happening on my system too and it's very annoying (e.g. I made a game with >> JavaFX and realized this too late?). Thus I would suggest that raising the >> priority of that bug would be appropriate? >> However, when I use the Software Renderer there's nothing like described >> above, so it's really likely related to Mesa/Xorg. >> >> >> Cheers >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8161914 >> >> Am 07.05.2017 um 06:03 schrieb Jose Martinez: >>> Looks like I am unable to update the Jira ticket so I guess I'll update >> the bug in here. >>> Kevin mentioned that there is some relief if >> "-Djavafx.animation.fullspeed=true" VM option is used. I notice that it >> does improve but not remove the problem. Also, the jitter is not limited >> to PathTransition. In the example below the problem is reproduced by using >> Timeline and no PathTransition. >>> Since like this is not just an issue with PathTransition, would it be >> possible to bump up the priority on this? The Jira mentions the fix is >> scheduled for Java 10. Does this affect all animation in JavaFX? Is there >> anyway to move objects on the screen without jitter? >>> >>> private void pathJitterBug(Stage primaryStage) { >>> // Circle circle = new Circle(30, Color.RED); >>> // Path path = new Path(); >>> // path.getElements().add(new MoveTo(100, 100)); >>> // path.getElements().add(new LineTo(500, 100)); >>> // path.getElements().add(new LineTo(500, 500)); >>> // path.getElements().add(new LineTo(100, 500)); >>> // path.getElements().add(new LineTo(100, 100)); >>> // >>> // PathTransition pathTransition = new >> PathTransition(Duration.seconds(10), path, circle); >>> // pathTransition.setCycleCount(Animation.INDEFINITE); >>> // pathTransition.setOrientation(PathTransition.OrientationType >> .ORTHOGONAL_TO_TANGENT); >>> // pathTransition.playFromStart(); >>> // >>> Circle circle2 = new Circle(20, Color.BLUE); >>> Timeline tl = new Timeline( >>> new KeyFrame(Duration.ZERO, new >> KeyValue(circle2.centerXProperty(), 125), new >> KeyValue(circle2.centerYProperty(), 125)), >>> new KeyFrame(Duration.seconds(5), new >> KeyValue(circle2.centerXProperty(), 425), new >> KeyValue(circle2.centerYProperty(), 425)) >>> ); >>> tl.setCycleCount(Timeline.INDEFINITE); >>> tl.setAutoReverse(true); >>> tl.playFromStart(); >>> // >>> Circle circle3 = new Circle(20, Color.GREEN); >>> Timeline tl2 = new Timeline( >>> new KeyFrame(Duration.ZERO, new >> KeyValue(circle3.centerXProperty(), 425), new >> KeyValue(circle3.centerYProperty(), 125)), >>> new KeyFrame(Duration.seconds(5), new >> KeyValue(circle3.centerXProperty(), 125), new >> KeyValue(circle3.centerYProperty(), 425)) >>> ); >>> tl2.setCycleCount(Timeline.INDEFINITE); >>> tl2.setAutoReverse(true); >>> tl2.playFromStart(); >>> // >>> Group root = new Group(); >>> // root.getChildren().addAll(circle, circle2, circle3); >>> root.getChildren().addAll(circle2, circle3); >>> Scene scene = new Scene(root, 600, 600); >>> primaryStage.setTitle("Hello World!"); >>> primaryStage.setScene(scene); >>> primaryStage.show(); >>> } >>> >>> >>> From: Kevin Rushforth >>> To: Jose Martinez >>> Cc: "openjfx-dev at openjdk.java.net" ; Lord >> Chaos >>> Sent: Friday, April 14, 2017 9:29 AM >> >>> Subject: Re: PathTransition jitter >>> >>> And here is the direct link in JBS: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8178805 >>> >>> -- Kevin >>> >>> >>> Jose Martinez wrote: >>>> Thank you Kevin. >>>> For those interested here is the bug report: >> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 >>>> >>>> >>>> >>>> >>>> From: Kevin Rushforth >>>> To: Jose Martinez >>>> Cc: "openjfx-dev at openjdk.java.net" >>>> Sent: Thursday, April 13, 2017 7:49 AM >>>> Subject: Re: PathTransition jitter >>>> >>>> One more thing: all bugs were transfered from the old JavaFX JIRA >> intoJBS in June 2015. You can find the ones you filed using this query: >>>> >>>> https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx >>>> >>>> -- Kevin >>>> >>>> >>>> Jose Martinez wrote: >>>> In case it helps, below is the original workaround that was provided. >> This workaround no longer has any affect. >>>> public class FixedPane extends Group { @Override >>>> public BaseBounds impl_computeGeomBounds(BaseBounds bounds, >> BaseTransform tx) { >>>> if (!tx.isTranslateOrIdentity()) { >>>> super.impl_computeGeomBounds(bounds, >> BaseTransform.IDENTITY_TRANSFORM); >>>> } >>>> return super.impl_computeGeomBounds(bounds, tx); >>>> } >>>> } >>>> Forgot to include: using a Windows 10 and Geforce gtx GPU. >>>> >>>> From: Tom Eugelink >>>> To: openjfx-dev at openjdk.java.net >>>> Sent: Thursday, April 13, 2017 3:15 AM >>>> Subject: Re: PathTransition jitter >>>> >>>> I'm seeing some very small irregularities; short hesitations and then >> small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz >> Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) >>>> >>>> Slowing the animation to 8 instead of 4 seconds, make these hiccups >> better visible. They're most definitely there. >>>> >>>> >>>> On 13-4-2017 08:46, Michael Paus wrote: >>>> >>>> It runs perfectly smooth on my old MacBook Pro from 2012 with JDK >> 8u152 ea. >>>> >>>> Am 13.04.17 um 04:25 schrieb Jose Martinez: >>>> >>>> Many moons ago I complained about jittery PathTransition animation. >> A bug was openned and I was provided a workaround. This was with Java 7. I >> revisted the old project that lead to that initial complain, this time with >> Java 8. The problem seems to be back. I could not find the old bugreport, >> since I think the JavaFX team is not using the same bug trackingsite. >>>> Below is the test code to reproduce. I tried it using JDK 8_64 u5, >> u11, u25, u112, u121 and the problem occurs with all of them. The >> ImageViewstutters through the PathTransition. I have a new laptop with 6th >> gen I7 and plenty of ram. I do not think it is the hardware. This used to >> besmooth like butter. Anyone else experiencing this or can make any >> suggestions? >>>> >>>> @Override >>>> public void start(Stage primaryStage) { String >> rocketImgStr= >>>> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAs >> YAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVN >> nVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8i >> giAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwf >> ACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsA >> HvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYC >> dmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhE >> AGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUp >> AAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4o >> zkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t >> 6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZr >> IPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/P >> f14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41 >> EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWH >> TA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCA >> AARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzb >> AdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph >>>> CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgx >> UopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQ >> ZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNj >> y7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0 >> EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMy >> J7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPk >> G+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2h >> tlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX >> 6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgq >> tip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtV >> qp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gs >> IWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0 >> TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1F >> u1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+ >> 6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzw >> dL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZ >> LTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz >>>> 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna >> 0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+ >> 6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2D >> PjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60v >> Wdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+ >> VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/ >> MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzr >> bZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mG >> Lw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5 >> qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1 >> weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtG >> I2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq >> 9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2Qqb >> oVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0 >> dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoL >> BtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG >> 4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N >>>> 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLd >> tWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvtt >> Xa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/ >> p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaR >> ptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19f >> i753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV >> 7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/ >> 1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+ >> 3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L >> 96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/ >> erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/ >> 2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAg >> OkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/ >> e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuK >> gJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/ >> er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+K >> PeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQ >> fwXxAGQD8Aeg5ssGIQGzgXLApUJAga >>>> kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3 >> DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xd >> fClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLI >> tUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltb >> V45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/ >> 39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2K >> VColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywO >> BoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZIm >> L4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD >> 4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv913 >> 36rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+ >> 2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi >> 8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtX >> C4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvso >> Gkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWh >> Rj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6 >> F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 >>>> NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j >> 2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV >> 5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0 >> fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5 >> WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQy >> SXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGK >> FSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+ >> orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUND >> Q8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/ >> bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwD >> sTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/Wye >> vVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+ >> 4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvv >> ZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqq >> OuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5Jq >> RZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJ >> E3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm >>>> letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0 >> mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE >> 6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJ >> IkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9N >> fWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++s >> hsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+ >> 6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2O >> x2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6 >> DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/ >> JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+ >> CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >>>> Base64.Decoder decoder = Base64.getDecoder(); >>>> ByteArrayInputStream rocketInputStream = new >> ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new >> ImageView(new Image(rocketInputStream)); >>>> Path path = new Path(); >>>> path.getElements().add(new MoveTo(100, 100)); >>>> path.getElements().add(new LineTo(500, 100)); >>>> path.getElements().add(new LineTo(500, 500)); >>>> path.getElements().add(new LineTo(100, 500)); >>>> path.getElements().add(new LineTo(100, 100)); PathTransition >> pathTransition = new PathTransition(Duration.seconds(4), path, iv); >>>> pathTransition.setCycleCount(Animation.INDEFINITE); >>>> pathTransition.setOrientation(PathTransition.OrientationType >> .ORTHOGONAL_TO_TANGENT); >>>> pathTransition.playFromStart(); Group root = new >> Group(); >>>> root.getChildren().add(iv); >>>> Scene scene = new Scene(root, 600, 600); >>>> primaryStage.setTitle("Hello World!"); >>>> primaryStage.setScene(scene); >>>> primaryStage.show(); >>>> } >>>> >>>> thanks, >>>> jose >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > From kevin.rushforth at oracle.com Mon May 8 15:20:20 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 May 2017 08:20:20 -0700 Subject: [10] Review request for 8179597: Handle cut and paste of 1, 2 and 4 byte characters In-Reply-To: <9f05f710-cc14-96eb-832f-1e1e898aa350@oracle.com> References: <9f05f710-cc14-96eb-832f-1e1e898aa350@oracle.com> Message-ID: <59108CB4.3080601@oracle.com> > Please review the fix for jfx9: I presume this is a typo and you meant to say jfx10? -- Kevin Semyon Sadetsky wrote: > Hello Kevin & David, > > Please review the fix for jfx9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8179597 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8179597/webrev.00/ > > --Semyon > From semyon.sadetsky at oracle.com Mon May 8 17:22:36 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 8 May 2017 10:22:36 -0700 Subject: [10] Review request for 8179597: Handle cut and paste of 1, 2 and 4 byte characters In-Reply-To: <59108CB4.3080601@oracle.com> References: <9f05f710-cc14-96eb-832f-1e1e898aa350@oracle.com> <59108CB4.3080601@oracle.com> Message-ID: <5910A95C.1000808@oracle.com> yes, that was a typo. Actually, the fix is for 10. --Semyon On 5/8/2017 8:20 AM, Kevin Rushforth wrote: > >> Please review the fix for jfx9: > > I presume this is a typo and you meant to say jfx10? > > -- Kevin > > > Semyon Sadetsky wrote: >> Hello Kevin & David, >> >> Please review the fix for jfx9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8179597 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8179597/webrev.00/ >> >> --Semyon >> From kevin.rushforth at oracle.com Mon May 8 20:37:41 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 May 2017 13:37:41 -0700 Subject: [9] Review request: 8177341: Fix typos in FX API docs Message-ID: <5910D715.606@oracle.com> Please review the following accumulated javadoc changes: https://bugs.openjdk.java.net/browse/JDK-8177341 http://cr.openjdk.java.net/~kcr/8177341/webrev.00/ Thanks. -- Kevin From avik.niyogi at oracle.com Tue May 9 09:14:53 2017 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 9 May 2017 14:44:53 +0530 Subject: 8089230: Mac: Window.maximize(false) won't restore a window into its original rectangle References: <9B09DC42-868B-4B5D-BEB0-88A762918138@oracle.com> Message-ID: <477B8693-C44E-4659-80D7-68BAA0C57407@oracle.com> > Begin forwarded message: > > From: Avik Niyogi > Subject: 8089230: Mac: Window.maximize(false) won't restore a window into its original rectangle > Date: 9 May 2017 2:35:39 pm IST > To: David Hill , Kevin Rushforth , Manajit Halder > Cc: Praveen Srivastava > > Hi All, > > Kindly review the fix for JDK10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8089230 > > Webrev: http://cr.openjdk.java.net/~aniyogi/8089230/webrev.00/ > > Issue: The test case tests/system/src/test/java/test/javafx/stage/RestoreStagePositionTest.java fails with wrong window position > > Cause: setFlipFrame method in native Obj C code was implemented wrongly for restorePreZoomedRect method calling method. > > Fix: Significant native changes were implemented to incorporate these changes for this particular case. > > With Regards, > Avik Niyogi From kevin.rushforth at oracle.com Wed May 10 01:08:43 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 May 2017 18:08:43 -0700 Subject: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs Message-ID: <5912681B.7040401@oracle.com> Please review the following to exclude jdk.packager module from the JDK docs bundle: https://bugs.openjdk.java.net/browse/JDK-8180040 http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ I also added a missing package description for the jdk.packager.services package (in the jdk.packager.services module), since the jdk.packager.services module will remain in the docs. -- Kevin From james.graham at oracle.com Wed May 10 01:17:19 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 9 May 2017 18:17:19 -0700 Subject: [10] Review request: JDK-8179946 - Objects are not rendered for certain rotation angle and cache hint combinations Message-ID: <8b55f17f-c537-5387-0e6b-3459d1d46f59@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8179946 webrev: http://cr.openjdk.java.net/~flar/JDK-8179946/webrev.00/ This should get back-ported to 9 as well, as soon as makes sense... ...jim From kevin.rushforth at oracle.com Wed May 10 01:19:55 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 May 2017 18:19:55 -0700 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <1f806cdc-a241-04aa-6e4b-0b11abb1f0a9@gmail.com> References: <5907D11D.20609@oracle.com> <1f806cdc-a241-04aa-6e4b-0b11abb1f0a9@gmail.com> Message-ID: <59126ABB.8090304@oracle.com> inline Peter Levart wrote: > Hi Kevin, > > On 05/02/2017 02:21 AM, Kevin Rushforth wrote: >> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >> >> Please review the proposed fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8177566 >> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >> >> Details of the fix as well as notes to reviewers are in the bug >> report [1] (e.g., I've also generated separate webrevs for the fix >> itself, the doc changes, and the test changes). >> >> -- Kevin >> >> [1] >> https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 >> > > I think it is very unusual to handle unqualified exports as something > special, different from qualified exports. I know what the reasoning > is: if a package is exported unconditionally (to everyone) then it is > part of public API and so the trampoline may access members of that > package on behalf of anyone. But such reasoning is just a consequence > of the lack of a finer-grained (per-module) access support in JavaFX. > I know it is too much to ask for JDK 9, but could JavaFX in say JDK > 10, given current API, somehow determine on whose behalf it is making > the trampoline access? If it could, then the trampoline could allow > qualified exports to be effective too. The primary remedy is for the application to use a qualified "opens" to the appropriate javafx module. For example, to allow the JavaBeanXXXProperty classes the ability to access a class in your module, your module needs to "opens my.package to javafx.base". The only difference between what you propose and what was implemented is qualified exports versus qualified opens, which really shouldn't be too much of an issue for applications (such applications already need to use qualified opens to allow access to their FXML controller class). The only reason we mention unconditional exports as an alternative is for the benefit of application that happen to already have their package exported unconditionally. -- Kevin > Regards, Peter > From erik.joelsson at oracle.com Wed May 10 01:31:34 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 May 2017 18:31:34 -0700 Subject: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs In-Reply-To: <5912681B.7040401@oracle.com> References: <5912681B.7040401@oracle.com> Message-ID: <0dae812f-b205-37f1-3ca4-f3fb1a93c4cd@oracle.com> Looks ok to me. /Erik On 2017-05-09 18:08, Kevin Rushforth wrote: > Please review the following to exclude jdk.packager module from the > JDK docs bundle: > > https://bugs.openjdk.java.net/browse/JDK-8180040 > http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ > > I also added a missing package description for the > jdk.packager.services package (in the jdk.packager.services module), > since the jdk.packager.services module will remain in the docs. > > -- Kevin > > From mandy.chung at oracle.com Wed May 10 01:41:51 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 18:41:51 -0700 Subject: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs In-Reply-To: <5912681B.7040401@oracle.com> References: <5912681B.7040401@oracle.com> Message-ID: > On May 9, 2017, at 6:08 PM, Kevin Rushforth wrote: > > Please review the following to exclude jdk.packager module from the JDK docs bundle: > > https://bugs.openjdk.java.net/browse/JDK-8180040 > http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ > > I also added a missing package description for the jdk.packager.services package (in the jdk.packager.services module), since the jdk.packager.services module will remain in the docs. I suggest to convert package.html to package-info.java. Also need copyright header. build.properties change looks fine. Mandy From kevin.rushforth at oracle.com Wed May 10 01:52:15 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 May 2017 18:52:15 -0700 Subject: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs In-Reply-To: References: <5912681B.7040401@oracle.com> Message-ID: <5912724F.3090904@oracle.com> Thanks for the review. We currently don't use package-info.java anywhere, but I can file a separate bug for converting all of our package.html to package-info.java. I can add the the missing copyright headers at the same time. -- Kevin Mandy Chung wrote: >> On May 9, 2017, at 6:08 PM, Kevin Rushforth wrote: >> >> Please review the following to exclude jdk.packager module from the JDK docs bundle: >> >> https://bugs.openjdk.java.net/browse/JDK-8180040 >> http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ >> >> I also added a missing package description for the jdk.packager.services package (in the jdk.packager.services module), since the jdk.packager.services module will remain in the docs. >> > > I suggest to convert package.html to package-info.java. Also need copyright header. > > build.properties change looks fine. > > Mandy From mandy.chung at oracle.com Wed May 10 03:04:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 20:04:32 -0700 Subject: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs In-Reply-To: <5912724F.3090904@oracle.com> References: <5912681B.7040401@oracle.com> <5912724F.3090904@oracle.com> Message-ID: > On May 9, 2017, at 6:52 PM, Kevin Rushforth wrote: > > Thanks for the review. We currently don't use package-info.java anywhere, but I can file a separate bug for converting all of our package.html to package-info.java. That?d be good. > I can add the the missing copyright headers at the same time. > OK. No need for an updated webrev. Mandy > -- Kevin > > > Mandy Chung wrote: >> >>> On May 9, 2017, at 6:08 PM, Kevin Rushforth wrote: >>> >>> Please review the following to exclude jdk.packager module from the JDK docs bundle: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8180040 >>> http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ >>> >>> I also added a missing package description for the jdk.packager.services package (in the jdk.packager.services module), since the jdk.packager.services module will remain in the docs. >>> >> >> I suggest to convert package.html to package-info.java. Also need copyright header. >> >> build.properties change looks fine. >> >> Mandy From ajit.ghaisas at oracle.com Wed May 10 08:50:26 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 10 May 2017 01:50:26 -0700 (PDT) Subject: [10] Review request : JDK-8089840 : Disabled menu items are invisible with 100% contrast display settings Message-ID: <441afce5-b9c6-4757-b9c6-0beddf48cef4@default> Hi Jonathan, Request you to review following fix : Bug : https://bugs.openjdk.java.net/browse/JDK-8089840 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8089840/webrev.0/ Regards, Ajit From Jens.Auer at h-d-gmbh.de Wed May 10 13:23:53 2017 From: Jens.Auer at h-d-gmbh.de (Jens Auer) Date: Wed, 10 May 2017 13:23:53 +0000 Subject: CSS id selector with embedded dot Message-ID: Hi, I am working on a project which enforces unique FX Id by using a naming convention mirroring the hierarchical structure of the controls in the name, delimited by dots. So for example, we have a button "myPane.button1". I am not able to select this button in a css file. Here is an example program and the css file: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class CssTest extends Application { public static void main(final String[] args) { Application.launch(args); } @Override public void start(final Stage stage) { VBox vbox = new VBox(); Button b1 = new Button(); b1.setId("the.button"); b1.setText("BUTTON1"); Button b2 = new Button(); b2.setId("thebutton"); b2.setText("BUTTON2"); vbox.getChildren().addAll(b1, b2); vbox.getStylesheets().add("stylesheet.css"); final Scene scene = new Scene(vbox); stage.setScene(scene); stage.show(); } } The css file is #the\.button { -fx-graphic: url("Keyboard.png"); } #thebutton { -fx-graphic: url("Keyboard.png"); } As far as I understand the CSS definition the names are valid ids and escaping should work here. Is this a limitation in the JavaFX CSS parser? Best wishes, Jens Jens Auer (Softwareentwicklung) ___________________________________________________________ Unternehmensberatung H & D GmbH Niederlassung Wei?enthurm Werftstr. 5 - 56575 Wei?enthurm Tel.:??? ??? ??? 02637/94238 -110 Fax:??? ??? ??? 02637/94238 -149 jens.auer at h-d-gmbh.de http://www.h-d-gmbh.de http://www.h-d-gmbh.de/impressum.html ___________________________________________________________ From david.grieve at oracle.com Wed May 10 14:02:50 2017 From: david.grieve at oracle.com (David Grieve) Date: Wed, 10 May 2017 10:02:50 -0400 Subject: CSS id selector with embedded dot In-Reply-To: References: Message-ID: <06104eaf-d237-a493-eb47-f9d5c798de54@oracle.com> Having an id with a dot is not valid CSS syntax. From the spec: " An ID selector contains a "number sign" (U+0023, #) immediately followed by the ID value, which must be an CSS identifiers." An identifier is defined here: https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr; is that an identifier cannot contain a dot. On 5/10/17 9:23 AM, Jens Auer wrote: > Hi, > > I am working on a project which enforces unique FX Id by using a naming convention mirroring the hierarchical structure of the controls in the name, delimited by dots. So for example, we have a button "myPane.button1". I am not able to select this button in a css file. Here is an example program and the css file: > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class CssTest extends Application { > > public static void main(final String[] args) { > Application.launch(args); > } > > @Override > public void start(final Stage stage) { > VBox vbox = new VBox(); > Button b1 = new Button(); > b1.setId("the.button"); > b1.setText("BUTTON1"); > > Button b2 = new Button(); > b2.setId("thebutton"); > b2.setText("BUTTON2"); > > vbox.getChildren().addAll(b1, b2); > vbox.getStylesheets().add("stylesheet.css"); > > final Scene scene = new Scene(vbox); > > stage.setScene(scene); > stage.show(); > } > } > The css file is > > #the\.button { > -fx-graphic: url("Keyboard.png"); > } > > #thebutton { > -fx-graphic: url("Keyboard.png"); > } > > As far as I understand the CSS definition the names are valid ids and escaping should work here. Is this a limitation in the JavaFX CSS parser? > > Best wishes, > Jens > > Jens Auer > (Softwareentwicklung) > ___________________________________________________________ > Unternehmensberatung H & D GmbH > Niederlassung Wei?enthurm > Werftstr. 5 - 56575 Wei?enthurm > Tel.: 02637/94238 -110 > Fax: 02637/94238 -149 > jens.auer at h-d-gmbh.de > http://www.h-d-gmbh.de > http://www.h-d-gmbh.de/impressum.html > ___________________________________________________________ > From tom.schindl at bestsolution.at Wed May 10 14:23:42 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 10 May 2017 16:23:42 +0200 Subject: CSS id selector with embedded dot In-Reply-To: <06104eaf-d237-a493-eb47-f9d5c798de54@oracle.com> References: <06104eaf-d237-a493-eb47-f9d5c798de54@oracle.com> Message-ID: <4AD8C168-C4DD-443D-9A18-50BFAECD7A4F@bestsolution.at> Infact '#the.button1' means id = the, cssclass = button1 So it would match Button b ...; b.setId("the"); b.getClassNames().add("button1"); Tom Von meinem iPhone gesendet > Am 10.05.2017 um 16:02 schrieb David Grieve : > > Having an id with a dot is not valid CSS syntax. > > From the spec: " An ID selector contains a "number sign" (U+0023, #) immediately followed by the ID value, which must be an CSS identifiers." > > An identifier is defined here: https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr; is that an identifier cannot contain a dot. > > >> On 5/10/17 9:23 AM, Jens Auer wrote: >> Hi, >> >> I am working on a project which enforces unique FX Id by using a naming convention mirroring the hierarchical structure of the controls in the name, delimited by dots. So for example, we have a button "myPane.button1". I am not able to select this button in a css file. Here is an example program and the css file: >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class CssTest extends Application { >> >> public static void main(final String[] args) { >> Application.launch(args); >> } >> >> @Override >> public void start(final Stage stage) { >> VBox vbox = new VBox(); >> Button b1 = new Button(); >> b1.setId("the.button"); >> b1.setText("BUTTON1"); >> >> Button b2 = new Button(); >> b2.setId("thebutton"); >> b2.setText("BUTTON2"); >> >> vbox.getChildren().addAll(b1, b2); >> vbox.getStylesheets().add("stylesheet.css"); >> >> final Scene scene = new Scene(vbox); >> >> stage.setScene(scene); >> stage.show(); >> } >> } >> The css file is >> >> #the\.button { >> -fx-graphic: url("Keyboard.png"); >> } >> >> #thebutton { >> -fx-graphic: url("Keyboard.png"); >> } >> >> As far as I understand the CSS definition the names are valid ids and escaping should work here. Is this a limitation in the JavaFX CSS parser? >> >> Best wishes, >> Jens >> >> Jens Auer >> (Softwareentwicklung) >> ___________________________________________________________ >> Unternehmensberatung H & D GmbH >> Niederlassung Wei?enthurm >> Werftstr. 5 - 56575 Wei?enthurm >> Tel.: 02637/94238 -110 >> Fax: 02637/94238 -149 >> jens.auer at h-d-gmbh.de >> http://www.h-d-gmbh.de >> http://www.h-d-gmbh.de/impressum.html >> ___________________________________________________________ >> > From kevin.rushforth at oracle.com Wed May 10 14:27:27 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 May 2017 07:27:27 -0700 Subject: [9] Review request: 8180040: Exclude jdk.packager module from unified JDK 9 docs In-Reply-To: References: <5912681B.7040401@oracle.com> <5912724F.3090904@oracle.com> Message-ID: <5913234F.2050200@oracle.com> I added the missing copyright header before pushing. I will file two new issues: one to add copyright headers to all the other package.html files (which I will do in JDK 9) and one to convert all of the package.html files to package-info.java (which I will target to 10...I don't want to make that change this late in 9). Thanks again. -- Kevin Mandy Chung wrote: > >> On May 9, 2017, at 6:52 PM, Kevin Rushforth >> > wrote: >> >> Thanks for the review. We currently don't use package-info.java >> anywhere, but I can file a separate bug for converting all of our >> package.html to package-info.java. > > That?d be good. > >> I can add the the missing copyright headers at the same time. >> > > OK. > > No need for an updated webrev. > > Mandy > >> -- Kevin >> >> >> Mandy Chung wrote: >>>> On May 9, 2017, at 6:08 PM, Kevin Rushforth wrote: >>>> >>>> Please review the following to exclude jdk.packager module from the JDK docs bundle: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8180040 >>>> http://cr.openjdk.java.net/~kcr/8180040/webrev.00/ >>>> >>>> I also added a missing package description for the jdk.packager.services package (in the jdk.packager.services module), since the jdk.packager.services module will remain in the docs. >>>> >>> >>> I suggest to convert package.html to package-info.java. Also need copyright header. >>> >>> build.properties change looks fine. >>> >>> Mandy > From Michael.Doswald at schiller.ch Wed May 10 15:10:00 2017 From: Michael.Doswald at schiller.ch (Doswald Michael) Date: Wed, 10 May 2017 15:10:00 +0000 Subject: CSS id selector with embedded dot Message-ID: <1494428999868.49074@schiller.ch> On 5/10/17 2:02 PM, David Grieve wrote: > Having an id with a dot is not valid CSS syntax. > > From the spec: " An ID selector contains a "number sign" (U+0023, #) > immediately followed by the ID value, which must be an CSS identifiers." > > An identifier is defined here: > https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr; > is that an identifier cannot contain a dot. But in the link you referenced it says: "Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F"." Wouldn't that include an escaped dot as a valid character for a CSS identifier? From nlisker at gmail.com Wed May 10 16:13:55 2017 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 May 2017 19:13:55 +0300 Subject: Corrections for Javadoc Message-ID: I'm looking at build 168 of JDK9 and there are a few mistakes in the docs. I can't submit issues to the JIRA so I'll list them here. A similar issue was https://bugs.openjdk.java.net/browse/JDK-8177341. - The following use "a Observable..." instead of "an Observable...". - javafx.beans.property - ListProperty - MapProperty - ReadOnlyListPropertyBase - SetProperty - javafx.beans.binding - NumberExpression - BooleanExpression - DoubleExpression - FloatExpression - IntegerExpression - ListExpression - LongExpression - MapExpression - ObjectExpression - SetExpression - StringExpression - javafx.scene.shape.ObservableFaceArray copies its description from its superinteface ObservableIntegerArray, does not declare any API methods and is listed under package javafx.scene.shape. It's not clear at all what this interface is. As it is, it looks like it's not meant to be exposed. - javafx.collections.ObservableIntegerArray uses "a int[]" instead of "an int[]". This writing ("a int") is found in java.lang.Integer as well in a few places. Nir From kevin.rushforth at oracle.com Wed May 10 16:25:00 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 May 2017 09:25:00 -0700 Subject: Corrections for Javadoc In-Reply-To: References: Message-ID: <59133EDC.6040007@oracle.com> I just filed a new issue to catch any last minute typos: https://bugs.openjdk.java.net/browse/JDK-8180070 I'll add your note to this new JBS bug. Thank you. -- Kevin Nir Lisker wrote: > I'm looking at build 168 of JDK9 and there are a few mistakes in the docs. > I can't submit issues to the JIRA so I'll list them here. A similar issue > was https://bugs.openjdk.java.net/browse/JDK-8177341. > > > - The following use "a Observable..." instead of "an Observable...". > - javafx.beans.property > - ListProperty > - MapProperty > - ReadOnlyListPropertyBase > - SetProperty > - javafx.beans.binding > - NumberExpression > - BooleanExpression > - DoubleExpression > - FloatExpression > - IntegerExpression > - ListExpression > - LongExpression > - MapExpression > - ObjectExpression > - SetExpression > - StringExpression > - javafx.scene.shape.ObservableFaceArray copies its description > from its superinteface ObservableIntegerArray, does not declare any API > methods and is listed under package javafx.scene.shape. It's not clear at > all what this interface is. As it is, it looks like it's not meant to be > exposed. > - javafx.collections.ObservableIntegerArray uses "a int[]" instead of > "an int[]". This writing ("a int") is found in java.lang.Integer as well in > a few places. > > Nir > From david.grieve at oracle.com Wed May 10 17:09:05 2017 From: david.grieve at oracle.com (David Grieve) Date: Wed, 10 May 2017 13:09:05 -0400 Subject: CSS id selector with embedded dot In-Reply-To: <1494428999868.49074@schiller.ch> References: <1494428999868.49074@schiller.ch> Message-ID: <6397508c-a41b-780f-b2f1-2f3a119316af@oracle.com> Fair enough. The CSS Reference Guide says " While the JavaFX CSS parser will parse valid CSS syntax, it is not a fully compliant CSS parser." Escaped characters is a case in point. On 5/10/17 11:10 AM, Doswald Michael wrote: > On 5/10/17 2:02 PM, David Grieve wrote: >> Having an id with a dot is not valid CSS syntax. >> >> From the spec: " An ID selector contains a "number sign" (U+0023, #) >> immediately followed by the ID value, which must be an CSS identifiers." >> >> An identifier is defined here: >> https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr; >> is that an identifier cannot contain a dot. > But in the link you referenced it says: > > "Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F"." > > Wouldn't that include an escaped dot as a valid character for a CSS identifier? > > > > > > From nlisker at gmail.com Thu May 11 00:09:10 2017 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 11 May 2017 03:09:10 +0300 Subject: Will there be an API for creating materials? Message-ID: It seems that currently developers can't create their own material because the abstract class Material is not designed to be subclassed, and so PhongMaterial is the only one available. Are there any plans to allow developers to subclass Material and crate their own materials? Phong is somewhat old and other shaders are more commonly used in the industry. From avik.niyogi at oracle.com Thu May 11 07:07:19 2017 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 11 May 2017 12:37:19 +0530 Subject: Review Request: JDK-8179514: [macosx] Maximize button is enabled for non-resizable parent window when child window is opened Message-ID: <51381FBD-2B22-4BF0-A8BC-C8620739BC7E@oracle.com> Hi All, Kindly review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8179514 Webrev: http://cr.openjdk.java.net/~aniyogi/8179514/webrev.00/ With Regards, Avik Niyogi From kevin.rushforth at oracle.com Thu May 11 12:28:34 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 May 2017 05:28:34 -0700 Subject: Will there be an API for creating materials? In-Reply-To: References: Message-ID: <591458F2.6040603@oracle.com> We don't currently plan any improvements in the area of 3D rendering. Even if we did, allowing application-defined materials would require some way for the application to provide the needed shader support for rendering such materials. -- Kevin Nir Lisker wrote: > It seems that currently developers can't create their own material because > the abstract class Material is not designed to be subclassed, and so > PhongMaterial is the only one available. > > Are there any plans to allow developers to subclass Material and crate > their own materials? Phong is somewhat old and other shaders are more > commonly used in the industry. > From nlisker at gmail.com Thu May 11 20:39:15 2017 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 11 May 2017 23:39:15 +0300 Subject: Corrections for Javadoc In-Reply-To: <59133EDC.6040007@oracle.com> References: <59133EDC.6040007@oracle.com> Message-ID: Add this to the list as well please: javafx.scene.image.Image's constructors: - Image(String url) - Image(String url, boolean backgroundLoading) - Image(String url, double requestedWidth, double requestedHeight, boolean preserveRatio, boolean smooth) all have a @see annotation pointing to a private constructor. This makes the link in the generated docs do nothing. On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth wrote: > I just filed a new issue to catch any last minute typos: > > https://bugs.openjdk.java.net/browse/JDK-8180070 > > I'll add your note to this new JBS bug. > > Thank you. > > -- Kevin > > > > > Nir Lisker wrote: > >> I'm looking at build 168 of JDK9 and there are a few mistakes in the docs. >> I can't submit issues to the JIRA so I'll list them here. A similar issue >> was https://bugs.openjdk.java.net/browse/JDK-8177341. >> >> >> - The following use "a Observable..." instead of "an Observable...". >> - javafx.beans.property >> - ListProperty >> - MapProperty >> - ReadOnlyListPropertyBase >> - SetProperty >> - javafx.beans.binding >> - NumberExpression >> - BooleanExpression >> - DoubleExpression >> - FloatExpression >> - IntegerExpression >> - ListExpression >> - LongExpression >> - MapExpression >> - ObjectExpression >> - SetExpression >> - StringExpression >> - javafx.scene.shape.ObservableFaceArray copies its description >> from its superinteface ObservableIntegerArray, does not declare any API >> methods and is listed under package javafx.scene.shape. It's not clear >> at >> all what this interface is. As it is, it looks like it's not meant to >> be >> exposed. >> - javafx.collections.ObservableIntegerArray uses "a int[]" instead of >> "an int[]". This writing ("a int") is found in java.lang.Integer as >> well in >> a few places. >> >> Nir >> >> > From peter.levart at gmail.com Thu May 11 21:00:48 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 11 May 2017 23:00:48 +0200 Subject: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline In-Reply-To: <59126ABB.8090304@oracle.com> References: <5907D11D.20609@oracle.com> <1f806cdc-a241-04aa-6e4b-0b11abb1f0a9@gmail.com> <59126ABB.8090304@oracle.com> Message-ID: Hi Kevin, On 05/10/2017 03:19 AM, Kevin Rushforth wrote: > inline > > Peter Levart wrote: >> Hi Kevin, >> >> On 05/02/2017 02:21 AM, Kevin Rushforth wrote: >>> This review is being cross-posted to both openjfx-dev and jigsaw-dev. >>> >>> Please review the proposed fix for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177566 >>> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ >>> >>> Details of the fix as well as notes to reviewers are in the bug >>> report [1] (e.g., I've also generated separate webrevs for the fix >>> itself, the doc changes, and the test changes). >>> >>> -- Kevin >>> >>> [1] >>> https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243 >>> >> >> I think it is very unusual to handle unqualified exports as something >> special, different from qualified exports. I know what the reasoning >> is: if a package is exported unconditionally (to everyone) then it is >> part of public API and so the trampoline may access members of that >> package on behalf of anyone. But such reasoning is just a consequence >> of the lack of a finer-grained (per-module) access support in JavaFX. >> I know it is too much to ask for JDK 9, but could JavaFX in say JDK >> 10, given current API, somehow determine on whose behalf it is making >> the trampoline access? If it could, then the trampoline could allow >> qualified exports to be effective too. > > The primary remedy is for the application to use a qualified "opens" > to the appropriate javafx module. For example, to allow the > JavaBeanXXXProperty classes the ability to access a class in your > module, your module needs to "opens my.package to javafx.base". The > only difference between what you propose and what was implemented is > qualified exports versus qualified opens, which really shouldn't be > too much of an issue for applications (such applications already need > to use qualified opens to allow access to their FXML controller class). > > The only reason we mention unconditional exports as an alternative is > for the benefit of application that happen to already have their > package exported unconditionally. > > -- Kevin I was thinking more in the direction of who the "real" accessor is when some JavaBeanXXXProperty is being used to access the bean getter/setter methods. Could it be the one invoking the JavaBeanXXXProperty.get()/.set() methods? Could it be the one invoking the JavaBeanXXXProperty.bind(ObservableValue) ? JavaBeanXXXProperty is a kind of "reflection" API with additional features. Classical Java reflection, for example, uses the "real" caller (the one invoking Method.invoke or Field.get/.set) to base access decisions on. Would this be the right approach for JavaBeanXXXProperty too? (injections with @FXML are a different story). Say for example, that module A has some Java bean classes that it would like to expose solely to module B and module B would like to bind their properties to some observables. Now module A would like to expose those bean classes to B with simple qualified exports so that no other module but B could bind or access A's bean properties. Does this make sense so far? If qualified "opens" to the appropriate javafx module is enough for JavaBeanXXXProperty to access bean properties in so opened packages, then JavaBeanXXXProperty provides a means for anyone to access those getters/setters. In my view this represents an elevation of privilege. A qualified opens to javafx then means more than just that. It means getters/setters are open to anyone who dares to use JavaBeanXXXProperty API instead of classic reflection API. What do you think? Regards, Peter From kevin.rushforth at oracle.com Thu May 11 21:02:26 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 May 2017 14:02:26 -0700 Subject: Corrections for Javadoc In-Reply-To: References: <59133EDC.6040007@oracle.com> Message-ID: <5914D162.8090302@oracle.com> Added. This is a questionable use of @see anyway. Thanks. -- Kevin Nir Lisker wrote: > Add this to the list as well please: > > javafx.scene.image.Image's constructors: > > - Image(String url) > - Image(String url, boolean backgroundLoading) > - Image(String url, double requestedWidth, double requestedHeight, > boolean preserveRatio, boolean smooth) > > all have a @see annotation pointing to a private constructor. This > makes the link in the generated docs do nothing. > > On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth > > wrote: > > I just filed a new issue to catch any last minute typos: > > https://bugs.openjdk.java.net/browse/JDK-8180070 > > > I'll add your note to this new JBS bug. > > Thank you. > > -- Kevin > > > > > Nir Lisker wrote: > > I'm looking at build 168 of JDK9 and there are a few mistakes > in the docs. > I can't submit issues to the JIRA so I'll list them here. A > similar issue > was https://bugs.openjdk.java.net/browse/JDK-8177341 > . > > > - The following use "a Observable..." instead of "an > Observable...". > - javafx.beans.property > - ListProperty > - MapProperty > - ReadOnlyListPropertyBase > - SetProperty > - javafx.beans.binding > - NumberExpression > - BooleanExpression > - DoubleExpression > - FloatExpression > - IntegerExpression > - ListExpression > - LongExpression > - MapExpression > - ObjectExpression > - SetExpression > - StringExpression > - javafx.scene.shape.ObservableFaceArray copies its > description > from its superinteface ObservableIntegerArray, does not > declare any API > methods and is listed under package javafx.scene.shape. > It's not clear at > all what this interface is. As it is, it looks like it's > not meant to be > exposed. > - javafx.collections.ObservableIntegerArray uses "a int[]" > instead of > "an int[]". This writing ("a int") is found in > java.lang.Integer as well in > a few places. > > Nir > > > From bourges.laurent at gmail.com Thu May 11 21:14:38 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 11 May 2017 23:14:38 +0200 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> Message-ID: Hi Jim, Please review this updated webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.1/ I mainly synchronized again all my Marlin repositories and this provides an up-to-date patch in synch with Marlin2D. Changes: - Renderer (4 variants): use shared memory among AA and NonAA renderer - Fixed comments in Helpers, XXXArrayCache - Marlin2D backports in ArrayCacheConst, Renderer ... - SWUtils: remove import + JavaShapeRenderer made static - fixed copyright year to 2017 You can see the incremental changes by comparing the openjfx10.patch: diff marlinFX-075.0/openjfx10.patch marlinFX-075.1/openjfx10.patch Regards, Laurent 2017-04-26 7:06 GMT+02:00 Jim Graham : > I've reviewed the code and run a number of tests. Things look fine. > > I spotted at least one thing that I brought up in the 2D Marlin review, > but since the 2 source bases are moving towards synchronizing with each > other I didn't look too closely since many of the changes in the 2D Marlin > update are things that are already "fixed" in this FX Marlin code, so I > thought I would focus my scrutiny more on the 2D review instead. Would this > code base be affected by the review comments I made there? Did you want to > hold both until they both are ready to go in and then push them at the same > time (to keep them in sync)? > > Minimally, it is time to file a bug against FX for this... > > ...jim > > > On 4/19/17 11:35 PM, Laurent Bourg?s wrote: > >> Hi, >> >> Please review this MarlinFX upgrade to Marlin 0.7.5: >> >> JBS: no bug yet for OpenJFX 10 >> webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/ >> >> Changes: >> - Renderers: fixed block processing >> - dead code & few comment removals in Strokers >> - fixed all floating-point number literals to be x.0f or x.0d to simplify >> the conversion between float & double variants >> >> PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools >> to fix any warning >> >> Cheers, >> Laurent >> >> -- -- Laurent Bourg?s From guru.hb at oracle.com Fri May 12 05:08:05 2017 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 12 May 2017 10:38:05 +0530 Subject: [10] Review request: 8179673: JVM Crash in WebPage.setBackgroundColor() during webpage navigation (Non Public API) Message-ID: Hi Arun, Murali & Kevin, Please review the fix for : https://bugs.openjdk.java.net/browse/JDK-8179673 Webrev : http://cr.openjdk.java.net/~ghb/8179673/webrev.00/ Thanks, Guru From james.graham at oracle.com Mon May 15 21:34:14 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 15 May 2017 14:34:14 -0700 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> Message-ID: <879bcc57-275b-c801-8427-c57ea248ff5a@oracle.com> Hi Laurent, I didn't notice anything functionally wrong with reviewing the webrev. I'm going to do some basic testing on it now while you create a JBS bug for it and submit for a formal review. But I did notice some discrepancies by diffing the sources against each other which it would be nice to know if they were oversights or "future work". If there is something you think should be addressed now, do that in the process of switching to a formal review (with JBS #) on it... I did a bit of diffing: - Marlin2D against MarlinFX - *NoAA against the AA versions and noticed: - RendererNoAA and DRendererNoAA line 38 are missing a "d" suffix. - RendererNoAA and DRendererNoAA lines 61,90 - missing comment about test - Helpers and DHelpers - some adjustment of "pts[ off+1 ]" lines that didn't happen in 2D - Configurable constants for Inc/Dec/Quad/Cubic in 2D, but not FX - DRendererSharedMemory in FX, but not 2D - FloatMath.ceil_f deleted from FX, but not 2D (not used in 2D) - (FloatMath.floor_f is also only in 2D, but it is used in MarlinRenderingEngine) ...jim On 5/11/17 2:14 PM, Laurent Bourg?s wrote: > Hi Jim, > > Please review this updated webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.1/ > > I mainly synchronized again all my Marlin repositories and this provides an > up-to-date patch in synch with Marlin2D. > > Changes: > - Renderer (4 variants): use shared memory among AA and NonAA renderer > - Fixed comments in Helpers, XXXArrayCache > - Marlin2D backports in ArrayCacheConst, Renderer ... > - SWUtils: remove import + JavaShapeRenderer made static > - fixed copyright year to 2017 > > You can see the incremental changes by comparing the openjfx10.patch: > diff marlinFX-075.0/openjfx10.patch marlinFX-075.1/openjfx10.patch > > Regards, > Laurent > > > 2017-04-26 7:06 GMT+02:00 Jim Graham : > >> I've reviewed the code and run a number of tests. Things look fine. >> >> I spotted at least one thing that I brought up in the 2D Marlin review, >> but since the 2 source bases are moving towards synchronizing with each >> other I didn't look too closely since many of the changes in the 2D Marlin >> update are things that are already "fixed" in this FX Marlin code, so I >> thought I would focus my scrutiny more on the 2D review instead. Would this >> code base be affected by the review comments I made there? Did you want to >> hold both until they both are ready to go in and then push them at the same >> time (to keep them in sync)? >> >> Minimally, it is time to file a bug against FX for this... >> >> ...jim >> >> >> On 4/19/17 11:35 PM, Laurent Bourg?s wrote: >> >>> Hi, >>> >>> Please review this MarlinFX upgrade to Marlin 0.7.5: >>> >>> JBS: no bug yet for OpenJFX 10 >>> webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/ >>> >>> Changes: >>> - Renderers: fixed block processing >>> - dead code & few comment removals in Strokers >>> - fixed all floating-point number literals to be x.0f or x.0d to simplify >>> the conversion between float & double variants >>> >>> PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools >>> to fix any warning >>> >>> Cheers, >>> Laurent >>> >>> > > From dipak.kumar at oracle.com Mon May 15 10:31:28 2017 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Mon, 15 May 2017 03:31:28 -0700 (PDT) Subject: [8] Code Review Request For 8180180: [Mac] WebView renders icons instead of letters on some sites Message-ID: <818935f8-2bc3-4edb-a1f0-efc7ded9b6d9@default> Hi Philip, Kevin and Arun, Please review the below changes: JBS: https://bugs.openjdk.java.net/browse/JDK-8180180 Webrev: http://cr.openjdk.java.net/~arajkumar/dipak/8180180/webrev/ Please note that this is a backport for JBS - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8088205"JDK-8088205 . Thanks, Dipak From kevin.rushforth at oracle.com Mon May 15 15:02:43 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 May 2017 08:02:43 -0700 Subject: [9] Review request: 8180337: JavaFX 9 msg drop 40 l10n resource file update In-Reply-To: <59171FFE.4010001@oracle.com> References: <59171FFE.4010001@oracle.com> Message-ID: <5919C313.5080608@oracle.com> I am posting this review on behalf of Leo Jiang (ljiang). https://bugs.openjdk.java.net/browse/JDK-8180337 http://cr.openjdk.java.net/~kcr/8180337/webrev/ This is the last planned translation drop for localized resource message for FX in JDK 9. -- Kevin From kevin.rushforth at oracle.com Mon May 15 14:30:53 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 May 2017 07:30:53 -0700 Subject: [8] Code Review Request For 8180180: [Mac] WebView renders icons instead of letters on some sites In-Reply-To: <818935f8-2bc3-4edb-a1f0-efc7ded9b6d9@default> References: <818935f8-2bc3-4edb-a1f0-efc7ded9b6d9@default> Message-ID: <5919BB9D.20605@oracle.com> Hi Dipak, Since this is the backport for JDK-8088205 the review should ideally be in a folder with that bug ID. Note that the commit message *must* use the base bugID and *never* the backport ID. Nothing should ever reference the backport ID, and the only thing that would go into the JBS issue is the changeset URL after the fix is pushed. All discussion, etc., happens in the main bug. -- Kevin Dipak Kumar wrote: > > Hi Philip, Kevin and Arun, > > > > Please review the below changes: > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8180180 > > Webrev: http://cr.openjdk.java.net/~arajkumar/dipak/8180180/webrev/ > > > > > Please note that this is a backport for JBS - JDK-8088205 > . > > > > Thanks, > > Dipak > > > From arunprasad.rajkumar at oracle.com Mon May 15 06:22:25 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 15 May 2017 11:52:25 +0530 Subject: [webkit] [10] 8178440: Build libxml2 and libxslt from source Message-ID: Hello Kevin, Please review the following changeset. JBS: https://bugs.openjdk.java.net/browse/JDK-8178440 Webrev: http://cr.openjdk.java.net/~arajkumar/8178440/webrev Regards, Arun From nlisker at gmail.com Tue May 16 19:07:06 2017 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 16 May 2017 22:07:06 +0300 Subject: Corrections for Javadoc In-Reply-To: <5914D162.8090302@oracle.com> References: <59133EDC.6040007@oracle.com> <5914D162.8090302@oracle.com> Message-ID: Another thing: javafx.scene.canvas.GraphicsContext should have a link to Canvas, either in the first sentence or as a @see, or both. On Fri, May 12, 2017 at 12:02 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > Added. This is a questionable use of @see anyway. > > Thanks. > > -- Kevin > > > Nir Lisker wrote: > > Add this to the list as well please: > > javafx.scene.image.Image's constructors: > > - Image(String url) > - Image(String url, boolean backgroundLoading) > - Image(String url, double requestedWidth, double requestedHeight, boolean > preserveRatio, boolean smooth) > > all have a @see annotation pointing to a private constructor. This makes > the link in the generated docs do nothing. > > On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I just filed a new issue to catch any last minute typos: >> >> https://bugs.openjdk.java.net/browse/JDK-8180070 >> >> I'll add your note to this new JBS bug. >> >> Thank you. >> >> -- Kevin >> >> >> >> >> Nir Lisker wrote: >> >>> I'm looking at build 168 of JDK9 and there are a few mistakes in the >>> docs. >>> I can't submit issues to the JIRA so I'll list them here. A similar issue >>> was https://bugs.openjdk.java.net/browse/JDK-8177341. >>> >>> >>> - The following use "a Observable..." instead of "an Observable...". >>> - javafx.beans.property >>> - ListProperty >>> - MapProperty >>> - ReadOnlyListPropertyBase >>> - SetProperty >>> - javafx.beans.binding >>> - NumberExpression >>> - BooleanExpression >>> - DoubleExpression >>> - FloatExpression >>> - IntegerExpression >>> - ListExpression >>> - LongExpression >>> - MapExpression >>> - ObjectExpression >>> - SetExpression >>> - StringExpression >>> - javafx.scene.shape.ObservableFaceArray copies its description >>> from its superinteface ObservableIntegerArray, does not declare any >>> API >>> methods and is listed under package javafx.scene.shape. It's not >>> clear at >>> all what this interface is. As it is, it looks like it's not meant to >>> be >>> exposed. >>> - javafx.collections.ObservableIntegerArray uses "a int[]" instead of >>> "an int[]". This writing ("a int") is found in java.lang.Integer as >>> well in >>> a few places. >>> >>> Nir >>> >>> >> > From kevin.rushforth at oracle.com Tue May 16 19:51:11 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 May 2017 12:51:11 -0700 Subject: Corrections for Javadoc In-Reply-To: References: <59133EDC.6040007@oracle.com> <5914D162.8090302@oracle.com> Message-ID: <591B582F.6060802@oracle.com> I added it to the list. Thanks. -- Kevin Nir Lisker wrote: > Another thing: > > javafx.scene.canvas.GraphicsContext should have a link to Canvas, > either in the first sentence or as a @see, or both. > > On Fri, May 12, 2017 at 12:02 AM, Kevin Rushforth > > wrote: > > Added. This is a questionable use of @see anyway. > > Thanks. > > -- Kevin > > > Nir Lisker wrote: >> Add this to the list as well please: >> >> javafx.scene.image.Image's constructors: >> >> - Image(String url) >> - Image(String url, boolean backgroundLoading) >> - Image(String url, double requestedWidth, double >> requestedHeight, boolean preserveRatio, boolean smooth) >> >> all have a @see annotation pointing to a private constructor. >> This makes the link in the generated docs do nothing. >> >> On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth >> > >> wrote: >> >> I just filed a new issue to catch any last minute typos: >> >> https://bugs.openjdk.java.net/browse/JDK-8180070 >> >> >> I'll add your note to this new JBS bug. >> >> Thank you. >> >> -- Kevin >> >> >> >> >> Nir Lisker wrote: >> >> I'm looking at build 168 of JDK9 and there are a few >> mistakes in the docs. >> I can't submit issues to the JIRA so I'll list them here. >> A similar issue >> was https://bugs.openjdk.java.net/browse/JDK-8177341 >> . >> >> >> - The following use "a Observable..." instead of "an >> Observable...". >> - javafx.beans.property >> - ListProperty >> - MapProperty >> - ReadOnlyListPropertyBase >> - SetProperty >> - javafx.beans.binding >> - NumberExpression >> - BooleanExpression >> - DoubleExpression >> - FloatExpression >> - IntegerExpression >> - ListExpression >> - LongExpression >> - MapExpression >> - ObjectExpression >> - SetExpression >> - StringExpression >> - javafx.scene.shape.ObservableFaceArray copies >> its description >> from its superinteface ObservableIntegerArray, does >> not declare any API >> methods and is listed under package >> javafx.scene.shape. It's not clear at >> all what this interface is. As it is, it looks like >> it's not meant to be >> exposed. >> - javafx.collections.ObservableIntegerArray uses "a >> int[]" instead of >> "an int[]". This writing ("a int") is found in >> java.lang.Integer as well in >> a few places. >> >> Nir >> >> >> > From bourges.laurent at gmail.com Tue May 16 21:11:09 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 16 May 2017 23:11:09 +0200 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: <879bcc57-275b-c801-8427-c57ea248ff5a@oracle.com> References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> <879bcc57-275b-c801-8427-c57ea248ff5a@oracle.com> Message-ID: Hi Jim, I didn't notice anything functionally wrong with reviewing the webrev. I'm > going to do some basic testing on it now while you create a JBS bug for it > and submit for a formal review. But I did notice some discrepancies by > diffing the sources against each other which it would be nice to know if > they were oversights or "future work". If there is something you think > should be addressed now, do that in the process of switching to a formal > review (with JBS #) on it... > I will create the JBS bug asap. > I did a bit of diffing: > > - Marlin2D against MarlinFX > - *NoAA against the AA versions > > and noticed: > Thanks for your carefull analysis, here are my comments below: - RendererNoAA and DRendererNoAA line 38 are missing a "d" suffix. > - RendererNoAA and DRendererNoAA lines 61,90 - missing comment about test > I forgot to synchronize recent changes into RendererNoAA variants: good catch ! > - Helpers and DHelpers - some adjustment of "pts[ off+1 ]" lines that > didn't happen in 2D > I decided to revert those minor syntax changes. > - Configurable constants for Inc/Dec/Quad/Cubic in 2D, but not FX > I hesitated but decided to backport the support for these configurable constants in all (D)Renderer(NoAA) (4 variants) > - DRendererSharedMemory in FX, but not 2D > > - FloatMath.ceil_f deleted from FX, but not 2D (not used in 2D) > - (FloatMath.floor_f is also only in 2D, but it is used in > MarlinRenderingEngine) > I decided to leave those FloatMath differences as Marlin2D (and FloatMath Tests) do use these methods. Finally I propose another MarlinFX webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/ Changes: - (D)Helpers: revert syntax changed in cubicRootsInAB() + fixed comment in subdivide() - (D)MarlinRenderingEngine: added logs for cubic/quad properties - (D)Renderer and (D)RendererNoAA: use cubic/quad properties like Marlin2D - (D)RendererNoAA: fixed syntax changes mentioned: missing "d" suffix + comment about test - MarlinProperties: added quality settings (cubic/quad) PS: I will send an updated webrev for the Marlin2D patch. Regards, Laurent From bourges.laurent at gmail.com Tue May 16 21:17:10 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 16 May 2017 23:17:10 +0200 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> <879bcc57-275b-c801-8427-c57ea248ff5a@oracle.com> Message-ID: One more comment about '(D)RendererSharedMemory in FX, but not 2D': This reduces the memory footprint of the RendererContext among Renderer and RendererNoAA implementations (shared arrays) that can co-exist at runtime if both AA and NonAA rendering is needed. As this behavior is unique to JavaFX, I wonder if it is worth to backport this small difference in Marlin2D where there will be no gain. Laurent 2017-05-16 23:11 GMT+02:00 Laurent Bourg?s : > Hi Jim, > > I didn't notice anything functionally wrong with reviewing the webrev. >> I'm going to do some basic testing on it now while you create a JBS bug for >> it and submit for a formal review. But I did notice some discrepancies by >> diffing the sources against each other which it would be nice to know if >> they were oversights or "future work". If there is something you think >> should be addressed now, do that in the process of switching to a formal >> review (with JBS #) on it... >> > > I will create the JBS bug asap. > > >> I did a bit of diffing: >> >> - Marlin2D against MarlinFX >> - *NoAA against the AA versions >> >> and noticed: >> > > Thanks for your carefull analysis, here are my comments below: > > - RendererNoAA and DRendererNoAA line 38 are missing a "d" suffix. >> - RendererNoAA and DRendererNoAA lines 61,90 - missing comment about test >> > > I forgot to synchronize recent changes into RendererNoAA variants: good > catch ! > > >> - Helpers and DHelpers - some adjustment of "pts[ off+1 ]" lines that >> didn't happen in 2D >> > > I decided to revert those minor syntax changes. > > >> - Configurable constants for Inc/Dec/Quad/Cubic in 2D, but not FX >> > > I hesitated but decided to backport the support for these configurable > constants in all (D)Renderer(NoAA) (4 variants) > > >> - DRendererSharedMemory in FX, but not 2D >> > > >> - FloatMath.ceil_f deleted from FX, but not 2D (not used in 2D) >> - (FloatMath.floor_f is also only in 2D, but it is used in >> MarlinRenderingEngine) >> > > I decided to leave those FloatMath differences as Marlin2D (and FloatMath > Tests) do use these methods. > > > Finally I propose another MarlinFX webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/ > > Changes: > - (D)Helpers: revert syntax changed in cubicRootsInAB() + fixed comment in > subdivide() > - (D)MarlinRenderingEngine: added logs for cubic/quad properties > - (D)Renderer and (D)RendererNoAA: use cubic/quad properties like Marlin2D > - (D)RendererNoAA: fixed syntax changes mentioned: missing "d" suffix + > comment about test > - MarlinProperties: added quality settings (cubic/quad) > > > PS: I will send an updated webrev for the Marlin2D patch. > > > Regards, > Laurent > -- -- Laurent Bourg?s From james.graham at oracle.com Tue May 16 21:27:12 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 16 May 2017 14:27:12 -0700 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> <879bcc57-275b-c801-8427-c57ea248ff5a@oracle.com> Message-ID: <468a101c-200e-fbcb-4e71-897b03f0809c@oracle.com> That's fine, I just wanted to make sure the difference was intentional and not something that fell through the cracks... ...jim On 5/16/17 2:17 PM, Laurent Bourg?s wrote: > One more comment about '(D)RendererSharedMemory in FX, but not 2D': > > This reduces the memory footprint of the RendererContext among Renderer and > RendererNoAA implementations (shared arrays) that can co-exist at runtime > if both AA and NonAA rendering is needed. > > As this behavior is unique to JavaFX, I wonder if it is worth to backport > this small difference in Marlin2D where there will be no gain. > > Laurent > > > 2017-05-16 23:11 GMT+02:00 Laurent Bourg?s : > >> Hi Jim, >> >> I didn't notice anything functionally wrong with reviewing the webrev. >>> I'm going to do some basic testing on it now while you create a JBS bug for >>> it and submit for a formal review. But I did notice some discrepancies by >>> diffing the sources against each other which it would be nice to know if >>> they were oversights or "future work". If there is something you think >>> should be addressed now, do that in the process of switching to a formal >>> review (with JBS #) on it... >>> >> >> I will create the JBS bug asap. >> >> >>> I did a bit of diffing: >>> >>> - Marlin2D against MarlinFX >>> - *NoAA against the AA versions >>> >>> and noticed: >>> >> >> Thanks for your carefull analysis, here are my comments below: >> >> - RendererNoAA and DRendererNoAA line 38 are missing a "d" suffix. >>> - RendererNoAA and DRendererNoAA lines 61,90 - missing comment about test >>> >> >> I forgot to synchronize recent changes into RendererNoAA variants: good >> catch ! >> >> >>> - Helpers and DHelpers - some adjustment of "pts[ off+1 ]" lines that >>> didn't happen in 2D >>> >> >> I decided to revert those minor syntax changes. >> >> >>> - Configurable constants for Inc/Dec/Quad/Cubic in 2D, but not FX >>> >> >> I hesitated but decided to backport the support for these configurable >> constants in all (D)Renderer(NoAA) (4 variants) >> >> >>> - DRendererSharedMemory in FX, but not 2D >>> >> >> >>> - FloatMath.ceil_f deleted from FX, but not 2D (not used in 2D) >>> - (FloatMath.floor_f is also only in 2D, but it is used in >>> MarlinRenderingEngine) >>> >> >> I decided to leave those FloatMath differences as Marlin2D (and FloatMath >> Tests) do use these methods. >> >> >> Finally I propose another MarlinFX webrev: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/ >> >> Changes: >> - (D)Helpers: revert syntax changed in cubicRootsInAB() + fixed comment in >> subdivide() >> - (D)MarlinRenderingEngine: added logs for cubic/quad properties >> - (D)Renderer and (D)RendererNoAA: use cubic/quad properties like Marlin2D >> - (D)RendererNoAA: fixed syntax changes mentioned: missing "d" suffix + >> comment about test >> - MarlinProperties: added quality settings (cubic/quad) >> >> >> PS: I will send an updated webrev for the Marlin2D patch. >> >> >> Regards, >> Laurent >> > > > From james.graham at oracle.com Tue May 16 22:17:23 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 16 May 2017 15:17:23 -0700 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> <879bcc57-275b-c801-8427-c57ea248ff5a@oracle.com> Message-ID: <60b56c26-2846-40a7-de14-f8db0361ed8d@oracle.com> This looks good. Did you create a JBS bug? ...jim On 5/16/17 2:11 PM, Laurent Bourg?s wrote: > Finally I propose another MarlinFX webrev: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/ > > Changes: > - (D)Helpers: revert syntax changed in cubicRootsInAB() + fixed comment in > subdivide() > - (D)MarlinRenderingEngine: added logs for cubic/quad properties > - (D)Renderer and (D)RendererNoAA: use cubic/quad properties like Marlin2D > - (D)RendererNoAA: fixed syntax changes mentioned: missing "d" suffix + > comment about test > - MarlinProperties: added quality settings (cubic/quad) > > > PS: I will send an updated webrev for the Marlin2D patch. > > > Regards, > Laurent > From kevin.rushforth at oracle.com Wed May 17 01:18:39 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 May 2017 18:18:39 -0700 Subject: [9] Review request: 8180064: Add missing copyright headers to package.html files Message-ID: <591BA4EF.8000605@oracle.com> Jonathan, Please review the following simple fix to add proper copyright headers to each package.html file and also the three other .html files in our doc-files directories: https://bugs.openjdk.java.net/browse/JDK-8180064 http://cr.openjdk.java.net/~kcr/8180064/webrev/ Thanks. -- Kevin From bourges.laurent at gmail.com Wed May 17 19:43:48 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 17 May 2017 21:43:48 +0200 Subject: [10] RFR Message-ID: Please review this MarlinFX upgrade, following recent changes in Marlin2D to synchronize Marlin 0.7.5 with OpenJDK & OpenJDK: JBS: https://bugs.openjdk.java.net/browse/JDK-8180449 (last) webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/ Changes: - Renderer (4 variants): use shared memory among AA and NonAA renderer - Renderers: fixed block processing - dead code & few comment removals in Strokers - added quality settings (cubic/quad) - fixed all floating-point number literals to be x.0f or x.0d to simplifythe conversion between float & double variants - many syntax & comment fixes This issue was discussed in the following threads: http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-April/020466.html http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-May/020554.html Cheers, Laurent From bourges.laurent at gmail.com Wed May 17 19:47:07 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 17 May 2017 21:47:07 +0200 Subject: [10] RFR 8180449: Upgrade the Marlin renderer in JavaFX Message-ID: Please review this MarlinFX upgrade, following recent changes in Marlin2D to synchronize Marlin 0.7.5 with OpenJDK & OpenJDK: JBS: https://bugs.openjdk.java.net/browse/JDK-8180449 (last) webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/ Changes: - Renderer (4 variants): use shared memory among AA and NonAA renderer - Renderers: fixed block processing - dead code & few comment removals in Strokers - added quality settings (cubic/quad) - fixed all floating-point number literals to be x.0f or x.0d to simplifythe conversion between float & double variants - many syntax & comment fixes This issue was discussed in the following threads: http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-April/020466.html http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-May/020554.html Cheers, Laurent From anthony.vanelverdinghe at gmail.com Fri May 19 16:51:16 2017 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Fri, 19 May 2017 18:51:16 +0200 Subject: JDK-8180368 javapackager and Maven Toolchains Message-ID: <15e70894-7ce6-e30e-5c3c-3061a4b2c45f@gmail.com> Hi This issue [1] was given lower priority because "reproducing the bug requires intentionally setting JAVA_HOME to old JDK and using files from new one". However, I just want to point out that this is not some artificial construction: Maven Toolchains [2] allow to build projects with a JDK which is different than the one Maven itself is running on. In my case, this issue was triggered by running Maven on JDK 8, while building with a JDK 9 toolchain. [1] https://bugs.openjdk.java.net/browse/JDK-8180368 [2] http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html Kind regards, Anthony From kamil.becmer at gmail.com Fri May 19 23:54:19 2017 From: kamil.becmer at gmail.com (Kamil Becmer) Date: Sat, 20 May 2017 01:54:19 +0200 Subject: RT-23952 Message-ID: I found a clever way to fix RT-23952, but I can't find corresponding ticket on bugs.openjdk.java.net. This RT is mentioned in com.sun.javafx.event.EventHandlerManager. Is there anyone who can check the status of this bug? Regards From kevin.rushforth at oracle.com Sat May 20 13:34:45 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 20 May 2017 06:34:45 -0700 Subject: RT-23952 In-Reply-To: References: Message-ID: <592045F5.6070402@oracle.com> You can go to http://bugs.openjdk.java.net/ and type in RT-23952 in the search box and it will take you there... or rather it would take you there, but the bug was mistakenly marked as Confidential. I fixed it so you should be able to see it now. -- Kevin Kamil Becmer wrote: > I found a clever way to fix RT-23952, but I can't find corresponding ticket > on bugs.openjdk.java.net. This RT is mentioned in > com.sun.javafx.event.EventHandlerManager. Is there anyone who can check the > status of this bug? > > Regards > From kamil.becmer at gmail.com Sat May 20 13:57:06 2017 From: kamil.becmer at gmail.com (Kamil Becmer) Date: Sat, 20 May 2017 15:57:06 +0200 Subject: RT-23952 In-Reply-To: <592045F5.6070402@oracle.com> References: <592045F5.6070402@oracle.com> Message-ID: Cool, thanks! 20.05.2017 3:34 PM "Kevin Rushforth" napisa?(a): > You can go to http://bugs.openjdk.java.net/ and type in RT-23952 in the > search box and it will take you there... or rather it would take you there, > but the bug was mistakenly marked as Confidential. I fixed it so you should > be able to see it now. > > -- Kevin > > > Kamil Becmer wrote: > >> I found a clever way to fix RT-23952, but I can't find corresponding >> ticket >> on bugs.openjdk.java.net. This RT is mentioned in >> com.sun.javafx.event.EventHandlerManager. Is there anyone who can check >> the >> status of this bug? >> >> Regards >> >> > From victor.drozdov at oracle.com Tue May 23 01:03:17 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Mon, 22 May 2017 18:03:17 -0700 Subject: [9] Review request: JDK-8180368: javapackager.exe fails to launch: Unrecognized option: -m Message-ID: Kevin, Please review my changes about removing the code that constructs java cmd based on JAVA_HOME. JIRA: https://bugs.openjdk.java.net/browse/JDK-8180368 Webrev: webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8180368/webrev.00/ --Victor From nlisker at gmail.com Tue May 23 16:11:00 2017 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 23 May 2017 19:11:00 +0300 Subject: Default PointLight for Scene Message-ID: A Scene supplies a default PointLight if it contains a 3D object. However, adding a Light to any group in the scene removes the default light. Is it possible to retain the light, or get a reference to it from the scene? From nlisker at gmail.com Tue May 23 16:19:39 2017 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 23 May 2017 19:19:39 +0300 Subject: Corrections for Javadoc In-Reply-To: <59133EDC.6040007@oracle.com> References: <59133EDC.6040007@oracle.com> Message-ID: Another typo: In javafx.scene.Scene, all onDragDone methods and the property use "@{code Scene}" instead of "{@code Scene}". On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth wrote: > I just filed a new issue to catch any last minute typos: > > https://bugs.openjdk.java.net/browse/JDK-8180070 > > I'll add your note to this new JBS bug. > > Thank you. > > -- Kevin > > > > > Nir Lisker wrote: > >> I'm looking at build 168 of JDK9 and there are a few mistakes in the docs. >> I can't submit issues to the JIRA so I'll list them here. A similar issue >> was https://bugs.openjdk.java.net/browse/JDK-8177341. >> >> >> - The following use "a Observable..." instead of "an Observable...". >> - javafx.beans.property >> - ListProperty >> - MapProperty >> - ReadOnlyListPropertyBase >> - SetProperty >> - javafx.beans.binding >> - NumberExpression >> - BooleanExpression >> - DoubleExpression >> - FloatExpression >> - IntegerExpression >> - ListExpression >> - LongExpression >> - MapExpression >> - ObjectExpression >> - SetExpression >> - StringExpression >> - javafx.scene.shape.ObservableFaceArray copies its description >> from its superinteface ObservableIntegerArray, does not declare any API >> methods and is listed under package javafx.scene.shape. It's not clear >> at >> all what this interface is. As it is, it looks like it's not meant to >> be >> exposed. >> - javafx.collections.ObservableIntegerArray uses "a int[]" instead of >> "an int[]". This writing ("a int") is found in java.lang.Integer as >> well in >> a few places. >> >> Nir >> >> > From kevin.rushforth at oracle.com Tue May 23 16:25:43 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 May 2017 09:25:43 -0700 Subject: Corrections for Javadoc In-Reply-To: References: <59133EDC.6040007@oracle.com> Message-ID: <59246287.6030409@oracle.com> Thanks. I'm a little surprised that doclint doesn't catch this one since it seems like it would be considered a malformed tag. As a note on timing, I plan to send out the webrev for this late this afternoon and push the changes on Thursday morning. -- Kevin Nir Lisker wrote: > Another typo: > > In javafx.scene.Scene, all onDragDone methods and the property use > "@{code Scene}" instead of "{@code Scene}". > > On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth > > wrote: > > I just filed a new issue to catch any last minute typos: > > https://bugs.openjdk.java.net/browse/JDK-8180070 > > > I'll add your note to this new JBS bug. > > Thank you. > > -- Kevin > > > > > Nir Lisker wrote: > > I'm looking at build 168 of JDK9 and there are a few mistakes > in the docs. > I can't submit issues to the JIRA so I'll list them here. A > similar issue > was https://bugs.openjdk.java.net/browse/JDK-8177341 > . > > > - The following use "a Observable..." instead of "an > Observable...". > - javafx.beans.property > - ListProperty > - MapProperty > - ReadOnlyListPropertyBase > - SetProperty > - javafx.beans.binding > - NumberExpression > - BooleanExpression > - DoubleExpression > - FloatExpression > - IntegerExpression > - ListExpression > - LongExpression > - MapExpression > - ObjectExpression > - SetExpression > - StringExpression > - javafx.scene.shape.ObservableFaceArray copies its > description > from its superinteface ObservableIntegerArray, does not > declare any API > methods and is listed under package javafx.scene.shape. > It's not clear at > all what this interface is. As it is, it looks like it's > not meant to be > exposed. > - javafx.collections.ObservableIntegerArray uses "a int[]" > instead of > "an int[]". This writing ("a int") is found in > java.lang.Integer as well in > a few places. > > Nir > > > From nlisker at gmail.com Tue May 23 16:33:04 2017 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 23 May 2017 19:33:04 +0300 Subject: Corrections for Javadoc In-Reply-To: <59246287.6030409@oracle.com> References: <59133EDC.6040007@oracle.com> <59246287.6030409@oracle.com> Message-ID: Yes, I saw that the due date on the report is the 24th. I don't know if it's worth anyone's time, but there are simple scripts that catch all sorts of spelling and grammar mistakes. Pretty sure it won't be that hard to integrate one. From nlisker at gmail.com Tue May 23 18:26:23 2017 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 23 May 2017 21:26:23 +0300 Subject: Corrections for Javadoc In-Reply-To: <59133EDC.6040007@oracle.com> References: <59133EDC.6040007@oracle.com> Message-ID: Hopefully this makes it in time: javafx.scene.control.TreeView has wrong javadoc for the queryAccessibleAttribute method. The source code uses javadoc blocks as titles, but they should probably be regular comment blocks. One of those blocks has been read as the doc for the method because that method has no doc. On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth wrote: > I just filed a new issue to catch any last minute typos: > > https://bugs.openjdk.java.net/browse/JDK-8180070 > > I'll add your note to this new JBS bug. > > Thank you. > > -- Kevin > > > > > Nir Lisker wrote: > >> I'm looking at build 168 of JDK9 and there are a few mistakes in the docs. >> I can't submit issues to the JIRA so I'll list them here. A similar issue >> was https://bugs.openjdk.java.net/browse/JDK-8177341. >> >> >> - The following use "a Observable..." instead of "an Observable...". >> - javafx.beans.property >> - ListProperty >> - MapProperty >> - ReadOnlyListPropertyBase >> - SetProperty >> - javafx.beans.binding >> - NumberExpression >> - BooleanExpression >> - DoubleExpression >> - FloatExpression >> - IntegerExpression >> - ListExpression >> - LongExpression >> - MapExpression >> - ObjectExpression >> - SetExpression >> - StringExpression >> - javafx.scene.shape.ObservableFaceArray copies its description >> from its superinteface ObservableIntegerArray, does not declare any API >> methods and is listed under package javafx.scene.shape. It's not clear >> at >> all what this interface is. As it is, it looks like it's not meant to >> be >> exposed. >> - javafx.collections.ObservableIntegerArray uses "a int[]" instead of >> "an int[]". This writing ("a int") is found in java.lang.Integer as >> well in >> a few places. >> >> Nir >> >> > From chien.yang at oracle.com Tue May 23 19:05:37 2017 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 23 May 2017 12:05:37 -0700 Subject: Default PointLight for Scene In-Reply-To: References: Message-ID: No, this light is created internally within JavaFX as a convenient light source if the scene doesn't have one. User can't access to it reference. You can find this information in the Scene class documentation: Class Scene ... A default headlight will be added to a scene that contains one or more Shape3D nodes, but no light nodes. This light source is a Color.WHITE PointLight placed at the camera position. - Chien On 05/23/2017 09:11 AM, Nir Lisker wrote: > A Scene supplies a default PointLight if it contains a 3D object. However, > adding a Light to any group in the scene removes the default light. Is it > possible to retain the light, or get a reference to it from the scene? From nlisker at gmail.com Tue May 23 19:12:21 2017 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 23 May 2017 22:12:21 +0300 Subject: Default PointLight for Scene In-Reply-To: References: Message-ID: Yes, I was referring to that line in the docs. Wouldn't it be better to allow users to retain the default light? On Tue, May 23, 2017 at 10:05 PM, Chien Yang wrote: > No, this light is created internally within JavaFX as a convenient light > source if the scene doesn't have one. User can't access to it reference. > > You can find this information in the Scene class documentation: > > Class Scene > > ... > > A default headlight will be added to a scene that contains one or more > Shape3D nodes, but no light nodes. This light source is a Color.WHITE > PointLight placed at the camera position. > > > - Chien > > > > > On 05/23/2017 09:11 AM, Nir Lisker wrote: > >> A Scene supplies a default PointLight if it contains a 3D object. However, >> adding a Light to any group in the scene removes the default light. Is it >> possible to retain the light, or get a reference to it from the scene? >> > > From kevin.rushforth at oracle.com Tue May 23 19:50:04 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 May 2017 12:50:04 -0700 Subject: Default PointLight for Scene In-Reply-To: References: Message-ID: <5924926C.7090900@oracle.com> It might be convenient to have a boolean on the scene to indicate whether it should be retained, but we don't plan any improvements to 3D in JDK 10 (which would be the absolute earliest such a change could happen). It seems it would be just as easy for an application to add a white point light at the camera, and that wouldn't have to wait until new API was added. -- Kevin Nir Lisker wrote: > Yes, I was referring to that line in the docs. > > Wouldn't it be better to allow users to retain the default light? > > On Tue, May 23, 2017 at 10:05 PM, Chien Yang wrote: > > >> No, this light is created internally within JavaFX as a convenient light >> source if the scene doesn't have one. User can't access to it reference. >> >> You can find this information in the Scene class documentation: >> >> Class Scene >> >> ... >> >> A default headlight will be added to a scene that contains one or more >> Shape3D nodes, but no light nodes. This light source is a Color.WHITE >> PointLight placed at the camera position. >> >> >> - Chien >> >> >> >> >> On 05/23/2017 09:11 AM, Nir Lisker wrote: >> >> >>> A Scene supplies a default PointLight if it contains a 3D object. However, >>> adding a Light to any group in the scene removes the default light. Is it >>> possible to retain the light, or get a reference to it from the scene? >>> >>> >> From kevin.rushforth at oracle.com Wed May 24 01:05:47 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 May 2017 18:05:47 -0700 Subject: [9] Review request: 8180070: Fix additional typos in API docs Message-ID: <5924DC6B.7080707@oracle.com> Jonathan, Please review the following fixes to various typos in the javadoc-generated API docs: https://bugs.openjdk.java.net/browse/JDK-8180070 http://cr.openjdk.java.net/~kcr/8180070/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Wed May 24 01:19:31 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 May 2017 18:19:31 -0700 Subject: [9] Review request: 8180338: Additional HTML5 cleanup Message-ID: <5924DFA3.40301@oracle.com> Hi Jon, Can you review this simple change to the three .html files (other than package.html) in the FX docs? https://bugs.openjdk.java.net/browse/JDK-8180338 http://cr.openjdk.java.net/~kcr/8180338/webrev.00/ Thanks. -- Kevin From tom.schindl at bestsolution.at Wed May 24 10:42:39 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 24 May 2017 12:42:39 +0200 Subject: javafx.scene.shape.Path (memory) inefficient PathElements In-Reply-To: References: Message-ID: Hi, I created: - https://bugs.openjdk.java.net/browse/JDK-8180935 - https://bugs.openjdk.java.net/browse/JDK-8180938 I'll work on a showcase to find out how much memory one can save. Tom On 04.05.17 23:33, Jim Graham wrote: > Hi Tom, > > Those look like good suggestions. I would file bugs in JBS and create > them separately: > > - Bug for lazy property creation in path elements > - Feature request for lower-memory paths > > Did you benchmark how much the lazy properties, on their own, would save > your application? > > ...jim > > On 5/4/17 2:22 PM, Tom Schindl wrote: >> Hi, >> >> We are currently working on a PDF-Rendering library in JavaFX and we >> need to draw glyphs using the JavaFX Path API (there are multiple >> reasons why we don't use the Text-Node and or Canvas). >> >> When drawing a page full of Text this means that we have a Path-Object >> with gazillions of MoveTo and CubicCurveTo elements who sum up to 30MB >> just to represent them in the SG because PathElements store their >> information in properties and forcefully intialize them in their >> constructor. >> >> The only public API to work around this problem is to construct a >> StringBuffer and use SVGPath which means: >> * it takes time to construct the SVG-Path-String >> * it takes time to parse the SVG-Path-String in JavaFX >> >> As an experiment (and because we are still on Java8 we can easily do >> that) was that we created our own Shape-Subclass who: >> * uses floats (there's no reason to use double in the SG when the >> backing API - Path2D - is float based) >> * passes the floats directly to the Path2D/NGPath API >> >> Guess what: We now need 2.5MB / page which means 27.5MB is the overhead >> added by the current Path-API - ouch! >> >> I think a fairly low hanging memory optimization for the PathElement >> would be to create properties lazy (only if someone access the property). >> >> For MoveTo this would mean the following minimal change (eg for the >> x-value): >> >> private DoubleProperty x; >> private double _x; >> >> public final void setX(double value) { >> if (x != null) { >> xProperty().set(value); >> } else { >> _x = value; >> u(); >> } >> } >> >> public final double getX() { >> return x == null ? _x : x.get(); >> } >> >> public final DoubleProperty xProperty() { >> if (x == null) { >> x = new DoublePropertyBase(_x) { >> >> @Override >> public void invalidated() { >> u(); >> } >> >> @Override >> public Object getBean() { >> return MoveTo.this; >> } >> >> @Override >> public String getName() { >> return "x"; >> } >> }; >> } >> return x; >> } >> >> I guess 99% of the code out there never access the Property so the small >> footprint added by the primitive field is justifiable. >> >> This still has the overhead of all the needless PathElement objects >> hanging around so another idea is to have a 3rd SG-Path-Type who >> strictly uses the float-Primitives with a similar API to Path2D (in fact >> it only acts as a public API to Path2D). >> >> Thoughts? >> >> Tom >> -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From james.graham at oracle.com Thu May 25 00:37:46 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 24 May 2017 17:37:46 -0700 Subject: javafx.scene.shape.Path (memory) inefficient PathElements In-Reply-To: References: Message-ID: Thanks Tom, I've already posted a patch for 8180938 (lazy property creation). Check it out and let me know how it performs for you. I have a couple of changes to make to it (and an independent memory usage test to write) before I send it out for formal review... ...jim On 5/24/17 3:42 AM, Tom Schindl wrote: > Hi, > > I created: > - https://bugs.openjdk.java.net/browse/JDK-8180935 > - https://bugs.openjdk.java.net/browse/JDK-8180938 > > I'll work on a showcase to find out how much memory one can save. > > Tom > > On 04.05.17 23:33, Jim Graham wrote: >> Hi Tom, >> >> Those look like good suggestions. I would file bugs in JBS and create >> them separately: >> >> - Bug for lazy property creation in path elements >> - Feature request for lower-memory paths >> >> Did you benchmark how much the lazy properties, on their own, would save >> your application? >> >> ...jim >> >> On 5/4/17 2:22 PM, Tom Schindl wrote: >>> Hi, >>> >>> We are currently working on a PDF-Rendering library in JavaFX and we >>> need to draw glyphs using the JavaFX Path API (there are multiple >>> reasons why we don't use the Text-Node and or Canvas). >>> >>> When drawing a page full of Text this means that we have a Path-Object >>> with gazillions of MoveTo and CubicCurveTo elements who sum up to 30MB >>> just to represent them in the SG because PathElements store their >>> information in properties and forcefully intialize them in their >>> constructor. >>> >>> The only public API to work around this problem is to construct a >>> StringBuffer and use SVGPath which means: >>> * it takes time to construct the SVG-Path-String >>> * it takes time to parse the SVG-Path-String in JavaFX >>> >>> As an experiment (and because we are still on Java8 we can easily do >>> that) was that we created our own Shape-Subclass who: >>> * uses floats (there's no reason to use double in the SG when the >>> backing API - Path2D - is float based) >>> * passes the floats directly to the Path2D/NGPath API >>> >>> Guess what: We now need 2.5MB / page which means 27.5MB is the overhead >>> added by the current Path-API - ouch! >>> >>> I think a fairly low hanging memory optimization for the PathElement >>> would be to create properties lazy (only if someone access the property). >>> >>> For MoveTo this would mean the following minimal change (eg for the >>> x-value): >>> >>> private DoubleProperty x; >>> private double _x; >>> >>> public final void setX(double value) { >>> if (x != null) { >>> xProperty().set(value); >>> } else { >>> _x = value; >>> u(); >>> } >>> } >>> >>> public final double getX() { >>> return x == null ? _x : x.get(); >>> } >>> >>> public final DoubleProperty xProperty() { >>> if (x == null) { >>> x = new DoublePropertyBase(_x) { >>> >>> @Override >>> public void invalidated() { >>> u(); >>> } >>> >>> @Override >>> public Object getBean() { >>> return MoveTo.this; >>> } >>> >>> @Override >>> public String getName() { >>> return "x"; >>> } >>> }; >>> } >>> return x; >>> } >>> >>> I guess 99% of the code out there never access the Property so the small >>> footprint added by the primitive field is justifiable. >>> >>> This still has the overhead of all the needless PathElement objects >>> hanging around so another idea is to have a 3rd SG-Path-Type who >>> strictly uses the float-Primitives with a similar API to Path2D (in fact >>> it only acts as a public API to Path2D). >>> >>> Thoughts? >>> >>> Tom >>> > > From kevin.rushforth at oracle.com Fri May 26 00:46:44 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 May 2017 17:46:44 -0700 Subject: [9] Review request: 8179644: Update copyright header for files modified in 2017 Message-ID: <59277AF4.7040407@oracle.com> Hi Chien, Please review the following simple fix to update the copyright header dates: https://bugs.openjdk.java.net/browse/JDK-8179644 http://cr.openjdk.java.net/~kcr/8179644/webrev/ Thanks. -- Kevin From kevin.rushforth at oracle.com Fri May 26 12:20:28 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 May 2017 05:20:28 -0700 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas Message-ID: <59281D8C.70106@oracle.com> I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. Ajit is a member of JavaFX team at Oracle, who has contributed 10 changesets to OpenJFX. A list of these changesets is available by the following link: http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 Votes are due by June 9, 2017. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks. -- Kevin [1] http://openjdk.java.net/census#aghaisas [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Fri May 26 12:20:54 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 May 2017 05:20:54 -0700 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: <59281DA6.4050007@oracle.com> Vote: YES Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 > changesets to OpenJFX. A list of these changesets is available by the > following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > From murali.billa at oracle.com Fri May 26 13:12:15 2017 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 26 May 2017 06:12:15 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281DA6.4050007@oracle.com> References: <59281D8C.70106@oracle.com> <59281DA6.4050007@oracle.com> Message-ID: Vote: YES Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 > changesets to OpenJFX. A list of these changesets is available by the > following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=autho > r%28aghaisas%29 > > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > From David.Hill at Oracle.com Fri May 26 14:37:58 2017 From: David.Hill at Oracle.com (David Hill) Date: Fri, 26 May 2017 10:37:58 -0400 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: <59283DC6.9090609@Oracle.com> On 5/26/17, 8:20 AM, Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. VOTE: yes > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 changesets to OpenJFX. A list of these changesets is available by the following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From semyon.sadetsky at oracle.com Fri May 26 15:10:21 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 26 May 2017 08:10:21 -0700 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: Vote: YES --Semyon On 05/26/2017 05:20 AM, Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 > changesets to OpenJFX. A list of these changesets is available by the > following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > From philip.race at oracle.com Fri May 26 15:32:46 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 May 2017 08:32:46 -0700 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: Vote: yes -phil. From jonathan.giles at oracle.com Fri May 26 16:21:58 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 26 May 2017 06:21:58 -1000 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: <95A707AF-72B2-40B6-AC0D-C5A72E46DC13@oracle.com> Vote: yes On May 26, 2017 2:20:28 AM HST, Kevin Rushforth wrote: >I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > >Ajit is a member of JavaFX team at Oracle, who has contributed 10 >changesets to OpenJFX. A list of these changesets is available by the >following link: > >http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > >Votes are due by June 9, 2017. > >Only current OpenJFX Committers [2] are eligible to vote on this >nomination. Votes must be cast in the open by replying to this mailing >list. > >For Lazy Consensus voting instructions, see [3]. Nomination to a >project >Committer is described in [4]. > >Thanks. > >-- Kevin > >[1] http://openjdk.java.net/census#aghaisas > >[2] http://openjdk.java.net/census#openjfx > >[3] http://openjdk.java.net/bylaws#lazy-consensus > >[4] http://openjdk.java.net/projects#project-committer From james.graham at oracle.com Fri May 26 21:25:47 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 26 May 2017 14:25:47 -0700 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: Vote: yes ...jim On 5/26/17 5:20 AM, Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 changesets to OpenJFX. A list of these changesets is > available by the following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > From nlisker at gmail.com Fri May 26 22:11:27 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 27 May 2017 01:11:27 +0300 Subject: Corrections for Javadoc In-Reply-To: References: <59133EDC.6040007@oracle.com> Message-ID: Looks like the above didn't make it in time. Can it be fixed in the next batch? On Tue, May 23, 2017 at 9:26 PM, Nir Lisker wrote: > Hopefully this makes it in time: > > javafx.scene.control.TreeView has wrong javadoc for the > queryAccessibleAttribute method. The source code uses javadoc blocks as > titles, but they should probably be regular comment blocks. > One of those blocks has been read as the doc for the method because that > method has no doc. > > On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I just filed a new issue to catch any last minute typos: >> >> https://bugs.openjdk.java.net/browse/JDK-8180070 >> >> I'll add your note to this new JBS bug. >> >> Thank you. >> >> -- Kevin >> >> >> >> >> Nir Lisker wrote: >> >>> I'm looking at build 168 of JDK9 and there are a few mistakes in the >>> docs. >>> I can't submit issues to the JIRA so I'll list them here. A similar issue >>> was https://bugs.openjdk.java.net/browse/JDK-8177341. >>> >>> >>> - The following use "a Observable..." instead of "an Observable...". >>> - javafx.beans.property >>> - ListProperty >>> - MapProperty >>> - ReadOnlyListPropertyBase >>> - SetProperty >>> - javafx.beans.binding >>> - NumberExpression >>> - BooleanExpression >>> - DoubleExpression >>> - FloatExpression >>> - IntegerExpression >>> - ListExpression >>> - LongExpression >>> - MapExpression >>> - ObjectExpression >>> - SetExpression >>> - StringExpression >>> - javafx.scene.shape.ObservableFaceArray copies its description >>> from its superinteface ObservableIntegerArray, does not declare any >>> API >>> methods and is listed under package javafx.scene.shape. It's not >>> clear at >>> all what this interface is. As it is, it looks like it's not meant to >>> be >>> exposed. >>> - javafx.collections.ObservableIntegerArray uses "a int[]" instead of >>> "an int[]". This writing ("a int") is found in java.lang.Integer as >>> well in >>> a few places. >>> >>> Nir >>> >>> >> > From arunprasad.rajkumar at oracle.com Sat May 27 10:36:05 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Sat, 27 May 2017 16:06:05 +0530 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: <36A762C5-5525-48C0-A17E-2A1FC158938F@oracle.com> Vote: YES > On 26-May-2017, at 5:50 PM, Kevin Rushforth wrote: > > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 changesets to OpenJFX. A list of these changesets is available by the following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > From kevin.rushforth at oracle.com Sat May 27 13:16:09 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 27 May 2017 06:16:09 -0700 Subject: Corrections for Javadoc In-Reply-To: References: <59133EDC.6040007@oracle.com> Message-ID: <59297C19.8050802@oracle.com> I missed seeing this comment so did not add it to JDK-8180070. Sorry about that. I filed a new bug for this one...currently it is assigned to 9, in case there is still time to get it fixed. https://bugs.openjdk.java.net/browse/JDK-8181169 -- Kevin Nir Lisker wrote: > Looks like the above didn't make it in time. Can it be fixed in the > next batch? > > On Tue, May 23, 2017 at 9:26 PM, Nir Lisker > wrote: > > Hopefully this makes it in time: > > javafx.scene.control.TreeView has wrong javadoc for the > queryAccessibleAttribute method. The source code uses javadoc > blocks as titles, but they should probably be regular comment blocks. > One of those blocks has been read as the doc for the method > because that method has no doc. > > On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth > > > wrote: > > I just filed a new issue to catch any last minute typos: > > https://bugs.openjdk.java.net/browse/JDK-8180070 > > > I'll add your note to this new JBS bug. > > Thank you. > > -- Kevin > > > > > Nir Lisker wrote: > > I'm looking at build 168 of JDK9 and there are a few > mistakes in the docs. > I can't submit issues to the JIRA so I'll list them here. > A similar issue > was https://bugs.openjdk.java.net/browse/JDK-8177341 > . > > > - The following use "a Observable..." instead of "an > Observable...". > - javafx.beans.property > - ListProperty > - MapProperty > - ReadOnlyListPropertyBase > - SetProperty > - javafx.beans.binding > - NumberExpression > - BooleanExpression > - DoubleExpression > - FloatExpression > - IntegerExpression > - ListExpression > - LongExpression > - MapExpression > - ObjectExpression > - SetExpression > - StringExpression > - javafx.scene.shape.ObservableFaceArray copies > its description > from its superinteface ObservableIntegerArray, does not > declare any API > methods and is listed under package javafx.scene.shape. > It's not clear at > all what this interface is. As it is, it looks like > it's not meant to be > exposed. > - javafx.collections.ObservableIntegerArray uses "a > int[]" instead of > "an int[]". This writing ("a int") is found in > java.lang.Integer as well in > a few places. > > Nir > > > > From alexander.zvegintsev at oracle.com Mon May 29 06:27:26 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 29 May 2017 09:27:26 +0300 Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: <59281D8C.70106@oracle.com> References: <59281D8C.70106@oracle.com> Message-ID: Vote: yes -- Thanks, Alexander. On 26.05.2017 15:20, Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 > changesets to OpenJFX. A list of these changesets is available by the > following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=author%28aghaisas%29 > > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > From a.ankit.srivastava at oracle.com Mon May 29 06:46:47 2017 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Sun, 28 May 2017 23:46:47 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Ajit Ghaisas In-Reply-To: References: <59281D8C.70106@oracle.com> <59281DA6.4050007@oracle.com> Message-ID: Vote: YES --Ankit -----Original Message----- From: Murali Billa Sent: Friday, May 26, 2017 6:42 PM To: openjfx-dev at openjdk.java.net; Ajit Ghaisas Subject: RE: CFV: New OpenJFX Committer: Ajit Ghaisas Vote: YES Kevin Rushforth wrote: > I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer. > > Ajit is a member of JavaFX team at Oracle, who has contributed 10 > changesets to OpenJFX. A list of these changesets is available by the > following link: > > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40&rev=autho > r%28aghaisas%29 > > > Votes are due by June 9, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#aghaisas > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > From ajit.ghaisas at oracle.com Mon May 29 08:36:49 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 29 May 2017 01:36:49 -0700 (PDT) Subject: [10] Review request : JDK-8089310 : [ContextMenu] Disabled Menu Rollover never receives Mouse hover Message-ID: Hi Jonathan, Request you to review following fix : Bug : https://bugs.openjdk.java.net/browse/JDK-8089310 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8089310/webrev.0/ Regards, Ajit From prem.balakrishnan at oracle.com Mon May 29 12:10:26 2017 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 29 May 2017 05:10:26 -0700 (PDT) Subject: [10] Review request: JDK-8088389 : [CSS, HighContrast] Menu - All the menu items look disabled on Mouse Click / Roll Over Message-ID: <3e97ace5-3362-406b-9799-55410d491176@default> Hi Jonathan, Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8088389 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8088389/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/fx/8088389/webrev.00/ Regards, Prem From ambarish.rapte at oracle.com Tue May 30 15:38:20 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 30 May 2017 08:38:20 -0700 (PDT) Subject: Review request : JDK-8181213 : [Tab] Tab content is not disabled when tab is disabled before content is set Message-ID: <1a9f0848-8154-4491-bad4-6a52449e6e53@default> Hi Jonathan & Ajit, Request you to review the fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8181213 Webrev: http://cr.openjdk.java.net/~arapte/fx/8181213/webrev.00/ Regards, Ambarish