From fastegal at openjdk.org Fri Nov 1 08:49:38 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 1 Nov 2019 08:49:38 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 31 Oct 2019 12:18:37 GMT, Nir Lisker wrote: > On Wed, 30 Oct 2019 14:01:58 GMT, Hadzic Samir wrote: > >> On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: >> >>> The pull request has been updated with additional changes. >>> >>> ---------------- >>> >>> Added commits: >>> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >>> >>> Changes: >>> - all: https://git.openjdk.java.net/jfx/pull/6/files >>> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >>> >>> Webrevs: >>> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >>> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >> >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 611: >> >>> 610: protected void resizeColumnToFitContent(int maxRows) { >>> 611: TableColumnBase tc = getTableColumn(); >>> 612: if (!tc.isResizable()) return; >> >> @nlisker I have added it this way. The auto-format of IntelliJ wanted to put the param before the implSpec but the documentation shows an example like that : >> >>> /** >>> * ... API specifications ... >>> * >>> * @apiNote >>> * ... API notes ... >>> * >>> * @implSpec >>> * ... implementation specification ... >>> * >>> * @implNote >>> * ... implementation notes ... >>> * >>> * @param ... >>> * @return ... >>> * @throws ... >>> */ >> >> So I thought this was the right way, let me know if I'm mistaken > > The generated docs will have the tags in the correct order as specified in the [build.gradle](https://github.com/openjdk/jfx/blob/master/build.gradle#L3953) file regardless of the order in the source code. This is what the [JDK](http://hg.openjdk.java.net/jdk/jdk/file/tip/make/Docs.gmk#l74) also uses and appears to be the same as the example you quoted. IntelliJ's order seems to be different. I would stick to JDK's order in the source as well just for consistency. looks good to me :) You would have to update the crs eventually, right? PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Fri Nov 1 10:59:57 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Fri, 1 Nov 2019 10:59:57 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Tue, 29 Oct 2019 13:19:27 GMT, Hadzic Samir wrote: > On Wed, 9 Oct 2019 16:01:38 GMT, Kevin Rushforth wrote: > >> On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: >> >>> On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: >>> >>>> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >>>> >>>>> Allright, this is a fix for JDK-8207957 >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 969ebb51: Fixing TableColumnHeaderTest >>>>> - 9d379619: Removing Tablecolumnbasehelper >>>>> - 4fe020fc: Fix javadoc for TableColumnHeader >>>>> - c422c80f: Minor modification and uni test added. >>>>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>>>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>>>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>>> >>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >>>> >>>>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>>>> 600: * {@code super()}) to provide their custom algorithm. >>>>> 601: * >>>> >>>> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) >>> >>> Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. >>> >>> I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. >> >> A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. > > Do you think this looks good now @kleopatra @nlisker ? Yes I was waiting for the final 'go'. I will update it asap, thanks Le ven. 1 nov. 2019 ? 09:49, Jeanette Winzenburg a ?crit : > *@kleopatra* commented on this pull request. > ------------------------------ > > In > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java > : > > > + * Resizes this {@code TableColumnHeader}'s column to fit the width of its content. > + * > + * @implSpec The resulting column width for this implementation is the maximum of the preferred width of the header > + * cell and the preferred width of the first {@code maxRow} cells. > + *

> + * Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their > + * custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum > + * width etc.). > + * > + * @param maxRows the number of rows considered when resizing. If -1 is given, all rows are considered. > + * @since 14 > > looks good to me :) You would have to update the crs eventually, right? > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > PR: https://git.openjdk.java.net/jfx/pull/6 From dlemmermann at gmail.com Mon Nov 4 13:51:11 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 4 Nov 2019 14:51:11 +0100 Subject: jpackage maven plugin Message-ID: Does anyone know if somebody has started work on a Maven plugin for jpackage? Dirk From aghaisas at openjdk.org Mon Nov 4 12:46:37 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 4 Nov 2019 12:46:37 GMT Subject: RFR: 8233040: ComboBoxPopupControl: remove eventFilter for F4 In-Reply-To: References: Message-ID: On Thu, 31 Oct 2019 21:20:55 GMT, Kevin Rushforth wrote: > On Thu, 31 Oct 2019 15:04:35 GMT, Jeanette Winzenburg wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8233040 >> >> The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. >> >> The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. >> >> ---------------- >> >> Commits: >> - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 >> >> Changes: https://git.openjdk.java.net/jfx/pull/28/files >> Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 >> Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod >> Patch: https://git.openjdk.java.net/jfx/pull/28.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 > > The PR title should match the bug title, so: > > 8233040: ComboBoxPopupControl: remove eventFilter for F4 > > @aghaisas can you review this, and also comment on whether you feel it needs a second reviewer (probably not unless you find something during the review that invites a more careful review). I can confirm that key F4 is managed even after removing this code block. PR: https://git.openjdk.java.net/jfx/pull/28 From aghaisas at openjdk.org Mon Nov 4 12:46:57 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 4 Nov 2019 12:46:57 GMT Subject: RFR: 8233040: Fix: ComboBoxPopupControl - remove eventFilter for F4 In-Reply-To: References: Message-ID: <9E-tymvO8mBa6HCEdTEh8ST-3d1TieJW1ou2v1GE1CU=.9e4824c4-b6cb-4267-b432-f6b328e7f2dc@github.com> On Thu, 31 Oct 2019 15:04:35 GMT, Jeanette Winzenburg wrote: > https://bugs.openjdk.java.net/browse/JDK-8233040 > > The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. > > The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. > > ---------------- > > Commits: > - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 > > Changes: https://git.openjdk.java.net/jfx/pull/28/files > Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 > Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/28.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboSpecialKeyTest.java line 1: > 1: /* > 2: * Created on 30.10.2019 This file needs to have a standard copyright header. Can be found in other test files. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 564: > 563: textField.fireEvent(ke); > 564: } > 565: } else if (ke.getCode() == KeyCode.F10 || ke.getCode() == KeyCode.ESCAPE) { Remove reference to "F4 key" in a comment present in this method. PR: https://git.openjdk.java.net/jfx/pull/28 From arapte at openjdk.org Tue Nov 5 06:28:33 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 5 Nov 2019 06:28:33 GMT Subject: [Rev 01] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: <1lm1yopfu5TCS3g_SvJksKuYu_mTLvjeaPn5JBtUcgI=.869a211e-ea1e-451b-8cf4-830ab4d89b64@github.com> References: <1lm1yopfu5TCS3g_SvJksKuYu_mTLvjeaPn5JBtUcgI=.869a211e-ea1e-451b-8cf4-830ab4d89b64@github.com> Message-ID: On Wed, 30 Oct 2019 20:46:53 GMT, Kevin Rushforth wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 5686a382: Update third-party license file to remove unneeded lines > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/26/files > - new: https://git.openjdk.java.net/jfx/pull/26/files/7a520adc..5686a382 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/26/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/26/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 > Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/26.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 modules/javafx.graphics/src/main/legal/mesa3d.md line 80: > 79: ---- > 80: include/GL/glext.h > 81: include/GL/glxext.h The copyright header of glx.h is not included here. Will it be good idea to include it ? looks good to me, posted a small query in mesa3d.md file. PR: https://git.openjdk.java.net/jfx/pull/26 From github.com+24428922+arun-Joseph at openjdk.org Tue Nov 5 06:59:25 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Tue, 5 Nov 2019 06:59:25 GMT Subject: RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 13:27:32 GMT, Kevin Rushforth wrote: > On Wed, 30 Oct 2019 11:09:38 GMT, Hadzic Samir wrote: > >> On Wed, 30 Oct 2019 10:07:42 GMT, Arun Joseph wrote: >> >>> In the HTMLEditor, when positioning the caret in a text and trying to set a font-family that has a number in it is not working. >>> >>> Issue: In [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp), concatenateFamilyName() function parses only identifiers. So, when a number is introduced in a font-name, it fails. >>> >>> Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes. >>> >>> A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf >>> >>> ---------------- >>> >>> Commits: >>> - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a number in it >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/27/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 >>> Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/27.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 >> >> Will this be in conflict with https://github.com/openjdk/jfx/pull/12 ? I'll look at your unit tests in order to implement one similar > > I would think that the two fixes are independent of one another, but it would be a good idea to test HTMLEditor with both patches applied. I tested HTMLEditor with both patches applied, and both fixes are working fine without any conflict. PR: https://git.openjdk.java.net/jfx/pull/27 From kcr at openjdk.org Tue Nov 5 08:37:37 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Nov 2019 08:37:37 GMT Subject: [Rev 01] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: <1lm1yopfu5TCS3g_SvJksKuYu_mTLvjeaPn5JBtUcgI=.869a211e-ea1e-451b-8cf4-830ab4d89b64@github.com> Message-ID: On Tue, 5 Nov 2019 06:28:33 GMT, Ambarish Rapte wrote: > On Wed, 30 Oct 2019 20:46:53 GMT, Kevin Rushforth wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 5686a382: Update third-party license file to remove unneeded lines >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/26/files >> - new: https://git.openjdk.java.net/jfx/pull/26/files/7a520adc..5686a382 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/26/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/26/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 >> Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod >> Patch: https://git.openjdk.java.net/jfx/pull/26.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 > > modules/javafx.graphics/src/main/legal/mesa3d.md line 80: > >> 79: ---- >> 80: include/GL/glext.h >> 81: include/GL/glxext.h > > The copyright header of glx.h is not included here. Will it be good idea to include it ? > > looks good to me, posted a small query in mesa3d.md file. The main license at the top of this file is the copyright header for `gl.h` and `glx.h`. In any case, this is as approved by our lawyers, so no changes should be made. PR: https://git.openjdk.java.net/jfx/pull/26 From github.com+24428922+arun-Joseph at openjdk.org Tue Nov 5 09:26:56 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Tue, 5 Nov 2019 09:26:56 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: <5sc2TcVxXD92jtPsDF4L5BvUSDrPDI-_Uwv_DRdonDo=.6ad0a745-e683-4ade-8080-644718a47fca@github.com> References: <5sc2TcVxXD92jtPsDF4L5BvUSDrPDI-_Uwv_DRdonDo=.6ad0a745-e683-4ade-8080-644718a47fca@github.com> Message-ID: On Thu, 10 Oct 2019 14:56:19 GMT, Hadzic Samir wrote: > On Thu, 10 Oct 2019 12:19:18 GMT, Kevin Rushforth wrote: > >> On Thu, 10 Oct 2019 09:12:57 GMT, Hadzic Samir wrote: >> >>> On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth wrote: >>> >>>> On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir wrote: >>>> >>>>> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: >>>>>> >>>>>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >>>>>>> >>>>>>> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>>>> >>>>>>> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>>>> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 >>>>>> >>>>>> @Maxoudela please edit the title as follows: >>>>>> >>>>>> 1. Remove the space before the `:` (that extra space is why jcheck failed) >>>>>> 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. >>>>>> >>>>>> As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: >>>>>> >>>>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >>>>> >>>>> Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. >>>>> >>>>> I'll try to add a test asap, thanks for the pointer. >>>> >>>>> I'm sorry for posting the Pull request like that >>>> >>>> No problem. I mainly wanted to make sure that you knew why the RFR wasn't sent. As for the note about the title matching, the contributing guidelines don't mention that and I now realize that they should -- I'll add that along with some other improvements I'll be making. >>>> >>>>> I'll try to add a test asap, thanks for the pointer. >>>> >>>> Great, thanks. >>> >>> Hum I do not succeed in running the existing test either. Here is my log. Apparently, the tests are failing because the WebView is null and not initialized. Do you have any clue of what I've been doing wrong? >>> >>> Should I try to update my gradle version and JDK version maybe? >>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >>> Starting a Gradle Daemon (subsequent builds will be faster) >>> >>>> Configure project : >>> MACOSX_MIN_VERSION = 10.9 >>> MACOSX_SDK_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk >>> ***************************************************************** >>> Unsupported gradle version 4.8 in use. >>> Only version 5.3 is supported. Use this version at your own risk >>> ***************************************************************** >>> gradle.gradleVersion: 4.8 >>> OS_NAME: mac os x >>> OS_ARCH: x86_64 >>> JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >>> JDK_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >>> java.runtime.version: 11.0.1+13 >>> java version: 11.0.1 >>> java build number: 13 >>> jdk.runtime.version: 11.0.1+13 >>> jdk version: 11.0.1 >>> jdk build number: 13 >>> minimum jdk version: 11 >>> minimum jdk build number: 28 >>> XCODE version: Xcode10.1-MacOSX10.14+1.0 >>> cmake version: 3.13.3 >>> ninja version: 1.8.2 >>> ant version: 1.10.5 >>> HAS_JAVAFX_MODULES: false >>> STUB_RUNTIME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >>> CONF: Debug >>> NUM_COMPILE_THREADS: 1 >>> COMPILE_TARGETS: mac >>> COMPILE_FLAGS_FILES: buildSrc/mac.gradle >>> HUDSON_JOB_NAME: not_hudson >>> HUDSON_BUILD_NUMBER: 0000 >>> PROMOTED_BUILD_NUMBER: 0 >>> PRODUCT_NAME: OpenJFX >>> RELEASE_VERSION: 14 >>> RELEASE_SUFFIX: -internal >>> RELEASE_VERSION_SHORT: 14-internal >>> RELEASE_VERSION_LONG: 14-internal+0-2019-10-10-110056 >>> RELEASE_VERSION_PADDED: 14.0.0.0 >>> MAVEN_VERSION: 14-internal+0-2019-10-10-110056 >>> UPDATE_STUB_CACHE: false >>> Building Webkit configuration /Release/ into /Users/shadzic/jfx/modules/javafx.web/build/mac >>> module: project ':apps' (buildModule=NO) >>> module: project ':base' (buildModule=YES) >>> module: project ':controls' (buildModule=YES) >>> module: project ':fxml' (buildModule=YES) >>> module: project ':graphics' (buildModule=YES) >>> module: project ':media' (buildModule=YES) >>> module: project ':swing' (buildModule=YES) >>> module: project ':swt' (buildModule=NO) >>> module: project ':systemTests' (buildModule=NO) >>> module: project ':web' (buildModule=YES) >>> >>>> Task :web:compileJava >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> >>>> Task :web:compileShimsJava >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> >>>> Task :web:compileTestJava >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> >>>> Task :systemTests:compileTestJava >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> >>>> Task :systemTests:test >>> >>> test.javafx.scene.web.HTMLEditorTest > checkStyleWithCSS FAILED >>> java.lang.NullPointerException >>> at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleWithCSS$7(HTMLEditorTest.java:192) >>> >>> test.javafx.scene.web.HTMLEditorTest > checkStyleProperty FAILED >>> java.lang.NullPointerException >>> at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleProperty$11(HTMLEditorTest.java:266) >>> >>> 3 tests completed, 2 failed, 1 skipped >>> >>>> Task :systemTests:test FAILED >> >> The test failure is almost certainly due to not having the native WebKit libraries. Two options: >> >> 1. You can build WebKit yourself (it's fairly painless on Mac) by running gradle with `-PCOMPILE_WEBKIT=true` >> 2. You can download libjfxwebkit.dylib from the openjfx14+1 EA build and put it in `../caches/modular-sdk/modules_libs/javafx.web/libjfxwebkit.dylib` > > Allright, I've been able to build the WebKit. > > I am now trying to add my test. I took some snippets from MiscellaneousTest and add my method to HTMLEditorTest: > > /** > * @test > * @bug 8230231 > * FIXME > */ > @Test > public void checkFontFamily() throws Exception { > final FontFaceTestHelper fontFaceHelper = new FontFaceTestHelper("src/test/resources/test/javafx/scene/web/Ahem.ttf"); > > > final CountDownLatch editorStateLatch = new CountDownLatch(1); > final AtomicReference result = new AtomicReference<>(); > Util.runAndWait(() -> { > webView.getEngine().loadContent("\n" + > "Toto Tutu\n" + > "\n", "text/html"); > > final JSObject window = (JSObject) webView.getEngine().executeScript("window"); > assertNotNull(window); > assertEquals("undefined", window.getMember("fontFaceHelper")); > window.setMember("fontFaceHelper", fontFaceHelper); > assertTrue(window.getMember("fontFaceHelper") instanceof FontFaceTestHelper); > // Create font-face object from byte[] > webView.getEngine().executeScript( > "var byteArray = new Uint8Array(fontFaceHelper.ttfFileContent);\n" + > "var arrayBuffer = byteArray.buffer;\n" + > "window.fontFace1 = new FontFace('WebFont test', arrayBuffer, {});" > ); > webView.getEngine().executeScript("document.execCommand('selectAll', false, 'true');"); > assertEquals("loaded", webView.getEngine().executeScript("fontFace1.status")); > // Add font-face to Document, so that it could be usable on styles > //webView.getEngine().executeScript( > // "document.fonts.add(fontFace1);\n" + > // "document.getElementById('probe1').style.fontFamily = 'WebFont test';\n" > //); > // webView.getEngine().getLoadWorker().stateProperty(). > // addListener((observable, oldValue, newValue) -> { > // if (newValue == SUCCEEDED) { > // htmlEditor.requestFocus(); > // } > // }); > > assertNotNull(fontFamilyComboBox); > assertFalse(fontFamilyComboBox.getItems().isEmpty()); > String theChosenOne = null; > for(String fontFamily: fontFamilyComboBox.getItems()){ > if(fontFamily.contains(" ")){ > theChosenOne = fontFamily; > break; > } > } > assertNotNull(theChosenOne); > //Select the font > fontFamilyComboBox.getSelectionModel().select(theChosenOne); > assertEquals(theChosenOne, fontFamilyComboBox.getSelectionModel().getSelectedItem()); > > webView.getEngine().executeScript("document.execCommand('selectAll', false, 'true');"); > > assertEquals(theChosenOne, fontFamilyComboBox.getSelectionModel().getSelectedItem()); > > > > editorStateLatch.countDown(); > }); > > assertTrue("Timeout when waiting for focus change ", Util.await(editorStateLatch)); > } > > where fontFamilyComboBox is retrieved like that : > fontFamilyComboBox = (ComboBox) htmlEditor.lookup(".font-menu-button"); > assertNotNull(fontFamilyComboBox); > > This idea is to add a Font family with a space in it, then apply it on the text. But I'm struggling to select a text portion, apply the font, then select elsewhere, and select back the text to demonstrate that the ComboBox is not updated. I tried to trigger some selectAll command but it's not working. > > If anyone has some ideas, I'm all ears. This bug still exists when the caret is placed on a text with the default font (""). PR: https://git.openjdk.java.net/jfx/pull/12 From arapte at openjdk.org Tue Nov 5 10:37:00 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 5 Nov 2019 10:37:00 GMT Subject: [Approved] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote: > This PR updates the header files we use the build the OpenGL ES2 pipeline to Mesa 19.2.1. See [this review thread](https://mail.openjdk.java.net/pipermail/2d-dev/2019-October/010372.html) for the equivalent change that is under review for Java2D. > > The updates to the `gl.h` and `glx.h` files are large, since we are many, many years behind. > > The `*ext.h` header files were updated fairly recently, so those diffs are not large. > > Previously we used to get the `*ext.h` headers from Khronos, but now we get all the headers from the Mesa project. > > This reduces the number of upstream sources we need to monitor. > > I note that with this update, the `glxext.h` and `wglext.h` files are slightly older in the Mesa bundle than in Khronos, but the differences are not relevant to FX. > > I did a full build and test on Mac and Linux and a sanity build (with `-PINCLUDE_ES2=true`) on Windows. I also verified that the build artifacts are unchanged. > > As with the Java2D change, the licensing terms are the same as before, but since we no longer get files directly from Khronos, the `opengl_fx.md` file is gone and the `mesa3d.md` is updated as required to mention these files. > > ---------------- > > Commits: > - 7a520adc: 8232210: Update Mesa 3-D Headers to version 19.2.1 > > Changes: https://git.openjdk.java.net/jfx/pull/26/files > Webrev: https://webrevs.openjdk.java.net/jfx/26/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232210 > Stats: 1515 lines in 8 files changed: 1076 ins; 269 del; 170 mod > Patch: https://git.openjdk.java.net/jfx/pull/26.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/26/head:pull/26 Approved by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/26 From fastegal at openjdk.org Tue Nov 5 10:38:23 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 5 Nov 2019 10:38:23 GMT Subject: [Rev 01] RFR: 8233040: ComboBoxPopupControl: remove eventFilter for F4 In-Reply-To: References: Message-ID: <3VL0RPPP5aPSllMTp3AqXc_6fF3g-BTZO2XFSV4FJPg=.051d1333-e9f0-4593-a12b-db03df50bbf9@github.com> The pull request has been updated with additional changes. ---------------- Added commits: - df3de536: changed as requested per review Changes: - all: https://git.openjdk.java.net/jfx/pull/28/files - new: https://git.openjdk.java.net/jfx/pull/28/files/2f015406..df3de536 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/28/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/28/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 PR: https://git.openjdk.java.net/jfx/pull/28 From fastegal at openjdk.org Tue Nov 5 10:38:24 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 5 Nov 2019 10:38:24 GMT Subject: RFR: 8233040: ComboBoxPopupControl: remove eventFilter for F4 In-Reply-To: <9E-tymvO8mBa6HCEdTEh8ST-3d1TieJW1ou2v1GE1CU=.9e4824c4-b6cb-4267-b432-f6b328e7f2dc@github.com> References: <9E-tymvO8mBa6HCEdTEh8ST-3d1TieJW1ou2v1GE1CU=.9e4824c4-b6cb-4267-b432-f6b328e7f2dc@github.com> Message-ID: On Mon, 4 Nov 2019 12:46:57 GMT, Ajit Ghaisas wrote: > On Thu, 31 Oct 2019 15:04:35 GMT, Jeanette Winzenburg wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8233040 >> >> The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. >> >> The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. >> >> ---------------- >> >> Commits: >> - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 >> >> Changes: https://git.openjdk.java.net/jfx/pull/28/files >> Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 >> Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod >> Patch: https://git.openjdk.java.net/jfx/pull/28.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboSpecialKeyTest.java line 1: > >> 1: /* >> 2: * Created on 30.10.2019 > > This file needs to have a standard copyright header. Can be found in other test files. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 564: > >> 563: textField.fireEvent(ke); >> 564: } >> 565: } else if (ke.getCode() == KeyCode.F10 || ke.getCode() == KeyCode.ESCAPE) { > > Remove reference to "F4 key" in a comment present in this method. Ajit, thanks for your review - changes pushed as suggested :) Noticed that I forgot the copyright headers in my other pull requests as well - should I add them now or wait until they are in review? PR: https://git.openjdk.java.net/jfx/pull/28 From kcr at openjdk.org Tue Nov 5 10:56:17 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Nov 2019 10:56:17 GMT Subject: RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 10:07:42 GMT, Arun Joseph wrote: > In the HTMLEditor, when positioning the caret in a text and trying to set a font-family that has a number in it is not working. > > Issue: In [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp), concatenateFamilyName() function parses only identifiers. So, when a number is introduced in a font-name, it fails. > > Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes. > > A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf > > ---------------- > > Commits: > - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a number in it > > Changes: https://git.openjdk.java.net/jfx/pull/27/files > Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 > Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/27.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java line 331: > 330: ComboBox fontFamilyComboBox = null; > 331: int i = 0; > 332: for(Node comboBox : htmlEditor.lookupAll(".font-menu-button")) { Please add a space after the `for` keyword. PR: https://git.openjdk.java.net/jfx/pull/27 From kcr at openjdk.org Tue Nov 5 10:56:18 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Nov 2019 10:56:18 GMT Subject: [Approved] RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 10:07:42 GMT, Arun Joseph wrote: > In the HTMLEditor, when positioning the caret in a text and trying to set a font-family that has a number in it is not working. > > Issue: In [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp), concatenateFamilyName() function parses only identifiers. So, when a number is introduced in a font-name, it fails. > > Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes. > > A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf > > ---------------- > > Commits: > - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a number in it > > Changes: https://git.openjdk.java.net/jfx/pull/27/files > Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 > Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/27.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 The fix and new test look good to me. I can confirm that the new test fails without the fix and passes with the fix. I left one minor formatting comment that you can correct before you integrate. Unless @Maxoudela has any concerns, I think this can go in with a single reviewer (or he may wish to be the second reviewer). ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/27 From github.com+24428922+arun-Joseph at openjdk.org Tue Nov 5 11:08:35 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Tue, 5 Nov 2019 11:08:35 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: References: <5sc2TcVxXD92jtPsDF4L5BvUSDrPDI-_Uwv_DRdonDo=.6ad0a745-e683-4ade-8080-644718a47fca@github.com> Message-ID: <807NKhSRXjlLn18IXMMGrlk72xPhRDvky1Q5t6ctc28=.ee2a0009-ba40-4232-b9ba-0c0fc9e81c46@github.com> On Tue, 5 Nov 2019 09:26:56 GMT, Arun Joseph wrote: > On Thu, 10 Oct 2019 14:56:19 GMT, Hadzic Samir wrote: > >> On Thu, 10 Oct 2019 12:19:18 GMT, Kevin Rushforth wrote: >> >>> On Thu, 10 Oct 2019 09:12:57 GMT, Hadzic Samir wrote: >>> >>>> On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth wrote: >>>> >>>>> On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir wrote: >>>>> >>>>>> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth wrote: >>>>>> >>>>>>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir wrote: >>>>>>> >>>>>>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >>>>>>>> >>>>>>>> Issue on JDK bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>>>>> >>>>>>>> I tried to add a test but I do not succeed at even running the existing Web tests.. I will need some help on that side.. >>>>>>>> >>>>>>>> ---------------- >>>>>>>> >>>>>>>> Commits: >>>>>>>> - e9df9db5: Adding double-quote for HTMLEditorSkin font-family >>>>>>>> >>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files >>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8230231 >>>>>>>> Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod >>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/12.diff >>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12 >>>>>>> >>>>>>> @Maxoudela please edit the title as follows: >>>>>>> >>>>>>> 1. Remove the space before the `:` (that extra space is why jcheck failed) >>>>>>> 2. Change the text of the title to match the JBS bug summary exactly. You can edit the JBS bug summary if you feel it needs to be changed, but in this case, the JBS bug has a title that is more in line with our usual practice of having the bug title be descriptive of what the problem is and not what the solution happens to be. >>>>>>> >>>>>>> As for unit tests, you will very likely need to add this as a system test under `tests/system/src/main/test`. See [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java). Presuming that you can add your test to that existing class, you would run it as follows: >>>>>>> >>>>>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >>>>>> >>>>>> Thanks @kevinrushforth . I'm sorry for posting the Pull request like that, I will thoroughly read the contributing guidelines and updates my PR accordingly. >>>>>> >>>>>> I'll try to add a test asap, thanks for the pointer. >>>>> >>>>>> I'm sorry for posting the Pull request like that >>>>> >>>>> No problem. I mainly wanted to make sure that you knew why the RFR wasn't sent. As for the note about the title matching, the contributing guidelines don't mention that and I now realize that they should -- I'll add that along with some other improvements I'll be making. >>>>> >>>>>> I'll try to add a test asap, thanks for the pointer. >>>>> >>>>> Great, thanks. >>>> >>>> Hum I do not succeed in running the existing test either. Here is my log. Apparently, the tests are failing because the WebView is null and not initialized. Do you have any clue of what I've been doing wrong? >>>> >>>> Should I try to update my gradle version and JDK version maybe? >>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest >>>> Starting a Gradle Daemon (subsequent builds will be faster) >>>> >>>>> Configure project : >>>> MACOSX_MIN_VERSION = 10.9 >>>> MACOSX_SDK_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk >>>> ***************************************************************** >>>> Unsupported gradle version 4.8 in use. >>>> Only version 5.3 is supported. Use this version at your own risk >>>> ***************************************************************** >>>> gradle.gradleVersion: 4.8 >>>> OS_NAME: mac os x >>>> OS_ARCH: x86_64 >>>> JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >>>> JDK_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >>>> java.runtime.version: 11.0.1+13 >>>> java version: 11.0.1 >>>> java build number: 13 >>>> jdk.runtime.version: 11.0.1+13 >>>> jdk version: 11.0.1 >>>> jdk build number: 13 >>>> minimum jdk version: 11 >>>> minimum jdk build number: 28 >>>> XCODE version: Xcode10.1-MacOSX10.14+1.0 >>>> cmake version: 3.13.3 >>>> ninja version: 1.8.2 >>>> ant version: 1.10.5 >>>> HAS_JAVAFX_MODULES: false >>>> STUB_RUNTIME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home >>>> CONF: Debug >>>> NUM_COMPILE_THREADS: 1 >>>> COMPILE_TARGETS: mac >>>> COMPILE_FLAGS_FILES: buildSrc/mac.gradle >>>> HUDSON_JOB_NAME: not_hudson >>>> HUDSON_BUILD_NUMBER: 0000 >>>> PROMOTED_BUILD_NUMBER: 0 >>>> PRODUCT_NAME: OpenJFX >>>> RELEASE_VERSION: 14 >>>> RELEASE_SUFFIX: -internal >>>> RELEASE_VERSION_SHORT: 14-internal >>>> RELEASE_VERSION_LONG: 14-internal+0-2019-10-10-110056 >>>> RELEASE_VERSION_PADDED: 14.0.0.0 >>>> MAVEN_VERSION: 14-internal+0-2019-10-10-110056 >>>> UPDATE_STUB_CACHE: false >>>> Building Webkit configuration /Release/ into /Users/shadzic/jfx/modules/javafx.web/build/mac >>>> module: project ':apps' (buildModule=NO) >>>> module: project ':base' (buildModule=YES) >>>> module: project ':controls' (buildModule=YES) >>>> module: project ':fxml' (buildModule=YES) >>>> module: project ':graphics' (buildModule=YES) >>>> module: project ':media' (buildModule=YES) >>>> module: project ':swing' (buildModule=YES) >>>> module: project ':swt' (buildModule=NO) >>>> module: project ':systemTests' (buildModule=NO) >>>> module: project ':web' (buildModule=YES) >>>> >>>>> Task :web:compileJava >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> >>>>> Task :web:compileShimsJava >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> >>>>> Task :web:compileTestJava >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> >>>>> Task :systemTests:compileTestJava >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> >>>>> Task :systemTests:test >>>> >>>> test.javafx.scene.web.HTMLEditorTest > checkStyleWithCSS FAILED >>>> java.lang.NullPointerException >>>> at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleWithCSS$7(HTMLEditorTest.java:192) >>>> >>>> test.javafx.scene.web.HTMLEditorTest > checkStyleProperty FAILED >>>> java.lang.NullPointerException >>>> at test.javafx.scene.web.HTMLEditorTest.lambda$checkStyleProperty$11(HTMLEditorTest.java:266) >>>> >>>> 3 tests completed, 2 failed, 1 skipped >>>> >>>>> Task :systemTests:test FAILED >>> >>> The test failure is almost certainly due to not having the native WebKit libraries. Two options: >>> >>> 1. You can build WebKit yourself (it's fairly painless on Mac) by running gradle with `-PCOMPILE_WEBKIT=true` >>> 2. You can download libjfxwebkit.dylib from the openjfx14+1 EA build and put it in `../caches/modular-sdk/modules_libs/javafx.web/libjfxwebkit.dylib` >> >> Allright, I've been able to build the WebKit. >> >> I am now trying to add my test. I took some snippets from MiscellaneousTest and add my method to HTMLEditorTest: >> >> /** >> * @test >> * @bug 8230231 >> * FIXME >> */ >> @Test >> public void checkFontFamily() throws Exception { >> final FontFaceTestHelper fontFaceHelper = new FontFaceTestHelper("src/test/resources/test/javafx/scene/web/Ahem.ttf"); >> >> >> final CountDownLatch editorStateLatch = new CountDownLatch(1); >> final AtomicReference result = new AtomicReference<>(); >> Util.runAndWait(() -> { >> webView.getEngine().loadContent("\n" + >> "Toto Tutu\n" + >> "\n", "text/html"); >> >> final JSObject window = (JSObject) webView.getEngine().executeScript("window"); >> assertNotNull(window); >> assertEquals("undefined", window.getMember("fontFaceHelper")); >> window.setMember("fontFaceHelper", fontFaceHelper); >> assertTrue(window.getMember("fontFaceHelper") instanceof FontFaceTestHelper); >> // Create font-face object from byte[] >> webView.getEngine().executeScript( >> "var byteArray = new Uint8Array(fontFaceHelper.ttfFileContent);\n" + >> "var arrayBuffer = byteArray.buffer;\n" + >> "window.fontFace1 = new FontFace('WebFont test', arrayBuffer, {});" >> ); >> webView.getEngine().executeScript("document.execCommand('selectAll', false, 'true');"); >> assertEquals("loaded", webView.getEngine().executeScript("fontFace1.status")); >> // Add font-face to Document, so that it could be usable on styles >> //webView.getEngine().executeScript( >> // "document.fonts.add(fontFace1);\n" + >> // "document.getElementById('probe1').style.fontFamily = 'WebFont test';\n" >> //); >> // webView.getEngine().getLoadWorker().stateProperty(). >> // addListener((observable, oldValue, newValue) -> { >> // if (newValue == SUCCEEDED) { >> // htmlEditor.requestFocus(); >> // } >> // }); >> >> assertNotNull(fontFamilyComboBox); >> assertFalse(fontFamilyComboBox.getItems().isEmpty()); >> String theChosenOne = null; >> for(String fontFamily: fontFamilyComboBox.getItems()){ >> if(fontFamily.contains(" ")){ >> theChosenOne = fontFamily; >> break; >> } >> } >> assertNotNull(theChosenOne); >> //Select the font >> fontFamilyComboBox.getSelectionModel().select(theChosenOne); >> assertEquals(theChosenOne, fontFamilyComboBox.getSelectionModel().getSelectedItem()); >> >> webView.getEngine().executeScript("document.execCommand('selectAll', false, 'true');"); >> >> assertEquals(theChosenOne, fontFamilyComboBox.getSelectionModel().getSelectedItem()); >> >> >> >> editorStateLatch.countDown(); >> }); >> >> assertTrue("Timeout when waiting for focus change ", Util.await(editorStateLatch)); >> } >> >> where fontFamilyComboBox is retrieved like that : >> fontFamilyComboBox = (ComboBox) htmlEditor.lookup(".font-menu-button"); >> assertNotNull(fontFamilyComboBox); >> >> This idea is to add a Font family with a space in it, then apply it on the text. But I'm struggling to select a text portion, apply the font, then select elsewhere, and select back the text to demonstrate that the ComboBox is not updated. I tried to trigger some selectAll command but it's not working. >> >> If anyone has some ideas, I'm all ears. > > This bug still exists when the caret is placed on a text with the default font (""). Applying this patch creates a new bug: Selecting text with multiple fonts in HTMLEditor sets the text to a single font. Steps to reproduce: Run the same sample program. Type "Hello world". Set "Hello" to FontA and "world" to FontB Select all (or right to left) using keyboard Expectation: "Hello world" is selected Observation: "Hello world" is selected and font changed to FontA PR: https://git.openjdk.java.net/jfx/pull/12 From aghaisas at openjdk.org Tue Nov 5 11:12:26 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 5 Nov 2019 11:12:26 GMT Subject: RFR: 8233040: ComboBoxPopupControl: remove eventFilter for F4 In-Reply-To: References: <9E-tymvO8mBa6HCEdTEh8ST-3d1TieJW1ou2v1GE1CU=.9e4824c4-b6cb-4267-b432-f6b328e7f2dc@github.com> Message-ID: On Tue, 5 Nov 2019 10:38:24 GMT, Jeanette Winzenburg wrote: > On Mon, 4 Nov 2019 12:46:57 GMT, Ajit Ghaisas wrote: > >> On Thu, 31 Oct 2019 15:04:35 GMT, Jeanette Winzenburg wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8233040 >>> >>> The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. >>> >>> The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. >>> >>> ---------------- >>> >>> Commits: >>> - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/28/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 >>> Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/28.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 >> >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboSpecialKeyTest.java line 1: >> >>> 1: /* >>> 2: * Created on 30.10.2019 >> >> This file needs to have a standard copyright header. Can be found in other test files. >> >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 564: >> >>> 563: textField.fireEvent(ke); >>> 564: } >>> 565: } else if (ke.getCode() == KeyCode.F10 || ke.getCode() == KeyCode.ESCAPE) { >> >> Remove reference to "F4 key" in a comment present in this method. > > Ajit, > > thanks for your review - changes pushed as suggested :) > > Noticed that I forgot the copyright headers in my other pull requests as well - should I add them now or wait until they are in review? It looks good to go. I think, one reviewer should suffice for this. For other PRs, we can deal with missing copyright headers as we review them. PR: https://git.openjdk.java.net/jfx/pull/28 From aghaisas at openjdk.org Tue Nov 5 11:13:01 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 5 Nov 2019 11:13:01 GMT Subject: [Approved] RFR: 8233040: ComboBoxPopupControl: remove eventFilter for F4 In-Reply-To: References: Message-ID: <19F67wUUYZ9cIuBLV2_qjpPynZp4nNU7Y1bnXvrfiKA=.ab603534-0a41-41cf-84f4-33aea7b6d881@github.com> On Thu, 31 Oct 2019 15:04:35 GMT, Jeanette Winzenburg wrote: > https://bugs.openjdk.java.net/browse/JDK-8233040 > > The issue is that the eventFilter in CBPC uses F4 for toggling the popup _and_ consumes it. This prevents client code to register there own filter. > > The fix was to remove the block entirely - F4 is already handled by a keyMapping in ComboBoxBehaviorBase. Added test that fails before the change and passes after, old tests are all passing. > > ---------------- > > Commits: > - 2f015406: Fix: ComboBoxPopupControl - remove eventFilter for F4 > > Changes: https://git.openjdk.java.net/jfx/pull/28/files > Webrev: https://webrevs.openjdk.java.net/jfx/28/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233040 > Stats: 159 lines in 2 files changed: 153 ins; 6 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/28.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/28/head:pull/28 Approved by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/28 From github.com+24428922+arun-Joseph at openjdk.org Tue Nov 5 11:17:55 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Tue, 5 Nov 2019 11:17:55 GMT Subject: [Rev 01] RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - afc7f17a: Minor formatting Changes: - all: https://git.openjdk.java.net/jfx/pull/27/files - new: https://git.openjdk.java.net/jfx/pull/27/files/5a1fbade..afc7f17a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/27/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/27/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 PR: https://git.openjdk.java.net/jfx/pull/27 From kcr at openjdk.org Tue Nov 5 11:28:19 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Nov 2019 11:28:19 GMT Subject: [Integrated] RFR: 8232210: Update Mesa 3-D Headers to version 19.2.1 In-Reply-To: References: Message-ID: <90ac1ee3-264b-4d43-96cb-38840a8209fa@openjdk.org> Changeset: a1cc4ab0 Author: Kevin Rushforth Date: 2019-11-05 11:27:22 +0000 URL: https://git.openjdk.java.net/jfx/commit/a1cc4ab0 8232210: Update Mesa 3-D Headers to version 19.2.1 Reviewed-by: prr, arapte ! modules/javafx.graphics/src/main/legal/mesa3d.md - modules/javafx.graphics/src/main/legal/opengl_fx.md ! modules/javafx.graphics/src/main/native-prism-es2/GL/gl.h ! modules/javafx.graphics/src/main/native-prism-es2/GL/glext.h ! modules/javafx.graphics/src/main/native-prism-es2/GL/glx.h ! modules/javafx.graphics/src/main/native-prism-es2/GL/glxext.h ! modules/javafx.graphics/src/main/native-prism-es2/GL/wglext.h ! modules/javafx.graphics/src/main/native-prism-es2/KHR/khrplatform.h From aghaisas at openjdk.org Tue Nov 5 12:09:15 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 5 Nov 2019 12:09:15 GMT Subject: [Integrated] RFR: 8233040: Fix: ComboBoxPopupControl - remove eventFilter for F4 In-Reply-To: References: Message-ID: Changeset: f74f3afb Author: Jeanette Winzenburg Committer: Ajit Ghaisas Date: 2019-11-05 12:08:33 +0000 URL: https://git.openjdk.java.net/jfx/commit/f74f3afb 8233040: ComboBoxPopupControl: remove eventFilter for F4 Reviewed-by: aghaisas ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java + modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboSpecialKeyTest.java From fastegal at openjdk.org Tue Nov 5 15:43:03 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 5 Nov 2019 15:43:03 GMT Subject: [Rev 01] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: <_s7efFv1cD4OqI7IYn25ruL2BU4cKMbJXvKMiNn0Aug=.5119a5b7-c13b-43c1-8cd8-b77778345583@github.com> The pull request has been updated with additional changes. ---------------- Added commits: - 0366a0a5: added copyright header Changes: - all: https://git.openjdk.java.net/jfx/pull/20/files - new: https://git.openjdk.java.net/jfx/pull/20/files/aabea139..0366a0a5 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/20/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 PR: https://git.openjdk.java.net/jfx/pull/20 From fastegal at openjdk.org Tue Nov 5 15:51:07 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 5 Nov 2019 15:51:07 GMT Subject: [Rev 01] RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - fdf97072: added copyright headers Changes: - all: https://git.openjdk.java.net/jfx/pull/15/files - new: https://git.openjdk.java.net/jfx/pull/15/files/93556393..fdf97072 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/15/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/15/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8207759 Stats: 114 lines in 5 files changed: 109 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15 PR: https://git.openjdk.java.net/jfx/pull/15 From swpalmer at gmail.com Tue Nov 5 17:03:02 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 5 Nov 2019 12:03:02 -0500 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <1c664471-9682-231d-aa8b-3d93a3db9d12@oracle.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> <99C8989F-13AD-46D0-A004-735FFBBDBBC0@gmail.com> <1c664471-9682-231d-aa8b-3d93a3db9d12@oracle.com> Message-ID: I finally had a moment to get back at this. I've changed the name of the property from tabWidth to tabSize and implemented the CSS property '-fx-tab-size'. The CSS documentation will need to be updated. I didn't see where the CSS document is located in the source tree. While adding CSS support I noticed that in both Text.java and TextFlow.java the indentation is wrong for the StyleableProperties nested class (has one extra space). I wasn't sure how much I should change in the scope of this feature. If I don't fix some indenting my changes will look funny beside the lines of existing code. If I fix all of the broken indenting I'll change a lot of lines that have nothing to do with this feature. If I just properly indent the lines I change or add, the indenting will be more chaotic than it is currently. I have noticed a rendering anomaly with a tab size of zero (the value I was initially clamping to) and rather than dealing with that I took the easy way out and changed it to agree with the minimum of 1 that Kevin indicated for the range. I have not limited the maximum tab size. I know Phil has expressed that MAXINT is not his preference, but I can't think of a good criteria for what the maximum should be. I can imagine someone using a tab separator to align columns of text that have much more than 16 characters for example. I did a quick test with the tab size set to Integer.MAX_VALUE-1 and nothing blew up. Of course the text after the tab was nowhere to be seen. Regards, Scott On Thu, Oct 17, 2019 at 3:42 PM Phil Race wrote: > > > On 10/17/19 12:32 PM, Kevin Rushforth wrote: > > It seems that you have a path forward then. So, there are a couple > > questions to answer: > > > > 1. Should the type of the property be int or double? If it really is > > only ever going to be a number of spaces, then int seems fine. That, > > along with the name of the property, would underscore the fact that > > no, this isn't a size where units make sense; it's a number of spaces. > > A discrete number of spaces, so int. > > > > > 2. Should the range be [1,MAXINT] or [1,16] or [1,something-else]? > > Once that is decided, I think clamp on use would be the most > > consistent with other similar properties, but that's worth checking. > > If we go with "MAXINT" (which is not my preference), I think there'd > need to be some testing of > the various code paths and pipelines to be sure that various values from > large, through extreme, > all do something sensible, and of course, no exceptions or crashes. > > Various code paths means Text, TextFlow, linewrapping or not ... > complex text and simple text too. > Perhaps complex text should be tested anyway, although I've been > assuming that we are handling > tab spacing outside of that but didn't verify it. > > -phil. > > > > > -- Kevin > > > > > > On 10/17/2019 12:11 PM, Scott Palmer wrote: > >> You?re right. Something I was reading indicated that while there was > >> no default unit, ?px? was implicitly appended. I can?t find that > >> now. Go figure. > >> > >> Everything I find now about CSS tab-size is in agreement with what > >> David wrote. It?s a number of spaces. With units it would be a > >> ?length? but nothing supports that. > >> > >> So I think it makes sense to add -fx-tab-size as a CSS property, only > >> supporting a number with no units. > >> > >> Scott > >> > >> > >>> On Oct 17, 2019, at 2:32 PM, Phil Race wrote: > >>> > >>> Really ? It defaults to pixels ? Is that just inherited as being the > >>> default CSS unit ? > >>> Is that FX's implementation > >>> > >>> Hmm. A bit of reading about web CSS says that strictly anything > >>> without an explicit unit should be ignored. > >>> The only exception is zero, where it doesn't matter. > >>> > >>> Eg see : > >>> https://stackoverflow.com/questions/7907749/default-unit-for-font-size > >>> > >>> Although I am sure there are more authoratative sources than that. > >>> > >>> -phil. > >>> > >>> On 10/17/19 11:22 AM, Scott Palmer wrote: > >>>> So do we go ahead and implement tabSize without the CSS support? > >>>> I?m not sure the CSS property should be added before unit issues > >>>> are worked out, as I think the units would be expected in the CSS > >>>> context. E.g. CSS implicitly adds ?px? if no unit is specified. If > >>>> our tabSize units are spaces, that breaks. > >>>> > >>>> Scott > >>>> > >>>>> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth > >>>>> wrote: > >>>>> > >>>>> It might make sense to just add the tabSize property now, and > >>>>> later consider adding a tabUnits property in the future if needed. > >>>>> By default, having the units be "number of spaces in the current > >>>>> font" is what makes the most sense, so before we could add > >>>>> tabUnits we would need to extend it as you suggest. I'm not sure > >>>>> it's needed, though, so that would be another reason not to do it > >>>>> now. > >>>>> > >>>>> It's probably best to have the type of tabSize be double rather > >>>>> than int. We do this for most attributes to leave the door open > >>>>> for fractional values. I don't know why anyone would want a tab > >>>>> that was 5.7 spaces, but if we ever were to add a tabUnits > >>>>> property, I could easily see wanting fractional values for some > >>>>> units. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> On 10/17/2019 10:40 AM, Scott Palmer wrote: > >>>>>> Hi Phil, > >>>>>> > >>>>>> Thanks for taking a look. I was going to get back to this soon > >>>>>> to attempt adding the CSS property as you mention in your > >>>>>> previous email. I considered tabSize as a name as well. I don?t > >>>>>> have a preference if we leave things as representing tabs as a > >>>>>> number of spaces. But it wouldn?t be too difficult to support > >>>>>> units, making it mostly compatible with CSS rules. The way I > >>>>>> envision that is having two properties, tabSize and tabUnit. > >>>>>> > >>>>>> David mentioned javafx.css.SizeUnits? I looked quickly at the > >>>>>> java docs for it, and it?s basically undocumented . So I went to > >>>>>> https://www.w3.org/TR/css-values-3/#lengths and I see there is no > >>>>>> CSS unit like ?ems? but meaning the width of a space in the > >>>>>> current font. The problem with that is it would leave out the > >>>>>> possibility to set the tab width to anything relative to the > >>>>>> current implementation of 8 spaces. (In hindsight it should have > >>>>>> been implemented based on ?ems?, which for a fixed width font as > >>>>>> typically used in a code editor would be the same as 8 spaces > >>>>>> anyway) > >>>>>> Do we add something to SizeUnits so we can work around this? > >>>>>> e.g. ?fxsp? (FX-space - fx prefix to avoid a potential collision > >>>>>> with any future official CSS units) > >>>>>> > >>>>>> // Two tab-related properties > >>>>>> public void setTabSize(int size); // defaults to 8 > >>>>>> public void setTabUnits(SizeUnits units); // ?? no unit for width > >>>>>> of space in current font > >>>>>> > >>>>>> If we did the above, I would consider adding this for convenience: > >>>>>> public void setTabWidth(int size, TabUnits units); > >>>>>> > >>>>>> As far as setting a range, I?m not sure there is any worthwhile > >>>>>> benefit to enforcing a maximum. If we want to store the value in > >>>>>> a short instead of an int to potentially save a couple bytes, > >>>>>> sure. Otherwise, if someone wants to set tabs to be 20 spaces or > >>>>>> 100, why should we prevent it? If there isn't a performance or > >>>>>> memory impact, I wouldn?t enforce a maximum. > >>>>>> > >>>>>> Ignoring any out of range values rather than clamping seems fine > >>>>>> to me as well. I was thinking of what happens if the value was > >>>>>> bound to another value that strayed out of range. Clamping would > >>>>>> get you as close as possible to the bound value, rather than > >>>>>> stuck at the previously observed value. I just guessed that > >>>>>> would be preferred, but if ignoring is more consistent with other > >>>>>> values, then I agree it makes sense. As long as the behaviour is > >>>>>> documented, I can?t think of any significant downside either way. > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Scott > >>>>>> > >>>>>> > >>>>>>> On Oct 17, 2019, at 12:45 PM, Phil Race > >>>>>>> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Some more points which I thought about but for whatever reason > >>>>>>> did not pen .. > >>>>>>> > >>>>>>> First one minor thing: tabWidth is an OK name, but it does not > >>>>>>> conjure up that the value you specify isn't a width in pixels > >>>>>>> but the > >>>>>>> number of discrete space characters to use. FWIW CSS calls it > >>>>>>> tab-size. > >>>>>>> But CSS then supports pixels and ems .. that complicates matters > >>>>>>> a lot. > >>>>>>> > >>>>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size > >>>>>>> > >>>>>>> Thee rest is mostly to do with "legal or sensible values" > >>>>>>> > >>>>>>> You have : > >>>>>>> if (spaces < 0) > >>>>>>> spaces = 0; > >>>>>>> > >>>>>>> since negative values are not something we want to support! > >>>>>>> But I think instead of clamping you could "ignore", any out of > >>>>>>> range value. > >>>>>>> This is practiced elsewhere in FX where illegal values are > >>>>>>> ignored rather than > >>>>>>> throwing an exception, although it might be that clamping is > >>>>>>> quite common > >>>>>>> in range cases. > >>>>>>> > >>>>>>> The follow on to that is that what is a sensible maximum value. > >>>>>>> Currently we have int which is more than we need. For that > >>>>>>> matter so is short. > >>>>>>> I think we should have a documented and enforced sensible maximum. > >>>>>>> Perhaps it could be "8" meaning we only support reducing tab > >>>>>>> width as I > >>>>>>> don't know if anyone really wants to increase it. > >>>>>>> CSS doesn't have a limit that I can see but if we are already > >>>>>>> only supporting > >>>>>>> it described as number of spaces, we can have this other > >>>>>>> limitation too. > >>>>>>> If you think 8 is too small, then maybe 16 ? > >>>>>>> Also remember we can compatibly relax it later but we can't > >>>>>>> compatibly tighten it. > >>>>>>> > >>>>>>> > >>>>>>> -phil. > >>>>>>> > >>>>>>> On 10/15/19 12:17 PM, Phil Race wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I've looked over this and I don't see any issues - meaning > >>>>>>>> gotchas. > >>>>>>>> It just provides a way to over-ride the hard-coded 8, > >>>>>>>> whether using a Text node directly or a TextFlow. > >>>>>>>> > >>>>>>>> Two observations of what one might call limitations > >>>>>>>> 1) This is a rendering time property, which is controlled by > >>>>>>>> the program. > >>>>>>>> A document containing tabs saved and re-rendered somewhere else > >>>>>>>> won't be helped. > >>>>>>>> > >>>>>>>> 2) This just provides API on the scene graph node types, not > >>>>>>>> any of the UI controls > >>>>>>>> which use Text nodes. Something like a CSS property may be the > >>>>>>>> way to go if > >>>>>>>> you wanted that. > >>>>>>>> Text has a nested class StyleableProperties for CSS properties > >>>>>>>> with which it > >>>>>>>> plays nice : font, underline, strikethrough, text-alignment > >>>>>>>> > >>>>>>>> So creating an fx-tabWidth (or similar name) CSS property could > >>>>>>>> be propagated > >>>>>>>> through to there in a similar way. > >>>>>>>> > >>>>>>>> -phil. > >>>>>>>> > >>>>>>>> > >>>>>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: > >>>>>>>>> Okay, current work relocated to a clone of the new official > >>>>>>>>> Git repo. > >>>>>>>>> My initial implementation is here: > >>>>>>>>> > https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f > >>>>>>>>> < > https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f> > > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I would submit it as a pull request but that seems premature > >>>>>>>>> since there hasn?t been any real discussion of challenges I?ve > >>>>>>>>> overlooked. All I have are the famous last words, ?It works > >>>>>>>>> for me.? > >>>>>>>>> > >>>>>>>>> I saw in the archives a concern about tab width vs tab stops. > >>>>>>>>> For some reason I didn?t get the email. Anyway, I don?t think > >>>>>>>>> arbitrary tab stop positions, at different intervals that is, > >>>>>>>>> are what was asked for. That certainly would require a > >>>>>>>>> significantly different implementation. > >>>>>>>>> > >>>>>>>>> Would love to keep some momentum going on this before I become > >>>>>>>>> busy with other things and won?t have time for it. > >>>>>>>>> > >>>>>>>>> Scott > >>>>>>>>> > >>>>>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> My current work is here > >>>>>>>>>> > https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 > >>>>>>>>>> < > https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1> > > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> While writing a unit test I realized that the StubToolkit > >>>>>>>>>> isn?t really running the Prism layout code, so I?m not sure > >>>>>>>>>> how that gets tested. I made it work with StubTextLayout for > >>>>>>>>>> now. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Scott > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > >>>>>>>>>>> > wrote: > >>>>>>>>>>> > >>>>>>>>>>> Thanks Kevin. > >>>>>>>>>>> > >>>>>>>>>>> My current implementation appears to be working for TextFlow > >>>>>>>>>>> and Text, with the TextFlow overriding the tabWidth of the > >>>>>>>>>>> child Text nodes. This seems to work out naturally from the > >>>>>>>>>>> way TextFlow overrides the TextLayout instance used by the > >>>>>>>>>>> Text node. > >>>>>>>>>>> > >>>>>>>>>>> If there are tricky corner-cases that I?m missing, I guess > >>>>>>>>>>> figuring out all the cases it will need to handle is part of > >>>>>>>>>>> this discussion. It didn?t seem to be that challenging so > >>>>>>>>>>> far, so perhaps I am missing something (hopefully not). I > >>>>>>>>>>> wrote a small test app to visually see that things were > >>>>>>>>>>> working as I expected. I have not yet written the unit tests. > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> > >>>>>>>>>>> Scott > >>>>>>>>>>> > >>>>>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > >>>>>>>>>>>> >>>>>>>>>>>> > wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Scott, > >>>>>>>>>>>> > >>>>>>>>>>>> I'm sure Phil will have more comments on this. While the > >>>>>>>>>>>> API seems simple enough on the surface, I suspect that this > >>>>>>>>>>>> will be a challenging feature to implement correctly for > >>>>>>>>>>>> all of the cases it will need to handle. It would need > >>>>>>>>>>>> careful review and testing as well. My only comment on the > >>>>>>>>>>>> API itself is that if we do accept this feature, it should > >>>>>>>>>>>> probably go on both Text and TextFlow, and be one of the > >>>>>>>>>>>> attributes of Text that is ignored / overridden when a Text > >>>>>>>>>>>> node is in a TextFlow. > >>>>>>>>>>>> > >>>>>>>>>>>> -- Kevin > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: > >>>>>>>>>>>>> I would like to implement this feature, being able to > >>>>>>>>>>>>> adjust the tab size in a TextFlow or Text node > >>>>>>>>>>>>> (JDK-8130738 > >>>>>>>>>>>>> >>>>>>>>>>>>> >). It > >>>>>>>>>>>>> involves new public API, so I want to start a discussion > >>>>>>>>>>>>> about it here. (My motivation is that RichTextFX suggests > >>>>>>>>>>>>> an entirely unacceptable workaround of substituting actual > >>>>>>>>>>>>> spaces when the tab character is typed and cites the lack > >>>>>>>>>>>>> of this API.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> I?ve already jumped the gun and taken a crack at an > >>>>>>>>>>>>> implementation. It is currently incomplete as I was just > >>>>>>>>>>>>> poking around to see if it was going to be easy enough to > >>>>>>>>>>>>> not take up too much of my time. It boils down to: > >>>>>>>>>>>>> TextFlow and Text get a new property for tab width, an > >>>>>>>>>>>>> integer representing the number of spaces taken by a tab. > >>>>>>>>>>>>> (The value is only used to initialize the tab width for > >>>>>>>>>>>>> the TextLayout when needed.) > >>>>>>>>>>>>> TextLayout interface gets a new method: boolean > >>>>>>>>>>>>> setTabWidth(int spaces) > >>>>>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; > >>>>>>>>>>>>> PrismTextLayout implements the new setTabWidth API. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I?m not sure that the Text node needs this new property. > >>>>>>>>>>>>> I figured it would be rarely used on that class, so I had > >>>>>>>>>>>>> implemented it via an added property in the private > >>>>>>>>>>>>> TextAttributes class. Maybe it isn?t needed at all. > >>>>>>>>>>>>> > >>>>>>>>>>>>> What?s the next step? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Scott > > > > From nlisker at openjdk.org Tue Nov 5 18:10:57 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Nov 2019 18:10:57 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors Message-ID: https://bugs.openjdk.java.net/browse/JDK-8229472 CSR will be created after the changes are approved. ---------------- Commits: - 6d29e034: Initial push of 8229472 Changes: https://git.openjdk.java.net/jfx/pull/30/files Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 PR: https://git.openjdk.java.net/jfx/pull/30 From nlisker at openjdk.org Tue Nov 5 18:16:55 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Nov 2019 18:16:55 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: Message-ID: On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: > https://bugs.openjdk.java.net/browse/JDK-8229472 > > CSR will be created after the changes are approved. > > ---------------- > > Commits: > - 6d29e034: Initial push of 8229472 > > Changes: https://git.openjdk.java.net/jfx/pull/30/files > Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 jcheck failed several times before passing. The report said "Exception occurred during jcheck - the operation will be retried". If there is a log of the failures someone might want to have a look. PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 6 04:54:07 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 04:54:07 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: Message-ID: On Tue, 5 Nov 2019 18:16:55 GMT, Nir Lisker wrote: > On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8229472 >> >> CSR will be created after the changes are approved. >> >> ---------------- >> >> Commits: >> - 6d29e034: Initial push of 8229472 >> >> Changes: https://git.openjdk.java.net/jfx/pull/30/files >> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 > > jcheck failed several times before passing. The report said "Exception occurred during jcheck - the operation will be retried". If there is a log of the failures someone might want to have a look. > > > jcheck failed several times before passing. The report said "Exception occurred during jcheck - the operation will be retried". If there is a log of the failures someone might want to have a look. @rwestberg @edvbld can you take a look? PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 6 05:02:36 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 05:02:36 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: Message-ID: On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: > https://bugs.openjdk.java.net/browse/JDK-8229472 > > CSR will be created after the changes are approved. > > ---------------- > > Commits: > - 6d29e034: Initial push of 8229472 > > Changes: https://git.openjdk.java.net/jfx/pull/30/files > Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 This looks fine with one (minor) formatting comment. Go ahead and create the CSR and I'll review that as well. PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 6 05:04:28 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 05:04:28 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: Message-ID: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: > https://bugs.openjdk.java.net/browse/JDK-8229472 > > CSR will be created after the changes are approved. > > ---------------- > > Commits: > - 6d29e034: Initial push of 8229472 > > Changes: https://git.openjdk.java.net/jfx/pull/30/files > Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: > 67: @Deprecated(since = "14", forRemoval = true) > 68: public JavaBeanBooleanPropertyBuilder() {} > 69: Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 6 05:07:56 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 05:07:56 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> Message-ID: On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: > On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8229472 >> >> CSR will be created after the changes are approved. >> >> ---------------- >> >> Commits: >> - 6d29e034: Initial push of 8229472 >> >> Changes: https://git.openjdk.java.net/jfx/pull/30/files >> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 > > modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: > >> 67: @Deprecated(since = "14", forRemoval = true) >> 68: public JavaBeanBooleanPropertyBuilder() {} >> 69: > > Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? PR: https://git.openjdk.java.net/jfx/pull/30 From rwestberg at openjdk.org Wed Nov 6 07:12:26 2019 From: rwestberg at openjdk.org (Robin Westberg) Date: Wed, 6 Nov 2019 07:12:26 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> Message-ID: On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: > On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: > >> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>> >>> CSR will be created after the changes are approved. >>> >>> ---------------- >>> >>> Commits: >>> - 6d29e034: Initial push of 8229472 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >> >> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >> >>> 67: @Deprecated(since = "14", forRemoval = true) >>> 68: public JavaBeanBooleanPropertyBuilder() {} >>> 69: >> >> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. > > I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 6 08:30:47 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 08:30:47 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 > > A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. > The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). > This fix introduced synthesized press-events, which is an unsafe fix for the problem. > > The pull request introduces a new fix for the problem. > Instead of simulating new input-events, we set JavaFX Scene/Window to focused. > We do so, by using setFocused. > When the original Swing-Focus event is called slightly later, it won't have any side-effects, > because calling setFocused just sets the value of a boolean property. > > I've now also added a unit-test for the problem. > > ---------------- > > Commits: > - 314e423c: JDK-8200224 > - 725e5fef: JDK-8200224 > > Changes: https://git.openjdk.java.net/jfx/pull/25/files > Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: > 456: > 457: sendMouseEventToFX(e); > 458: super.processMouseEvent(e); typo: save --> safe modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: > 1: /* > 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. replace `2014, 2016` with `2019,` modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: > 27: > 28: import javafx.application.Application; > 29: import javafx.application.Platform; Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: > 47: > 48: import static junit.framework.Assert.assertEquals; > 49: import static org.junit.Assert.assertNotNull; This method should be imported from `org.junit` package. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: > 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, > 116: 5, 5, 1, false, MouseEvent.BUTTON1); > 117: This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: > 56: > 57: > 58: @BeforeClass You can remove the extra blank line. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: > 64: > 65: > 66: try { You can remove the extra blank line. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: > 78: > 79: class TestFXPanel extends JFXPanel { > 80: protected void processMouseEventPublic(MouseEvent e) { I think this can be a static class. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: > 87: > 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); > 89: This can be final. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: > 90: // It's an array, so we can mutate it inside of lambda statement > 91: int[] pressedEventCounter = {0}; > 92: This can be final. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: > 131: > 132: > 133: } You can remove the extra blank line. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: > 122: > 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { > 124: throw new Exception(); Add a space after the `if`. The fix seems fine. Have you tested it on all three platforms? I have several comments on the test. ---------------- Disapproved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/25 From shadzic at openjdk.org Wed Nov 6 08:51:02 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 6 Nov 2019 08:51:02 GMT Subject: [Rev 01] RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: <1JX2U0eS_m-XRVpLBobtlvsa3MZE34ssnwgXPLd-hz8=.7e953249-93f4-47dc-bddc-613b6741002e@github.com> On Tue, 5 Nov 2019 11:17:55 GMT, Arun Joseph wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - afc7f17a: Minor formatting > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/27/files > - new: https://git.openjdk.java.net/jfx/pull/27/files/5a1fbade..afc7f17a > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/27/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/27/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8230492 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/27.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27 Approved by shadzic (Author). PR: https://git.openjdk.java.net/jfx/pull/27 From github.com+24428922+arun-Joseph at openjdk.org Wed Nov 6 10:17:05 2019 From: github.com+24428922+arun-Joseph at openjdk.org (Arun Joseph) Date: Wed, 6 Nov 2019 10:17:05 GMT Subject: RFR: 8231188: Update SQLite to version 3.30.1 Message-ID: We currently use SQLite version 3.28.0. We should update to the latest stable release version 3.30.1 released. https://www.sqlite.org/index.html ---------------- Commits: - 24c6375d: 8231188: Update SQLite to version 3.30.1 Changes: https://git.openjdk.java.net/jfx/pull/31/files Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231188 Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod Patch: https://git.openjdk.java.net/jfx/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31 PR: https://git.openjdk.java.net/jfx/pull/31 From nlisker at openjdk.org Wed Nov 6 11:50:27 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 6 Nov 2019 11:50:27 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> Message-ID: On Wed, 6 Nov 2019 07:12:26 GMT, Robin Westberg wrote: > On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: > >> On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: >> >>> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>>> >>>> CSR will be created after the changes are approved. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 6d29e034: Initial push of 8229472 >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >>> >>> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >>> >>>> 67: @Deprecated(since = "14", forRemoval = true) >>>> 68: public JavaBeanBooleanPropertyBuilder() {} >>>> 69: >>> >>> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. >> >> I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? > > Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) For both `since` and `forRemoval`? PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 6 12:44:14 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 12:44:14 GMT Subject: [Integrated] RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it In-Reply-To: References: Message-ID: <2363163b-fa14-4a98-9b83-b0f3f43e31e1@openjdk.org> Changeset: 286d1b54 Author: Arun Joseph Committer: Kevin Rushforth Date: 2019-11-06 12:43:43 +0000 URL: https://git.openjdk.java.net/jfx/commit/286d1b54 8230492: font-family not set in HTMLEditor if font name has a number in it Reviewed-by: kcr, shadzic ! modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java ! tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java = tests/system/src/test/resources/test/javafx/scene/web/WebKit_Layout_Tests_2.ttf From kcr at openjdk.org Wed Nov 6 12:54:40 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Nov 2019 12:54:40 GMT Subject: RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> Message-ID: On Wed, 6 Nov 2019 11:50:27 GMT, Nir Lisker wrote: > On Wed, 6 Nov 2019 07:12:26 GMT, Robin Westberg wrote: > >> On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: >> >>> On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>> >>>>> CSR will be created after the changes are approved. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 6d29e034: Initial push of 8229472 >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >>>> >>>> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >>>> >>>>> 67: @Deprecated(since = "14", forRemoval = true) >>>>> 68: public JavaBeanBooleanPropertyBuilder() {} >>>>> 69: >>>> >>>> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. >>> >>> I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? >> >> Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) > > For both `since` and `forRemoval`? Yes. The pattern used consistently (in all cases that I could find) would be: @Deprecated(since="14", forRemoval=true) PR: https://git.openjdk.java.net/jfx/pull/30 From kevin.rushforth at oracle.com Wed Nov 6 14:00:24 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 6 Nov 2019 15:00:24 +0100 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> <1f1c0269-9f9f-4922-0092-d18d5917e719@oracle.com> <390C1796-079D-4CEF-B622-B5410DDE5A75@gmail.com> <29cb42d9-8426-75b6-44eb-cd8aa90d4bc5@oracle.com> <99C8989F-13AD-46D0-A004-735FFBBDBBC0@gmail.com> <1c664471-9682-231d-aa8b-3d93a3db9d12@oracle.com> Message-ID: <08fd7296-631c-6de6-f9cb-12b8ce55b380@oracle.com> Hi Scott, The CSS reference is here: modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html As for your question about indentation, reformatting entire files or large blocks of code you aren't touching is discouraged. In your specific case, reformatting the methods in the StyleableProperties nested class that are adjacent to code you add or modify seems fine, as long as you only change the indentation and not the line wrapping. This will allow reviewers to turn on "hide whitespace changes" (which is an option of the GitHub diffs view, and is default for the webrev). -- Kevin On 11/5/2019 6:03 PM, Scott Palmer wrote: > I finally had a moment to get back at this. > > I've changed the name of the property from tabWidth to tabSize and > implemented the CSS property '-fx-tab-size'. The CSS documentation > will need to be updated. I didn't see where the CSS document is > located in the source tree. > > While adding CSS support I noticed that in both Text.java and > TextFlow.java the indentation is wrong for the StyleableProperties > nested class (has one extra space).? I wasn't sure how much I should > change in the scope of this feature.? If I don't fix some indenting my > changes will look funny beside the lines of existing code.? If I fix > all of the broken indenting I'll change a lot of lines that have > nothing to do with this feature. If I just properly indent the lines I > change or add, the indenting will be more chaotic than it is currently. > > I have noticed a rendering anomaly with a tab size of zero (the value > I was initially clamping to) and rather than dealing with that I took > the easy way out and changed it to agree with the minimum of 1 that > Kevin indicated for the range. > > I have not limited the maximum tab size.? I know Phil has expressed > that MAXINT is not his preference, but I can't think of a good > criteria for what the maximum should be.? I can imagine someone using > a tab separator to align columns of text that have much more than 16 > characters for example.? I did a quick test with the tab size set to > Integer.MAX_VALUE-1 and nothing blew up.? Of course the text after the > tab was nowhere to be seen. > > > Regards, > > Scott > > > On Thu, Oct 17, 2019 at 3:42 PM Phil Race > wrote: > > > > On 10/17/19 12:32 PM, Kevin Rushforth wrote: > > It seems that you have a path forward then. So, there are a couple > > questions to answer: > > > > 1. Should the type of the property be int or double? If it > really is > > only ever going to be a number of spaces, then int seems fine. > That, > > along with the name of the property, would underscore the fact that > > no, this isn't a size where units make sense; it's a number of > spaces. > > A discrete number of spaces, so int. > > > > > 2. Should the range be [1,MAXINT] or [1,16] or [1,something-else]? > > Once that is decided, I think clamp on use would be the most > > consistent with other similar properties, but that's worth checking. > > If we go with "MAXINT" (which is not my preference), I think there'd > need to be some testing of > the various code paths and pipelines to be sure that various > values from > large, through extreme, > all do something sensible, and of course, no exceptions or crashes. > > Various code paths means Text, TextFlow,? linewrapping or not ... > complex text and simple text too. > Perhaps complex text should be tested anyway, although I've been > assuming that we are handling > tab spacing outside of that but didn't verify it. > > -phil. > > > > > -- Kevin > > > > > > On 10/17/2019 12:11 PM, Scott Palmer wrote: > >> You?re right.? Something I was reading indicated that while > there was > >> no default unit, ?px? was implicitly appended.? I can?t find that > >> now. Go figure. > >> > >> Everything I find now about CSS tab-size is in agreement with what > >> David wrote.? It?s a number of spaces.? With units it would be a > >> ?length? but nothing supports that. > >> > >> So I think it makes sense to add -fx-tab-size as a CSS > property, only > >> supporting a number with no units. > >> > >> Scott > >> > >> > >>> On Oct 17, 2019, at 2:32 PM, Phil Race > wrote: > >>> > >>> Really ? It defaults to pixels ? Is that just inherited as > being the > >>> default CSS unit ? > >>> Is that FX's implementation > >>> > >>> Hmm. A bit of reading about web CSS says that strictly anything > >>> without an explicit unit should be ignored. > >>> The only exception is zero, where it doesn't matter. > >>> > >>> Eg see : > >>> > https://stackoverflow.com/questions/7907749/default-unit-for-font-size > >>> > >>> Although I am sure there are more authoratative sources than that. > >>> > >>> -phil. > >>> > >>> On 10/17/19 11:22 AM, Scott Palmer wrote: > >>>> So do we go ahead and implement tabSize without the CSS support? > >>>> I?m not sure the CSS property should be added before unit issues > >>>> are worked out, as I think the units would be expected in the > CSS > >>>> context. E.g. CSS implicitly adds ?px? if no unit is > specified.? If > >>>> our tabSize units are spaces, that breaks. > >>>> > >>>> Scott > >>>> > >>>>> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth > >>>>> > wrote: > >>>>> > >>>>> It might make sense to just add the tabSize property now, and > >>>>> later consider adding a tabUnits property in the future if > needed. > >>>>> By default, having the units be "number of spaces in the > current > >>>>> font" is what makes the most sense, so before we could add > >>>>> tabUnits we would need to extend it as you suggest. I'm not > sure > >>>>> it's needed, though, so that would be another reason not to > do it > >>>>> now. > >>>>> > >>>>> It's probably best to have the type of tabSize be double rather > >>>>> than int. We do this for most attributes to leave the door open > >>>>> for fractional values. I don't know why anyone would want a tab > >>>>> that was 5.7 spaces, but if we ever were to add a tabUnits > >>>>> property, I could easily see wanting fractional values for some > >>>>> units. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> On 10/17/2019 10:40 AM, Scott Palmer wrote: > >>>>>> Hi Phil, > >>>>>> > >>>>>> Thanks for taking a look.? I was going to get back to this > soon > >>>>>> to attempt adding the CSS property as you mention in your > >>>>>> previous email.? I considered tabSize as a name as well.? I > don?t > >>>>>> have a preference if we leave things as representing tabs as a > >>>>>> number of spaces.? But it wouldn?t be too difficult to support > >>>>>> units, making it mostly compatible with CSS rules.? The way I > >>>>>> envision that is having two properties, tabSize and tabUnit. > >>>>>> > >>>>>> David mentioned javafx.css.SizeUnits? I looked quickly at the > >>>>>> java docs for it, and it?s basically undocumented .? So I > went to > >>>>>> https://www.w3.org/TR/css-values-3/#lengths and I see there > is no > >>>>>> CSS unit like ?ems? but meaning the width of a space in the > >>>>>> current font.? The problem with that is it would leave out the > >>>>>> possibility to set the tab width to anything relative to the > >>>>>> current implementation of 8 spaces. (In hindsight it should > have > >>>>>> been implemented based on ?ems?, which for a fixed width > font as > >>>>>> typically used in a code editor would be the same as 8 spaces > >>>>>> anyway) > >>>>>> Do we add something to SizeUnits so we can work around this? > >>>>>> e.g. ?fxsp?? (FX-space - fx prefix to avoid a potential > collision > >>>>>> with any future official CSS units) > >>>>>> > >>>>>> // Two tab-related properties > >>>>>> public void setTabSize(int size); // defaults to 8 > >>>>>> public void setTabUnits(SizeUnits units); // ?? no unit for > width > >>>>>> of space in current font > >>>>>> > >>>>>> If we did the above, I would consider adding this for > convenience: > >>>>>> public void setTabWidth(int size, TabUnits units); > >>>>>> > >>>>>> As far as setting a range, I?m not sure there is any > worthwhile > >>>>>> benefit to enforcing a maximum.? If we want to store the > value in > >>>>>> a short instead of an int to potentially save a couple bytes, > >>>>>> sure.? Otherwise, if someone wants to set tabs to be 20 > spaces or > >>>>>> 100, why should we prevent it?? If there isn't a > performance or > >>>>>> memory impact, I wouldn?t enforce a maximum. > >>>>>> > >>>>>> Ignoring any out of range values rather than clamping seems > fine > >>>>>> to me as well.? I was thinking of what happens if the value > was > >>>>>> bound to another value that strayed out of range. Clamping > would > >>>>>> get you as close as possible to the bound value, rather than > >>>>>> stuck at the previously observed value.? I just guessed that > >>>>>> would be preferred, but if ignoring is more consistent with > other > >>>>>> values, then I agree it makes sense. As long as the > behaviour is > >>>>>> documented, I can?t think of any significant downside > either way. > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Scott > >>>>>> > >>>>>> > >>>>>>> On Oct 17, 2019, at 12:45 PM, Phil Race > > > >>>>>>> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Some more points which I thought about but for whatever > reason > >>>>>>> did not pen .. > >>>>>>> > >>>>>>> First one minor thing: tabWidth is an OK name, but it does not > >>>>>>> conjure up that the value you specify isn't a width in pixels > >>>>>>> but the > >>>>>>> number of discrete space characters to use. FWIW CSS calls it > >>>>>>> tab-size. > >>>>>>> But CSS then supports pixels and ems .. that complicates > matters > >>>>>>> a lot. > >>>>>>> > >>>>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size > >>>>>>> > >>>>>>> Thee rest is mostly to do with "legal or sensible values" > >>>>>>> > >>>>>>> You have : > >>>>>>> ???????? if (spaces < 0) > >>>>>>> ???????????? spaces = 0; > >>>>>>> > >>>>>>> since negative values are not something we want to support! > >>>>>>> But I think instead of clamping you could "ignore", any > out of > >>>>>>> range value. > >>>>>>> This is practiced elsewhere in FX where illegal values are > >>>>>>> ignored rather than > >>>>>>> throwing an exception, although it might be that clamping is > >>>>>>> quite common > >>>>>>> in range cases. > >>>>>>> > >>>>>>> The follow on to that is that what is a sensible maximum > value. > >>>>>>> Currently we have int which is more than we need. For that > >>>>>>> matter so is short. > >>>>>>> I think we should have a documented and enforced sensible > maximum. > >>>>>>> Perhaps it could be "8" meaning we only support reducing tab > >>>>>>> width as I > >>>>>>> don't know if anyone really wants to increase it. > >>>>>>> CSS doesn't have a limit that I can see but if we are already > >>>>>>> only supporting > >>>>>>> it described as number of spaces, we can have this other > >>>>>>> limitation too. > >>>>>>> If you think 8 is too small, then maybe 16 ? > >>>>>>> Also remember we can compatibly relax it later but we can't > >>>>>>> compatibly tighten it. > >>>>>>> > >>>>>>> > >>>>>>> -phil. > >>>>>>> > >>>>>>> On 10/15/19 12:17 PM, Phil Race wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I've looked over this and I don't see any issues - meaning > >>>>>>>> gotchas. > >>>>>>>> It just provides a way to over-ride the hard-coded 8, > >>>>>>>> whether using a Text node directly or a TextFlow. > >>>>>>>> > >>>>>>>> Two observations of what one might call limitations > >>>>>>>> 1) This is a rendering time property, which is controlled by > >>>>>>>> the program. > >>>>>>>> A document containing tabs saved and re-rendered > somewhere else > >>>>>>>> won't be helped. > >>>>>>>> > >>>>>>>> 2) This just provides API on the scene graph node types, not > >>>>>>>> any of the UI controls > >>>>>>>> which use Text nodes. Something like a CSS property may > be the > >>>>>>>> way to go if > >>>>>>>> you wanted that. > >>>>>>>> Text has a nested class StyleableProperties for CSS > properties > >>>>>>>> with which it > >>>>>>>> plays nice : font, underline, strikethrough, text-alignment > >>>>>>>> > >>>>>>>> So creating an fx-tabWidth (or similar name) CSS property > could > >>>>>>>> be propagated > >>>>>>>> through to there in a similar way. > >>>>>>>> > >>>>>>>> -phil. > >>>>>>>> > >>>>>>>> > >>>>>>>> On 9/30/19 9:48 AM, Scott Palmer wrote: > >>>>>>>>> Okay, current work relocated to a clone of the new official > >>>>>>>>> Git repo. > >>>>>>>>> My initial implementation is here: > >>>>>>>>> > https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f > > >>>>>>>>> > > > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I would submit it as a pull request but that seems > premature > >>>>>>>>> since there hasn?t been any real discussion of > challenges I?ve > >>>>>>>>> overlooked.? All I have are the famous last words, ?It > works > >>>>>>>>> for me.? > >>>>>>>>> > >>>>>>>>> I saw in the archives a concern about tab width vs tab > stops. > >>>>>>>>> For some reason I didn?t get the email.? Anyway, I don?t > think > >>>>>>>>> arbitrary tab stop positions, at different intervals > that is, > >>>>>>>>> are what was asked for. That certainly would require a > >>>>>>>>> significantly different implementation. > >>>>>>>>> > >>>>>>>>> Would love to keep some momentum going on this before I > become > >>>>>>>>> busy with other things and won?t have time for it. > >>>>>>>>> > >>>>>>>>> Scott > >>>>>>>>> > >>>>>>>>>> On Sep 23, 2019, at 3:57 PM, Scott Palmer > >>>>>>>>>> > wrote: > >>>>>>>>>> > >>>>>>>>>> My current work is here > >>>>>>>>>> > https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 > > >>>>>>>>>> > > > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> While writing a unit test I realized that the StubToolkit > >>>>>>>>>> isn?t really running the Prism layout code, so I?m not > sure > >>>>>>>>>> how that gets tested.? I made it work with > StubTextLayout for > >>>>>>>>>> now. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Scott > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > >>>>>>>>>>> > >> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Thanks Kevin. > >>>>>>>>>>> > >>>>>>>>>>> My current implementation appears to be working for > TextFlow > >>>>>>>>>>> and Text, with the TextFlow overriding the tabWidth of > the > >>>>>>>>>>> child Text nodes.? This seems to work out naturally > from the > >>>>>>>>>>> way TextFlow overrides the TextLayout instance used by > the > >>>>>>>>>>> Text node. > >>>>>>>>>>> > >>>>>>>>>>> If there are tricky corner-cases that I?m missing, I > guess > >>>>>>>>>>> figuring out all the cases it will need to handle is > part of > >>>>>>>>>>> this discussion. It didn?t seem to be that challenging so > >>>>>>>>>>> far, so perhaps I am missing something (hopefully > not).? I > >>>>>>>>>>> wrote a small test app to visually see that things were > >>>>>>>>>>> working as I expected.? I have not yet written the > unit tests. > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> > >>>>>>>>>>> Scott > >>>>>>>>>>> > >>>>>>>>>>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > >>>>>>>>>>>> > >>>>>>>>>>>> >> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Scott, > >>>>>>>>>>>> > >>>>>>>>>>>> I'm sure Phil will have more comments on this. While the > >>>>>>>>>>>> API seems simple enough on the surface, I suspect > that this > >>>>>>>>>>>> will be a challenging feature to implement correctly for > >>>>>>>>>>>> all of the cases it will need to handle. It would need > >>>>>>>>>>>> careful review and testing as well. My only comment > on the > >>>>>>>>>>>> API itself is that if we do accept this feature, it > should > >>>>>>>>>>>> probably go on both Text and TextFlow, and be one of the > >>>>>>>>>>>> attributes of Text that is ignored / overridden when > a Text > >>>>>>>>>>>> node is in a TextFlow. > >>>>>>>>>>>> > >>>>>>>>>>>> -- Kevin > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: > >>>>>>>>>>>>> I would like to implement this feature, being able to > >>>>>>>>>>>>> adjust the tab size in a TextFlow or Text node > >>>>>>>>>>>>> (JDK-8130738 > >>>>>>>>>>>>> >>>>>>>>>>>>> > >). It > >>>>>>>>>>>>> involves new public API, so I want to start a > discussion > >>>>>>>>>>>>> about it here.? (My motivation is that RichTextFX > suggests > >>>>>>>>>>>>> an entirely unacceptable workaround of substituting > actual > >>>>>>>>>>>>> spaces when the tab character is typed and cites the > lack > >>>>>>>>>>>>> of this API.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> I?ve already jumped the gun and taken a crack at an > >>>>>>>>>>>>> implementation.? It is currently incomplete as I was > just > >>>>>>>>>>>>> poking around to see if it was going to be easy > enough to > >>>>>>>>>>>>> not take up too much of my time.? It boils down to: > >>>>>>>>>>>>> TextFlow and Text get a new property for tab width, an > >>>>>>>>>>>>> integer representing the number of spaces taken by a > tab. > >>>>>>>>>>>>> (The value is only used to initialize the tab width for > >>>>>>>>>>>>> the TextLayout when needed.) > >>>>>>>>>>>>> TextLayout interface gets a new method: boolean > >>>>>>>>>>>>> setTabWidth(int spaces) > >>>>>>>>>>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; > >>>>>>>>>>>>> PrismTextLayout implements the new setTabWidth API. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I?m not sure that the Text node needs this new > property. > >>>>>>>>>>>>> I figured it would be rarely used on that class, so > I had > >>>>>>>>>>>>> implemented it via an added property in the private > >>>>>>>>>>>>> TextAttributes class.? Maybe it isn?t needed at all. > >>>>>>>>>>>>> > >>>>>>>>>>>>> What?s the next step? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Scott > > > From nlisker at openjdk.org Wed Nov 6 14:28:20 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 6 Nov 2019 14:28:20 GMT Subject: [Rev 01] RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - a1cdb37b: Removed whitespaces in @Deprecated comments Changes: - all: https://git.openjdk.java.net/jfx/pull/30/files - new: https://git.openjdk.java.net/jfx/pull/30/files/6d29e034..a1cdb37b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/30/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/30/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 PR: https://git.openjdk.java.net/jfx/pull/30 From Rony.Flatscher at wu.ac.at Wed Nov 6 15:05:01 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 6 Nov 2019 16:05:01 +0100 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script Message-ID: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> Using a script engine (javax.script.ScriptEngine) for implementing a FXML controller there are two important information missing in the ScriptContext.ENGINE_SCOPE Bindings supplied to the script used to eval() the script code: * ScriptEngine.FILENAME o This value denotes the file name from where the script code was fetched that is being eval()'d. o When debugging script controllers in a complex JavaFX application it is mandatory to know the file name the script code was taken from (as such scripts could be called/run from different FXML files). Also, in the case of script runtime errors, usually the file name is given by the script engine where the error has occurred to ease debugging, such that it is important to really supply the filename. + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE refers the FXML file,? not to the file that hosts the script that gets run if using the " Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both. TextFlow's tab size overrides that of contained Text nodes. ---------------- Commits: - 68d221c7: 8130738: TextFlow's tab width is static Changes: https://git.openjdk.java.net/jfx/pull/32/files Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod Patch: https://git.openjdk.java.net/jfx/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 PR: https://git.openjdk.java.net/jfx/pull/32 From David.Grieve at microsoft.com Thu Nov 7 04:23:58 2019 From: David.Grieve at microsoft.com (David Grieve) Date: Thu, 7 Nov 2019 04:23:58 +0000 Subject: RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: What happens if you do text.tabSizeProperty().setValue(null) ? > -----Original Message----- > From: openjfx-dev On Behalf Of > Scott Palmer > Sent: Wednesday, November 6, 2019 11:12 AM > To: openjfx-dev at openjdk.java.net > Subject: RFR: 8130738: TextFlow's tab width is static > > Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to > both. TextFlow's tab size overrides that of contained Text nodes. > > ---------------- > > Commits: > - 68d221c7: 8130738: TextFlow's tab width is static > > Changes: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.o > penjdk.java.net%2Fjfx%2Fpull%2F32%2Ffiles&data=02%7C01%7CDavid. > Grieve%40microsoft.com%7C6044739a564243b00a3b08d762edb49b%7C72f9 > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086645878076773& > sdata=ov9cwdWgDaJxX0waFCXv3ca0CStlZm39q%2FQMNt9X%2BQU%3D&am > p;reserved=0 > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebr > evs.openjdk.java.net%2Fjfx%2F32%2Fwebrev.00&data=02%7C01%7CDa > vid.Grieve%40microsoft.com%7C6044739a564243b00a3b08d762edb49b%7C > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086645878076773&a > mp;sdata=00p7TljKs9FhkblloXDQhY74l4j3GqORzH%2ByRfwn40E%3D&re > served=0 > Issue: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK- > 8130738&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C604473 > 9a564243b00a3b08d762edb49b%7C72f988bf86f141af91ab2d7cd011db47%7 > C1%7C0%7C637086645878076773&sdata=iZyZ5RTtfjzCd5bME%2Bpf3nA > OI%2BtE8sjJGkRMl%2BQdUL8%3D&reserved=0 > Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod > Patch: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.o > penjdk.java.net%2Fjfx%2Fpull%2F32.diff&data=02%7C01%7CDavid.Grie > ve%40microsoft.com%7C6044739a564243b00a3b08d762edb49b%7C72f988b > f86f141af91ab2d7cd011db47%7C1%7C0%7C637086645878086767&sdat > a=L5BuXwvyCYwG%2BEb1hktl2ahXDPXgHkeFMLDthRSr2BY%3D&reserve > d=0 > Fetch: git fetch > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.o > penjdk.java.net%2Fjfx&data=02%7C01%7CDavid.Grieve%40microsoft.co > m%7C6044739a564243b00a3b08d762edb49b%7C72f988bf86f141af91ab2d7c > d011db47%7C1%7C0%7C637086645878086767&sdata=waZ9DLUjPqyBv > kOrgJQDjtp6gp9Y8chyhVFlbsXplU0%3D&reserved=0 > pull/32/head:pull/32 > > PR: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.o > penjdk.java.net%2Fjfx%2Fpull%2F32&data=02%7C01%7CDavid.Grieve% > 40microsoft.com%7C6044739a564243b00a3b08d762edb49b%7C72f988bf86f > 141af91ab2d7cd011db47%7C1%7C0%7C637086645878086767&sdata=G > kwyOTeBRFTdQnZ0Ovttf3vz7F4rkhrJZ9nT0pwUZrQ%3D&reserved=0 From aghaisas at openjdk.org Thu Nov 7 07:03:47 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 7 Nov 2019 07:03:47 GMT Subject: [Rev 01] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: <_s7efFv1cD4OqI7IYn25ruL2BU4cKMbJXvKMiNn0Aug=.5119a5b7-c13b-43c1-8cd8-b77778345583@github.com> References: <_s7efFv1cD4OqI7IYn25ruL2BU4cKMbJXvKMiNn0Aug=.5119a5b7-c13b-43c1-8cd8-b77778345583@github.com> Message-ID: <6Jm3WHv8PFjDjnP4BR-zpSb1iwTjfqJffBUzDzWWfM0=.f89f1d4e-e614-4b37-a457-5b39b8db75ee@github.com> On Tue, 5 Nov 2019 15:43:03 GMT, Jeanette Winzenburg wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 0366a0a5: added copyright header > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/20/files > - new: https://git.openjdk.java.net/jfx/pull/20/files/aabea139..0366a0a5 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/20/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 > Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/20.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 204: > 203: public void setup() { > 204: // This step is not needed (Just to make sure StubToolkit is loaded into VM) > 205: // @SuppressWarnings("unused") Remove this commented code. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 55: > 54: * Most of these tests are meant to document how to use the KeyEventFirer and what > 55: * happens if used incorrectly. The latter are ignored, because the build should pass. > 56: * I see ignored tests - for false greens. As these tests are written for new code in KeyEventFirer test infrastructure class, I suggest not to ignore these tests. Rather adjust asserts to pass them. A comment explaining the expected result should be added. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java line 85: > 84: > 85: public void doUpArrowPress(KeyModifier... modifiers) { > 86: doKeyPress(KeyCode.UP, modifiers); Enclose in braces {} PR: https://git.openjdk.java.net/jfx/pull/20 From Rony.Flatscher at wu.ac.at Thu Nov 7 10:44:44 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 7 Nov 2019 11:44:44 +0100 Subject: RFE: Allow any javax.script language to be used for script code in HTML event attributes and script elements processed by WebView/WebEngine Message-ID: <446e1165-fa45-52fb-559d-4294af94d0ff@wu.ac.at> Currently it is possible to create one own's browser using WebView where the WebEngine processes script code written in JavaScript for event attributes or for script elements. WebEngine is currently implemented such that only JavaScript gets supported for scripts in HTML (in event attributes or script elements). This request for a feature enhancement is therefore asking to enhance WebEngine such that it allows any of the javax.script languages to be used for writing scripts in HTML, very much like FXML controllers can be implemented in any of the Java script languages. The javax.script language (e.g. groovy, jruby, jython, rexx, ...) to be used could be determined with the "type" attribute (expecting a mime-type) or like in MS InternetExplorer with the (in the meantime deprecated) "language" attribute (expecting the language name). As one of the results this would allow one to use WebView as the presentation (and print) layer for (stand-alone) applications written in any javax.script language. A comparable solution has been available (and quite heavily exploited in some companies) with MS InternetExplorer and MS IIS allowing any ActiveX script language (JScript, VBScript, etc.) on Windows to be used in client HTML text and ASP for server side (this exists for twenty+ years on that platform). However, this solution has been restricted to MS Windows and MS InternetExplorer and not supported by any other competing browsers. Although HTML allows for denoting the name/mime-type of a script language used for script code, it seems that only MS has honored that in the past. Using WebView/WebEngine with any javax.script language would make a comparable solution totally platform independent and truly portable (and independent of any other third-party Web browser like Chrome, Safari, Firefox and the like). It is assumed that adding this feature would be quite attractive for private use, but also for small to medium sized companies. Any ideas how complex it would be to change WebEngine accordingly? Would there be related classes that need to be changed as well? What pitfalls would one have to think about? ---rony From fastegal at openjdk.org Thu Nov 7 11:13:17 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 11:13:17 GMT Subject: [Rev 01] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: <6Jm3WHv8PFjDjnP4BR-zpSb1iwTjfqJffBUzDzWWfM0=.f89f1d4e-e614-4b37-a457-5b39b8db75ee@github.com> References: <_s7efFv1cD4OqI7IYn25ruL2BU4cKMbJXvKMiNn0Aug=.5119a5b7-c13b-43c1-8cd8-b77778345583@github.com> <6Jm3WHv8PFjDjnP4BR-zpSb1iwTjfqJffBUzDzWWfM0=.f89f1d4e-e614-4b37-a457-5b39b8db75ee@github.com> Message-ID: On Thu, 7 Nov 2019 07:03:47 GMT, Ajit Ghaisas wrote: > On Tue, 5 Nov 2019 15:43:03 GMT, Jeanette Winzenburg wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 0366a0a5: added copyright header >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/20/files >> - new: https://git.openjdk.java.net/jfx/pull/20/files/aabea139..0366a0a5 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/20/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 >> Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod >> Patch: https://git.openjdk.java.net/jfx/pull/20.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 204: > >> 203: public void setup() { >> 204: // This step is not needed (Just to make sure StubToolkit is loaded into VM) >> 205: // @SuppressWarnings("unused") > > Remove this commented code. > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 55: > >> 54: * Most of these tests are meant to document how to use the KeyEventFirer and what >> 55: * happens if used incorrectly. The latter are ignored, because the build should pass. >> 56: * > > I see ignored tests - for false greens. > As these tests are written for new code in KeyEventFirer test infrastructure class, I suggest not to ignore these tests. Rather adjust asserts to pass them. A comment explaining the expected result should be added. > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java line 85: > >> 84: >> 85: public void doUpArrowPress(KeyModifier... modifiers) { >> 86: doKeyPress(KeyCode.UP, modifiers); > > Enclose in braces {} yeah, suspected that ignoring a test is not the right thingy to do (though there are precedences in the code base, that you are currently cleaning up ;) But couldn't come up with a passing test that demonstrates the failure of a false-green. Any ideas? Or alternatively: the basic idea in these ignored tests was to document the correct vs. incorrect useage - is there any place/internal documentation to reach that goal, other than a failing test? Maybe it's only me, but it took me quite a while to find out why that darn test (on comboBox) was _not_ failing, that is was a real false-green - which I would like to spare future contributors. PR: https://git.openjdk.java.net/jfx/pull/20 From fastegal at openjdk.org Thu Nov 7 11:51:02 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 11:51:02 GMT Subject: [Rev 02] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 92cd944e: changed as requested in review Changes: - all: https://git.openjdk.java.net/jfx/pull/20/files - new: https://git.openjdk.java.net/jfx/pull/20/files/0366a0a5..92cd944e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/20/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.01-02 Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 Stats: 83 lines in 2 files changed: 10 ins; 65 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 PR: https://git.openjdk.java.net/jfx/pull/20 From fastegal at openjdk.org Thu Nov 7 11:52:36 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 11:52:36 GMT Subject: RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: On Thu, 31 Oct 2019 21:21:47 GMT, Kevin Rushforth wrote: > On Wed, 23 Oct 2019 11:32:48 GMT, Jeanette Winzenburg wrote: > >> The issue is that firing keyEvents on a node that is not focusOwner might produce false green tests, please see the issue for details. >> >> fix for https://bugs.openjdk.java.net/browse/JDK-8231692 >> - added contructor taking the scene >> - changed event firing to use either the target directly or inject into >> scene >> >> ---------------- >> >> Commits: >> - aabea139: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into >> >> Changes: https://git.openjdk.java.net/jfx/pull/20/files >> Webrev: https://webrevs.openjdk.java.net/jfx/20/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 >> Stats: 263 lines in 2 files changed: 260 ins; 2 del; 1 mod >> Patch: https://git.openjdk.java.net/jfx/pull/20.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 > > @aghaisas can you review this? A single reviewer will be sufficient. done as requested :) As to the ignored tests, I removed most and re-formulated one to demonstrate the difference between firing onto a not-focusOwner and firing via scene PR: https://git.openjdk.java.net/jfx/pull/20 From fastegal at openjdk.org Thu Nov 7 12:07:55 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 12:07:55 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Fri, 1 Nov 2019 10:59:57 GMT, Hadzic Samir wrote: > On Tue, 29 Oct 2019 13:19:27 GMT, Hadzic Samir wrote: > >> On Wed, 9 Oct 2019 16:01:38 GMT, Kevin Rushforth wrote: >> >>> On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: >>> >>>> On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: >>>> >>>>> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >>>>> >>>>>> Allright, this is a fix for JDK-8207957 >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - 969ebb51: Fixing TableColumnHeaderTest >>>>>> - 9d379619: Removing Tablecolumnbasehelper >>>>>> - 4fe020fc: Fix javadoc for TableColumnHeader >>>>>> - c422c80f: Minor modification and uni test added. >>>>>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>>>>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>>>>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>>>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>>>> >>>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >>>>> >>>>>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>>>>> 600: * {@code super()}) to provide their custom algorithm. >>>>>> 601: * >>>>> >>>>> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) >>>> >>>> Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. >>>> >>>> I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. >>> >>> A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. >> >> Do you think this looks good now @kleopatra @nlisker ? > > Yes I was waiting for the final 'go'. I will update it asap, thanks > > Le ven. 1 nov. 2019 ? 09:49, Jeanette Winzenburg > a ?crit : > >> *@kleopatra* commented on this pull request. >> ------------------------------ >> >> In >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java >> : >> >> > + * Resizes this {@code TableColumnHeader}'s column to fit the width of its content. >> + * >> + * @implSpec The resulting column width for this implementation is the maximum of the preferred width of the header >> + * cell and the preferred width of the first {@code maxRow} cells. >> + *

>> + * Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their >> + * custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum >> + * width etc.). >> + * >> + * @param maxRows the number of rows considered when resizing. If -1 is given, all rows are considered. >> + * @since 14 >> >> looks good to me :) You would have to update the crs eventually, right? >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> >> . >> As to the test, it's a bit ... confusing, will try to suggest some changes - take them with a grain of salt, though, because I'm still groping to find my path through the wilderness here :) PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Nov 7 12:48:47 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 12:48:47 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/6/files > - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 > - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > 53: private MyTableColumnHeader tableColumnHeader; > 54: > 55: @Before If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy b) don't subclass but use that new accessor modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > 60: @Test > 61: public void test_resizeColumnToFitContent() { > 62: ObservableList model = FXCollections.observableArrayList( This method actually is three-in-one :) It's testing a) trigger a resize initially doesn't change the with b) change content to larger and trigger a resize increases column width c) change content to smaller and trigger a resize decreases column width Not sure about conventions here, but I would separate them out into distinct methods. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); > 118: tableColumnHeader.resizeCol(); that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > 120: width < column.getWidth()); > 121: > 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > 132: assertTrue("Column width must be smaller", > 133: width > column.getWidth()); > 134: } same as above but the other way round. Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on - header content - maxRows Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only An open question for me is: what is the standard procedure here? a) there are no tests around sizing (that I could find, maybe overlooked them) b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. ---------------- Disapproved by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Thu Nov 7 13:03:11 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 7 Nov 2019 13:03:11 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). Well that depends on the point of view. From my point of view, I'm testing the "resize to fit content" feature. So I'm testing one feature and therefore the same size, a bit smaller and a bit greater. But we could split this into 3 separate tests if that is the convention. PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Thu Nov 7 13:04:56 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 7 Nov 2019 13:04:56 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: <10IQ0NvLBSB-ZRjE1G7huWw1loy4rHAG2t1FWDbtNkI=.1505f963-0ef2-461f-9a24-d23b1c45da31@github.com> On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). Changing the firstName of the firstItem would be another test IMHO. It would test the fact that the backing model has changed and needs to be reflected in the view. Here I want to test the fact that a user has modified a cell through the view, and it impacts the model. PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Thu Nov 7 13:06:27 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 7 Nov 2019 13:06:27 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: <01TRnHj4FRkGrsmNYBTehKOX2r-2WY1HFDgBm22RUt0=.b9c866c7-7ae1-4b47-97c3-5509cbea9057@github.com> On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). But what if the resizeCol never worked and the value never changed at all? PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Nov 7 13:36:57 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 13:36:57 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). hmm ... tend to disagree: I see the resize feature/api as independent on how the data that is measured is changed. There's no automatic resize on editing (nor on changing content), you manually trigger the method, so keep the test as simple as possible. PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Nov 7 13:40:57 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 13:40:57 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). that's what the first step guards against :) PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Nov 7 13:44:07 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 13:44:07 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). so you end up with one test per public/protected method? Hmm .. PR: https://git.openjdk.java.net/jfx/pull/6 From philip.race at oracle.com Thu Nov 7 13:48:24 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 Nov 2019 05:48:24 -0800 Subject: Fwd: Re: Can't commit into lanai repo (Artem at JetBrains) In-Reply-To: References: Message-ID: <5DC420A8.9050300@oracle.com> Based on everything I see here, I wonder if Artem is not configured as a Project Lanai committer ? Contrary to the census .. -phil. -------- Original Message -------- Subject: Re: Can't commit into lanai repo Date: Thu, 7 Nov 2019 15:57:02 +0300 From: Artem Bochkarev To: Philip Race Hello! 1. I can pull over ssh. Command line output: bocha at unit-1145 lanai % hg pull pulling from ssh://abochkarev at hg.openjdk.java.net/lanai/lanai Enter passphrase for key '/Users/bocha/.ssh/id_rsa': searching for changes no changes found 2. It seems that I've got 'write'-rights via ssh (at least for abochkarev at cr.openjdk.java.net ). Scp works correctly: scp README.md abochkarev at cr.openjdk.java.net:~ 3. Output for hg verify: bocha at unit-1145 lanai % hg verify checking changesets checking manifests crosschecking files in changesets and manifests checking files checked 56593 changesets with 485676 changes to 184847 files 4. hg heads: bocha at unit-1145 lanai % hg heads changeset: 56592:f2e40582513d tag: tip user: abochkarev date: Thu Nov 07 12:24:48 2019 +0300 summary: 8233714: support 32bpp raster formats (for SwToTexture blit) 5. hg incoming: bocha at unit-1145 lanai % hg incoming Enter passphrase for key '/Users/bocha/.ssh/id_rsa': comparing with ssh://abochkarev at hg.openjdk.java.net/lanai/lanai searching for changes no changes found 6. hg out: bocha at unit-1145 lanai % hg out comparing with ssh://abochkarev at hg.openjdk.java.net/lanai/lanai Enter passphrase for key '/Users/bocha/.ssh/id_rsa': searching for changes changeset: 56592:f2e40582513d tag: tip user: abochkarev date: Thu Nov 07 12:24:48 2019 +0300 summary: 8233714: support 32bpp raster formats (for SwToTexture blit) 7. hg push: bocha at unit-1145 lanai % hg push pushing to ssh://abochkarev at hg.openjdk.java.net/lanai/lanai Enter passphrase for key '/Users/bocha/.ssh/id_rsa': searching for changes remote: abort: could not lock repository lanai/lanai: Read-only file system abort: unexpected response: empty string I don't know where ssh-config problem can be. My ssh public key ends with "bocha at unit-1145.labs.intellij.net " (i.e. the key was generated for user 'bocha'), but my oracle login is "abochkarev" - could this mismatch affect anything? On Tue, Nov 5, 2019 at 11:15 PM Philip Race > wrote: That's a very generic message. The census here says you DO have rights : http://openjdk.java.net/census#lanai Could be an ssh config problem or a problem with your repo. I just can't tell from that message. Can you *pull* over ssh ? What do you see for these commands ? hg verify hg heads hg incoming hg out -phil. On 11/5/19, 11:48 AM, Artem Bochkarev wrote: > Hello! Three days ago I was trying to push commits into lanai and I've > got strange error: > "empty response string" > It seems that I haven't got enough rights to push into lanai repo. > Please advise me what can I do to solve (at least diagnose) this problem? From philip.race at oracle.com Thu Nov 7 14:12:29 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 Nov 2019 06:12:29 -0800 Subject: Fwd: Re: Can't commit into lanai repo (Artem at JetBrains) In-Reply-To: <5DC420A8.9050300@oracle.com> References: <5DC420A8.9050300@oracle.com> Message-ID: <5DC4264D.70109@oracle.com> Sorry .. wrong list - auto-complete ! Please ignore. -phil. On 11/7/19, 5:48 AM, Philip Race wrote: > Based on everything I see here, I wonder if Artem is not configured as > a Project Lanai committer ? > Contrary to the census .. > From swpalmer at gmail.com Thu Nov 7 14:38:37 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 7 Nov 2019 09:38:37 -0500 Subject: RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: <01B6D78F-0A34-4A7E-8EC9-93D42953BF61@gmail.com> setValue(null) is interpreted as set(0) by IntegerProperty. This in turn will be clamped to 1 by the TextLayout. The property on the Text node will still read as 0. So now that you mention it, I don?t like where the clamping is implemented. I should clamp so it reads back as 1 - Fixed. Scott > On Nov 6, 2019, at 11:23 PM, David Grieve wrote: > > What happens if you do text.tabSizeProperty().setValue(null) ? > >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Scott Palmer >> Sent: Wednesday, November 6, 2019 11:12 AM >> To: openjfx-dev at openjdk.java.net >> Subject: RFR: 8130738: TextFlow's tab width is static >> >> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to >> both. TextFlow's tab size overrides that of contained Text nodes. From swpalmer at openjdk.org Thu Nov 7 14:39:00 2019 From: swpalmer at openjdk.org (Scott Palmer) Date: Thu, 7 Nov 2019 14:39:00 GMT Subject: [Rev 01] RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - a670c4f8: 8130738: TextFlow's tab width is static Changes: - all: https://git.openjdk.java.net/jfx/pull/32/files - new: https://git.openjdk.java.net/jfx/pull/32/files/68d221c7..a670c4f8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/32/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 PR: https://git.openjdk.java.net/jfx/pull/32 From shadzic at openjdk.org Thu Nov 7 14:52:07 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 7 Nov 2019 14:52:07 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). Allright, allright, I'll add the initial width Assert then PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Thu Nov 7 14:54:57 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 7 Nov 2019 14:54:57 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). Allright, I can do it like that if you prefer PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Thu Nov 7 14:56:58 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Nov 2019 14:56:58 GMT Subject: RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer wrote: > Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both. TextFlow's tab size overrides that of contained Text nodes. > > ---------------- > > Commits: > - 68d221c7: 8130738: TextFlow's tab width is static > > Changes: https://git.openjdk.java.net/jfx/pull/32/files > Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 > Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod > Patch: https://git.openjdk.java.net/jfx/pull/32.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 > I should clamp so it reads back as 1 - Fixed. This has implications for binding, etc., so I suspect this is not what we want. I'll look into this more when I review it. NOTE: This will need a CSR in addition to two reviewers. You can file the CSR any time, but I suggest leaving it in Draft state until Phil and I have had a first pass look at the API. PR: https://git.openjdk.java.net/jfx/pull/32 From shadzic at openjdk.org Thu Nov 7 14:57:18 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Thu, 7 Nov 2019 14:57:18 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). But should I be able to call the protected method? I'll take a look to see what I can do PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Nov 7 15:50:38 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 15:50:38 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). ehh ... do what you want - I have no rights whatsoever to force (not even nudge :) you into anything. Just been there and thought you might want a helping hand. PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at openjdk.org Thu Nov 7 15:53:18 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 7 Nov 2019 15:53:18 GMT Subject: [Rev 04] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 12:48:47 GMT, Jeanette Winzenburg wrote: > On Wed, 30 Oct 2019 13:59:08 GMT, Hadzic Samir wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 2b088993: Add @implSpec tag for javadoc of TableColumnHeader >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/6/files >> - new: https://git.openjdk.java.net/jfx/pull/6/files/1f1f7c44..2b088993 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/6/webrev.04 >> - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.03-04 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >> Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 54: > >> 53: private MyTableColumnHeader tableColumnHeader; >> 54: >> 55: @Before > > If I understand the intention correctly, the only reason for subclassing the TableView with a custom skin, headerRow, etc deep down into a custom columnHeader is to access its protected resizeColumnToFitContent? If so, an alternative approach might be to > > a) add a accessing method to TableColumnHeaderUtil in the shims hierarchy > b) don't subclass but use that new accessor > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 61: > >> 60: @Test >> 61: public void test_resizeColumnToFitContent() { >> 62: ObservableList model = FXCollections.observableArrayList( > > This method actually is three-in-one :) It's testing > > a) trigger a resize initially doesn't change the with > b) change content to larger and trigger a resize increases column width > c) change content to smaller and trigger a resize decreases column width > > Not sure about conventions here, but I would separate them out into distinct methods. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 117: > >> 116: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( >> 117: tableView, new TablePosition(tableView, 0, column), (EventType) eventType, "This is a big text inside that column")); >> 118: tableColumnHeader.resizeCol(); > > that looks like a rather convoluted way of changing content - what's wrong with straightforward changing the firstName of the first item :) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 121: > >> 120: width < column.getWidth()); >> 121: >> 122: column.getOnEditCommit().handle(new TableColumn.CellEditEvent( > > feels a bit unspecific (though I can't think of how to do it better - the internal measuring is ... doohoo ;) > > what I usually do in such a case is to take this as a first step, then change content back to original and again trigger a resize: now the current width should be the same as the initial width. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 133: > >> 132: assertTrue("Column width must be smaller", >> 133: width > column.getWidth()); >> 134: } > > same as above but the other way round. > > Until, the tests verified that the column width is effected by cell content and goes into the course direction of what is expected. What's still missing are tests that cover the complete specification (we now have one :), that is verify that/how resize is indeed depend on > > - header content > - maxRows > > Plus maybe that custom implementations are respected: f.i. doing nothing, making them constant, header only > > An open question for me is: what is the standard procedure here? > > a) there are no tests around sizing (that I could find, maybe overlooked them) > b) the change in this pull request is (more or less) simply moving around old code and pulling from private into protected scope, no changes in implementation/functionality > > Now is the contributor responsible for writing those missing tests? It can be considered a good opportunity ;) And strictly speaking is mandatory (probably?) for all public/protected api. On the other extreme, doing nothing (no tests because basically nothing changed) might be appropriate as well. > > ---------------- > > Disapproved by fastegal (Author). yes, the shim and/or the utiliy class can (they reside in the xx.skin package, so have access to protected/package-private stuff PR: https://git.openjdk.java.net/jfx/pull/6 From swpalmer at gmail.com Thu Nov 7 20:27:08 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 7 Nov 2019 15:27:08 -0500 Subject: RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: Yes, I suppose this should behave like anything else that uses an IntegerProperty as far as bindings are concerned. I'll wait for further review before reverting that last change. If tabSize=0 worked reasonably it would be much simpler. I'm not sure if I will have the time to hunt down why things go wrong in that case (everything after a tab appears at x offset 0). I've created the CSR, hopefully I did it correctly. https://bugs.openjdk.java.net/browse/JDK-8233810 Scott On Thu, Nov 7, 2019 at 9:57 AM Kevin Rushforth wrote: > On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer > wrote: > > > Added tabSize property to Text and TextFlow and -fx-tab-size CSS > attribute to both. TextFlow's tab size overrides that of contained Text > nodes. > > > > ---------------- > > > > Commits: > > - 68d221c7: 8130738: TextFlow's tab width is static > > > > Changes: https://git.openjdk.java.net/jfx/pull/32/files > > Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 > > Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod > > Patch: https://git.openjdk.java.net/jfx/pull/32.diff > > Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 > > > I should clamp so it reads back as 1 - Fixed. > > This has implications for binding, etc., so I suspect this is not what we > want. I'll look into this more when I review it. > > NOTE: This will need a CSR in addition to two reviewers. You can file the > CSR any time, but I suggest leaving it in Draft state until Phil and I have > had a first pass look at the API. > > PR: https://git.openjdk.java.net/jfx/pull/32 > From aghaisas at openjdk.org Fri Nov 8 07:14:48 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Nov 2019 07:14:48 GMT Subject: [Rev 02] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 11:51:02 GMT, Jeanette Winzenburg wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 92cd944e: changed as requested in review > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/20/files > - new: https://git.openjdk.java.net/jfx/pull/20/files/0366a0a5..92cd944e > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/20/webrev.02 > - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.01-02 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 > Stats: 83 lines in 2 files changed: 10 ins; 65 del; 8 mod > Patch: https://git.openjdk.java.net/jfx/pull/20.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 115: > 114: correctFirer.doKeyPress(A); > 115: assertNotEquals(falseTextFieldNotification, textFieldEvents.size()); > 116: assertNotEquals(falseButtonNotification, buttonEvents.size()); assertNotEquals does not compile for me. PR: https://git.openjdk.java.net/jfx/pull/20 From kcr at openjdk.org Fri Nov 8 08:16:59 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Nov 2019 08:16:59 GMT Subject: [Rev 02] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: On Fri, 8 Nov 2019 07:14:48 GMT, Ajit Ghaisas wrote: > On Thu, 7 Nov 2019 11:51:02 GMT, Jeanette Winzenburg wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 92cd944e: changed as requested in review >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/20/files >> - new: https://git.openjdk.java.net/jfx/pull/20/files/0366a0a5..92cd944e >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/20/webrev.02 >> - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.01-02 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 >> Stats: 83 lines in 2 files changed: 10 ins; 65 del; 8 mod >> Patch: https://git.openjdk.java.net/jfx/pull/20.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 115: > >> 114: correctFirer.doKeyPress(A); >> 115: assertNotEquals(falseTextFieldNotification, textFieldEvents.size()); >> 116: assertNotEquals(falseButtonNotification, buttonEvents.size()); > > assertNotEquals does not compile for me. It looks like `assertNotEquals` was added in a later version of junit than the one we use, which is still junit 4.8.2. We should upgrade to a newer version at some point, but until then we need to avoid using anything from newer versions of junit. PR: https://git.openjdk.java.net/jfx/pull/20 From daniel.peintner at gmail.com Fri Nov 8 08:36:36 2019 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 8 Nov 2019 09:36:36 +0100 Subject: JDK-8089514 - Clicking outside of the edited cell, node, or entry should commit the value Message-ID: All, I am following issue JDK-8089514 [1] given that I have a custom implementation for listening focusLost and committing the value in a TableCell (which doesn't work reliable). I believe having a solution in JavaFX default code itself would be desirable. Hence, I was wondering whether a) someone is still trying (or plans) to look into the issue b) how I can help (even though I might not know enough about intrinsic problems) Any comment welcome, -- Daniel [1] https://bugs.openjdk.java.net/browse/JDK-8089514 From fastegal at openjdk.org Fri Nov 8 10:32:58 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 8 Nov 2019 10:32:58 GMT Subject: [Rev 03] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - fbdea3df: changed test to compile under oldish junit Changes: - all: https://git.openjdk.java.net/jfx/pull/20/files - new: https://git.openjdk.java.net/jfx/pull/20/files/92cd944e..fbdea3df Webrevs: - full: https://webrevs.openjdk.java.net/jfx/20/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.02-03 Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 PR: https://git.openjdk.java.net/jfx/pull/20 From fastegal at openjdk.org Fri Nov 8 10:34:06 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 8 Nov 2019 10:34:06 GMT Subject: [Rev 02] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: On Fri, 8 Nov 2019 08:16:59 GMT, Kevin Rushforth wrote: > On Fri, 8 Nov 2019 07:14:48 GMT, Ajit Ghaisas wrote: > >> On Thu, 7 Nov 2019 11:51:02 GMT, Jeanette Winzenburg wrote: >> >>> The pull request has been updated with additional changes. >>> >>> ---------------- >>> >>> Added commits: >>> - 92cd944e: changed as requested in review >>> >>> Changes: >>> - all: https://git.openjdk.java.net/jfx/pull/20/files >>> - new: https://git.openjdk.java.net/jfx/pull/20/files/0366a0a5..92cd944e >>> >>> Webrevs: >>> - full: https://webrevs.openjdk.java.net/jfx/20/webrev.02 >>> - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.01-02 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 >>> Stats: 83 lines in 2 files changed: 10 ins; 65 del; 8 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/20.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 >> >> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java line 115: >> >>> 114: correctFirer.doKeyPress(A); >>> 115: assertNotEquals(falseTextFieldNotification, textFieldEvents.size()); >>> 116: assertNotEquals(falseButtonNotification, buttonEvents.size()); >> >> assertNotEquals does not compile for me. > > It looks like `assertNotEquals` was added in a later version of junit than the one we use, which is still junit 4.8.2. We should upgrade to a newer version at some point, but until then we need to avoid using anything from newer versions of junit. *I-must-not-push-without-commandline-build, *I-must-not-push-without-commandline-build, *I-must-... sry, guys, for wasting your time - changed PR: https://git.openjdk.java.net/jfx/pull/20 From fastegal at swingempire.de Fri Nov 8 10:54:58 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 08 Nov 2019 11:54:58 +0100 Subject: To write tests or not to write tests ... Message-ID: <20191108115458.Horde.MPxm0psLdtU0gprI8EEetA1@webmail.df.eu> ... if changes are "just" a re-arrangement of code (like https://github.com/openjdk/jfx/pull/6 - 8207957: TableSkinUtils should not contain actual code implementation)? In an ideal world, there would be a safety-net of tests (they would have been written at the time the old code was pushed - wouldn't they ;). All we would need to do is run them to ensure that our re-arrangement doesn't break anything. In the real world and that particular pull request above, there are not tests (that I could find, maybe overlooked them). Now the question: is the contributor responsible for writing those missing tests? The two extremes are - yes, it's a good opportunity ;) And it is mandatory (probably?) for all public/protected api. A new protected method with specification was condensed and should be tested. - no, nothing changed, the tests were always missing and all still live ;) so doing nothing is just fine What's the procedure here? -- Jeanette From kevin.rushforth at oracle.com Fri Nov 8 15:21:53 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 8 Nov 2019 16:21:53 +0100 Subject: To write tests or not to write tests ... In-Reply-To: <20191108115458.Horde.MPxm0psLdtU0gprI8EEetA1@webmail.df.eu> References: <20191108115458.Horde.MPxm0psLdtU0gprI8EEetA1@webmail.df.eu> Message-ID: <1b03c98c-945b-01d9-6399-cda892413f5f@oracle.com> In general, I would say it's OK to rely on existing tests for trivial refactoring, that is a refactoring where it seems fairly obvious that there are not going to be changes in behavior (even if such tests may be inadequate). For less trivial refactoring, if there are clearly missing tests, I would think they should be added to ensure no unintended behavioral changes, although I wouldn't go overboard. Bug fixes and new features are a different matter. In the specific case you cite, there is new public API, so at the very least, testing the new API is needed. I haven't (yet) looked closely enough to know whether the refactoring is a possible source of concern that would warrant additional tests. -- Kevin On 11/8/2019 11:54 AM, Jeanette Winzenburg wrote: > > ... if changes are "just" a re-arrangement of code (like > https://github.com/openjdk/jfx/pull/6 - 8207957: TableSkinUtils should > not contain actual code implementation)? > > In an ideal world, there would be a safety-net of tests (they would > have been written at the time the old code was pushed - wouldn't they > ;). All we would need to do is run them to ensure that our > re-arrangement doesn't break anything. > > In the real world and that particular pull request above, there are > not tests (that I could find, maybe overlooked them). > > Now the question: is the contributor responsible for writing those > missing tests? The two extremes are > > - yes, it's a good opportunity ;) And it is mandatory (probably?) for > all public/protected api. A new protected method with specification > was condensed and should be tested. > - no, nothing changed, the tests were always missing and all still > live ;) so doing nothing is just fine > > What's the procedure here? > > -- Jeanette > From aghaisas at openjdk.org Mon Nov 11 12:02:06 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 11 Nov 2019 12:02:06 GMT Subject: [Approved] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: <8cnTpI5dkPkTZdrziLdIUoYm2seudS5z0IWoHnqjxHk=.7b08536b-d7b5-42ad-9892-39d0f5b4b234@github.com> On Fri, 8 Nov 2019 10:32:58 GMT, Jeanette Winzenburg wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - fbdea3df: changed test to compile under oldish junit > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/20/files > - new: https://git.openjdk.java.net/jfx/pull/20/files/92cd944e..fbdea3df > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/20/webrev.03 > - incr: https://webrevs.openjdk.java.net/jfx/20/webrev.02-03 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8231692 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/20.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/20/head:pull/20 Approved by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/20 From kcr at openjdk.org Mon Nov 11 15:22:48 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Nov 2019 15:22:48 GMT Subject: RFR: 8232063: Upgrade gradle to version 6.0 Message-ID: This PR upgrades the version of gradle used to build JavaFX to 6.0. In addition to keeping up to date, this will allow us to subsequently upgrade the boot JDK to JDK 13. This change does the following: 1. Use ivy `patternLayout ...` instead of `layout "pattern" ...` and specify no metadata for ivy repositories. This was split out of [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754), PR #9, because the replacement API is documented as unstable in gradle 5.x (although it works fine) and isn't needed until we actually upgrade to 6.0. 2. Bump the gradle version used by the build from 5.3 to 6.0. Note that this does not change the minimum required version of gradle, which remains at 5.3. I have compared the artifacts produced before and after this change and there are no differences. ---------------- Commits: - 5b224e5d: 8232063: Upgrade gradle to version 6.0 Changes: https://git.openjdk.java.net/jfx/pull/33/files Webrev: https://webrevs.openjdk.java.net/jfx/33/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232063 Stats: 24 lines in 5 files changed: 15 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/33/head:pull/33 PR: https://git.openjdk.java.net/jfx/pull/33 From kcr at openjdk.org Mon Nov 11 15:25:24 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Nov 2019 15:25:24 GMT Subject: RFR: 8232063: Upgrade gradle to version 6.0 In-Reply-To: References: Message-ID: <2e4EJcLhYLsGJyhpVW-0IGr5ExUrst9tppc85SWybhQ=.377c661e-4533-4a6b-a6df-cea4aa7afc41@github.com> On Mon, 11 Nov 2019 15:22:48 GMT, Kevin Rushforth wrote: > This PR upgrades the version of gradle used to build JavaFX to 6.0. In addition to keeping up to date, this will allow us to subsequently upgrade the boot JDK to JDK 13. > > This change does the following: > > 1. Use ivy `patternLayout ...` instead of `layout "pattern" ...` and specify no metadata for ivy repositories. This was split out of [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754), PR #9, because the replacement API is documented as unstable in gradle 5.x (although it works fine) and isn't needed until we actually upgrade to 6.0. > > 2. Bump the gradle version used by the build from 5.3 to 6.0. > > Note that this does not change the minimum required version of gradle, which remains at 5.3. > > I have compared the artifacts produced before and after this change and there are no differences. > > ---------------- > > Commits: > - 5b224e5d: 8232063: Upgrade gradle to version 6.0 > > Changes: https://git.openjdk.java.net/jfx/pull/33/files > Webrev: https://webrevs.openjdk.java.net/jfx/33/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232063 > Stats: 24 lines in 5 files changed: 15 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/33.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/33/head:pull/33 Reviewers: @johanvos @arapte PR: https://git.openjdk.java.net/jfx/pull/33 From kcr at openjdk.org Mon Nov 11 15:40:24 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Nov 2019 15:40:24 GMT Subject: RFR: 8233338: FX javadoc headings are out of sequence In-Reply-To: References: Message-ID: On Thu, 31 Oct 2019 19:40:25 GMT, Kevin Rushforth wrote: > As indicated in [JDK-8233338](https://bugs.openjdk.java.net/browse/JDK-8233338), this fixes all of our javadoc HTML headings to conform with the rule that all HTML heading tags in class documents must start with `

` and be nested correctly (i.e., no skipping levels). See [JDK-8219801](https://bugs.openjdk.java.net/browse/JDK-8219801) and [JDK-8220379](https://bugs.openjdk.java.net/browse/JDK-8220379). > > We have a few places where we are using `

` tags and several more where we are using `

`. As a result, the build of FX docs via `gradle javadoc` fails with JDK 13. We had one `

` heading that wasn't supposed to be nested with the previous `

` heading, so I made both of the `

` to reflect this. > > This fix can go in at any time, but must be done before we can switch the boot JDK to 13 in [JDK-8232064](https://bugs.openjdk.java.net/browse/JDK-8232064), else the build will fail. > > ---------------- > > Commits: > - c5d8372a: 8233338: FX javadoc headings are out of sequence > > Changes: https://git.openjdk.java.net/jfx/pull/29/files > Webrev: https://webrevs.openjdk.java.net/jfx/29/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233338 > Stats: 69 lines in 26 files changed: 0 ins; 0 del; 69 mod > Patch: https://git.openjdk.java.net/jfx/pull/29.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/29/head:pull/29 Reviewers: @aghaisas PR: https://git.openjdk.java.net/jfx/pull/29 From kcr at openjdk.org Mon Nov 11 15:41:24 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Nov 2019 15:41:24 GMT Subject: RFR: 8233338: FX javadoc headings are out of sequence In-Reply-To: References: Message-ID: <7LSvxWxfAxySDYG2qRBxV9lqnoPmEljuFqKkA0muydw=.3b38290e-38ad-4b1b-9372-3e0e3674c541@github.com> On Mon, 11 Nov 2019 15:40:24 GMT, Kevin Rushforth wrote: > On Thu, 31 Oct 2019 19:40:25 GMT, Kevin Rushforth wrote: > >> As indicated in [JDK-8233338](https://bugs.openjdk.java.net/browse/JDK-8233338), this fixes all of our javadoc HTML headings to conform with the rule that all HTML heading tags in class documents must start with `

` and be nested correctly (i.e., no skipping levels). See [JDK-8219801](https://bugs.openjdk.java.net/browse/JDK-8219801) and [JDK-8220379](https://bugs.openjdk.java.net/browse/JDK-8220379). >> >> We have a few places where we are using `

` tags and several more where we are using `

`. As a result, the build of FX docs via `gradle javadoc` fails with JDK 13. We had one `

` heading that wasn't supposed to be nested with the previous `

` heading, so I made both of the `

` to reflect this. >> >> This fix can go in at any time, but must be done before we can switch the boot JDK to 13 in [JDK-8232064](https://bugs.openjdk.java.net/browse/JDK-8232064), else the build will fail. >> >> ---------------- >> >> Commits: >> - c5d8372a: 8233338: FX javadoc headings are out of sequence >> >> Changes: https://git.openjdk.java.net/jfx/pull/29/files >> Webrev: https://webrevs.openjdk.java.net/jfx/29/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8233338 >> Stats: 69 lines in 26 files changed: 0 ins; 0 del; 69 mod >> Patch: https://git.openjdk.java.net/jfx/pull/29.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/29/head:pull/29 > > Reviewers: @aghaisas This only needs 1 reviewer. PR: https://git.openjdk.java.net/jfx/pull/29 From aghaisas at openjdk.org Tue Nov 12 04:21:45 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Nov 2019 04:21:45 GMT Subject: [Integrated] RFR: 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene In-Reply-To: References: Message-ID: <9dc13147-e667-46a7-b899-ae8a40231063@openjdk.org> Changeset: 94bcf3fc Author: Jeanette Winzenburg Committer: Ajit Ghaisas Date: 2019-11-12 04:21:17 +0000 URL: https://git.openjdk.java.net/jfx/commit/94bcf3fc 8231692: Test Infrastructure: enhance KeyEventFirer to inject keyEvents into scene Reviewed-by: aghaisas ! modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java + modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirerTest.java From fkirmaier at openjdk.org Tue Nov 12 10:15:49 2019 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 12 Nov 2019 10:15:49 GMT Subject: [Rev 01] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 85c87628: JDK-8200224 Changes: - all: https://git.openjdk.java.net/jfx/pull/25/files - new: https://git.openjdk.java.net/jfx/pull/25/files/314e423c..85c87628 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/25/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 Stats: 52 lines in 3 files changed: 8 ins; 34 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.org Tue Nov 12 10:23:16 2019 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 12 Nov 2019 10:23:16 GMT Subject: [Rev 02] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 5cd96a56: JDK-8200224 Changes: - all: https://git.openjdk.java.net/jfx/pull/25/files - new: https://git.openjdk.java.net/jfx/pull/25/files/85c87628..5cd96a56 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/25/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.01-02 Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.org Tue Nov 12 10:33:53 2019 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 12 Nov 2019 10:33:53 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 08:30:47 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > >> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >> >> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >> >> The pull request introduces a new fix for the problem. >> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >> We do so, by using setFocused. >> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >> because calling setFocused just sets the value of a boolean property. >> >> I've now also added a unit-test for the problem. >> >> ---------------- >> >> Commits: >> - 314e423c: JDK-8200224 >> - 725e5fef: JDK-8200224 >> >> Changes: https://git.openjdk.java.net/jfx/pull/25/files >> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: > >> 456: >> 457: sendMouseEventToFX(e); >> 458: super.processMouseEvent(e); > > typo: save --> safe > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > replace `2014, 2016` with `2019,` > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: > >> 27: >> 28: import javafx.application.Application; >> 29: import javafx.application.Platform; > > Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: > >> 47: >> 48: import static junit.framework.Assert.assertEquals; >> 49: import static org.junit.Assert.assertNotNull; > > This method should be imported from `org.junit` package. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: > >> 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, >> 116: 5, 5, 1, false, MouseEvent.BUTTON1); >> 117: > > This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: > >> 56: >> 57: >> 58: @BeforeClass > > You can remove the extra blank line. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: > >> 64: >> 65: >> 66: try { > > You can remove the extra blank line. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: > >> 78: >> 79: class TestFXPanel extends JFXPanel { >> 80: protected void processMouseEventPublic(MouseEvent e) { > > I think this can be a static class. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: > >> 87: >> 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); >> 89: > > This can be final. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: > >> 90: // It's an array, so we can mutate it inside of lambda statement >> 91: int[] pressedEventCounter = {0}; >> 92: > > This can be final. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: > >> 131: >> 132: >> 133: } > > You can remove the extra blank line. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: > >> 122: >> 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >> 124: throw new Exception(); > > Add a space after the `if`. > > The fix seems fine. Have you tested it on all three platforms? > > I have several comments on the test. > > ---------------- > > Disapproved by kcr (Lead). You can run the AWT_TESTS with the following statement: ./gradlew -PFULL_TEST=true swing:clean swing:test For some reason, it's hidden behind this flag. Maybe that's the reason, why you couldn't reproduce the bug? As fas as I can thee, the swing-tests are stable, so there is no real reason to hide it behind a flag. Maybe that's something which should be changed? The tests are now stable. The previous version had some problems because the other test for Swing was calling System.exit. The fix is well tested under Windows and Mac but not on Linux. The tests are based on a backport to an older JavaFX-version. PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.org Tue Nov 12 10:35:36 2019 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 12 Nov 2019 10:35:36 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 08:30:47 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > >> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >> >> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >> >> The pull request introduces a new fix for the problem. >> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >> We do so, by using setFocused. >> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >> because calling setFocused just sets the value of a boolean property. >> >> I've now also added a unit-test for the problem. >> >> ---------------- >> >> Commits: >> - 314e423c: JDK-8200224 >> - 725e5fef: JDK-8200224 >> >> Changes: https://git.openjdk.java.net/jfx/pull/25/files >> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: > >> 456: >> 457: sendMouseEventToFX(e); >> 458: super.processMouseEvent(e); > > typo: save --> safe > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > replace `2014, 2016` with `2019,` > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: > >> 27: >> 28: import javafx.application.Application; >> 29: import javafx.application.Platform; > > Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: > >> 47: >> 48: import static junit.framework.Assert.assertEquals; >> 49: import static org.junit.Assert.assertNotNull; > > This method should be imported from `org.junit` package. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: > >> 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, >> 116: 5, 5, 1, false, MouseEvent.BUTTON1); >> 117: > > This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: > >> 56: >> 57: >> 58: @BeforeClass > > You can remove the extra blank line. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: > >> 64: >> 65: >> 66: try { > > You can remove the extra blank line. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: > >> 78: >> 79: class TestFXPanel extends JFXPanel { >> 80: protected void processMouseEventPublic(MouseEvent e) { > > I think this can be a static class. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: > >> 87: >> 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); >> 89: > > This can be final. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: > >> 90: // It's an array, so we can mutate it inside of lambda statement >> 91: int[] pressedEventCounter = {0}; >> 92: > > This can be final. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: > >> 131: >> 132: >> 133: } > > You can remove the extra blank line. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: > >> 122: >> 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >> 124: throw new Exception(); > > Add a space after the `if`. > > The fix seems fine. Have you tested it on all three platforms? > > I have several comments on the test. > > ---------------- > > Disapproved by kcr (Lead). Maybe try `./gradlew -PFULL_TEST=true swing:clean swing:test`. I'm sure, it can be reproduced on windows. If you still can not reproduce it, then I will add a test for the Robot. PR: https://git.openjdk.java.net/jfx/pull/25 From aghaisas at openjdk.org Tue Nov 12 16:45:04 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Nov 2019 16:45:04 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation Message-ID: **Issue :** https://bugs.openjdk.java.net/browse/JDK-8193445 **Background :** The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. **Description :** This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). For ease of review, I have made two separate commits - 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test **Root Cause :** CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) **Fix :** Fixed the identified root cause. See commit 2. **Testing :** 1. All passing unit tests continue to pass 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix 3. System test JDK8183100Test continues to pass 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix In addition, testing by community with specific CSS performance / functionality will be helpful. ---------------- Commits: - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test - d964675e: Reintroduce JDK-8151756 CSS performance fix Changes: https://git.openjdk.java.net/jfx/pull/34/files Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 PR: https://git.openjdk.java.net/jfx/pull/34 From aghaisas at openjdk.org Tue Nov 12 16:52:54 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Nov 2019 16:52:54 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > **Issue :** > https://bugs.openjdk.java.net/browse/JDK-8193445 > > **Background :** > The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. > > **Description :** > This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > For ease of review, I have made two separate commits - > 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. > 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test > > **Root Cause :** > CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. > What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. > This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) > > **Fix :** > Fixed the identified root cause. See commit 2. > > **Testing :** > 1. All passing unit tests continue to pass > 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix > 3. System test JDK8183100Test continues to pass > 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix > > In addition, testing by community with specific CSS performance / functionality will be helpful. > > ---------------- > > Commits: > - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test > - d964675e: Reintroduce JDK-8151756 CSS performance fix > > Changes: https://git.openjdk.java.net/jfx/pull/34/files > Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 > Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/34.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 Reviewers: @kevinrushforth and @arapte PR: https://git.openjdk.java.net/jfx/pull/34 From aghaisas at openjdk.org Tue Nov 12 16:55:45 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Nov 2019 16:55:45 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: > On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > >> **Issue :** >> https://bugs.openjdk.java.net/browse/JDK-8193445 >> >> **Background :** >> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >> >> **Description :** >> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >> For ease of review, I have made two separate commits - >> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >> >> **Root Cause :** >> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >> >> **Fix :** >> Fixed the identified root cause. See commit 2. >> >> **Testing :** >> 1. All passing unit tests continue to pass >> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >> 3. System test JDK8183100Test continues to pass >> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >> >> In addition, testing by community with specific CSS performance / functionality will be helpful. >> >> ---------------- >> >> Commits: >> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >> - d964675e: Reintroduce JDK-8151756 CSS performance fix >> >> Changes: https://git.openjdk.java.net/jfx/pull/34/files >> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 > > Reviewers: @kevinrushforth and @arapte It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. PR: https://git.openjdk.java.net/jfx/pull/34 From kevin.rushforth at oracle.com Tue Nov 12 17:59:26 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 12 Nov 2019 09:59:26 -0800 Subject: FYI, New candidate JEP: 369: Migrate to GitHub Message-ID: <8e365e27-323c-47c4-0040-fe9a1dc74758@oracle.com> FYI, a new candidate JEP [1] that proposes to migrate OpenJDK source repositories to GitHub was published today [2]. As most of you know, the JavaFX repository has already moved to GitHub as an early access of this proposed migration. If you are interested, you can use discuss at openjdk.java.net for feedback on the JEP. -- Kevin [1] https://openjdk.java.net/jeps/369 [2] https://mail.openjdk.java.net/pipermail/discuss/2019-November/005185.html From kcr at openjdk.org Wed Nov 13 01:17:44 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 01:17:44 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: <5XRJyBGYagcqRuOygjHubkkI_twGh8i3N2UUwnT7p9k=.197bf17a-13ef-4b61-a337-e310e39f1044@github.com> On Tue, 12 Nov 2019 10:35:36 GMT, Florian Kirmaier wrote: > On Wed, 6 Nov 2019 08:30:47 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >> >>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>> >>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>> >>> The pull request introduces a new fix for the problem. >>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>> We do so, by using setFocused. >>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>> because calling setFocused just sets the value of a boolean property. >>> >>> I've now also added a unit-test for the problem. >>> >>> ---------------- >>> >>> Commits: >>> - 314e423c: JDK-8200224 >>> - 725e5fef: JDK-8200224 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >> >> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: >> >>> 456: >>> 457: sendMouseEventToFX(e); >>> 458: super.processMouseEvent(e); >> >> typo: save --> safe >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. >>> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> replace `2014, 2016` with `2019,` >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: >> >>> 27: >>> 28: import javafx.application.Application; >>> 29: import javafx.application.Platform; >> >> Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: >> >>> 47: >>> 48: import static junit.framework.Assert.assertEquals; >>> 49: import static org.junit.Assert.assertNotNull; >> >> This method should be imported from `org.junit` package. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: >> >>> 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, >>> 116: 5, 5, 1, false, MouseEvent.BUTTON1); >>> 117: >> >> This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: >> >>> 56: >>> 57: >>> 58: @BeforeClass >> >> You can remove the extra blank line. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: >> >>> 64: >>> 65: >>> 66: try { >> >> You can remove the extra blank line. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: >> >>> 78: >>> 79: class TestFXPanel extends JFXPanel { >>> 80: protected void processMouseEventPublic(MouseEvent e) { >> >> I think this can be a static class. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: >> >>> 87: >>> 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); >>> 89: >> >> This can be final. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: >> >>> 90: // It's an array, so we can mutate it inside of lambda statement >>> 91: int[] pressedEventCounter = {0}; >>> 92: >> >> This can be final. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: >> >>> 131: >>> 132: >>> 133: } >> >> You can remove the extra blank line. >> >> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: >> >>> 122: >>> 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >>> 124: throw new Exception(); >> >> Add a space after the `if`. >> >> The fix seems fine. Have you tested it on all three platforms? >> >> I have several comments on the test. >> >> ---------------- >> >> Disapproved by kcr (Lead). > > Maybe try `./gradlew -PFULL_TEST=true swing:clean swing:test`. > I'm sure, it can be reproduced on windows. > If you still can not reproduce it, then I will add a test for the Robot. I'll try it again with the updated test. > You can run the AWT_TESTS with the following statement: > > ``` > ./gradlew -PFULL_TEST=true swing:clean swing:test > ``` Yes, I know that it needs `-PFULL_TEST=true`, but the earlier test wasn't failing for me. And yes, it is intentional; for reasons I can't recall, the swing tests don't work in headless mode. Anyway, I don't want to revisit this right now. > The tests are now stable. The previous version had some problems because the other test for Swing was calling System.exit. Tests should not call `System.exit`. If they do, then that's almost certainly a bug. PR: https://git.openjdk.java.net/jfx/pull/25 From aghaisas at openjdk.org Wed Nov 13 06:58:25 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 13 Nov 2019 06:58:25 GMT Subject: [Approved] RFR: 8233338: FX javadoc headings are out of sequence In-Reply-To: References: Message-ID: <0eH9dKxC3NnQk06Gc9oaq7VN9_V0CYyocAkzEKLuCyM=.de597bdc-7d95-45ab-ae5d-f35e8f0ce0f0@github.com> On Thu, 31 Oct 2019 19:40:25 GMT, Kevin Rushforth wrote: > As indicated in [JDK-8233338](https://bugs.openjdk.java.net/browse/JDK-8233338), this fixes all of our javadoc HTML headings to conform with the rule that all HTML heading tags in class documents must start with `

` and be nested correctly (i.e., no skipping levels). See [JDK-8219801](https://bugs.openjdk.java.net/browse/JDK-8219801) and [JDK-8220379](https://bugs.openjdk.java.net/browse/JDK-8220379). > > We have a few places where we are using `

` tags and several more where we are using `

`. As a result, the build of FX docs via `gradle javadoc` fails with JDK 13. We had one `

` heading that wasn't supposed to be nested with the previous `

` heading, so I made both of the `

` to reflect this. > > This fix can go in at any time, but must be done before we can switch the boot JDK to 13 in [JDK-8232064](https://bugs.openjdk.java.net/browse/JDK-8232064), else the build will fail. > > ---------------- > > Commits: > - c5d8372a: 8233338: FX javadoc headings are out of sequence > > Changes: https://git.openjdk.java.net/jfx/pull/29/files > Webrev: https://webrevs.openjdk.java.net/jfx/29/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233338 > Stats: 69 lines in 26 files changed: 0 ins; 0 del; 69 mod > Patch: https://git.openjdk.java.net/jfx/pull/29.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/29/head:pull/29 Approved by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/29 From shadzic at openjdk.org Wed Nov 13 11:26:35 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 13 Nov 2019 11:26:35 GMT Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - e1a9d2d0: Add more unit tests upon review Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new: https://git.openjdk.java.net/jfx/pull/6/files/2b088993..e1a9d2d0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/6/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.04-05 Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 Stats: 185 lines in 2 files changed: 117 ins; 48 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx/pull/6 From shadzic at openjdk.org Wed Nov 13 11:26:54 2019 From: shadzic at openjdk.org (Hadzic Samir) Date: Wed, 13 Nov 2019 11:26:54 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Thu, 7 Nov 2019 12:07:55 GMT, Jeanette Winzenburg wrote: > On Fri, 1 Nov 2019 10:59:57 GMT, Hadzic Samir wrote: > >> On Tue, 29 Oct 2019 13:19:27 GMT, Hadzic Samir wrote: >> >>> On Wed, 9 Oct 2019 16:01:38 GMT, Kevin Rushforth wrote: >>> >>>> On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: >>>> >>>>> On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: >>>>> >>>>>> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >>>>>> >>>>>>> Allright, this is a fix for JDK-8207957 >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - 969ebb51: Fixing TableColumnHeaderTest >>>>>>> - 9d379619: Removing Tablecolumnbasehelper >>>>>>> - 4fe020fc: Fix javadoc for TableColumnHeader >>>>>>> - c422c80f: Minor modification and uni test added. >>>>>>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>>>>>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>>>>>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>>>>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>>>>> >>>>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >>>>>> >>>>>>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>>>>>> 600: * {@code super()}) to provide their custom algorithm. >>>>>>> 601: * >>>>>> >>>>>> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) >>>>> >>>>> Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. >>>>> >>>>> I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. >>>> >>>> A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. >>> >>> Do you think this looks good now @kleopatra @nlisker ? >> >> Yes I was waiting for the final 'go'. I will update it asap, thanks >> >> Le ven. 1 nov. 2019 ? 09:49, Jeanette Winzenburg >> a ?crit : >> >>> *@kleopatra* commented on this pull request. >>> ------------------------------ >>> >>> In >>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java >>> : >>> >>> > + * Resizes this {@code TableColumnHeader}'s column to fit the width of its content. >>> + * >>> + * @implSpec The resulting column width for this implementation is the maximum of the preferred width of the header >>> + * cell and the preferred width of the first {@code maxRow} cells. >>> + *

>>> + * Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their >>> + * custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum >>> + * width etc.). >>> + * >>> + * @param maxRows the number of rows considered when resizing. If -1 is given, all rows are considered. >>> + * @since 14 >>> >>> looks good to me :) You would have to update the crs eventually, right? >>> >>> ? >>> You are receiving this because you authored the thread. >>> Reply to this email directly, view it on GitHub >>> , >>> or unsubscribe >>> >>> . >>> > > As to the test, it's a bit ... confusing, will try to suggest some changes - take them with a grain of salt, though, because I'm still groping to find my path through the wilderness here :) I have changed the unit test according to @kleopatra review and also add two more unit test regarding the headerContent and maxRows. PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Wed Nov 13 13:40:45 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 13:40:45 GMT Subject: [Integrated] RFR: 8233338: FX javadoc headings are out of sequence In-Reply-To: References: Message-ID: Changeset: d46dcae7 Author: Kevin Rushforth Date: 2019-11-13 13:40:05 +0000 URL: https://git.openjdk.java.net/jfx/commit/d46dcae7 8233338: FX javadoc headings are out of sequence Reviewed-by: aghaisas ! modules/javafx.base/src/main/java/javafx/beans/binding/package.html ! modules/javafx.base/src/main/java/javafx/beans/property/package.html ! modules/javafx.base/src/main/java/javafx/beans/value/package.html ! modules/javafx.controls/src/main/java/javafx/scene/control/ButtonBar.java ! modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java ! modules/javafx.controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java ! modules/javafx.controls/src/main/java/javafx/scene/control/ListView.java ! modules/javafx.controls/src/main/java/javafx/scene/control/Pagination.java ! modules/javafx.controls/src/main/java/javafx/scene/control/TreeView.java ! modules/javafx.graphics/src/main/java/javafx/scene/Node.java ! modules/javafx.graphics/src/main/java/javafx/scene/input/DragEvent.java ! modules/javafx.graphics/src/main/java/javafx/scene/input/MouseEvent.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderPane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/FlowPane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/StackPane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/TilePane.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java ! modules/javafx.graphics/src/main/java/javafx/scene/layout/package.html ! modules/javafx.graphics/src/main/java/javafx/scene/package.html ! modules/javafx.graphics/src/main/java/javafx/scene/shape/Shape.java ! modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java From Rony.Flatscher at wu.ac.at Wed Nov 13 14:14:59 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 13 Nov 2019 15:14:59 +0100 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> Message-ID: <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> Hmm, not getting any feedback so far, so wondering if there are currently any Java developers who take advantage of the ability of FXMLLoader to have FXML controllers implemented in any of the Java javax.script languages? For those, who use scripting languages for FXML controllers the request that FXMLLoader adds both entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV () (for making the event object available directly as an argument) into the engine Bindings, should be quite helpful while developing and running the scripts. [Personally I am using the scripting engine ooRexx successfully for teaching oo programming from scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a Business Administration university. So these two missing features in the current FXMLLoader support for FXML controllers would help tremendously, especially in case of coding errors as currently it is not clear from which file the script that has an error comes from, making it extremely cumbersome and time consuming in JavaFX applications that use multiple and complex FXML files.] Therefore I would kindly ask interested committers for mentoring the proposed changes. Enclosed please find a simpler version of the patch that adds these missing features to the ENGINE_SCOPE Bindings in the three locations where ScriptEngine.eval() gets invoked (it ). To comment this simple patch, maybe I should add a few remarks such that the context becomes clear: * invoking a script via ScriptEngine.eval() will always be accompanied with a ScriptContext that usually maintains two Bindings (Maps): o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting the FXML elements that have an fx:id attribute defined, such that scripts can get access to them, independent of a particular ScriptEngine) which can also be used for sharing values among different script invocations, o one, ENGINE_SCOPE Bindings, usually used for individual invocations. * while a FXML file gets processed sequentially by the FXMLLoader elements in the form of "" will cause invoking the ScriptEngine.eval(Reader): this patch fetches the ENGINE_SCOPE Bindings and puts the value "someScript.ext" with the key ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class FXMLLoader" and "@@ -1582,6 +1585,8 @@ public class FXMLLoader" in the patch), * if an event handler gets defined (e.g. with the event attribute "") the FXMLLoader creates a ScriptEventHandler and stores "someScript" and the ScriptEngine for executing that script whenever the event fires. o When an event fires, the current implementation creates a copy of the current ENGINE_SCOPE Bindings from the ScriptEngine's ScriptContext, adds its entries to it after saving the entry "event" with the ActionEvent object in it. It then changes the ScriptEngine's current ScriptContext such that it now uses the new copy of the Bindings as its ENGINE_SCOPE Bindings, runs the script using eval() and then restores the ScriptContext ENGINE_SCOPE Bindings. o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class FXMLLoader") instead will create a copy of the ENGINE_SCOPE Bindings only once at creation time (and puts the appropriate ScriptEngine.FILENAME into it using the name of the FXML file that defines the event script attribute) and will reuse that Bindings each time the handler gets invoked, after putting the actual "event" object and the respective ScriptEngine.ARGV entry into it. Using ScriptEngine.eval(String,Bindings) will use the supplied Bindings as the ENGINE_SCOPE Bindings for this invocation only, such that no restore is necessary upon return. As only entries get added to the engine Bindings that have not been used by FXMLLoader this simple patch should not affect existing scripts. The patch has been tested and works. Maybe it helps the cause for applying this patch, if I point out that I have been active in a number of opensource projects, including Apache's BSF which led to my participation as an expert in JSR-223 which originally defined the javax.script framework introduced with Java 6 (also authored a complete ScriptEngine implementation with both, the javax.script.Compilable and the javax.script.Invocable interfaces). So looking for interested committers who would be willing to mentor this patch. Please advise. ---rony On 06.11.2019 16:05, Rony G. Flatscher wrote: > Using a script engine (javax.script.ScriptEngine) for implementing a FXML controller there are two > important information missing in the ScriptContext.ENGINE_SCOPE Bindings supplied to the script used > to eval() the script code: > > * ScriptEngine.FILENAME > o This value denotes the file name from where the script code was fetched that is being eval()'d. > o When debugging script controllers in a complex JavaFX application it is mandatory to know > the file name the script code was taken from (as such scripts could be called/run from > different FXML files). Also, in the case of script runtime errors, usually the file name is > given by the script engine where the error has occurred to ease debugging, such that it is > important to really supply the filename. > + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE refers the FXML file,? not to the > file that hosts the script that gets run if using the " "source" attribute denotes the name of the script file. > o General solution: supply the appropriate ScriptEngine.FILENAME entry to the > ScriptContext.ENGINE_SCOPE Bindings. > > * ScriptEngine.ARGV > o This value denotes the arguments that get passed to the script from Java in form of a Java > Array of type Object. > o When defining event handlers in FXML files in script code the script does not get the > appropriate argument. Rather the script programmer needs to access the > ScriptContext.ENGINE_SCOPE and fetch the entry named "event" from there. Some script engines > may make the entries in the Bindings implicitly available to the scripts, however this > cannot be expected by default. However, a ScriptEngine.ARGV entry must be supplied to the > script by the script engine implementor, such that a script coder gets the event object > argument in the script language's manner. > o General solution: supply the appropriate ScriptEngine.ARGV Object array to the > ScriptContext.ENGINE_SCOPE Bindings. > > With these two changes not only writing controller scripts would be eased, it also would > instrumentate ScriptContext.ENGINE_SCOPE Bindings the way it was intended by JSR-223. > > Enclosed please find a tested diff for FXMLLoader.java from the current OpenJavaFX Master (version > 14) that implements both, ScriptEngine.FILENAME entries for all script invocations and in the case > of a script event handler the appropriate ScriptEngine.ARGV entry gets supplied, allowing the script > to fetch the event object directly as an argument. > > As I have signed the OCA the code (in form of a git diff) can be directly applied to FXMLLoader.java. > > If you need the patch in a different form, then please advise. > > ---rony > > -------------- next part -------------- diff --git a/gradlew b/gradlew old mode 100644 new mode 100755 diff --git a/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java b/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java index 7f3d2f3083..f9e2400f4c 100644 --- a/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java +++ b/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java @@ -1558,6 +1558,9 @@ public class FXMLLoader { location = new URL(FXMLLoader.this.location, source); } + Bindings engineBindings = engine.getBindings(ScriptContext.ENGINE_SCOPE); + engineBindings.put(engine.FILENAME, location.getPath()); + InputStreamReader scriptReader = null; try { scriptReader = new InputStreamReader(location.openStream(), charset); @@ -1582,6 +1585,8 @@ public class FXMLLoader { if (value != null && !staticLoad) { // Evaluate the script try { + Bindings engineBindings = scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE); + engineBindings.put(scriptEngine.FILENAME, location.getPath()); scriptEngine.eval((String)value); } catch (ScriptException exception) { System.err.println(exception.getMessage()); @@ -1675,30 +1680,28 @@ public class FXMLLoader { private static class ScriptEventHandler implements EventHandler { public final String script; public final ScriptEngine scriptEngine; + public final Bindings engineBindings; public ScriptEventHandler(String script, ScriptEngine scriptEngine) { this.script = script; this.scriptEngine = scriptEngine; + this.engineBindings = scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE); + URL location=(URL) scriptEngine.getBindings(ScriptContext.GLOBAL_SCOPE).get(LOCATION_KEY); + this.engineBindings.put(scriptEngine.FILENAME, location.getPath()); } @Override public void handle(Event event) { - // Don't pollute the page namespace with values defined in the script - Bindings engineBindings = scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE); - Bindings localBindings = scriptEngine.createBindings(); - localBindings.put(EVENT_KEY, event); - localBindings.putAll(engineBindings); - scriptEngine.setBindings(localBindings, ScriptContext.ENGINE_SCOPE); + // Don't pollute the page namespace with values defined in the script use initial engineBindings + engineBindings.put(EVENT_KEY, event); + engineBindings.put(scriptEngine.ARGV, new Object[]{event}); // Execute the script try { - scriptEngine.eval(script); + scriptEngine.eval(script,engineBindings); } catch (ScriptException exception){ throw new RuntimeException(exception); } - - // Restore the original bindings - scriptEngine.setBindings(engineBindings, ScriptContext.ENGINE_SCOPE); } } From mp at jugs.org Wed Nov 13 14:40:17 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 13 Nov 2019 15:40:17 +0100 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> Message-ID: Hi, have you considered directly contributing your proposed change via a PR on ? According to my experience this may speed up things considerably but don't forget to follow the procedures as outlined in . --Michael Am 13.11.19 um 15:14 schrieb Rony G. Flatscher: > Hmm, not getting any feedback so far, so wondering if there are currently any Java developers who > take advantage of the ability of FXMLLoader to have FXML controllers implemented in any of the Java > javax.script languages? > > For those, who use scripting languages for FXML controllers the request that FXMLLoader adds both > entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV () (for making the > event object available directly as an argument) into the engine Bindings, should be quite helpful > while developing and running the scripts. > > [Personally I am using the scripting engine ooRexx successfully for teaching oo programming from > scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a Business Administration > university. So these two missing features in the current FXMLLoader support for FXML controllers > would help tremendously, especially in case of coding errors as currently it is not clear from which > file the script that has an error comes from, making it extremely cumbersome and time consuming in > JavaFX applications that use multiple and complex FXML files.] > > Therefore I would kindly ask interested committers for mentoring the proposed changes. Enclosed > please find a simpler version of the patch that adds these missing features to the ENGINE_SCOPE > Bindings in the three locations where ScriptEngine.eval() gets invoked (it ). > > To comment this simple patch, maybe I should add a few remarks such that the context becomes clear: > > * invoking a script via ScriptEngine.eval() will always be accompanied with a ScriptContext that > usually maintains two Bindings (Maps): > > o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting the FXML elements that > have an fx:id attribute defined, such that scripts can get access to them, independent of a > particular ScriptEngine) which can also be used for sharing values among different script > invocations, > > o one, ENGINE_SCOPE Bindings, usually used for individual invocations. > > * while a FXML file gets processed sequentially by the FXMLLoader elements in the form of > "" will cause invoking the ScriptEngine.eval(Reader): this > patch fetches the ENGINE_SCOPE Bindings and puts the value "someScript.ext" with the key > ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class FXMLLoader" and "@@ > -1582,6 +1585,8 @@ public class FXMLLoader" in the patch), > > * if an event handler gets defined (e.g. with the event attribute " onAction="someScript">") the FXMLLoader creates a ScriptEventHandler and stores "someScript" and > the ScriptEngine for executing that script whenever the event fires. > > o When an event fires, the current implementation creates a copy of the current ENGINE_SCOPE > Bindings from the ScriptEngine's ScriptContext, adds its entries to it after saving the > entry "event" with the ActionEvent object in it. It then changes the ScriptEngine's current > ScriptContext such that it now uses the new copy of the Bindings as its ENGINE_SCOPE > Bindings, runs the script using eval() and then restores the ScriptContext ENGINE_SCOPE > Bindings. > > o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class FXMLLoader") instead will > create a copy of the ENGINE_SCOPE Bindings only once at creation time (and puts the > appropriate ScriptEngine.FILENAME into it using the name of the FXML file that defines the > event script attribute) and will reuse that Bindings each time the handler gets invoked, > after putting the actual "event" object and the respective ScriptEngine.ARGV entry into it. > Using ScriptEngine.eval(String,Bindings) will use the supplied Bindings as the ENGINE_SCOPE > Bindings for this invocation only, such that no restore is necessary upon return. > > As only entries get added to the engine Bindings that have not been used by FXMLLoader this simple > patch should not affect existing scripts. The patch has been tested and works. > > Maybe it helps the cause for applying this patch, if I point out that I have been active in a number > of opensource projects, including Apache's BSF which led to my participation as an expert in JSR-223 > which originally defined the javax.script framework introduced with Java 6 (also authored a complete > ScriptEngine implementation with both, the javax.script.Compilable and the javax.script.Invocable > interfaces). > > So looking for interested committers who would be willing to mentor this patch. Please advise. > > ---rony > > > > On 06.11.2019 16:05, Rony G. Flatscher wrote: >> Using a script engine (javax.script.ScriptEngine) for implementing a FXML controller there are two >> important information missing in the ScriptContext.ENGINE_SCOPE Bindings supplied to the script used >> to eval() the script code: >> >> * ScriptEngine.FILENAME >> o This value denotes the file name from where the script code was fetched that is being eval()'d. >> o When debugging script controllers in a complex JavaFX application it is mandatory to know >> the file name the script code was taken from (as such scripts could be called/run from >> different FXML files). Also, in the case of script runtime errors, usually the file name is >> given by the script engine where the error has occurred to ease debugging, such that it is >> important to really supply the filename. >> + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE refers the FXML file,? not to the >> file that hosts the script that gets run if using the "> "source" attribute denotes the name of the script file. >> o General solution: supply the appropriate ScriptEngine.FILENAME entry to the >> ScriptContext.ENGINE_SCOPE Bindings. >> >> * ScriptEngine.ARGV >> o This value denotes the arguments that get passed to the script from Java in form of a Java >> Array of type Object. >> o When defining event handlers in FXML files in script code the script does not get the >> appropriate argument. Rather the script programmer needs to access the >> ScriptContext.ENGINE_SCOPE and fetch the entry named "event" from there. Some script engines >> may make the entries in the Bindings implicitly available to the scripts, however this >> cannot be expected by default. However, a ScriptEngine.ARGV entry must be supplied to the >> script by the script engine implementor, such that a script coder gets the event object >> argument in the script language's manner. >> o General solution: supply the appropriate ScriptEngine.ARGV Object array to the >> ScriptContext.ENGINE_SCOPE Bindings. >> >> With these two changes not only writing controller scripts would be eased, it also would >> instrumentate ScriptContext.ENGINE_SCOPE Bindings the way it was intended by JSR-223. >> >> Enclosed please find a tested diff for FXMLLoader.java from the current OpenJavaFX Master (version >> 14) that implements both, ScriptEngine.FILENAME entries for all script invocations and in the case >> of a script event handler the appropriate ScriptEngine.ARGV entry gets supplied, allowing the script >> to fetch the event object directly as an argument. >> >> As I have signed the OCA the code (in form of a git diff) can be directly applied to FXMLLoader.java. >> >> If you need the patch in a different form, then please advise. >> >> ---rony >> >> From Rony.Flatscher at wu.ac.at Wed Nov 13 15:21:47 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 13 Nov 2019 16:21:47 +0100 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> Message-ID: On 13.11.2019 15:40, Michael Paus wrote: > have you considered directly contributing your proposed change via a PR on > ? According to my experience this may speed > up things considerably but don't forget to follow the procedures as outlined in > . Thank you very much for this pointer, will read and try to follow the procedures outlined there! ---rony > Am 13.11.19 um 15:14 schrieb Rony G. Flatscher: >> Hmm, not getting any feedback so far, so wondering if there are currently any Java developers who >> take advantage of the ability of FXMLLoader to have FXML controllers implemented in any of the Java >> javax.script languages? >> >> For those, who use scripting languages for FXML controllers the request that FXMLLoader adds both >> entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV () (for making the >> event object available directly as an argument) into the engine Bindings, should be quite helpful >> while developing and running the scripts. >> >> [Personally I am using the scripting engine ooRexx successfully for teaching oo programming from >> scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a Business Administration >> university. So these two missing features in the current FXMLLoader support for FXML controllers >> would help tremendously, especially in case of coding errors as currently it is not clear from which >> file the script that has an error comes from, making it extremely cumbersome and time consuming in >> JavaFX applications that use multiple and complex FXML files.] >> >> Therefore I would kindly ask interested committers for mentoring the proposed changes. Enclosed >> please find a simpler version of the patch that adds these missing features to the ENGINE_SCOPE >> Bindings in the three locations where ScriptEngine.eval() gets invoked (it ). >> >> To comment this simple patch, maybe I should add a few remarks such that the context becomes clear: >> >> ?? * invoking a script via ScriptEngine.eval() will always be accompanied with a ScriptContext that >> ???? usually maintains two Bindings (Maps): >> >> ?????? o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting the FXML elements >> that >> ???????? have an fx:id attribute defined, such that scripts can get access to them, independent of a >> ???????? particular ScriptEngine) which can also be used for sharing values among different script >> ???????? invocations, >> >> ?????? o one, ENGINE_SCOPE Bindings, usually used for individual invocations. >> >> ?? * while a FXML file gets processed sequentially by the FXMLLoader elements in the form of >> ???? "" will cause invoking the ScriptEngine.eval(Reader): this >> ???? patch fetches the ENGINE_SCOPE Bindings and puts the value "someScript.ext" with the key >> ???? ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class FXMLLoader" and "@@ >> ???? -1582,6 +1585,8 @@ public class FXMLLoader" in the patch), >> >> ?? * if an event handler gets defined (e.g. with the event attribute "> ???? onAction="someScript">") the FXMLLoader creates a ScriptEventHandler and stores "someScript" >> and >> ???? the ScriptEngine for executing that script whenever the event fires. >> >> ?????? o When an event fires, the current implementation creates a copy of the current ENGINE_SCOPE >> ???????? Bindings from the ScriptEngine's ScriptContext, adds its entries to it after saving the >> ???????? entry "event" with the ActionEvent object in it. It then changes the ScriptEngine's current >> ???????? ScriptContext such that it now uses the new copy of the Bindings as its ENGINE_SCOPE >> ???????? Bindings, runs the script using eval() and then restores the ScriptContext ENGINE_SCOPE >> ???????? Bindings. >> >> ?????? o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class FXMLLoader") instead will >> ???????? create a copy of the ENGINE_SCOPE Bindings only once at creation time (and puts the >> ???????? appropriate ScriptEngine.FILENAME into it using the name of the FXML file that defines the >> ???????? event script attribute) and will reuse that Bindings each time the handler gets invoked, >> ???????? after putting the actual "event" object and the respective ScriptEngine.ARGV entry into it. >> ???????? Using ScriptEngine.eval(String,Bindings) will use the supplied Bindings as the ENGINE_SCOPE >> ???????? Bindings for this invocation only, such that no restore is necessary upon return. >> >> As only entries get added to the engine Bindings that have not been used by FXMLLoader this simple >> patch should not affect existing scripts. The patch has been tested and works. >> >> Maybe it helps the cause for applying this patch, if I point out that I have been active in a number >> of opensource projects, including Apache's BSF which led to my participation as an expert in JSR-223 >> which originally defined the javax.script framework introduced with Java 6 (also authored a complete >> ScriptEngine implementation with both, the javax.script.Compilable and the javax.script.Invocable >> interfaces). >> >> So looking for interested committers who would be willing to mentor this patch. Please advise. >> >> ---rony >> >> >> >> On 06.11.2019 16:05, Rony G. Flatscher wrote: >>> Using a script engine (javax.script.ScriptEngine) for implementing a FXML controller there are two >>> important information missing in the ScriptContext.ENGINE_SCOPE Bindings supplied to the script >>> used >>> to eval() the script code: >>> >>> ?? * ScriptEngine.FILENAME >>> ?????? o This value denotes the file name from where the script code was fetched that is being >>> eval()'d. >>> ?????? o When debugging script controllers in a complex JavaFX application it is mandatory to know >>> ???????? the file name the script code was taken from (as such scripts could be called/run from >>> ???????? different FXML files). Also, in the case of script runtime errors, usually the file >>> name is >>> ???????? given by the script engine where the error has occurred to ease debugging, such that it is >>> ???????? important to really supply the filename. >>> ?????????? + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE refers the FXML file,? not >>> to the >>> ???????????? file that hosts the script that gets run if using the ">> ???????????? "source" attribute denotes the name of the script file. >>> ?????? o General solution: supply the appropriate ScriptEngine.FILENAME entry to the >>> ???????? ScriptContext.ENGINE_SCOPE Bindings. >>> >>> ?? * ScriptEngine.ARGV >>> ?????? o This value denotes the arguments that get passed to the script from Java in form of a Java >>> ???????? Array of type Object. >>> ?????? o When defining event handlers in FXML files in script code the script does not get the >>> ???????? appropriate argument. Rather the script programmer needs to access the >>> ???????? ScriptContext.ENGINE_SCOPE and fetch the entry named "event" from there. Some script >>> engines >>> ???????? may make the entries in the Bindings implicitly available to the scripts, however this >>> ???????? cannot be expected by default. However, a ScriptEngine.ARGV entry must be supplied to the >>> ???????? script by the script engine implementor, such that a script coder gets the event object >>> ???????? argument in the script language's manner. >>> ?????? o General solution: supply the appropriate ScriptEngine.ARGV Object array to the >>> ???????? ScriptContext.ENGINE_SCOPE Bindings. >>> >>> With these two changes not only writing controller scripts would be eased, it also would >>> instrumentate ScriptContext.ENGINE_SCOPE Bindings the way it was intended by JSR-223. >>> >>> Enclosed please find a tested diff for FXMLLoader.java from the current OpenJavaFX Master (version >>> 14) that implements both, ScriptEngine.FILENAME entries for all script invocations and in the case >>> of a script event handler the appropriate ScriptEngine.ARGV entry gets supplied, allowing the >>> script >>> to fetch the event object directly as an argument. >>> >>> As I have signed the OCA the code (in form of a git diff) can be directly applied to >>> FXMLLoader.java. >>> >>> If you need the patch in a different form, then please advise. >>> >>> ---rony From kevin.rushforth at oracle.com Wed Nov 13 15:53:57 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Nov 2019 07:53:57 -0800 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> Message-ID: <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> Actually, in this case, sending an email to this list is the right way to start this discussion. I had meant to reply last week, but was out of town (at Devoxx), and busy with other things. Before we take a look at a patch that implements what you propose to change, we need a little more information about what problems are being caused by the current behavior. Do you have a test program that isn't working correctly? Since this proposed fix changes visible behavior, we also need to consider whether there are any compatibility or documentation implications. The next step would be to file a bug at bugreport.java.com [1]. The bug report should include a test case that demonstrates the problem. Also, if you haven't already done so, please read the CONTRIBUTING [2] guidelines. Before a pull request, we will need a bug report with a standalone reproducible test case, submitted at https://bugreport.java.com/ ?-- ideally a test case that could be turned into an automated test. -- Kevin On 11/13/2019 6:40 AM, Michael Paus wrote: > Hi, > have you considered directly contributing your proposed change via a > PR on > ? According to my experience this may > speed > up things considerably but don't forget to follow the procedures as > outlined in > . > --Michael > > Am 13.11.19 um 15:14 schrieb Rony G. Flatscher: >> Hmm, not getting any feedback so far, so wondering if there are >> currently any Java developers who >> take advantage of the ability of FXMLLoader to have FXML controllers >> implemented in any of the Java >> javax.script languages? >> >> For those, who use scripting languages for FXML controllers the >> request that FXMLLoader adds both >> entries, ScriptEngine.FILENAME (for debugging, logging) and >> ScriptEngine.ARGV () (for making the >> event object available directly as an argument) into the engine >> Bindings, should be quite helpful >> while developing and running the scripts. >> >> [Personally I am using the scripting engine ooRexx successfully for >> teaching oo programming from >> scratch to JavaFX in a single semester (four hour lecture, eight >> ECTS) at a Business Administration >> university. So these two missing features in the current FXMLLoader >> support for FXML controllers >> would help tremendously, especially in case of coding errors as >> currently it is not clear from which >> file the script that has an error comes from, making it extremely >> cumbersome and time consuming in >> JavaFX applications that use multiple and complex FXML files.] >> >> Therefore I would kindly ask interested committers for mentoring the >> proposed changes. Enclosed >> please find a simpler version of the patch that adds these missing >> features to the ENGINE_SCOPE >> Bindings in the three locations where ScriptEngine.eval() gets >> invoked (it ). >> >> To comment this simple patch, maybe I should add a few remarks such >> that the context becomes clear: >> >> ?? * invoking a script via ScriptEngine.eval() will always be >> accompanied with a ScriptContext that >> ???? usually maintains two Bindings (Maps): >> >> ?????? o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. >> for putting the FXML elements that >> ???????? have an fx:id attribute defined, such that scripts can get >> access to them, independent of a >> ???????? particular ScriptEngine) which can also be used for sharing >> values among different script >> ???????? invocations, >> >> ?????? o one, ENGINE_SCOPE Bindings, usually used for individual >> invocations. >> >> ?? * while a FXML file gets processed sequentially by the FXMLLoader >> elements in the form of >> ???? "" will cause invoking the >> ScriptEngine.eval(Reader): this >> ???? patch fetches the ENGINE_SCOPE Bindings and puts the value >> "someScript.ext" with the key >> ???? ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public >> class FXMLLoader" and "@@ >> ???? -1582,6 +1585,8 @@ public class FXMLLoader" in the patch), >> >> ?? * if an event handler gets defined (e.g. with the event attribute >> "> ???? onAction="someScript">") the FXMLLoader creates a >> ScriptEventHandler and stores "someScript" and >> ???? the ScriptEngine for executing that script whenever the event >> fires. >> >> ?????? o When an event fires, the current implementation creates a >> copy of the current ENGINE_SCOPE >> ???????? Bindings from the ScriptEngine's ScriptContext, adds its >> entries to it after saving the >> ???????? entry "event" with the ActionEvent object in it. It then >> changes the ScriptEngine's current >> ???????? ScriptContext such that it now uses the new copy of the >> Bindings as its ENGINE_SCOPE >> ???????? Bindings, runs the script using eval() and then restores the >> ScriptContext ENGINE_SCOPE >> ???????? Bindings. >> >> ?????? o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public >> class FXMLLoader") instead will >> ???????? create a copy of the ENGINE_SCOPE Bindings only once at >> creation time (and puts the >> ???????? appropriate ScriptEngine.FILENAME into it using the name of >> the FXML file that defines the >> ???????? event script attribute) and will reuse that Bindings each >> time the handler gets invoked, >> ???????? after putting the actual "event" object and the respective >> ScriptEngine.ARGV entry into it. >> ???????? Using ScriptEngine.eval(String,Bindings) will use the >> supplied Bindings as the ENGINE_SCOPE >> ???????? Bindings for this invocation only, such that no restore is >> necessary upon return. >> >> As only entries get added to the engine Bindings that have not been >> used by FXMLLoader this simple >> patch should not affect existing scripts. The patch has been tested >> and works. >> >> Maybe it helps the cause for applying this patch, if I point out that >> I have been active in a number >> of opensource projects, including Apache's BSF which led to my >> participation as an expert in JSR-223 >> which originally defined the javax.script framework introduced with >> Java 6 (also authored a complete >> ScriptEngine implementation with both, the javax.script.Compilable >> and the javax.script.Invocable >> interfaces). >> >> So looking for interested committers who would be willing to mentor >> this patch. Please advise. >> >> ---rony >> >> >> >> On 06.11.2019 16:05, Rony G. Flatscher wrote: >>> Using a script engine (javax.script.ScriptEngine) for implementing a >>> FXML controller there are two >>> important information missing in the ScriptContext.ENGINE_SCOPE >>> Bindings supplied to the script used >>> to eval() the script code: >>> >>> ?? * ScriptEngine.FILENAME >>> ?????? o This value denotes the file name from where the script code >>> was fetched that is being eval()'d. >>> ?????? o When debugging script controllers in a complex JavaFX >>> application it is mandatory to know >>> ???????? the file name the script code was taken from (as such >>> scripts could be called/run from >>> ???????? different FXML files). Also, in the case of script runtime >>> errors, usually the file name is >>> ???????? given by the script engine where the error has occurred to >>> ease debugging, such that it is >>> ???????? important to really supply the filename. >>> ?????????? + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE >>> refers the FXML file,? not to the >>> ???????????? file that hosts the script that gets run if using the >>> ">> ???????????? "source" attribute denotes the name of the script file. >>> ?????? o General solution: supply the appropriate >>> ScriptEngine.FILENAME entry to the >>> ???????? ScriptContext.ENGINE_SCOPE Bindings. >>> >>> ?? * ScriptEngine.ARGV >>> ?????? o This value denotes the arguments that get passed to the >>> script from Java in form of a Java >>> ???????? Array of type Object. >>> ?????? o When defining event handlers in FXML files in script code >>> the script does not get the >>> ???????? appropriate argument. Rather the script programmer needs to >>> access the >>> ???????? ScriptContext.ENGINE_SCOPE and fetch the entry named >>> "event" from there. Some script engines >>> ???????? may make the entries in the Bindings implicitly available >>> to the scripts, however this >>> ???????? cannot be expected by default. However, a ScriptEngine.ARGV >>> entry must be supplied to the >>> ???????? script by the script engine implementor, such that a script >>> coder gets the event object >>> ???????? argument in the script language's manner. >>> ?????? o General solution: supply the appropriate ScriptEngine.ARGV >>> Object array to the >>> ???????? ScriptContext.ENGINE_SCOPE Bindings. >>> >>> With these two changes not only writing controller scripts would be >>> eased, it also would >>> instrumentate ScriptContext.ENGINE_SCOPE Bindings the way it was >>> intended by JSR-223. >>> >>> Enclosed please find a tested diff for FXMLLoader.java from the >>> current OpenJavaFX Master (version >>> 14) that implements both, ScriptEngine.FILENAME entries for all >>> script invocations and in the case >>> of a script event handler the appropriate ScriptEngine.ARGV entry >>> gets supplied, allowing the script >>> to fetch the event object directly as an argument. >>> >>> As I have signed the OCA the code (in form of a git diff) can be >>> directly applied to FXMLLoader.java. >>> >>> If you need the patch in a different form, then please advise. >>> >>> ---rony >>> >>> > From Rony.Flatscher at wu.ac.at Wed Nov 13 17:42:37 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 13 Nov 2019 18:42:37 +0100 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> Message-ID: On 13.11.2019 16:53, Kevin Rushforth wrote: > Actually, in this case, sending an email to this list is the right way to start this discussion. I > had meant to reply last week, but was out of town (at Devoxx), and busy with other things. > > Before we take a look at a patch that implements what you propose to change, we need a little more > information about what problems are being caused by the current behavior. Do you have a test > program that isn't working correctly? Since this proposed fix changes visible behavior, we also > need to consider whether there are any compatibility or documentation implications. > > The next step would be to file a bug at bugreport.java.com [1]. The bug report should include a > test case that demonstrates the problem. Also, if you haven't already done so, please read the > CONTRIBUTING [2] guidelines. > > Before a pull request, we will need a bug report with a standalone reproducible test case, > submitted at https://bugreport.java.com/ > ?-- ideally a test case that could be turned into an automated test. Thank you very much, indeed! Will come up with a short reproducible testcase in ooRexx with brief comments such that the testcase could be understood without the runtime (ooRexx reads almost like pseudo-code). To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all opensource) for which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a script to set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be o.k.? ---rony From kevin.rushforth at oracle.com Wed Nov 13 18:50:50 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Nov 2019 10:50:50 -0800 Subject: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> Message-ID: <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: > Will come up with a short reproducible testcase in ooRexx with brief > comments such that the testcase > could be understood without the runtime (ooRexx reads almost like pseudo-code). > > To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all opensource) for > which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a script to > set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be o.k.? We prefer not to rely on third-party libraries for test cases. In any case we would not be able to use that for a regression test / unit test. How hard to you think it would be to use NashornScriptEngine for a test case? -- Kevin From github.com+4412658+dsgrieve at openjdk.org Wed Nov 13 19:10:45 2019 From: github.com+4412658+dsgrieve at openjdk.org (David Grieve) Date: Wed, 13 Nov 2019 19:10:45 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas wrote: > On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: > >> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >> >>> **Issue :** >>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>> >>> **Background :** >>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>> >>> **Description :** >>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>> For ease of review, I have made two separate commits - >>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>> >>> **Root Cause :** >>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>> >>> **Fix :** >>> Fixed the identified root cause. See commit 2. >>> >>> **Testing :** >>> 1. All passing unit tests continue to pass >>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>> 3. System test JDK8183100Test continues to pass >>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>> >>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>> >>> ---------------- >>> >>> Commits: >>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >> >> Reviewers: @kevinrushforth and @arapte > > It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. Has this been checked with SubScene? Two cases would be 1) SubScene inheriting a style from its parent, and 2) behavior of a parent in the SubScene itself. I don't expect that this would be an issue, but there is some special handling of CSS in SubScene IIRC. PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.org Wed Nov 13 19:22:05 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 19:22:05 GMT Subject: [Approved] RFR: 8231188: Update SQLite to version 3.30.1 In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 10:17:05 GMT, Arun Joseph wrote: > We currently use SQLite version 3.28.0. We should update to the latest stable release version 3.30.1 released. > https://www.sqlite.org/index.html > > ---------------- > > Commits: > - 24c6375d: 8231188: Update SQLite to version 3.30.1 > > Changes: https://git.openjdk.java.net/jfx/pull/31/files > Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231188 > Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod > Patch: https://git.openjdk.java.net/jfx/pull/31.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31 Looks good. Tested on all three platforms. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/31 From kcr at openjdk.org Wed Nov 13 19:23:03 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 19:23:03 GMT Subject: RFR: 8231188: Update SQLite to version 3.30.1 In-Reply-To: References: Message-ID: <9vvDhVMm27ZzNSPjAhA9dkTF2psPDGEDmM7fE-SOKuA=.c6648227-a851-43f4-8e6e-9cbb4252e2ab@github.com> On Wed, 6 Nov 2019 10:17:05 GMT, Arun Joseph wrote: > We currently use SQLite version 3.28.0. We should update to the latest stable release version 3.30.1 released. > https://www.sqlite.org/index.html > > ---------------- > > Commits: > - 24c6375d: 8231188: Update SQLite to version 3.30.1 > > Changes: https://git.openjdk.java.net/jfx/pull/31/files > Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231188 > Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod > Patch: https://git.openjdk.java.net/jfx/pull/31.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31 This will need a second reviewer. @johanvos @tiainen - could one of you be the second reviewer? PR: https://git.openjdk.java.net/jfx/pull/31 From kcr at openjdk.org Wed Nov 13 19:57:04 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 19:57:04 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <7b3FypbOegTPgE32Ab6wK_-o-RhqLEQjfUrbgDyDzQQ=.ace45171-6730-4997-9f38-567e8e114eea@github.com> Message-ID: On Tue, 29 Oct 2019 11:31:18 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 10:10:32 GMT, Dell Green wrote: > >> On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: >> >>> On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>> >>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>> >>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>> >>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>> >>>> This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. >>>> >>>> ---------------- >>>> >>>> Disapproved by kcr (Lead). >>> >>> Is this PR open for review now? Or will a new PR be created? >> >> this is ready for review form my perspective. :) > > The Skara tooling bug in question has been fixed, so yes this is ready for review. I have no particular issue one way or the other on this. I will defer the review to @johanvos PR: https://git.openjdk.java.net/jfx/pull/5 From kcr at openjdk.org Wed Nov 13 20:00:14 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 20:00:14 GMT Subject: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() In-Reply-To: References: <0YJvd4XIwHfRAuOVa3jtcjFVOhDVvaq94-fi6HKRKqY=.42af4fb5-cc1b-42eb-9fad-b9409971a9ca@github.com> Message-ID: On Mon, 21 Oct 2019 22:52:47 GMT, Kevin Rushforth wrote: > On Thu, 17 Oct 2019 15:28:31 GMT, Kevin Rushforth wrote: > >> On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka wrote: >> >>> On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka wrote: >>> >>>> Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call. >>>> This patch fixes the problem by submitting the UI work (including the call to the SecondaryLoop.exit() method) before entering the secondary loop. >>>> >>>> [1] https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4 >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 9483ccde: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/16/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 >>>> Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/16.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16 >>> >>> @kevinrushforth I believe you should be able to move forward with the review of this PR now as I've filed a bug report for the problem and signed the OCA as required. (As I did not know I needed to have my github account associated with the OCA, I did not include it in my details. I've asked Dalibor Topic from the Java SE PM team to help me have that fixed or get in touch with you to confirm my signing of the OCA.) >> >> @mruzicka once Dalibor connects your OCA with your GitHub account, this review will be able to proceed. > > Do you have a test program that shows the bug? > > Also, can you take a look at whether you could turn the test case into an automated test? @mruzicka - are you interested in moving this forward? If so, there is a pending request for a test case that needs to be answered before the review can proceed. PR: https://git.openjdk.java.net/jfx/pull/16 From github.com+12861109+dellgreen at openjdk.org Wed Nov 13 20:50:44 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Wed, 13 Nov 2019 20:50:44 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <7b3FypbOegTPgE32Ab6wK_-o-RhqLEQjfUrbgDyDzQQ=.ace45171-6730-4997-9f38-567e8e114eea@github.com> Message-ID: On Wed, 13 Nov 2019 19:57:04 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 11:31:18 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 10:10:32 GMT, Dell Green wrote: >> >>> On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: >>> >>>> On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>> >>>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>>> >>>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>>> >>>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>>> >>>>> This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. >>>>> >>>>> ---------------- >>>>> >>>>> Disapproved by kcr (Lead). >>>> >>>> Is this PR open for review now? Or will a new PR be created? >>> >>> this is ready for review form my perspective. :) >> >> The Skara tooling bug in question has been fixed, so yes this is ready for review. > > I have no particular issue one way or the other on this. I will defer the review to @johanvos As a follow up, if its desirable for javafx to be used in IOT/embedded devices, we should fix this issue, otherwise it doesn't look as slick on startup when i put it next to competing devices. :) PR: https://git.openjdk.java.net/jfx/pull/5 From mp at jugs.org Wed Nov 13 21:06:05 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 13 Nov 2019 22:06:05 +0100 Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <7b3FypbOegTPgE32Ab6wK_-o-RhqLEQjfUrbgDyDzQQ=.ace45171-6730-4997-9f38-567e8e114eea@github.com> Message-ID: +1 Am 13.11.19 um 21:50 schrieb Dell Green: > On Wed, 13 Nov 2019 19:57:04 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 11:31:18 GMT, Kevin Rushforth wrote: >> >>> On Tue, 29 Oct 2019 10:10:32 GMT, Dell Green wrote: >>> >>>> On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: >>>> >>>>> On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>> >>>>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>>>> >>>>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>>>> >>>>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>>>> This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Disapproved by kcr (Lead). >>>>> Is this PR open for review now? Or will a new PR be created? >>>> this is ready for review form my perspective. :) >>> The Skara tooling bug in question has been fixed, so yes this is ready for review. >> I have no particular issue one way or the other on this. I will defer the review to @johanvos > As a follow up, if its desirable for javafx to be used in IOT/embedded devices, we should fix this issue, otherwise it doesn't look as slick on startup when i put it next to competing devices. :) > > PR: https://git.openjdk.java.net/jfx/pull/5 From github.com+1413266+jgneff at openjdk.org Wed Nov 13 21:34:06 2019 From: github.com+1413266+jgneff at openjdk.org (John Neffenger) Date: Wed, 13 Nov 2019 21:34:06 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. > > NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. > > A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. > > ---------------- > > Commits: > - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor > > Changes: https://git.openjdk.java.net/jfx/pull/5/files > Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/5.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: > 49: AccessController.doPrivileged((PrivilegedAction) () -> { > 50: final String str = > 51: System.getProperty("monocle.debugcursor", ""); Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. monocle.cursor.enabled monocle.debugcursor monocle.epd.bitsPerPixel monocle.epd.enableInversion monocle.epd.forceMonochrome monocle.epd.noWait monocle.epd.rotate monocle.epd.useDitheringY1 monocle.epd.useDitheringY4 monocle.epd.waveformMode monocle.epd.y8inverted monocle.input..flipXY monocle.input..maxX monocle.input..maxY monocle.input..minX monocle.input..minY monocle.input..touchFilters monocle.input.touchFilters monocle.input.touchRadius monocle.input.traceEvents monocle.input.traceEvents.verbose monocle.maliSignedStruct monocle.platform monocle.platform.traceConfig monocle.screen.fb monocle.stackSize I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. PR: https://git.openjdk.java.net/jfx/pull/5 From kcr at openjdk.org Wed Nov 13 21:53:13 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 21:53:13 GMT Subject: [Rev 02] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 12 Nov 2019 10:23:16 GMT, Florian Kirmaier wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 5cd96a56: JDK-8200224 > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/25/files > - new: https://git.openjdk.java.net/jfx/pull/25/files/85c87628..5cd96a56 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/25/webrev.02 > - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.01-02 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 I see that when you made your earlier comment regarding `System.exit`, you really meant that the existing swing test was calling `Platform.exit`, which isn't the same thing; it does shut down the JavaFX runtime, which is intended. The problem you are running into is that gradle runs multiple tests in the same VM and in an undefined, and unpredicable, order. This means that tests need to take care not to alter or rely on global state such as threads, static fields, global JavaFX state, and the running (or lack thereof) of the JavaFX runtime. The swing tests violate this rule and are therefore inherently unstable. The only reason this hasn't been a problem up to now is that the javafx.swing module contains a single test class. I will file a new test bug to address it -- probably by moving that test to the `systemTests` project. You will need to move your test into the `systemTests` project under the `tests/system/` directory. Such tests are valid in the system tests project because we run each test in that project in its own VM. Once your proposed test is robust (meaning consistently catches the bug without your fix and consistently passes with your fix) on all platforms without using Robot, then `tests/system/src/test/java/test/javafx/embed/swing/` would be the best place to put your new test. Regarding the test itself, it still doesn't fail for me on Windows without your fix. I ran the test program attached to the bug and I see something that might help explain this. That test program creates a pair of JFXPanel objects and adds both to the JPanel. If I first click on the first one, then it only shows a single click. Every time after that, if I click on a new JFXPanel, then I get 2 clicks. If, instead, I click on the second JFXPanel right after starting the program, I get 2 clicks the first time. With that in mind, I modified your test to add a dummy JFXPanel to the JPanel before the one you are sending the mouse pressed event to, and then it then does what I expect: it catches the bug without your fix and passes with your fix. That might help you come up with a more robust test. I added some specific comments on the test as well. modules/javafx.swing/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java line 46: > 45: > 46: > 47: public class SwingFXUtilsTest { Your proposed fix for this test class is not the right fix, and needs to be reverted. It highlights an existing bug with the swing tests, which I will address in general comments. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 100: > 99: jpanel.add(fxPnl); > 100: jframe.setContentPane(jpanel); > 101: jframe.setVisible(true); You should call `jframe.pack()` here. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 128: > 127: > 128: Thread.sleep(100); // there should be no pressed event after the initial one. Let's wait for 0.1s and check again. > 129: assertEquals(1, pressedEventCounter[0]); I recommend using 500 msec so we don't risk missing a failing click on slower systems. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 60: > 59: public static void doSetupOnce() { > 60: if (setupIsDone) return; > 61: Platform.startup(() -> { This is not needed if you revert the changes to the other test class. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 130: > 129: assertEquals(1, pressedEventCounter[0]); > 130: } > 131: } You will want to add a cleanup method, annotated with `@AfterClass` to call `Platform.exit` and dispose of the JFrame. modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 106: > 105: Scene scene = new Scene(new Group()); > 106: scene.getRoot().requestFocus(); > 107: I don't think requesting focus is necessary (or desired). ---------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/25 From github.com+12861109+dellgreen at openjdk.org Wed Nov 13 22:04:36 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Wed, 13 Nov 2019 22:04:36 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> Message-ID: On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: > On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > >> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >> >> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >> >> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >> >> ---------------- >> >> Commits: >> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >> >> Changes: https://git.openjdk.java.net/jfx/pull/5/files >> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: > >> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >> 50: final String str = >> 51: System.getProperty("monocle.debugcursor", ""); > > Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. > > monocle.cursor.enabled > monocle.debugcursor > monocle.epd.bitsPerPixel > monocle.epd.enableInversion > monocle.epd.forceMonochrome > monocle.epd.noWait > monocle.epd.rotate > monocle.epd.useDitheringY1 > monocle.epd.useDitheringY4 > monocle.epd.waveformMode > monocle.epd.y8inverted > monocle.input..flipXY > monocle.input..maxX > monocle.input..maxY > monocle.input..minX > monocle.input..minY > monocle.input..touchFilters > monocle.input.touchFilters > monocle.input.touchRadius > monocle.input.traceEvents > monocle.input.traceEvents.verbose > monocle.maliSignedStruct > monocle.platform > monocle.platform.traceConfig > monocle.screen.fb > monocle.stackSize > > I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) PR: https://git.openjdk.java.net/jfx/pull/5 From kcr at openjdk.org Wed Nov 13 22:11:14 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 22:11:14 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: <5XRJyBGYagcqRuOygjHubkkI_twGh8i3N2UUwnT7p9k=.197bf17a-13ef-4b61-a337-e310e39f1044@github.com> References: <5XRJyBGYagcqRuOygjHubkkI_twGh8i3N2UUwnT7p9k=.197bf17a-13ef-4b61-a337-e310e39f1044@github.com> Message-ID: <_c3s21NA3wisUO6yXmpSQEt9QRfpRRHx2LoFgbS8ARM=.5da17758-6f78-41b5-813b-2c6586d277bb@github.com> On Wed, 13 Nov 2019 01:17:44 GMT, Kevin Rushforth wrote: > On Tue, 12 Nov 2019 10:35:36 GMT, Florian Kirmaier wrote: > >> On Wed, 6 Nov 2019 08:30:47 GMT, Kevin Rushforth wrote: >> >>> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >>> >>>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>>> >>>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>>> >>>> The pull request introduces a new fix for the problem. >>>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>>> We do so, by using setFocused. >>>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>>> because calling setFocused just sets the value of a boolean property. >>>> >>>> I've now also added a unit-test for the problem. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 314e423c: JDK-8200224 >>>> - 725e5fef: JDK-8200224 >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >>> >>> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: >>> >>>> 456: >>>> 457: sendMouseEventToFX(e); >>>> 458: super.processMouseEvent(e); >>> >>> typo: save --> safe >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: >>> >>>> 1: /* >>>> 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. >>>> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> >>> replace `2014, 2016` with `2019,` >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: >>> >>>> 27: >>>> 28: import javafx.application.Application; >>>> 29: import javafx.application.Platform; >>> >>> Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: >>> >>>> 47: >>>> 48: import static junit.framework.Assert.assertEquals; >>>> 49: import static org.junit.Assert.assertNotNull; >>> >>> This method should be imported from `org.junit` package. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: >>> >>>> 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, >>>> 116: 5, 5, 1, false, MouseEvent.BUTTON1); >>>> 117: >>> >>> This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: >>> >>>> 56: >>>> 57: >>>> 58: @BeforeClass >>> >>> You can remove the extra blank line. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: >>> >>>> 64: >>>> 65: >>>> 66: try { >>> >>> You can remove the extra blank line. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: >>> >>>> 78: >>>> 79: class TestFXPanel extends JFXPanel { >>>> 80: protected void processMouseEventPublic(MouseEvent e) { >>> >>> I think this can be a static class. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: >>> >>>> 87: >>>> 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); >>>> 89: >>> >>> This can be final. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: >>> >>>> 90: // It's an array, so we can mutate it inside of lambda statement >>>> 91: int[] pressedEventCounter = {0}; >>>> 92: >>> >>> This can be final. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: >>> >>>> 131: >>>> 132: >>>> 133: } >>> >>> You can remove the extra blank line. >>> >>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: >>> >>>> 122: >>>> 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >>>> 124: throw new Exception(); >>> >>> Add a space after the `if`. >>> >>> The fix seems fine. Have you tested it on all three platforms? >>> >>> I have several comments on the test. >>> >>> ---------------- >>> >>> Disapproved by kcr (Lead). >> >> Maybe try `./gradlew -PFULL_TEST=true swing:clean swing:test`. >> I'm sure, it can be reproduced on windows. >> If you still can not reproduce it, then I will add a test for the Robot. > > I'll try it again with the updated test. > >> You can run the AWT_TESTS with the following statement: >> >> ``` >> ./gradlew -PFULL_TEST=true swing:clean swing:test >> ``` > > Yes, I know that it needs `-PFULL_TEST=true`, but the earlier test wasn't failing for me. And yes, it is intentional; for reasons I can't recall, the swing tests don't work in headless mode. Anyway, I don't want to revisit this right now. > >> The tests are now stable. The previous version had some problems because the other test for Swing was calling System.exit. > > Tests should not call `System.exit`. If they do, then that's almost certainly a bug. FYI, I filed [JDK-8234110](https://bugs.openjdk.java.net/browse/JDK-8234110) to move the existing `:swing` test to `:systemTests`. PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.org Wed Nov 13 22:54:01 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 22:54:01 GMT Subject: RFR: 8234110: SwingFXUtilsTest is unsuitable for unit test framework Message-ID: This fixes [JDK-8234110](https://bugs.openjdk.java.net/browse/JDK-8234110) by moving `SwingFXUtilsTest` from the `:swing` project to the `:systemTests` project. As explained in the JBS issue, `SwingFXUtilsTest` must be run in its own VM, since it starts and stops the FX runtime, so must be in the system tests project. I note that I could have instead modified `build.gradle` to specify `forkEvery = 1` in the `test` task of the `:swing` project, but since other similar tests are already in `systemTests` this seems cleaner. There are no actual changes needed to any of the moved files, since the package name remains the same. ---------------- Commits: - 141a388a: 8234110: SwingFXUtilsTest is unsuitable for unit test framework Changes: https://git.openjdk.java.net/jfx/pull/35/files Webrev: https://webrevs.openjdk.java.net/jfx/35/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234110 Stats: 0 lines in 6 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/35.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/35/head:pull/35 PR: https://git.openjdk.java.net/jfx/pull/35 From kcr at openjdk.org Wed Nov 13 22:54:03 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 22:54:03 GMT Subject: RFR: 8234110: SwingFXUtilsTest is unsuitable for unit test framework In-Reply-To: References: Message-ID: On Wed, 13 Nov 2019 22:54:01 GMT, Kevin Rushforth wrote: > This fixes [JDK-8234110](https://bugs.openjdk.java.net/browse/JDK-8234110) by moving `SwingFXUtilsTest` from the `:swing` project to the `:systemTests` project. As explained in the JBS issue, `SwingFXUtilsTest` must be run in its own VM, since it starts and stops the FX runtime, so must be in the system tests project. > > I note that I could have instead modified `build.gradle` to specify `forkEvery = 1` in the `test` task of the `:swing` project, but since other similar tests are already in `systemTests` this seems cleaner. > > There are no actual changes needed to any of the moved files, since the package name remains the same. > > ---------------- > > Commits: > - 141a388a: 8234110: SwingFXUtilsTest is unsuitable for unit test framework > > Changes: https://git.openjdk.java.net/jfx/pull/35/files > Webrev: https://webrevs.openjdk.java.net/jfx/35/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234110 > Stats: 0 lines in 6 files changed: 0 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/35.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/35/head:pull/35 Reviewer: @aghaisas PR: https://git.openjdk.java.net/jfx/pull/35 From kcr at openjdk.org Wed Nov 13 23:47:45 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 23:47:45 GMT Subject: [Approved] RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 14:28:20 GMT, Nir Lisker wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - a1cdb37b: Removed whitespaces in @Deprecated comments > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/30/files > - new: https://git.openjdk.java.net/jfx/pull/30/files/6d29e034..a1cdb37b > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/30/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/30/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 Looks good. This will need a second reviewer and an approved CSR before integration. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 13 23:47:58 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Nov 2019 23:47:58 GMT Subject: RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> Message-ID: <_1kwgRzlZ9hO4BHRV29HK0K87bPrS3_4e8xsvinr1MU=.71c948c8-a3e3-464c-bb90-a8a6f5fe40ce@github.com> On Wed, 6 Nov 2019 12:54:40 GMT, Kevin Rushforth wrote: > On Wed, 6 Nov 2019 11:50:27 GMT, Nir Lisker wrote: > >> On Wed, 6 Nov 2019 07:12:26 GMT, Robin Westberg wrote: >> >>> On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: >>> >>>> On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>> >>>>>> CSR will be created after the changes are approved. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - 6d29e034: Initial push of 8229472 >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >>>>> >>>>> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >>>>> >>>>>> 67: @Deprecated(since = "14", forRemoval = true) >>>>>> 68: public JavaBeanBooleanPropertyBuilder() {} >>>>>> 69: >>>>> >>>>> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. >>>> >>>> I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? >>> >>> Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) >> >> For both `since` and `forRemoval`? > > Yes. The pattern used consistently (in all cases that I could find) would be: > > @Deprecated(since="14", forRemoval=true) @arapte can you also review this? PR: https://git.openjdk.java.net/jfx/pull/30 From jvos at openjdk.org Thu Nov 14 08:18:17 2019 From: jvos at openjdk.org (Johan Vos) Date: Thu, 14 Nov 2019 08:18:17 GMT Subject: RFR: 8231188: Update SQLite to version 3.30.1 In-Reply-To: <9vvDhVMm27ZzNSPjAhA9dkTF2psPDGEDmM7fE-SOKuA=.c6648227-a851-43f4-8e6e-9cbb4252e2ab@github.com> References: <9vvDhVMm27ZzNSPjAhA9dkTF2psPDGEDmM7fE-SOKuA=.c6648227-a851-43f4-8e6e-9cbb4252e2ab@github.com> Message-ID: On Wed, 13 Nov 2019 19:23:03 GMT, Kevin Rushforth wrote: > On Wed, 6 Nov 2019 10:17:05 GMT, Arun Joseph wrote: > >> We currently use SQLite version 3.28.0. We should update to the latest stable release version 3.30.1 released. >> https://www.sqlite.org/index.html >> >> ---------------- >> >> Commits: >> - 24c6375d: 8231188: Update SQLite to version 3.30.1 >> >> Changes: https://git.openjdk.java.net/jfx/pull/31/files >> Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231188 >> Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod >> Patch: https://git.openjdk.java.net/jfx/pull/31.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31 > > This will need a second reviewer. > > @johanvos @tiainen - could one of you be the second reviewer? Code changes look ok. Will test on 3 platforms later today. PR: https://git.openjdk.java.net/jfx/pull/31 From aghaisas at openjdk.org Thu Nov 14 09:33:39 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 14 Nov 2019 09:33:39 GMT Subject: RFR: 8234150: Address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest Message-ID: This PR is to address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest. strategy is as follows - 1) Enable tests marked with @Ignore by removing that tag 2) Run the test 3) If test Passes - remove the @Ignore tag 4) If test fails - if test is invalid - remove it, else fix the test 5) In case if the failure cannot be fixed, leave the test ignored (keep @Ignore tag) With these corrections - here are the results: Results BEFORE this FIX 1. ComboBoxTest -- tests:156, failures:0, ignored:4 2. LabeledTest -- tests:93, failures:0, ignored:5 3. HyperlinkTest -- tests:34, failures:0, ignored:3 4. TextInputControlTest -- tests:594, failures:0, ignored:12 Results AFTER this FIX 1. ComboBoxTest -- tests:156, failures:0, ignored:2 2. LabeledTest -- tests:93, failures:0, ignored:3 3. HyperlinkTest -- tests:31, failures:0, ignored:0 4. TextInputControlTest -- tests:585, failures:0, ignored:0 ---------------- Commits: - 6709837b: Fix-Remove-Keep @Ignore tests Changes: https://git.openjdk.java.net/jfx/pull/36/files Webrev: https://webrevs.openjdk.java.net/jfx/36/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234150 Stats: 63 lines in 4 files changed: 0 ins; 57 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/36/head:pull/36 PR: https://git.openjdk.java.net/jfx/pull/36 From jvos at openjdk.org Thu Nov 14 10:00:24 2019 From: jvos at openjdk.org (Johan Vos) Date: Thu, 14 Nov 2019 10:00:24 GMT Subject: [Approved] RFR: 8231188: Update SQLite to version 3.30.1 In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 10:17:05 GMT, Arun Joseph wrote: > We currently use SQLite version 3.28.0. We should update to the latest stable release version 3.30.1 released. > https://www.sqlite.org/index.html > > ---------------- > > Commits: > - 24c6375d: 8231188: Update SQLite to version 3.30.1 > > Changes: https://git.openjdk.java.net/jfx/pull/31/files > Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231188 > Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod > Patch: https://git.openjdk.java.net/jfx/pull/31.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31 Sanity checks work on Linux/Mac/Windows ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/31 From aghaisas at openjdk.org Thu Nov 14 10:49:36 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 14 Nov 2019 10:49:36 GMT Subject: [Approved] RFR: 8234110: SwingFXUtilsTest is unsuitable for unit test framework In-Reply-To: References: Message-ID: On Wed, 13 Nov 2019 22:54:01 GMT, Kevin Rushforth wrote: > This fixes [JDK-8234110](https://bugs.openjdk.java.net/browse/JDK-8234110) by moving `SwingFXUtilsTest` from the `:swing` project to the `:systemTests` project. As explained in the JBS issue, `SwingFXUtilsTest` must be run in its own VM, since it starts and stops the FX runtime, so must be in the system tests project. > > I note that I could have instead modified `build.gradle` to specify `forkEvery = 1` in the `test` task of the `:swing` project, but since other similar tests are already in `systemTests` this seems cleaner. > > There are no actual changes needed to any of the moved files, since the package name remains the same. > > ---------------- > > Commits: > - 141a388a: 8234110: SwingFXUtilsTest is unsuitable for unit test framework > > Changes: https://git.openjdk.java.net/jfx/pull/35/files > Webrev: https://webrevs.openjdk.java.net/jfx/35/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234110 > Stats: 0 lines in 6 files changed: 0 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/35.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/35/head:pull/35 Approved by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/35 From dwookey at openjdk.org Thu Nov 14 11:33:24 2019 From: dwookey at openjdk.org (Dean Wookey) Date: Thu, 14 Nov 2019 11:33:24 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> References: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> Message-ID: On Wed, 13 Nov 2019 19:10:45 GMT, David Grieve wrote: > On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas wrote: > >> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: >> >>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>> >>>> **Issue :** >>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>> >>>> **Background :** >>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>> >>>> **Description :** >>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>> For ease of review, I have made two separate commits - >>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>> >>>> **Root Cause :** >>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>> >>>> **Fix :** >>>> Fixed the identified root cause. See commit 2. >>>> >>>> **Testing :** >>>> 1. All passing unit tests continue to pass >>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>> 3. System test JDK8183100Test continues to pass >>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>> >>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>> >>> Reviewers: @kevinrushforth and @arapte >> >> It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. > > Has this been checked with SubScene? Two cases would be 1) SubScene inheriting a style from its parent, and 2) behavior of a parent in the SubScene itself. I don't expect that this would be an issue, but there is some special handling of CSS in SubScene IIRC. Having looked at this issue previously (https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022842.html and https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6), I'm a bit confused. Doesn't commit https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f essentially add another reapplyCSS() above the scenesChanged call on line 1074? I'm guessing this works because reapplyCss() (different from reapplyCSS()) sets cssFlag to UPDATE, which then means subsequent calls to reapplyCSS() don't call reapplyCss()? Does this leave the whole tree with the CssFlags.REAPPLY set instead of CssFlags.UPDATE as they would be without these changes? I'm not sure about the impact of that. I'm also curious whether commit 1 is even necessary with commit 2. PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.org Thu Nov 14 11:52:35 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 11:52:35 GMT Subject: RFR: 8231188: Update SQLite to version 3.30.1 In-Reply-To: References: <9vvDhVMm27ZzNSPjAhA9dkTF2psPDGEDmM7fE-SOKuA=.c6648227-a851-43f4-8e6e-9cbb4252e2ab@github.com> Message-ID: On Thu, 14 Nov 2019 08:18:17 GMT, Johan Vos wrote: > On Wed, 13 Nov 2019 19:23:03 GMT, Kevin Rushforth wrote: > >> On Wed, 6 Nov 2019 10:17:05 GMT, Arun Joseph wrote: >> >>> We currently use SQLite version 3.28.0. We should update to the latest stable release version 3.30.1 released. >>> https://www.sqlite.org/index.html >>> >>> ---------------- >>> >>> Commits: >>> - 24c6375d: 8231188: Update SQLite to version 3.30.1 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/31/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231188 >>> Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/31.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31 >> >> This will need a second reviewer. >> >> @johanvos @tiainen - could one of you be the second reviewer? > > Code changes look ok. Will test on 3 platforms later today. /sponsor PR: https://git.openjdk.java.net/jfx/pull/31 From kcr at openjdk.org Thu Nov 14 11:58:30 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 11:58:30 GMT Subject: [Integrated] RFR: 8231188: Update SQLite to version 3.30.1 In-Reply-To: References: Message-ID: <1c4db694-eba7-4781-81e6-a87328ec59e7@openjdk.org> Changeset: 5b96ee42 Author: Arun Joseph Committer: Kevin Rushforth Date: 2019-11-14 11:57:24 +0000 URL: https://git.openjdk.java.net/jfx/commit/5b96ee42 8231188: Update SQLite to version 3.30.1 Reviewed-by: kcr, jvos ! modules/javafx.web/src/main/native/Source/ThirdParty/sqlite/VERSION ! modules/javafx.web/src/main/native/Source/ThirdParty/sqlite/sqlite3.c ! modules/javafx.web/src/main/native/Source/ThirdParty/sqlite/sqlite3.h ! modules/javafx.web/src/main/native/Source/ThirdParty/sqlite/sqlite3ext.h From kcr at openjdk.org Thu Nov 14 11:59:29 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 11:59:29 GMT Subject: [Integrated] RFR: 8234110: SwingFXUtilsTest is unsuitable for unit test framework In-Reply-To: References: Message-ID: <5423e4b5-4f7a-426b-b551-e3be1cd9c1e8@openjdk.org> Changeset: dc013094 Author: Kevin Rushforth Date: 2019-11-14 11:59:08 +0000 URL: https://git.openjdk.java.net/jfx/commit/dc013094 8234110: SwingFXUtilsTest is unsuitable for unit test framework Reviewed-by: aghaisas = tests/system/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java = tests/system/src/test/resources/test/javafx/embed/swing/alpha.png = tests/system/src/test/resources/test/javafx/embed/swing/opaque.gif = tests/system/src/test/resources/test/javafx/embed/swing/opaque.jpg = tests/system/src/test/resources/test/javafx/embed/swing/opaque.png = tests/system/src/test/resources/test/javafx/embed/swing/trans.gif From kcr at openjdk.org Thu Nov 14 12:34:56 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 12:34:56 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> Message-ID: <6EhektI1uVt5wjrCdFjPLfT2k8bdERlpUq8dCWu12uc=.2acad032-2a42-4f35-ad6d-282c908440c4@github.com> On Thu, 14 Nov 2019 11:33:24 GMT, Dean Wookey wrote: > On Wed, 13 Nov 2019 19:10:45 GMT, David Grieve wrote: > >> On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas wrote: >> >>> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: >>> >>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>> >>>>> **Issue :** >>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>> >>>>> **Background :** >>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>> >>>>> **Description :** >>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>> For ease of review, I have made two separate commits - >>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>> >>>>> **Root Cause :** >>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>> >>>>> **Fix :** >>>>> Fixed the identified root cause. See commit 2. >>>>> >>>>> **Testing :** >>>>> 1. All passing unit tests continue to pass >>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>> 3. System test JDK8183100Test continues to pass >>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>> >>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>> >>>> Reviewers: @kevinrushforth and @arapte >>> >>> It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. >> >> Has this been checked with SubScene? Two cases would be 1) SubScene inheriting a style from its parent, and 2) behavior of a parent in the SubScene itself. I don't expect that this would be an issue, but there is some special handling of CSS in SubScene IIRC. > > Having looked at this issue previously (https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022842.html and https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6), I'm a bit confused. > > Doesn't commit https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f essentially add another reapplyCSS() above the scenesChanged call on line 1074? I'm guessing this works because reapplyCss() (different from reapplyCSS()) sets cssFlag to UPDATE, which then means subsequent calls to reapplyCSS() don't call reapplyCss()? > > Does this leave the whole tree with the CssFlags.REAPPLY set instead of CssFlags.UPDATE as they would be without these changes? I'm not sure about the impact of that. > > I'm also curious whether commit 1 is even necessary with commit 2. The above raises good questions about the effect of adding a call to `reapplyCSS` when `scenesChanged` is called. This will need a careful analysis. Regarding whether commit 2 by itself would be sufficient, my initial guess was that it wouldn't be. However, I tested it, and it does in fact improve performance of the test case. Very interesting. PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.org Thu Nov 14 14:27:24 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 14:27:24 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: <6EhektI1uVt5wjrCdFjPLfT2k8bdERlpUq8dCWu12uc=.2acad032-2a42-4f35-ad6d-282c908440c4@github.com> References: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> <6EhektI1uVt5wjrCdFjPLfT2k8bdERlpUq8dCWu12uc=.2acad032-2a42-4f35-ad6d-282c908440c4@github.com> Message-ID: On Thu, 14 Nov 2019 12:34:56 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 11:33:24 GMT, Dean Wookey wrote: > >> On Wed, 13 Nov 2019 19:10:45 GMT, David Grieve wrote: >> >>> On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas wrote: >>> >>>> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: >>>> >>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>> >>>>>> **Issue :** >>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>> >>>>>> **Background :** >>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>> >>>>>> **Description :** >>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>> For ease of review, I have made two separate commits - >>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>> >>>>>> **Root Cause :** >>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>> >>>>>> **Fix :** >>>>>> Fixed the identified root cause. See commit 2. >>>>>> >>>>>> **Testing :** >>>>>> 1. All passing unit tests continue to pass >>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>> 3. System test JDK8183100Test continues to pass >>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>> >>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>> >>>>> Reviewers: @kevinrushforth and @arapte >>>> >>>> It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. >>> >>> Has this been checked with SubScene? Two cases would be 1) SubScene inheriting a style from its parent, and 2) behavior of a parent in the SubScene itself. I don't expect that this would be an issue, but there is some special handling of CSS in SubScene IIRC. >> >> Having looked at this issue previously (https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022842.html and https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6), I'm a bit confused. >> >> Doesn't commit https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f essentially add another reapplyCSS() above the scenesChanged call on line 1074? I'm guessing this works because reapplyCss() (different from reapplyCSS()) sets cssFlag to UPDATE, which then means subsequent calls to reapplyCSS() don't call reapplyCss()? >> >> Does this leave the whole tree with the CssFlags.REAPPLY set instead of CssFlags.UPDATE as they would be without these changes? I'm not sure about the impact of that. >> >> I'm also curious whether commit 1 is even necessary with commit 2. > > The above raises good questions about the effect of adding a call to `reapplyCSS` when `scenesChanged` is called. This will need a careful analysis. > > Regarding whether commit 2 by itself would be sufficient, my initial guess was that it wouldn't be. However, I tested it, and it does in fact improve performance of the test case. Very interesting. Looking at this a little further, the change from commit 2, to call `reapplyCSS` at the beginning of `scenesChanged` really does two things: 1. Calling `reapplyCSS` right at the beginning of `scenesChanged` flips the order of CSS reapplication from the existing "bottom up" order to a "top down" order. Note that `scenesChanged` calls `invalidatedScenes` recursively (via `setScenes`) to traverse the scene graph. 2. It effectively undoes the rest of the changes, which were intended to avoid calling `reapplyCSS` in cases where it is redundant. As long as the performance improvement is preserved, this seems fine. The first of the above appears to be both necessary and sufficient to both maintain correctness while still avoiding the n^2 application of CSS in the case of adding a deep scene graph. If this is in fact the case, then I think the fix can be simplified even further by moving the following call from its current location (after `updateTreeShowing`) to right before the call to `scenesChanged`: if (sceneChanged) reapplyCSS(); in which case the changes to `Node::scenesChanged` and `Parent::scenesChanged` can be reverted The following patch, by itself (with nothing from commit 1) might be sufficient: --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java @@ -1069,6 +1069,7 @@ public abstract class Node implements EventTarget, Styleable { focusSetDirty(oldScene); focusSetDirty(newScene); } + if (sceneChanged) reapplyCSS(); // Note this can be moved inside the previous 'if' block scenesChanged(newScene, newSubScene, oldScene, oldSubScene); // isTreeShowing needs to take into account of Window's showing @@ -1091,8 +1092,6 @@ public abstract class Node implements EventTarget, Styleable { } updateTreeShowing(); - if (sceneChanged) reapplyCSS(); - if (sceneChanged && !isDirtyEmpty()) { //Note: no need to remove from scene's dirty list //Scene's is checking if the node's scene is correct We will need to do a more complete evaluation as to whether this inversion of calling reapplyCSS on the parent before its children has any side effects, and also whether there are any of the performance improvements from the original fix that aren't covered here. PR: https://git.openjdk.java.net/jfx/pull/34 From alexsch at openjdk.org Thu Nov 14 14:35:26 2019 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 14 Nov 2019 14:35:26 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git Message-ID: Allow IDEA to correctly detect Git version control system when opening JFX project. ---------------- Commits: - f0f1866a: 8234174: Change IDEA VCS mapping to Git Changes: https://git.openjdk.java.net/jfx/pull/37/files Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 PR: https://git.openjdk.java.net/jfx/pull/37 From kcr at openjdk.org Thu Nov 14 14:35:27 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 14:35:27 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: > Allow IDEA to correctly detect Git version control system when opening JFX project. > > ---------------- > > Commits: > - f0f1866a: 8234174: Change IDEA VCS mapping to Git > > Changes: https://git.openjdk.java.net/jfx/pull/37/files > Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 @AlexanderScherbatiy this is the part that applies to you: > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user AlexanderScherbatiy" as summary for the issue. Also, please read the [contributing guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md). As with the JDK project, we need a JBS bug ID for every pull request. PR: https://git.openjdk.java.net/jfx/pull/37 From alexsch at openjdk.org Thu Nov 14 14:35:28 2019 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 14 Nov 2019 14:35:28 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 14:35:27 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: > >> Allow IDEA to correctly detect Git version control system when opening JFX project. >> >> ---------------- >> >> Commits: >> - f0f1866a: 8234174: Change IDEA VCS mapping to Git >> >> Changes: https://git.openjdk.java.net/jfx/pull/37/files >> Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/37.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 > > @AlexanderScherbatiy this is the part that applies to you: > >> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user AlexanderScherbatiy" as summary for the issue. > > Also, please read the [contributing guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md). As with the JDK project, we need a JBS bug ID for every pull request. I have created issue JDK-8234174 Change IDEA VCS mapping to Git. I have created SKARA-161 to map my GitHub username to your OpenJDK username. PR: https://git.openjdk.java.net/jfx/pull/37 From tsayao at openjdk.org Thu Nov 14 14:44:34 2019 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 14 Nov 2019 14:44:34 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 14:35:28 GMT, Alexander Scherbatiy wrote: > On Thu, 14 Nov 2019 14:35:27 GMT, Kevin Rushforth wrote: > >> On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: >> >>> Allow IDEA to correctly detect Git version control system when opening JFX project. >>> >>> ---------------- >>> >>> Commits: >>> - f0f1866a: 8234174: Change IDEA VCS mapping to Git >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/37/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 >>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/37.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 >> >> @AlexanderScherbatiy this is the part that applies to you: >> >>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user AlexanderScherbatiy" as summary for the issue. >> >> Also, please read the [contributing guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md). As with the JDK project, we need a JBS bug ID for every pull request. > > I have created issue JDK-8234174 Change IDEA VCS mapping to Git. > > I have created SKARA-161 to map my GitHub username to your OpenJDK username. Just one note: Idea can import the project from gradle, so many idea files on the project just gets on the way when committing. Not sure about this file in particular, but I think it would be better to remove IDE specific project files (for IDEs that supports it). PR: https://git.openjdk.java.net/jfx/pull/37 From dwookey at openjdk.org Thu Nov 14 15:02:40 2019 From: dwookey at openjdk.org (Dean Wookey) Date: Thu, 14 Nov 2019 15:02:40 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> <6EhektI1uVt5wjrCdFjPLfT2k8bdERlpUq8dCWu12uc=.2acad032-2a42-4f35-ad6d-282c908440c4@github.com> Message-ID: On Thu, 14 Nov 2019 14:27:24 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 12:34:56 GMT, Kevin Rushforth wrote: > >> On Thu, 14 Nov 2019 11:33:24 GMT, Dean Wookey wrote: >> >>> On Wed, 13 Nov 2019 19:10:45 GMT, David Grieve wrote: >>> >>>> On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas wrote: >>>> >>>>> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: >>>>> >>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>>> >>>>>>> **Issue :** >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>> >>>>>>> **Background :** >>>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>>> >>>>>>> **Description :** >>>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>> For ease of review, I have made two separate commits - >>>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>>> >>>>>>> **Root Cause :** >>>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>>> >>>>>>> **Fix :** >>>>>>> Fixed the identified root cause. See commit 2. >>>>>>> >>>>>>> **Testing :** >>>>>>> 1. All passing unit tests continue to pass >>>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>>> 3. System test JDK8183100Test continues to pass >>>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>>> >>>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>>> >>>>>> Reviewers: @kevinrushforth and @arapte >>>>> >>>>> It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. >>>> >>>> Has this been checked with SubScene? Two cases would be 1) SubScene inheriting a style from its parent, and 2) behavior of a parent in the SubScene itself. I don't expect that this would be an issue, but there is some special handling of CSS in SubScene IIRC. >>> >>> Having looked at this issue previously (https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022842.html and https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6), I'm a bit confused. >>> >>> Doesn't commit https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f essentially add another reapplyCSS() above the scenesChanged call on line 1074? I'm guessing this works because reapplyCss() (different from reapplyCSS()) sets cssFlag to UPDATE, which then means subsequent calls to reapplyCSS() don't call reapplyCss()? >>> >>> Does this leave the whole tree with the CssFlags.REAPPLY set instead of CssFlags.UPDATE as they would be without these changes? I'm not sure about the impact of that. >>> >>> I'm also curious whether commit 1 is even necessary with commit 2. >> >> The above raises good questions about the effect of adding a call to `reapplyCSS` when `scenesChanged` is called. This will need a careful analysis. >> >> Regarding whether commit 2 by itself would be sufficient, my initial guess was that it wouldn't be. However, I tested it, and it does in fact improve performance of the test case. Very interesting. > > Looking at this a little further, the change from commit 2, to call `reapplyCSS` at the beginning of `scenesChanged` really does two things: > > 1. Calling `reapplyCSS` right at the beginning of `scenesChanged` flips the order of CSS reapplication from the existing "bottom up" order to a "top down" order. Note that `scenesChanged` calls `invalidatedScenes` recursively (via `setScenes`) to traverse the scene graph. > > 2. It effectively undoes the rest of the changes, which were intended to avoid calling `reapplyCSS` in cases where it is redundant. As long as the performance improvement is preserved, this seems fine. > > The first of the above appears to be both necessary and sufficient to both maintain correctness while still avoiding the n^2 application of CSS in the case of adding a deep scene graph. If this is in fact the case, then I think the fix can be simplified even further by moving the following call from its current location (after `updateTreeShowing`) to right before the call to `scenesChanged`: > > if (sceneChanged) reapplyCSS(); > > in which case the changes to `Node::scenesChanged` and `Parent::scenesChanged` can be reverted > > The following patch, by itself (with nothing from commit 1) might be sufficient: > > --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java > +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java > @@ -1069,6 +1069,7 @@ public abstract class Node implements EventTarget, Styleable { > focusSetDirty(oldScene); > focusSetDirty(newScene); > } > + if (sceneChanged) reapplyCSS(); // Note this can be moved inside the previous 'if' block > scenesChanged(newScene, newSubScene, oldScene, oldSubScene); > > // isTreeShowing needs to take into account of Window's showing > @@ -1091,8 +1092,6 @@ public abstract class Node implements EventTarget, Styleable { > } > updateTreeShowing(); > > - if (sceneChanged) reapplyCSS(); > - > if (sceneChanged && !isDirtyEmpty()) { > //Note: no need to remove from scene's dirty list > //Scene's is checking if the node's scene is correct > > We will need to do a more complete evaluation as to whether this inversion of calling reapplyCSS on the parent before its children has any side effects, and also whether there are any of the performance improvements from the original fix that aren't covered here. I think inverting the call is fine. That's what I did in my fix (https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6) and we've been testing that out thoroughly for over a year. It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): if (cssFlag == CssFlags.UPDATE) { cssFlag = CssFlags.REAPPLY; notifyParentsOfInvalidatedCSS(); return; } and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.org Thu Nov 14 15:06:07 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 15:06:07 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: > Allow IDEA to correctly detect Git version control system when opening JFX project. > > ---------------- > > Commits: > - f0f1866a: 8234174: Change IDEA VCS mapping to Git > > Changes: https://git.openjdk.java.net/jfx/pull/37/files > Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 Adding to what @tsayao said, there is a JBS issue, [JDK-8223373](https://bugs.openjdk.java.net/browse/JDK-8223373), to remove the `.idea` files from the repo. I think this change is fine in the short term even if we end up removing the .idea files in the near future. .idea/vcs.xml line 8: Minor: can you restore the newline that was removed? It isn't related to the change, and in general, text files should end with a newline (although that's a suggestion, not a rule). PR: https://git.openjdk.java.net/jfx/pull/37 From alexsch at openjdk.org Thu Nov 14 15:18:15 2019 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 14 Nov 2019 15:18:15 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: <52oE7O0_WxbKwIZWoZlUK2-a75VO14y1wxZrezDZ2vs=.2ba5e9d4-b728-4a74-b781-a10f67aa48cf@github.com> On Thu, 14 Nov 2019 15:06:07 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: > >> Allow IDEA to correctly detect Git version control system when opening JFX project. >> >> ---------------- >> >> Commits: >> - f0f1866a: 8234174: Change IDEA VCS mapping to Git >> >> Changes: https://git.openjdk.java.net/jfx/pull/37/files >> Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/37.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 > > Adding to what @tsayao said, there is a JBS issue, [JDK-8223373](https://bugs.openjdk.java.net/browse/JDK-8223373), to remove the `.idea` files from the repo. > > I think this change is fine in the short term even if we end up removing the .idea files in the near future. > > .idea/vcs.xml line 8: > > > Minor: can you restore the newline that was removed? It isn't related to the change, and in general, text files should end with a newline (although that's a suggestion, not a rule). I use IDEA 2019.2.4. I tried to remove the .idea directory from jfx project and and open jfx project by IDEA using File -> New -> Project From Existing Sources... and point to jfx/build.gradle file. It started to analyze the project and just silently stops importing the project without any message in the ~/.IdeaIC2019.2/system/log/idea.log file. PR: https://git.openjdk.java.net/jfx/pull/37 From alexsch at openjdk.org Thu Nov 14 15:27:25 2019 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 14 Nov 2019 15:27:25 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: <52oE7O0_WxbKwIZWoZlUK2-a75VO14y1wxZrezDZ2vs=.2ba5e9d4-b728-4a74-b781-a10f67aa48cf@github.com> References: <52oE7O0_WxbKwIZWoZlUK2-a75VO14y1wxZrezDZ2vs=.2ba5e9d4-b728-4a74-b781-a10f67aa48cf@github.com> Message-ID: <0Psxr-Gtc43DJFZxzwHJKdOAGTVUz6yb6zwfR_Of6wM=.48ac2d27-f49b-494f-8ed3-43278d3bad86@github.com> On Thu, 14 Nov 2019 15:18:15 GMT, Alexander Scherbatiy wrote: > On Thu, 14 Nov 2019 15:06:07 GMT, Kevin Rushforth wrote: > >> On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: >> >>> Allow IDEA to correctly detect Git version control system when opening JFX project. >>> >>> ---------------- >>> >>> Commits: >>> - f0f1866a: 8234174: Change IDEA VCS mapping to Git >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/37/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 >>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/37.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 >> >> Adding to what @tsayao said, there is a JBS issue, [JDK-8223373](https://bugs.openjdk.java.net/browse/JDK-8223373), to remove the `.idea` files from the repo. >> >> I think this change is fine in the short term even if we end up removing the .idea files in the near future. >> >> .idea/vcs.xml line 8: >> >> >> Minor: can you restore the newline that was removed? It isn't related to the change, and in general, text files should end with a newline (although that's a suggestion, not a rule). > > I use IDEA 2019.2.4. > I tried to remove the .idea directory from jfx project and and open jfx project by IDEA using File -> New -> Project From Existing Sources... and point to jfx/build.gradle file. > It started to analyze the project and just silently stops importing the project without any message in the ~/.IdeaIC2019.2/system/log/idea.log file. Some .idea files are already in [.gitignore](https://github.com/openjdk/jfx/blob/master/.gitignore) # Ignore IntelliJ files .idea/tasks.xml .idea/workspace.xml .idea/inspectionProfiles/** .idea/copyright/profiles_settings.xml .idea/codeStyles/** .idea/checkstyle-idea.xml PR: https://git.openjdk.java.net/jfx/pull/37 From alexsch at openjdk.org Thu Nov 14 15:30:09 2019 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 14 Nov 2019 15:30:09 GMT Subject: [Rev 01] RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - c55e4d81: Restore new line in the end of .idea/vcs.xml file Changes: - all: https://git.openjdk.java.net/jfx/pull/37/files - new: https://git.openjdk.java.net/jfx/pull/37/files/f0f1866a..c55e4d81 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/37/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/37/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 PR: https://git.openjdk.java.net/jfx/pull/37 From alexsch at openjdk.org Thu Nov 14 15:30:12 2019 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Thu, 14 Nov 2019 15:30:12 GMT Subject: RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: <6HWagpj1R8IOP9mclV9jaIrDaBxEhrXRM62axziovaU=.0cde16ec-ddf7-404f-9294-b329a1a4577d@github.com> On Thu, 14 Nov 2019 15:06:07 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 14:35:26 GMT, Alexander Scherbatiy wrote: > >> Allow IDEA to correctly detect Git version control system when opening JFX project. >> >> ---------------- >> >> Commits: >> - f0f1866a: 8234174: Change IDEA VCS mapping to Git >> >> Changes: https://git.openjdk.java.net/jfx/pull/37/files >> Webrev: https://webrevs.openjdk.java.net/jfx/37/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/37.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 > > Adding to what @tsayao said, there is a JBS issue, [JDK-8223373](https://bugs.openjdk.java.net/browse/JDK-8223373), to remove the `.idea` files from the repo. > > I think this change is fine in the short term even if we end up removing the .idea files in the near future. > > .idea/vcs.xml line 8: > > > Minor: can you restore the newline that was removed? It isn't related to the change, and in general, text files should end with a newline (although that's a suggestion, not a rule). Updated. PR: https://git.openjdk.java.net/jfx/pull/37 From Rony.Flatscher at wu.ac.at Thu Nov 14 15:34:04 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 14 Nov 2019 16:34:04 +0100 Subject: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> Message-ID: On 13.11.2019 19:50, Kevin Rushforth wrote: > > On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: >> Will come up with a short reproducible testcase in ooRexx with brief comments such that the testcase >> could be understood without the runtime (ooRexx reads almost like pseudo-code). >> >> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all opensource) for >> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a script to >> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be o.k.? > > We prefer not to rely on third-party libraries for test cases. In any case we would not be able to > use that for a regression test / unit test. Yes, this is understandable. > How hard to you think it would be to use NashornScriptEngine for a test case? Probably impossible. Have researched NashornScriptEngine a little bit for a couple of hours now in order to assess it with respect to writing a testcase to demonstrate the problem. According to [1] the implementation has some Nashorn specific uses with respect to the ENGINE_SCOPE Bindings like:? - "... The default context's ENGINE_SCOPE is a wrapped instance of ECMAScript "global" object - which is the "this" in top level script expressions. ..." - "...? Please note that the context's GLOBAL_SCOPE Bindings and nashorn global object are different. Nashorn's global object is associated with ENGINE_SCOPE and not with GLOBAL_SCOPE. GLOBAL_SCOPE object of default script context is a javax.script.SimpleBindings instance. ..." - "... If you create a new ScriptContext object and use it to evaluate scripts, then ENGINE_SCOPE of that context has to be associated with a nashorn Global object somehow - or else script execution is not possible with that context - this is because evaluated script expects standard ECMAScript global builtins always. ..." - "... But, user can supply any ScriptContext implementation containing any Bindings object as ENGINE_SCOPE, nashorn engine cannot always assume ENGINE_SCOPE Bindings to be backed by a nashorn Global instance. Nashorn engine checks if ENGINE_SCOPE of the ScriptContext is backed by a Nashorn Global object or not. If not, it creates a fresh Bindings backed by a nashorn Global instance and associates the same with the ENGINE_SCOPE that the user provided. ..." - "... Limitations/Known issues / While nashorn attempts to give a seamless illusion of ScriptObjectMirrors and JSObjects, not every operation and script API (JSON, Array, Function's properties/functions) treats ScriptObjectMirror and jdk.nashorn.internal.runtime.ScriptObject uniformly. There are places where ScriptObjects work as expected but if you pass ScriptObjectMirror or your own JSObject implementation, it won't work as expected. ..." [2] states: "Summary: Nashorn uses javax.script.filename uses as "source name" of the generated class *only* for engine.eval calls. For "load", it uses the? URL/file name of the loaded script as "source name". As for? javax.script.filename variable, Nashorn never sets - only uses it." In addition [3] indicates that scripts themselves should not get access to ScriptEngine.FILENAME. Indeed, adding the entry ScriptEngine.FILENAME to the NashornScriptEngine supplied ENGINE_SCOPE Bindings (which will be of type "jdk.nashorn.api.scripting.ScriptObjectMirror") will not leave that entry in the Bindings. Also, invoking a Javascript script stored in a file via ScriptEngine.eval() does not make the arguments (entry ScriptEngine.ARGV) available to the invoked Javascript script (i.e. "arguments.length" will return 0), e.g. in the following testscript.js: ?? print( "hi, this is from 'testargs.js', arguments.length="+arguments.length); ?? print( "arguments.length: " + arguments.length ); ?? print( "---") ?? func1 ( "uno", "deux", 3); ?? function func1(a, b, c) { ?? ? ? print( "--> func1(a, b, c) - arguments.length: " + arguments.length ); ? ? ?? print( "\ta: "+ a + " / arguments[0]: " + arguments[0] ); ? ? ?? print( "\tb: "+ b + " / arguments[1]: " + arguments[1] ); ?? ? ? print( "\tc: "+ c + " / arguments[2]: " + arguments[2] ); ?? } Doing a ScriptEngine.eval() with the ENGINE_SCOPE Bindings possessing the argument entry by the name of ScriptEngine.ARGV will yield the following output in this case: ?? hi, this is from 'testargs.js', arguments.length=0 ?? arguments.length: 0 ?? --- ?? --> func1(a, b, c) - arguments.length: 3 ? ? ?????? a: uno / arguments[0]: uno ? ? ?????? b: deux / arguments[1]: deux ? ? ?????? c: 3 / arguments[2]: 3 [1] Sundararajan A., "Nashorn jsr223 engine notes": [2] Sundararajan A., "Nashorn, javax.script.filename, and load()": [3] "JDK-8050432 : javax.script.filename variable should not be enumerable with nashorn engine's ENGINE_SCOPE bindings": [4] Oracle, "Java Platform, Standard Edition Nashorn User's Guide": --- So concluding that the NashornScriptEngine will not be an implementation that could be used to create a testcase to demonstrate the problem and to create a testunit, because of its specific implementation that ?? a) swallows the ScriptEngine.FILENAME (https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html#FILENAME) entry and ?? b) does not honor the ScriptEngine.ARGV (cf. ) entry. Would you have other suggestions for scripting engines that you think could be used instead, such that I can take a look at its implementation and try to create a testcase with it? ---rony From Rony.Flatscher at wu.ac.at Thu Nov 14 15:34:16 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 14 Nov 2019 16:34:16 +0100 Subject: Correct diff (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> Message-ID: <679cd632-148d-8863-33ed-d30bbd56c906@wu.ac.at> Just for the record: attached the wrong diff, so attaching the correct one to this posting. Sorry for the confusion. ---rony On 13.11.2019 15:14, Rony G. Flatscher wrote: > Hmm, not getting any feedback so far, so wondering if there are currently any Java developers who > take advantage of the ability of FXMLLoader to have FXML controllers implemented in any of the Java > javax.script languages? > > For those, who use scripting languages for FXML controllers the request that FXMLLoader adds both > entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV () (for making the > event object available directly as an argument) into the engine Bindings, should be quite helpful > while developing and running the scripts. > > [Personally I am using the scripting engine ooRexx successfully for teaching oo programming from > scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a Business Administration > university. So these two missing features in the current FXMLLoader support for FXML controllers > would help tremendously, especially in case of coding errors as currently it is not clear from which > file the script that has an error comes from, making it extremely cumbersome and time consuming in > JavaFX applications that use multiple and complex FXML files.] > > Therefore I would kindly ask interested committers for mentoring the proposed changes. Enclosed > please find a simpler version of the patch that adds these missing features to the ENGINE_SCOPE > Bindings in the three locations where ScriptEngine.eval() gets invoked (it ). > > To comment this simple patch, maybe I should add a few remarks such that the context becomes clear: > > * invoking a script via ScriptEngine.eval() will always be accompanied with a ScriptContext that > usually maintains two Bindings (Maps): > > o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting the FXML elements that > have an fx:id attribute defined, such that scripts can get access to them, independent of a > particular ScriptEngine) which can also be used for sharing values among different script > invocations, > > o one, ENGINE_SCOPE Bindings, usually used for individual invocations. > > * while a FXML file gets processed sequentially by the FXMLLoader elements in the form of > "" will cause invoking the ScriptEngine.eval(Reader): this > patch fetches the ENGINE_SCOPE Bindings and puts the value "someScript.ext" with the key > ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class FXMLLoader" and "@@ > -1582,6 +1585,8 @@ public class FXMLLoader" in the patch), > > * if an event handler gets defined (e.g. with the event attribute " onAction="someScript">") the FXMLLoader creates a ScriptEventHandler and stores "someScript" and > the ScriptEngine for executing that script whenever the event fires. > > o When an event fires, the current implementation creates a copy of the current ENGINE_SCOPE > Bindings from the ScriptEngine's ScriptContext, adds its entries to it after saving the > entry "event" with the ActionEvent object in it. It then changes the ScriptEngine's current > ScriptContext such that it now uses the new copy of the Bindings as its ENGINE_SCOPE > Bindings, runs the script using eval() and then restores the ScriptContext ENGINE_SCOPE > Bindings. > > o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class FXMLLoader") instead will > create a copy of the ENGINE_SCOPE Bindings only once at creation time (and puts the > appropriate ScriptEngine.FILENAME into it using the name of the FXML file that defines the > event script attribute) and will reuse that Bindings each time the handler gets invoked, > after putting the actual "event" object and the respective ScriptEngine.ARGV entry into it. > Using ScriptEngine.eval(String,Bindings) will use the supplied Bindings as the ENGINE_SCOPE > Bindings for this invocation only, such that no restore is necessary upon return. > > As only entries get added to the engine Bindings that have not been used by FXMLLoader this simple > patch should not affect existing scripts. The patch has been tested and works. > > Maybe it helps the cause for applying this patch, if I point out that I have been active in a number > of opensource projects, including Apache's BSF which led to my participation as an expert in JSR-223 > which originally defined the javax.script framework introduced with Java 6 (also authored a complete > ScriptEngine implementation with both, the javax.script.Compilable and the javax.script.Invocable > interfaces). > > So looking for interested committers who would be willing to mentor this patch. Please advise. > > ---rony > > > > On 06.11.2019 16:05, Rony G. Flatscher wrote: >> Using a script engine (javax.script.ScriptEngine) for implementing a FXML controller there are two >> important information missing in the ScriptContext.ENGINE_SCOPE Bindings supplied to the script used >> to eval() the script code: >> >> * ScriptEngine.FILENAME >> o This value denotes the file name from where the script code was fetched that is being eval()'d. >> o When debugging script controllers in a complex JavaFX application it is mandatory to know >> the file name the script code was taken from (as such scripts could be called/run from >> different FXML files). Also, in the case of script runtime errors, usually the file name is >> given by the script engine where the error has occurred to ease debugging, such that it is >> important to really supply the filename. >> + Note: the 'location'-URL in ScriptContext.GLOBAL_SCOPE refers the FXML file,? not to the >> file that hosts the script that gets run if using the "> "source" attribute denotes the name of the script file. >> o General solution: supply the appropriate ScriptEngine.FILENAME entry to the >> ScriptContext.ENGINE_SCOPE Bindings. >> >> * ScriptEngine.ARGV >> o This value denotes the arguments that get passed to the script from Java in form of a Java >> Array of type Object. >> o When defining event handlers in FXML files in script code the script does not get the >> appropriate argument. Rather the script programmer needs to access the >> ScriptContext.ENGINE_SCOPE and fetch the entry named "event" from there. Some script engines >> may make the entries in the Bindings implicitly available to the scripts, however this >> cannot be expected by default. However, a ScriptEngine.ARGV entry must be supplied to the >> script by the script engine implementor, such that a script coder gets the event object >> argument in the script language's manner. >> o General solution: supply the appropriate ScriptEngine.ARGV Object array to the >> ScriptContext.ENGINE_SCOPE Bindings. >> >> With these two changes not only writing controller scripts would be eased, it also would >> instrumentate ScriptContext.ENGINE_SCOPE Bindings the way it was intended by JSR-223. >> >> Enclosed please find a tested diff for FXMLLoader.java from the current OpenJavaFX Master (version >> 14) that implements both, ScriptEngine.FILENAME entries for all script invocations and in the case >> of a script event handler the appropriate ScriptEngine.ARGV entry gets supplied, allowing the script >> to fetch the event object directly as an argument. >> >> As I have signed the OCA the code (in form of a git diff) can be directly applied to FXMLLoader.java. >> >> If you need the patch in a different form, then please advise. >> >> ---rony -------------- next part -------------- diff --git a/gradlew b/gradlew old mode 100644 new mode 100755 diff --git a/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java b/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java index 7f3d2f3083..1d56ca0614 100644 --- a/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java +++ b/modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java @@ -1558,6 +1558,9 @@ public class FXMLLoader { location = new URL(FXMLLoader.this.location, source); } + Bindings engineBindings = engine.getBindings(ScriptContext.ENGINE_SCOPE); + engineBindings.put(engine.FILENAME, location.getPath()); + InputStreamReader scriptReader = null; try { scriptReader = new InputStreamReader(location.openStream(), charset); @@ -1582,6 +1585,8 @@ public class FXMLLoader { if (value != null && !staticLoad) { // Evaluate the script try { + Bindings engineBindings = scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE); + engineBindings.put(scriptEngine.FILENAME, location.getPath()); scriptEngine.eval((String)value); } catch (ScriptException exception) { System.err.println(exception.getMessage()); @@ -1675,30 +1680,29 @@ public class FXMLLoader { private static class ScriptEventHandler implements EventHandler { public final String script; public final ScriptEngine scriptEngine; + public final Bindings engineBindings; public ScriptEventHandler(String script, ScriptEngine scriptEngine) { this.script = script; this.scriptEngine = scriptEngine; + engineBindings = scriptEngine.createBindings(); + engineBindings.putAll(scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE)); + URL location=(URL) scriptEngine.getBindings(ScriptContext.GLOBAL_SCOPE).get(LOCATION_KEY); + engineBindings.put(scriptEngine.FILENAME, location.getPath()); } @Override public void handle(Event event) { - // Don't pollute the page namespace with values defined in the script - Bindings engineBindings = scriptEngine.getBindings(ScriptContext.ENGINE_SCOPE); - Bindings localBindings = scriptEngine.createBindings(); - localBindings.put(EVENT_KEY, event); - localBindings.putAll(engineBindings); - scriptEngine.setBindings(localBindings, ScriptContext.ENGINE_SCOPE); + // Don't pollute the page namespace with values defined in the script use initial engineBindings + engineBindings.put(EVENT_KEY, event); + engineBindings.put(scriptEngine.ARGV, new Object[]{event}); // Execute the script try { - scriptEngine.eval(script); + scriptEngine.eval(script,engineBindings); } catch (ScriptException exception){ throw new RuntimeException(exception); } - - // Restore the original bindings - scriptEngine.setBindings(engineBindings, ScriptContext.ENGINE_SCOPE); } } From github.com+4412658+dsgrieve at openjdk.org Thu Nov 14 16:11:45 2019 From: github.com+4412658+dsgrieve at openjdk.org (David Grieve) Date: Thu, 14 Nov 2019 16:11:45 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: <0HgCzVHoxU3V6jdrDSrL8UGIWutu86BwFyCALsd8LDw=.ac86a1aa-9e96-4747-ac74-f0be4c8e83ba@github.com> <6EhektI1uVt5wjrCdFjPLfT2k8bdERlpUq8dCWu12uc=.2acad032-2a42-4f35-ad6d-282c908440c4@github.com> Message-ID: On Thu, 14 Nov 2019 15:02:40 GMT, Dean Wookey wrote: > On Thu, 14 Nov 2019 14:27:24 GMT, Kevin Rushforth wrote: > >> On Thu, 14 Nov 2019 12:34:56 GMT, Kevin Rushforth wrote: >> >>> On Thu, 14 Nov 2019 11:33:24 GMT, Dean Wookey wrote: >>> >>>> On Wed, 13 Nov 2019 19:10:45 GMT, David Grieve wrote: >>>> >>>>> On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas wrote: >>>>> >>>>>> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas wrote: >>>>>> >>>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>>>> >>>>>>>> **Issue :** >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>>> >>>>>>>> **Background :** >>>>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>>>> >>>>>>>> **Description :** >>>>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>>> For ease of review, I have made two separate commits - >>>>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>>>> >>>>>>>> **Root Cause :** >>>>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>>>> >>>>>>>> **Fix :** >>>>>>>> Fixed the identified root cause. See commit 2. >>>>>>>> >>>>>>>> **Testing :** >>>>>>>> 1. All passing unit tests continue to pass >>>>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>>>> 3. System test JDK8183100Test continues to pass >>>>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>>>> >>>>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>>>> >>>>>>>> ---------------- >>>>>>>> >>>>>>>> Commits: >>>>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>>>> >>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>>>> >>>>>>> Reviewers: @kevinrushforth and @arapte >>>>>> >>>>>> It will be helpful if I can get some feedback from community with additional testing apart from what is mentioned in the description. >>>>> >>>>> Has this been checked with SubScene? Two cases would be 1) SubScene inheriting a style from its parent, and 2) behavior of a parent in the SubScene itself. I don't expect that this would be an issue, but there is some special handling of CSS in SubScene IIRC. >>>> >>>> Having looked at this issue previously (https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022842.html and https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6), I'm a bit confused. >>>> >>>> Doesn't commit https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f essentially add another reapplyCSS() above the scenesChanged call on line 1074? I'm guessing this works because reapplyCss() (different from reapplyCSS()) sets cssFlag to UPDATE, which then means subsequent calls to reapplyCSS() don't call reapplyCss()? >>>> >>>> Does this leave the whole tree with the CssFlags.REAPPLY set instead of CssFlags.UPDATE as they would be without these changes? I'm not sure about the impact of that. >>>> >>>> I'm also curious whether commit 1 is even necessary with commit 2. >>> >>> The above raises good questions about the effect of adding a call to `reapplyCSS` when `scenesChanged` is called. This will need a careful analysis. >>> >>> Regarding whether commit 2 by itself would be sufficient, my initial guess was that it wouldn't be. However, I tested it, and it does in fact improve performance of the test case. Very interesting. >> >> Looking at this a little further, the change from commit 2, to call `reapplyCSS` at the beginning of `scenesChanged` really does two things: >> >> 1. Calling `reapplyCSS` right at the beginning of `scenesChanged` flips the order of CSS reapplication from the existing "bottom up" order to a "top down" order. Note that `scenesChanged` calls `invalidatedScenes` recursively (via `setScenes`) to traverse the scene graph. >> >> 2. It effectively undoes the rest of the changes, which were intended to avoid calling `reapplyCSS` in cases where it is redundant. As long as the performance improvement is preserved, this seems fine. >> >> The first of the above appears to be both necessary and sufficient to both maintain correctness while still avoiding the n^2 application of CSS in the case of adding a deep scene graph. If this is in fact the case, then I think the fix can be simplified even further by moving the following call from its current location (after `updateTreeShowing`) to right before the call to `scenesChanged`: >> >> if (sceneChanged) reapplyCSS(); >> >> in which case the changes to `Node::scenesChanged` and `Parent::scenesChanged` can be reverted >> >> The following patch, by itself (with nothing from commit 1) might be sufficient: >> >> --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >> @@ -1069,6 +1069,7 @@ public abstract class Node implements EventTarget, Styleable { >> focusSetDirty(oldScene); >> focusSetDirty(newScene); >> } >> + if (sceneChanged) reapplyCSS(); // Note this can be moved inside the previous 'if' block >> scenesChanged(newScene, newSubScene, oldScene, oldSubScene); >> >> // isTreeShowing needs to take into account of Window's showing >> @@ -1091,8 +1092,6 @@ public abstract class Node implements EventTarget, Styleable { >> } >> updateTreeShowing(); >> >> - if (sceneChanged) reapplyCSS(); >> - >> if (sceneChanged && !isDirtyEmpty()) { >> //Note: no need to remove from scene's dirty list >> //Scene's is checking if the node's scene is correct >> >> We will need to do a more complete evaluation as to whether this inversion of calling reapplyCSS on the parent before its children has any side effects, and also whether there are any of the performance improvements from the original fix that aren't covered here. > > I think inverting the call is fine. That's what I did in my fix (https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6) and we've been testing that out thoroughly for over a year. > > It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. > > The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): > > if (cssFlag == CssFlags.UPDATE) { > cssFlag = CssFlags.REAPPLY; > notifyParentsOfInvalidatedCSS(); > return; > } > and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? > > Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. I think the order of calls in invalidatedScenes is correct. The scene graph plumbing needs to be done before CSS is applied since a node's style can depend on the styles of its parent. The issue is really calling reapplyCss(). In the case where a child is added to a parent, the child's parent property is invalidated which should call reapplyCSS(), which should (in turn) call reapplyCss(). Next the invalidatedScenes call happens and the whole dance starts again. (See Parent children.onChanged). Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. Since CSS is reapplied from the top down, my parent's cssFlag should be CLEAN before reapplyCss() method is called from reapplyCSS(). It has been a long time since I've been in this code. I'm going to look at this some more. PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.org Thu Nov 14 16:37:10 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 16:37:10 GMT Subject: [Approved] RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 15:30:09 GMT, Alexander Scherbatiy wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - c55e4d81: Restore new line in the end of .idea/vcs.xml file > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/37/files > - new: https://git.openjdk.java.net/jfx/pull/37/files/f0f1866a..c55e4d81 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/37/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/37/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8234174 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/37/head:pull/37 Looks good. Since this is a trivial, and obviously correct, change to an IDE file, it only needs a single reviewer. You may integrate it when ready; I'll sponsor it. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/37 From arapte at openjdk.org Thu Nov 14 17:53:29 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 14 Nov 2019 17:53:29 GMT Subject: RFR: 8234189: [TEST_BUG] Remove ignored and invalid graphics unit tests Message-ID: Following unit tests are to be removed: 1. test.com.sun.javafx.iio.ImageLoaderScalingTest.testAllTheScalesJPG: Color of a pixel in original and scaled jpg image can not be guarantted to be same. 2. test.javafx.scene.layout.BackgroundSizeTest.negativeWidthThrowsException3 test.javafx.scene.layout.BackgroundSizeTest.negativeHeightThrowsException3: Double.MIN_VALUE is not < 0 and there are tests included for negative value. 3.test.javafx.scene.input.PasteboardTest: Pasteboard is removed. 4. test.javafx.scene.input.TouchEventTest.shouldThrowREOnLostIndirectRelease: Indirect gesture touch events are not supported yet. There will be lot of more tests needed once we decide to support the Indirect gesture events. This test can be reintroduced after that. ---------------- Commits: - a8ecc824: Remove ignored and invalid graphics unit tests Changes: https://git.openjdk.java.net/jfx/pull/38/files Webrev: https://webrevs.openjdk.java.net/jfx/38/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234189 Stats: 167 lines in 4 files changed: 0 ins; 164 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/38.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/38/head:pull/38 PR: https://git.openjdk.java.net/jfx/pull/38 From Rony.Flatscher at wu.ac.at Thu Nov 14 18:12:19 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 14 Nov 2019 19:12:19 +0100 Subject: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> Message-ID: <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> On 14.11.2019 16:34, Rony G. Flatscher wrote: > On 13.11.2019 19:50, Kevin Rushforth wrote: >> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: ... cut ... >>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all opensource) for >>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a script to >>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be o.k.? >> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to >> use that for a regression test / unit test. If test units really seem to be important in this particular case, one possibility would be to create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval() methods return the ScriptContext at invocation time in order to allow inspection of the Bindings. This way it would become also possible to write in addition test units that also check whether all FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings. However, From kcr at openjdk.org Thu Nov 14 18:15:34 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 18:15:34 GMT Subject: [Approved] RFR: 8234189: [TEST_BUG] Remove ignored and invalid graphics unit tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 17:53:29 GMT, Ambarish Rapte wrote: > Following unit tests are to be removed: > 1. test.com.sun.javafx.iio.ImageLoaderScalingTest.testAllTheScalesJPG: > Color of a pixel in original and scaled jpg image can not be guarantted to be same. > > 2. test.javafx.scene.layout.BackgroundSizeTest.negativeWidthThrowsException3 > test.javafx.scene.layout.BackgroundSizeTest.negativeHeightThrowsException3: > Double.MIN_VALUE is not < 0 and there are tests included for negative value. > > 3.test.javafx.scene.input.PasteboardTest: Pasteboard is removed. > > 4. test.javafx.scene.input.TouchEventTest.shouldThrowREOnLostIndirectRelease: > Indirect gesture touch events are not supported yet. There will be lot of more tests needed once we decide to support the Indirect gesture events. This test can be reintroduced after that. > > ---------------- > > Commits: > - a8ecc824: Remove ignored and invalid graphics unit tests > > Changes: https://git.openjdk.java.net/jfx/pull/38/files > Webrev: https://webrevs.openjdk.java.net/jfx/38/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234189 > Stats: 167 lines in 4 files changed: 0 ins; 164 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/38.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/38/head:pull/38 Looks good. Since this is a simple test fix, one reviewer is sufficient. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/38 From kcr at openjdk.org Thu Nov 14 18:33:05 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 18:33:05 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > **Issue :** > https://bugs.openjdk.java.net/browse/JDK-8193445 > > **Background :** > The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. > > **Description :** > This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > For ease of review, I have made two separate commits - > 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. > 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test > > **Root Cause :** > CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. > What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. > This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) > > **Fix :** > Fixed the identified root cause. See commit 2. > > **Testing :** > 1. All passing unit tests continue to pass > 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix > 3. System test JDK8183100Test continues to pass > 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix > > In addition, testing by community with specific CSS performance / functionality will be helpful. > > ---------------- > > Commits: > - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test > - d964675e: Reintroduce JDK-8151756 CSS performance fix > > Changes: https://git.openjdk.java.net/jfx/pull/34/files > Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 > Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/34.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: > 25: > 26: package test.robot.javafx.scene; > 27: There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: > 54: > 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { > 56: We have moved away from putting the bug ID in the test class name, so I recommend renaming it. tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: > 77: HBox hbox = new HBox(); > 78: for (int i = 0; i < 300; i++) { > 79: hbox = new HBox(new Text("y"), hbox); In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: > 93: // It is good enough to catch the regression in performance, if any > 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); > 95: } If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.org Thu Nov 14 18:49:18 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 18:49:18 GMT Subject: RFR: 8234150: Address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 09:33:39 GMT, Ajit Ghaisas wrote: > This PR is to address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest. > > strategy is as follows - > > 1) Enable tests marked with @Ignore by removing that tag > 2) Run the test > 3) If test Passes - remove the @Ignore tag > 4) If test fails - if test is invalid - remove it, else fix the test > 5) In case if the failure cannot be fixed, leave the test ignored (keep @Ignore tag) > > > With these corrections - here are the results: > > Results BEFORE this FIX > 1. ComboBoxTest -- tests:156, failures:0, ignored:4 > 2. LabeledTest -- tests:93, failures:0, ignored:5 > 3. HyperlinkTest -- tests:34, failures:0, ignored:3 > 4. TextInputControlTest -- tests:594, failures:0, ignored:12 > > Results AFTER this FIX > 1. ComboBoxTest -- tests:156, failures:0, ignored:2 > 2. LabeledTest -- tests:93, failures:0, ignored:3 > 3. HyperlinkTest -- tests:31, failures:0, ignored:0 > 4. TextInputControlTest -- tests:585, failures:0, ignored:0 > > ---------------- > > Commits: > - 6709837b: Fix-Remove-Keep @Ignore tests > > Changes: https://git.openjdk.java.net/jfx/pull/36/files > Webrev: https://webrevs.openjdk.java.net/jfx/36/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234150 > Stats: 63 lines in 4 files changed: 0 ins; 57 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/36.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/36/head:pull/36 It looks OK to me. Have you run this on all three platforms? PR: https://git.openjdk.java.net/jfx/pull/36 From arapte at openjdk.org Thu Nov 14 19:56:16 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 14 Nov 2019 19:56:16 GMT Subject: RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests Message-ID: Following graphics unit tests can be re-enabled. 1. test.com.sun.javafx.scene.layout.region.BackgroundRepeatConverterTest.scenario2 RepeatStructConverter.convert() is an internal method and does not verify the parameters. Passing null value to this method results in NPE. 2. test.javafx.scene.layout.RegionCSSTest.borderImageWidth_auto test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_auto test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_2Percent_auto It is not certain if the value of auto for -fx-border-image-width is 1 or 2 by defaut. But the tests seem correct and they pass. 3. test.javafx.scene.Node_cssMethods_Test [JDK-8094155](https://bugs.openjdk.java.net/browse/JDK-8094155) is fixed and the tests can be re-enabled. ---------------- Commits: - 5df00884: Reenable few of the graphics unit tests Changes: https://git.openjdk.java.net/jfx/pull/39/files Webrev: https://webrevs.openjdk.java.net/jfx/39/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 Stats: 12 lines in 3 files changed: 0 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 PR: https://git.openjdk.java.net/jfx/pull/39 From marcel.au at web.de Thu Nov 14 20:15:11 2019 From: marcel.au at web.de (marcel Austenfeld) Date: Thu, 14 Nov 2019 21:15:11 +0100 Subject: HighDPI Scaling Bug On Linux With JavaFX Interoperability With SWT (Possible Solution) Message-ID: From marcel.au at web.de Thu Nov 14 20:21:40 2019 From: marcel.au at web.de (marcel Austenfeld) Date: Thu, 14 Nov 2019 21:21:40 +0100 Subject: HighDPI Scaling Bug On Linux With JavaFX Interoperability With SWT (Possible Solution) Message-ID: I filed this bug regarding the high dpi scaling on Linux when using the FXCanvas for SWT: ? https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8233181 ? I think I found the problem in the FXCancas class whereas the Linux case is simply not handled: ? https://github.com/openjdk/jfx/blob/master/modules/javafx.swt/src/main/java/javafx/embed/swt/FXCanvas.java#L174 https://github.com/openjdk/jfx/blob/master/modules/javafx.swt/src/main/java/javafx/embed/swt/FXCanvas.java#L240 ? In both cases the scale factor for MacOSX and Windows is returned (by reflection) but not for Linux which I think i the same method as for Windows. ? Thus the scaling factor is always 1 which leads to this graphical distortion (if I set the scale with DPIUtil.setScale differently I can also cause a distortion!) ? However I was not able to built openjfx on Ubuntu 19.10 so far. ? Is there a gradle command to built the swt module only? ? @Kevin Rushforth: can you confirm that this is the cause for the bug? ? Unfortunately there is no issue tab on the Github page so I post here. From kevin.rushforth at oracle.com Thu Nov 14 21:54:02 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Nov 2019 13:54:02 -0800 Subject: HighDPI Scaling Bug On Linux With JavaFX Interoperability With SWT (Possible Solution) In-Reply-To: References: Message-ID: <7df12761-7cdb-304d-8284-8648442a597b@oracle.com> Btw, the direct pointer to the JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8233181 You're right that FXCanvas Hi-DPI support doesn't handle Linux at all. As for building JavaFX on Ubuntu 19.10, I just did that, but needed to disable warnings as errors, likely due to the fact that gcc 9 is generating more warnings. If this is your problem, then you can temporarily edit buildSrc/linux.gradle and remove "-Werror" from the three LINUX.glass.glass*.cFlags settings. Also, make sure that you have all of the required packages installed. See: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-LinuxDesktopBuildLinux -- Kevin On 11/14/2019 12:21 PM, marcel Austenfeld wrote: > I filed this bug regarding the high dpi scaling on Linux when using the FXCanvas for SWT: > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8233181 > > I think I found the problem in the FXCancas class whereas the Linux case is simply not handled: > > https://github.com/openjdk/jfx/blob/master/modules/javafx.swt/src/main/java/javafx/embed/swt/FXCanvas.java#L174 > > https://github.com/openjdk/jfx/blob/master/modules/javafx.swt/src/main/java/javafx/embed/swt/FXCanvas.java#L240 > > In both cases the scale factor for MacOSX and Windows is returned (by reflection) but not for Linux which I think i the same method as for Windows. > > Thus the scaling factor is always 1 which leads to this graphical distortion (if I set the scale with DPIUtil.setScale differently I can also cause a distortion!) > > However I was not able to built openjfx on Ubuntu 19.10 so far. > > Is there a gradle command to built the swt module only? > > @Kevin Rushforth: can you confirm that this is the cause for the bug? > > Unfortunately there is no issue tab on the Github page so I post here. From kevin.rushforth at oracle.com Thu Nov 14 21:57:48 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Nov 2019 13:57:48 -0800 Subject: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> Message-ID: <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote: > On 14.11.2019 16:34, Rony G. Flatscher wrote: >> On 13.11.2019 19:50, Kevin Rushforth wrote: >>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: > ... cut ... >>>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all opensource) for >>>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a script to >>>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be o.k.? >>> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to >>> use that for a regression test / unit test. > If test units really seem to be important in this particular case, one possibility would be to > create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow > the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and > ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval() > methods return the ScriptContext at invocation time in order to allow inspection of the Bindings. > This way it would become also possible to write in addition test units that also check whether all > FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings. Something like that seems reasonable, and would avoid a dependence on Nashorn, which in addition to having all the problems you mentioned, is deprecated for removal. > However, Did you have something more to add? -- Kevin From kcr at openjdk.org Thu Nov 14 23:31:34 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 23:31:34 GMT Subject: RFR: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 Message-ID: [JDK-8233421](https://bugs.openjdk.java.net/browse/JDK-8233421) This bumps the windows compiler version to VS2017 version 15.9.16 to match JDK 14. I have run a full build and test, including WebKit and media. ---------------- Commits: - aab19fa8: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 Changes: https://git.openjdk.java.net/jfx/pull/40/files Webrev: https://webrevs.openjdk.java.net/jfx/40/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233421 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/40/head:pull/40 PR: https://git.openjdk.java.net/jfx/pull/40 From kcr at openjdk.org Thu Nov 14 23:33:25 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 23:33:25 GMT Subject: RFR: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 23:31:34 GMT, Kevin Rushforth wrote: > [JDK-8233421](https://bugs.openjdk.java.net/browse/JDK-8233421) > > This bumps the windows compiler version to VS2017 version 15.9.16 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - aab19fa8: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 > > Changes: https://git.openjdk.java.net/jfx/pull/40/files > Webrev: https://webrevs.openjdk.java.net/jfx/40/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233421 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/40.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/40/head:pull/40 Reviewers: @arapte @johanvos PR: https://git.openjdk.java.net/jfx/pull/40 From kcr at openjdk.org Thu Nov 14 23:34:49 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 23:34:49 GMT Subject: RFR: 8233420: Upgrade to gcc 8.3 on Linux Message-ID: [JDK-8233420](https://bugs.openjdk.java.net/browse/JDK-8233420) This bumps the Linux compiler version to gcc 8.3 to match JDK 14. I have run a full build and test, including WebKit and media. ---------------- Commits: - ab06dc58: 8233420: Upgrade to gcc 8.3 on Linux Changes: https://git.openjdk.java.net/jfx/pull/41/files Webrev: https://webrevs.openjdk.java.net/jfx/41/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233420 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/41/head:pull/41 PR: https://git.openjdk.java.net/jfx/pull/41 From kcr at openjdk.org Thu Nov 14 23:34:50 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 23:34:50 GMT Subject: RFR: 8233420: Upgrade to gcc 8.3 on Linux In-Reply-To: References: Message-ID: <0058FZLr3zGXhdZpc_-wVgNEA6i39UM30cuCg3WyzLY=.ee37a722-b162-4c45-b549-6282a90ad326@github.com> On Thu, 14 Nov 2019 23:34:49 GMT, Kevin Rushforth wrote: > [JDK-8233420](https://bugs.openjdk.java.net/browse/JDK-8233420) > > This bumps the Linux compiler version to gcc 8.3 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - ab06dc58: 8233420: Upgrade to gcc 8.3 on Linux > > Changes: https://git.openjdk.java.net/jfx/pull/41/files > Webrev: https://webrevs.openjdk.java.net/jfx/41/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233420 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/41.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/41/head:pull/41 Reviewers: @arapte @johanvos PR: https://git.openjdk.java.net/jfx/pull/41 From prr at openjdk.org Thu Nov 14 23:54:16 2019 From: prr at openjdk.org (Phil Race) Date: Thu, 14 Nov 2019 23:54:16 GMT Subject: [Approved] RFR: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 In-Reply-To: References: Message-ID: <2ky_TElLwo-aiHJ2Y8lx084gSXKCOVUW7Tv4Hs-C3_M=.12ae6425-9c3a-49b8-bfd2-8f9cc9b083f2@github.com> On Thu, 14 Nov 2019 23:31:34 GMT, Kevin Rushforth wrote: > [JDK-8233421](https://bugs.openjdk.java.net/browse/JDK-8233421) > > This bumps the windows compiler version to VS2017 version 15.9.16 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - aab19fa8: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 > > Changes: https://git.openjdk.java.net/jfx/pull/40/files > Webrev: https://webrevs.openjdk.java.net/jfx/40/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233421 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/40.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/40/head:pull/40 Approved by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/40 From kcr at openjdk.org Thu Nov 14 23:55:45 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Nov 2019 23:55:45 GMT Subject: RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 19:56:16 GMT, Ambarish Rapte wrote: > Following graphics unit tests can be re-enabled. > > 1. test.com.sun.javafx.scene.layout.region.BackgroundRepeatConverterTest.scenario2 > RepeatStructConverter.convert() is an internal method and does not verify the parameters. Passing null value to this method results in NPE. > > 2. test.javafx.scene.layout.RegionCSSTest.borderImageWidth_auto > test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_auto > test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_2Percent_auto > It is not certain if the value of auto for -fx-border-image-width is 1 or 2 by defaut. But the tests seem correct and they pass. > > 3. test.javafx.scene.Node_cssMethods_Test > [JDK-8094155](https://bugs.openjdk.java.net/browse/JDK-8094155) is fixed and the tests can be re-enabled. > > ---------------- > > Commits: > - 5df00884: Reenable few of the graphics unit tests > > Changes: https://git.openjdk.java.net/jfx/pull/39/files > Webrev: https://webrevs.openjdk.java.net/jfx/39/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 > Stats: 12 lines in 3 files changed: 0 ins; 7 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/39.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 Most of this looks OK, but there is one I had a question on. Have you run this on all platforms? modules/javafx.graphics/src/test/java/test/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java line 57: > 56: @Test(expected=NullPointerException.class) > 57: public void scenario2() { > 58: ParsedValue[][] values = new ParsedValueImpl[][] { This is at odds with the body of the test, since presumably, the `assertEquals` will never be called. An expect exception annotation is best used in the case where you do a single thing that is expected to generate that exception. Otherwise and unexpected exception could end up making the test look like it's passing. PR: https://git.openjdk.java.net/jfx/pull/39 From aghaisas at openjdk.org Fri Nov 15 07:07:04 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 15 Nov 2019 07:07:04 GMT Subject: RFR: 8234150: Address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 18:49:18 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 09:33:39 GMT, Ajit Ghaisas wrote: > >> This PR is to address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest. >> >> strategy is as follows - >> >> 1) Enable tests marked with @Ignore by removing that tag >> 2) Run the test >> 3) If test Passes - remove the @Ignore tag >> 4) If test fails - if test is invalid - remove it, else fix the test >> 5) In case if the failure cannot be fixed, leave the test ignored (keep @Ignore tag) >> >> >> With these corrections - here are the results: >> >> Results BEFORE this FIX >> 1. ComboBoxTest -- tests:156, failures:0, ignored:4 >> 2. LabeledTest -- tests:93, failures:0, ignored:5 >> 3. HyperlinkTest -- tests:34, failures:0, ignored:3 >> 4. TextInputControlTest -- tests:594, failures:0, ignored:12 >> >> Results AFTER this FIX >> 1. ComboBoxTest -- tests:156, failures:0, ignored:2 >> 2. LabeledTest -- tests:93, failures:0, ignored:3 >> 3. HyperlinkTest -- tests:31, failures:0, ignored:0 >> 4. TextInputControlTest -- tests:585, failures:0, ignored:0 >> >> ---------------- >> >> Commits: >> - 6709837b: Fix-Remove-Keep @Ignore tests >> >> Changes: https://git.openjdk.java.net/jfx/pull/36/files >> Webrev: https://webrevs.openjdk.java.net/jfx/36/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234150 >> Stats: 63 lines in 4 files changed: 0 ins; 57 del; 6 mod >> Patch: https://git.openjdk.java.net/jfx/pull/36.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/36/head:pull/36 > > It looks OK to me. Have you run this on all three platforms? Yes. Tests are consistent on all platforms. Total controls tests results on all platforms with this fix are - Tests : 7339 Failures : 0 Ignored : 215 PR: https://git.openjdk.java.net/jfx/pull/36 From aghaisas at openjdk.org Fri Nov 15 09:14:04 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 15 Nov 2019 09:14:04 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: > On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > >> **Issue :** >> https://bugs.openjdk.java.net/browse/JDK-8193445 >> >> **Background :** >> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >> >> **Description :** >> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >> For ease of review, I have made two separate commits - >> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >> >> **Root Cause :** >> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >> >> **Fix :** >> Fixed the identified root cause. See commit 2. >> >> **Testing :** >> 1. All passing unit tests continue to pass >> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >> 3. System test JDK8183100Test continues to pass >> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >> >> In addition, testing by community with specific CSS performance / functionality will be helpful. >> >> ---------------- >> >> Commits: >> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >> - d964675e: Reintroduce JDK-8151756 CSS performance fix >> >> Changes: https://git.openjdk.java.net/jfx/pull/34/files >> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 > > While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). > > tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: > >> 25: >> 26: package test.robot.javafx.scene; >> 27: > > There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). > > tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: > >> 54: >> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >> 56: > > We have moved away from putting the bug ID in the test class name, so I recommend renaming it. > > tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: > >> 77: HBox hbox = new HBox(); >> 78: for (int i = 0; i < 300; i++) { >> 79: hbox = new HBox(new Text("y"), hbox); > > In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. > > tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: > >> 93: // It is good enough to catch the regression in performance, if any >> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >> 95: } > > If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. > I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. > > It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. > > The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): > > ``` > if (cssFlag == CssFlags.UPDATE) { > cssFlag = CssFlags.REAPPLY; > notifyParentsOfInvalidatedCSS(); > return; > } > ``` > > and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? > > Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. PR: https://git.openjdk.java.net/jfx/pull/34 From ajoseph at openjdk.org Fri Nov 15 09:43:14 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Fri, 15 Nov 2019 09:43:14 GMT Subject: RFR: 8234239: [TEST_BUG] Reenable few ignored web tests Message-ID: The following tests can be reenabled: CookieManager.testPutOverwriteExpired CookieManager.testPutPurgeDomainAfterExpiry CookieManager.testPutPurgeCookiesGlobally2 CookieManager.testPutPurgeCookiesGlobally3 CookieManager.testPutPurgeCookiesGloballyAfterExpiry CallbackTest.testCustomPopup CallbackTest.testDefaultPopup LeakTest.testGarbageCollectability LeakTest.testOleg MiscellaneousTest.testRT30835 ---------------- Commits: - f2f121d9: 8234239: Reenable few ignored web tests Changes: https://git.openjdk.java.net/jfx/pull/42/files Webrev: https://webrevs.openjdk.java.net/jfx/42/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 Stats: 20 lines in 4 files changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 PR: https://git.openjdk.java.net/jfx/pull/42 From ajoseph at openjdk.org Fri Nov 15 10:01:51 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Fri, 15 Nov 2019 10:01:51 GMT Subject: [Rev 01] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - ca460353: Remove ignore imports and update copyright Changes: - all: https://git.openjdk.java.net/jfx/pull/42/files - new: https://git.openjdk.java.net/jfx/pull/42/files/f2f121d9..ca460353 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/42/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 PR: https://git.openjdk.java.net/jfx/pull/42 From arapte at openjdk.org Fri Nov 15 10:33:16 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 15 Nov 2019 10:33:16 GMT Subject: [Rev 01] RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - e7856f6e: reenable some more tests and fix review comment Changes: - all: https://git.openjdk.java.net/jfx/pull/39/files - new: https://git.openjdk.java.net/jfx/pull/39/files/5df00884..e7856f6e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/39/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/39/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 Stats: 14 lines in 3 files changed: 6 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 PR: https://git.openjdk.java.net/jfx/pull/39 From arapte at openjdk.org Fri Nov 15 10:34:58 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 15 Nov 2019 10:34:58 GMT Subject: RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: References: Message-ID: <1R-CTU5Y3wA86s3Ho04qr6gNFqgfdujW6N5bTmwTVME=.4e91410a-5392-428e-924c-05a1f5e8af5d@github.com> On Thu, 14 Nov 2019 23:55:45 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 19:56:16 GMT, Ambarish Rapte wrote: > >> Following graphics unit tests can be re-enabled. >> >> 1. test.com.sun.javafx.scene.layout.region.BackgroundRepeatConverterTest.scenario2 >> RepeatStructConverter.convert() is an internal method and does not verify the parameters. Passing null value to this method results in NPE. >> >> 2. test.javafx.scene.layout.RegionCSSTest.borderImageWidth_auto >> test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_auto >> test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_2Percent_auto >> It is not certain if the value of auto for -fx-border-image-width is 1 or 2 by defaut. But the tests seem correct and they pass. >> >> 3. test.javafx.scene.Node_cssMethods_Test >> [JDK-8094155](https://bugs.openjdk.java.net/browse/JDK-8094155) is fixed and the tests can be re-enabled. >> >> ---------------- >> >> Commits: >> - 5df00884: Reenable few of the graphics unit tests >> >> Changes: https://git.openjdk.java.net/jfx/pull/39/files >> Webrev: https://webrevs.openjdk.java.net/jfx/39/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 >> Stats: 12 lines in 3 files changed: 0 ins; 7 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/39.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 > > Most of this looks OK, but there is one I had a question on. > > Have you run this on all platforms? > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java line 57: > >> 56: @Test(expected=NullPointerException.class) >> 57: public void scenario2() { >> 58: ParsedValue[][] values = new ParsedValueImpl[][] { > > This is at odds with the body of the test, since presumably, the `assertEquals` will never be called. > > An expect exception annotation is best used in the case where you do a single thing that is expected to generate that exception. Otherwise and unexpected exception could end up making the test look like it's passing. Hi Kevin, the test corrected now. Removed `(expected=NullPointerException.class)` and added try, catch block. PR: https://git.openjdk.java.net/jfx/pull/39 From arapte at openjdk.org Fri Nov 15 10:37:55 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 15 Nov 2019 10:37:55 GMT Subject: RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: <1R-CTU5Y3wA86s3Ho04qr6gNFqgfdujW6N5bTmwTVME=.4e91410a-5392-428e-924c-05a1f5e8af5d@github.com> References: <1R-CTU5Y3wA86s3Ho04qr6gNFqgfdujW6N5bTmwTVME=.4e91410a-5392-428e-924c-05a1f5e8af5d@github.com> Message-ID: On Fri, 15 Nov 2019 10:34:58 GMT, Ambarish Rapte wrote: > On Thu, 14 Nov 2019 23:55:45 GMT, Kevin Rushforth wrote: > >> On Thu, 14 Nov 2019 19:56:16 GMT, Ambarish Rapte wrote: >> >>> Following graphics unit tests can be re-enabled. >>> >>> 1. test.com.sun.javafx.scene.layout.region.BackgroundRepeatConverterTest.scenario2 >>> RepeatStructConverter.convert() is an internal method and does not verify the parameters. Passing null value to this method results in NPE. >>> >>> 2. test.javafx.scene.layout.RegionCSSTest.borderImageWidth_auto >>> test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_auto >>> test.javafx.scene.layout.RegionCSSTest.borderImageWidth_1_2Percent_auto >>> It is not certain if the value of auto for -fx-border-image-width is 1 or 2 by defaut. But the tests seem correct and they pass. >>> >>> 3. test.javafx.scene.Node_cssMethods_Test >>> [JDK-8094155](https://bugs.openjdk.java.net/browse/JDK-8094155) is fixed and the tests can be re-enabled. >>> >>> ---------------- >>> >>> Commits: >>> - 5df00884: Reenable few of the graphics unit tests >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/39/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/39/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 >>> Stats: 12 lines in 3 files changed: 0 ins; 7 del; 5 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/39.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 >> >> Most of this looks OK, but there is one I had a question on. >> >> Have you run this on all platforms? >> >> modules/javafx.graphics/src/test/java/test/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java line 57: >> >>> 56: @Test(expected=NullPointerException.class) >>> 57: public void scenario2() { >>> 58: ParsedValue[][] values = new ParsedValueImpl[][] { >> >> This is at odds with the body of the test, since presumably, the `assertEquals` will never be called. >> >> An expect exception annotation is best used in the case where you do a single thing that is expected to generate that exception. Otherwise and unexpected exception could end up making the test look like it's passing. > > Hi Kevin, the test corrected now. > Removed `(expected=NullPointerException.class)` and added try, catch block. > Have you run this on all platforms? Yes, The change is verified on platforms. and It shows same result. tests: 22988, fails: 0, ignored: 279 Also I have included few more tests to enable, please take a look. PR: https://git.openjdk.java.net/jfx/pull/39 From arapte at openjdk.org Fri Nov 15 10:54:19 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 15 Nov 2019 10:54:19 GMT Subject: [Integrated] RFR: 8234189: [TEST_BUG] Remove ignored and invalid graphics unit tests In-Reply-To: References: Message-ID: Changeset: 3d0cb496 Author: Ambarish Rapte Date: 2019-11-15 10:53:31 +0000 URL: https://git.openjdk.java.net/jfx/commit/3d0cb496 8234189: [TEST_BUG] Remove ignored and invalid graphics unit tests Reviewed-by: kcr ! modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageLoaderScalingTest.java - modules/javafx.graphics/src/test/java/test/javafx/scene/input/PasteboardTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/input/TouchEventTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundSizeTest.java From fastegal at openjdk.org Fri Nov 15 12:59:15 2019 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 15 Nov 2019 12:59:15 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: On Wed, 13 Nov 2019 11:26:54 GMT, Hadzic Samir wrote: > On Thu, 7 Nov 2019 12:07:55 GMT, Jeanette Winzenburg wrote: > >> On Fri, 1 Nov 2019 10:59:57 GMT, Hadzic Samir wrote: >> >>> On Tue, 29 Oct 2019 13:19:27 GMT, Hadzic Samir wrote: >>> >>>> On Wed, 9 Oct 2019 16:01:38 GMT, Kevin Rushforth wrote: >>>> >>>>> On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: >>>>> >>>>>> On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: >>>>>> >>>>>>> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >>>>>>> >>>>>>>> Allright, this is a fix for JDK-8207957 >>>>>>>> >>>>>>>> ---------------- >>>>>>>> >>>>>>>> Commits: >>>>>>>> - 969ebb51: Fixing TableColumnHeaderTest >>>>>>>> - 9d379619: Removing Tablecolumnbasehelper >>>>>>>> - 4fe020fc: Fix javadoc for TableColumnHeader >>>>>>>> - c422c80f: Minor modification and uni test added. >>>>>>>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>>>>>>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>>>>>>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>>>>>>> >>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>>>>>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>>>>>> >>>>>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >>>>>>> >>>>>>>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>>>>>>> 600: * {@code super()}) to provide their custom algorithm. >>>>>>>> 601: * >>>>>>> >>>>>>> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) >>>>>> >>>>>> Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. >>>>>> >>>>>> I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. >>>>> >>>>> A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. >>>> >>>> Do you think this looks good now @kleopatra @nlisker ? >>> >>> Yes I was waiting for the final 'go'. I will update it asap, thanks >>> >>> Le ven. 1 nov. 2019 ? 09:49, Jeanette Winzenburg >>> a ?crit : >>> >>>> *@kleopatra* commented on this pull request. >>>> ------------------------------ >>>> >>>> In >>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java >>>> : >>>> >>>> > + * Resizes this {@code TableColumnHeader}'s column to fit the width of its content. >>>> + * >>>> + * @implSpec The resulting column width for this implementation is the maximum of the preferred width of the header >>>> + * cell and the preferred width of the first {@code maxRow} cells. >>>> + *

>>>> + * Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their >>>> + * custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum >>>> + * width etc.). >>>> + * >>>> + * @param maxRows the number of rows considered when resizing. If -1 is given, all rows are considered. >>>> + * @since 14 >>>> >>>> looks good to me :) You would have to update the crs eventually, right? >>>> >>>> ? >>>> You are receiving this because you authored the thread. >>>> Reply to this email directly, view it on GitHub >>>> , >>>> or unsubscribe >>>> >>>> . >>>> >> >> As to the test, it's a bit ... confusing, will try to suggest some changes - take them with a grain of salt, though, because I'm still groping to find my path through the wilderness here :) > > I have changed the unit test according to @kleopatra review and also add two more unit test regarding the headerContent and maxRows. looks good to me - would approve if I could :) PR: https://git.openjdk.java.net/jfx/pull/6 From kcr at openjdk.org Fri Nov 15 13:05:20 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Nov 2019 13:05:20 GMT Subject: [Integrated] RFR: 8234174: Change IDEA VCS mapping to Git In-Reply-To: References: Message-ID: <94d985fc-c094-476a-8e9c-3691c81bf615@openjdk.org> Changeset: 927fc8a0 Author: Alexander Scherbatiy Committer: Kevin Rushforth Date: 2019-11-15 13:04:12 +0000 URL: https://git.openjdk.java.net/jfx/commit/927fc8a0 8234174: Change IDEA VCS mapping to Git Reviewed-by: kcr ! .idea/vcs.xml From fastegal at swingempire.de Fri Nov 15 13:09:44 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 15 Nov 2019 14:09:44 +0100 Subject: To write tests or not to write tests ... In-Reply-To: <1b03c98c-945b-01d9-6399-cda892413f5f@oracle.com> References: <20191108115458.Horde.MPxm0psLdtU0gprI8EEetA1@webmail.df.eu> <1b03c98c-945b-01d9-6399-cda892413f5f@oracle.com> Message-ID: <20191115140944.Horde.TqfCaNJ_5HNHqnLge6Nn0Q1@webmail.df.eu> Zitat von Kevin Rushforth : > In general, I would say it's OK to rely on existing tests for > trivial refactoring, that is a refactoring where it seems fairly > obvious that there are not going to be changes in behavior (even if > such tests may be inadequate). For less trivial refactoring, if > there are clearly missing tests, I would think they should be added > to ensure no unintended behavioral changes, although I wouldn't go > overboard. > reasonable middle ground :) > Bug fixes and new features are a different matter. In the specific > case you cite, there is new public API, so at the very least, > testing the new API is needed. I haven't (yet) looked closely enough > to know whether the refactoring is a possible source of concern that > would warrant additional tests. > in that specific case, I don't see much of a risk - and now there are tests for all aspects of the behavior as specified by the new api (as far as it can go, IMO, testing actual sizes in the context of column/cell/header is .. tricky to impossible) -- Jeanette > -- Kevin > > > On 11/8/2019 11:54 AM, Jeanette Winzenburg wrote: >> >> ... if changes are "just" a re-arrangement of code (like >> https://github.com/openjdk/jfx/pull/6 - 8207957: TableSkinUtils >> should not contain actual code implementation)? >> >> In an ideal world, there would be a safety-net of tests (they would >> have been written at the time the old code was pushed - wouldn't >> they ;). All we would need to do is run them to ensure that our >> re-arrangement doesn't break anything. >> >> In the real world and that particular pull request above, there are >> not tests (that I could find, maybe overlooked them). >> >> Now the question: is the contributor responsible for writing those >> missing tests? The two extremes are >> >> - yes, it's a good opportunity ;) And it is mandatory (probably?) >> for all public/protected api. A new protected method with >> specification was condensed and should be tested. >> - no, nothing changed, the tests were always missing and all still >> live ;) so doing nothing is just fine >> >> What's the procedure here? >> >> -- Jeanette >> From kcr at openjdk.org Fri Nov 15 13:15:26 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Nov 2019 13:15:26 GMT Subject: RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: <3Mb9Zmn4D5nAezLuuOj1QEIWdDdPvGn6YFXhsczbrzs=.9c9c7507-70e6-4237-9be5-3172c8a0a09b@github.com> Message-ID: <19KDZSI5wbqd9sJupAw4RSyl_sYpDs-iRFFaCkIpQ-s=.9fa0112e-9b4a-42d7-a3f7-7340e676c781@github.com> On Fri, 15 Nov 2019 12:59:15 GMT, Jeanette Winzenburg wrote: > On Wed, 13 Nov 2019 11:26:54 GMT, Hadzic Samir wrote: > >> On Thu, 7 Nov 2019 12:07:55 GMT, Jeanette Winzenburg wrote: >> >>> On Fri, 1 Nov 2019 10:59:57 GMT, Hadzic Samir wrote: >>> >>>> On Tue, 29 Oct 2019 13:19:27 GMT, Hadzic Samir wrote: >>>> >>>>> On Wed, 9 Oct 2019 16:01:38 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Wed, 9 Oct 2019 12:26:31 GMT, Hadzic Samir wrote: >>>>>> >>>>>>> On Mon, 7 Oct 2019 10:22:11 GMT, Jeanette Winzenburg wrote: >>>>>>> >>>>>>>> On Fri, 4 Oct 2019 06:13:48 GMT, Hadzic Samir wrote: >>>>>>>> >>>>>>>>> Allright, this is a fix for JDK-8207957 >>>>>>>>> >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>> Commits: >>>>>>>>> - 969ebb51: Fixing TableColumnHeaderTest >>>>>>>>> - 9d379619: Removing Tablecolumnbasehelper >>>>>>>>> - 4fe020fc: Fix javadoc for TableColumnHeader >>>>>>>>> - c422c80f: Minor modification and uni test added. >>>>>>>>> - b2bdfb5b: Change resizeColumn to protected without static in order to be able to override >>>>>>>>> - 3b9b7903: Second option for resizeColumnToFitContent in TableColumnHeader >>>>>>>>> - d91c56e5: First attempt to extract resizeColumnToFitContent >>>>>>>>> >>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/6/files >>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/6/webrev.00 >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 >>>>>>>>> Stats: 523 lines in 4 files changed: 330 ins; 187 del; 6 mod >>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/6.diff >>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 >>>>>>>> >>>>>>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 600: >>>>>>>> >>>>>>>>> 599: * expensive if the number of rows is large. Subclass can either call this method or override it (no need to call >>>>>>>>> 600: * {@code super()}) to provide their custom algorithm. >>>>>>>>> 601: * >>>>>>>> >>>>>>>> see https://github.com/javafxports/openjdk-jfx/pull/289#discussion_r245482213 - I think I made a suggestion (that probably needs some native speaker's fine tuning :) >>>>>>> >>>>>>> Allright @kleopatra , I have indeed removed the TableColumn argument. It is clearer now that we are resizing the TableColumn of the header. >>>>>>> >>>>>>> I have updated the description a bit but really I'm really not good at method description so I'm open to all suggestions.. >>>>>> >>>>>> A Draft CSR was filed here: [JDK-8215554](https://bugs.openjdk.java.net/browse/JDK-8215554). It will need to be updated once the API review is complete. >>>>> >>>>> Do you think this looks good now @kleopatra @nlisker ? >>>> >>>> Yes I was waiting for the final 'go'. I will update it asap, thanks >>>> >>>> Le ven. 1 nov. 2019 ? 09:49, Jeanette Winzenburg >>>> a ?crit : >>>> >>>>> *@kleopatra* commented on this pull request. >>>>> ------------------------------ >>>>> >>>>> In >>>>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java >>>>> : >>>>> >>>>> > + * Resizes this {@code TableColumnHeader}'s column to fit the width of its content. >>>>> + * >>>>> + * @implSpec The resulting column width for this implementation is the maximum of the preferred width of the header >>>>> + * cell and the preferred width of the first {@code maxRow} cells. >>>>> + *

>>>>> + * Subclasses can either use this method or override it (without the need to call {@code super()}) to provide their >>>>> + * custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum >>>>> + * width etc.). >>>>> + * >>>>> + * @param maxRows the number of rows considered when resizing. If -1 is given, all rows are considered. >>>>> + * @since 14 >>>>> >>>>> looks good to me :) You would have to update the crs eventually, right? >>>>> >>>>> ? >>>>> You are receiving this because you authored the thread. >>>>> Reply to this email directly, view it on GitHub >>>>> , >>>>> or unsubscribe >>>>> >>>>> . >>>>> >>> >>> As to the test, it's a bit ... confusing, will try to suggest some changes - take them with a grain of salt, though, because I'm still groping to find my path through the wilderness here :) >> >> I have changed the unit test according to @kleopatra review and also add two more unit test regarding the headerContent and maxRows. > > looks good to me - would approve if I could :) > looks good to me - would approve if I could :) You can add yourself as a reviewer, even though it wouldn't count as an approving review by someone with a "R"eviewer role in the project. PR: https://git.openjdk.java.net/jfx/pull/6 From fastegal at swingempire.de Fri Nov 15 13:30:36 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 15 Nov 2019 14:30:36 +0100 Subject: Refire event while it is delivered is evil - always?! In-Reply-To: <20191017135249.Horde.bOu2guvMYKcu01bJoH3xPQ7@webmail.df.eu> References: <20191017135249.Horde.bOu2guvMYKcu01bJoH3xPQ7@webmail.df.eu> Message-ID: <20191115143036.Horde.N4aMds-xvHLSkvuZmzfz5w1@webmail.df.eu> *muttering to myself .. Meanwhile, my understanding evolved a bit - there are actually two refiring scenarios, both wrecking the event dispatch sequence, the first more evil than the second 1. getParent.fireEvent(receivedKeyEvent) which leads to serious misbehaviour (as reported f.i. in https://bugs.openjdk.java.net/browse/JDK-8207759 ) - fix understood, implemented and waiting for review 2. child.fireEvent(receivedKeyEvent) which leads to misbehavior (as reported in https://bugs.openjdk.java.net/browse/JDK-8229924 ) - still don't know how to fix it: the child will never get a keyEvent "naturally" because it's never focusOwner. So the parent must deliver it somehow .. Currently experimenting with custom implementation of buildEventDispatchChain (append the editor's chain? or a custom dispatcher doing so?) More questions than answers ;) -- Jeanette Zitat von Jeanette Winzenburg : > While fixing https://bugs.openjdk.java.net/browse/JDK-8207759 it > turned out that the underlying reason for the bug was a broken event > dispatch sequence introduced by behavior.forwardToParent. Which is a > call to parent.fireEvent with the event that was received. This > builds a nested chain and delivers the event to all handlers in > that new chain - down and up again - _before_ the current chain is > completed. Consequently, the consuming singleton handler for the > same event is notified _after_ the scene-level handlers (in > particular the accelerators) have seen and handled it. > > Looks like it happens for any control (not only for a TextField as > in the referenced issue, nor only for controls with a > FakeFocusTextField which refire while processing keyEvents), as the > example below demonstrates. > > My current understanding of event dispatch is, that a chain has a > life-cycle consisting of separate (?) states: > > - building the chain from eventTargets > - delivering the event along the dispatchers in the chain > > There's a contract for dispatch sequence (like capturing/bubbling > phase, dispatch from specialized to super event types and other > rules). That can be guaranteed as long as chain building and event > delivering are separate phases, it seems to break down if they are > mixed (there are other issues with a similar/same underlying reason, > f.i. in all controls with a FakeFocusTextField). > > Now the questions: > > - is there any specification about not mixing the life-cycle states? > if so, where? > - or is there a way to safely re-fire an event at the moment of receiving it? > - or maybe I got it all wrong, if so please guide me :) > > -- Cheers, Jeanette > > > The example: > > public class NestedEventDispatchChain extends Application { > > > private KeyCode key = DIGIT1; > private Parent createContent() { > Button button = new Button("the evil button!"); > // re-firing handler > button.addEventHandler(KEY_PRESSED, e -> { > if (key == e.getCode()) { > System.out.println("before refire " + e); > button.getParent().fireEvent(e); > System.out.println("after refire " + e); > } > }); > > // consuming singleton handler > button.setOnKeyPressed(e -> { > if (key == e.getCode()) { > e.consume(); > System.out.println("consumed in singleton " + e.getCode()); > } > }); > BorderPane content = new BorderPane(button); > return content; > } > > @Override > public void start(Stage stage) throws Exception { > Scene scene = new Scene(createContent()); > // accelerator that shouldn't be triggered because singleton > handler consumed > > scene.getAccelerators().put(KeyCombination.keyCombination(key.getName()), () > -> { > System.out.println("accelerator triggered for " + key); > }); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From Rony.Flatscher at wu.ac.at Fri Nov 15 15:08:54 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Fri, 15 Nov 2019 16:08:54 +0100 Subject: Ad NashornScriptEngine (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com> Message-ID: <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at> On 14.11.2019 22:57, Kevin Rushforth wrote: > On 11/14/2019 10:12 AM, Rony G. Flatscher wrote: >> On 14.11.2019 16:34, Rony G. Flatscher wrote: >>> On 13.11.2019 19:50, Kevin Rushforth wrote: >>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: >> ... cut ... >>>>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all >>>>> opensource) for >>>>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a >>>>> script to >>>>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be >>>>> o.k.? >>>> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to >>>> use that for a regression test / unit test. >> If test units really seem to be important in this particular case, one possibility would be to >> create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow >> the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and >> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval() >> methods return the ScriptContext at invocation time in order to allow inspection of the Bindings. >> This way it would become also possible to write in addition test units that also check whether all >> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings. > > Something like that seems reasonable, and would avoid a dependence on Nashorn, which in addition > to having all the problems you mentioned, is deprecated for removal. > >> However, > > Did you have something more to add? No, sorry for that. Rewrote my e-mail and had sent it too early by mistake and without noticing. Will study all the procedures and create a testcase to be submitted at as per your advice (and will report back under this thread once submitted). The testcase would use an artificial ScriptEngine implementation that could be used for testunit testing as well. This might take a while due to other obligations that I will have to meet during the next few days. ---rony From kcr at openjdk.org Fri Nov 15 22:37:26 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Nov 2019 22:37:26 GMT Subject: [Approved] RFR: 8234150: Address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest In-Reply-To: References: Message-ID: <0G8x4iBLAGYJMYJxnBGkB0CUNkTiOIWb0LY8RXjif3E=.01637f46-dbb9-41b1-ad3c-d973e9833bf2@github.com> On Thu, 14 Nov 2019 09:33:39 GMT, Ajit Ghaisas wrote: > This PR is to address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest. > > strategy is as follows - > > 1) Enable tests marked with @Ignore by removing that tag > 2) Run the test > 3) If test Passes - remove the @Ignore tag > 4) If test fails - if test is invalid - remove it, else fix the test > 5) In case if the failure cannot be fixed, leave the test ignored (keep @Ignore tag) > > > With these corrections - here are the results: > > Results BEFORE this FIX > 1. ComboBoxTest -- tests:156, failures:0, ignored:4 > 2. LabeledTest -- tests:93, failures:0, ignored:5 > 3. HyperlinkTest -- tests:34, failures:0, ignored:3 > 4. TextInputControlTest -- tests:594, failures:0, ignored:12 > > Results AFTER this FIX > 1. ComboBoxTest -- tests:156, failures:0, ignored:2 > 2. LabeledTest -- tests:93, failures:0, ignored:3 > 3. HyperlinkTest -- tests:31, failures:0, ignored:0 > 4. TextInputControlTest -- tests:585, failures:0, ignored:0 > > ---------------- > > Commits: > - 6709837b: Fix-Remove-Keep @Ignore tests > > Changes: https://git.openjdk.java.net/jfx/pull/36/files > Webrev: https://webrevs.openjdk.java.net/jfx/36/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234150 > Stats: 63 lines in 4 files changed: 0 ins; 57 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/36.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/36/head:pull/36 Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/36 From kcr at openjdk.org Fri Nov 15 22:38:56 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Nov 2019 22:38:56 GMT Subject: [Approved] RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: References: Message-ID: On Fri, 15 Nov 2019 10:33:16 GMT, Ambarish Rapte wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - e7856f6e: reenable some more tests and fix review comment > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/39/files > - new: https://git.openjdk.java.net/jfx/pull/39/files/5df00884..e7856f6e > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/39/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/39/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 > Stats: 14 lines in 3 files changed: 6 ins; 3 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/39.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 Looks good. modules/javafx.graphics/src/test/java/test/javafx/css/Node_cssStyleMap_Test.java line 102: > 101: } > 102: > 103: @Ignore("JDK-8234241") Based on the description in JBS, I presume that [JDK-8234241](https://bugs.openjdk.java.net/browse/JDK-8234241) is a test bug? If so, can you label the new bug as such? ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/39 From kcr at openjdk.org Fri Nov 15 23:03:46 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Nov 2019 23:03:46 GMT Subject: [Rev 01] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: On Fri, 15 Nov 2019 10:01:51 GMT, Arun Joseph wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - ca460353: Remove ignore imports and update copyright > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/42/files > - new: https://git.openjdk.java.net/jfx/pull/42/files/f2f121d9..ca460353 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/42/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 > Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod > Patch: https://git.openjdk.java.net/jfx/pull/42.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 I added some questions and one requested change below. modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 82: > 81: } > 82: > 83: @Test public void testGarbageCollectability() throws InterruptedException { RT-26710, aka [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139), is still listed as open. Since these tests no longer hang, can you close [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139) as "Cannot reproduce"? modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 58: > 57: > 58: @Test public void testOleg() throws InterruptedException{ > 59: final String URL = new File("src/test/resources/test/html/guimark2-vector.html").toURI().toASCIIString(); This test takes 80 seconds (`16 * 5 * 1sec`) to run, which is too long for a simple unit test, when the entire rest of the test suite takes about 5 minutes. I recommend decreasing the duration of the key frame to 200 msec, which would allow the test to run in 16 seconds. modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java line 90: > 89: > 90: @Test public void testDefaultPopup() { > 91: clear(); This test, along with `testCustomPopup` is listed as unstable. Have you run it multiple times on different systems? ---------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/42 From github.com+1413266+jgneff at openjdk.org Sat Nov 16 00:32:31 2019 From: github.com+1413266+jgneff at openjdk.org (John Neffenger) Date: Sat, 16 Nov 2019 00:32:31 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> Message-ID: On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: > On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: > >> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >> >>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>> >>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>> >>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>> >>> ---------------- >>> >>> Commits: >>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >> >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: >> >>> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >>> 50: final String str = >>> 51: System.getProperty("monocle.debugcursor", ""); >> >> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. >> >> monocle.cursor.enabled >> monocle.debugcursor >> monocle.epd.bitsPerPixel >> monocle.epd.enableInversion >> monocle.epd.forceMonochrome >> monocle.epd.noWait >> monocle.epd.rotate >> monocle.epd.useDitheringY1 >> monocle.epd.useDitheringY4 >> monocle.epd.waveformMode >> monocle.epd.y8inverted >> monocle.input..flipXY >> monocle.input..maxX >> monocle.input..maxY >> monocle.input..minX >> monocle.input..minY >> monocle.input..touchFilters >> monocle.input.touchFilters >> monocle.input.touchRadius >> monocle.input.traceEvents >> monocle.input.traceEvents.verbose >> monocle.maliSignedStruct >> monocle.platform >> monocle.platform.traceConfig >> monocle.screen.fb >> monocle.stackSize >> >> I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. > > if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) On second thought, let's remove `monocle.debugcursor` and use a [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). The JavaFX loggers are available from [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). In retrospect, that's how I managed to avoid any new *debug* properties for Monocle EPD even though it's packed with debugging and trace messages. For examples, see the variable `logger` in [EPDFrameBuffer](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), where `logger.fine` is called for messages printed once per run, while `logger.finer` is called for messages printed once per rendered frame. PR: https://git.openjdk.java.net/jfx/pull/5 From github.com+1413266+jgneff at openjdk.org Sat Nov 16 00:32:30 2019 From: github.com+1413266+jgneff at openjdk.org (John Neffenger) Date: Sat, 16 Nov 2019 00:32:30 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: > Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. > > NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. > > A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. > > ---------------- > > Commits: > - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor > > Changes: https://git.openjdk.java.net/jfx/pull/5/files > Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/5.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 162: > 161: final String name = cursor == null ? null : cursor.getClass().getSimpleName(); > 162: System.err.println("Using native cursor: " + name); > 163: } Here you would call `PlatformLogger.fine` unconditionally, for example, instead of the conditional call to `System.err.println`. Changes requested by jgneff at github.com (no OpenJDK username). PR: https://git.openjdk.java.net/jfx/pull/5 From github.com+12861109+dellgreen at openjdk.org Sat Nov 16 06:09:35 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Sat, 16 Nov 2019 06:09:35 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> Message-ID: <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger wrote: > On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: > >> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: >> >>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>> >>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>> >>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>> >>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>> >>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: >>> >>>> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >>>> 50: final String str = >>>> 51: System.getProperty("monocle.debugcursor", ""); >>> >>> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. >>> >>> monocle.cursor.enabled >>> monocle.debugcursor >>> monocle.epd.bitsPerPixel >>> monocle.epd.enableInversion >>> monocle.epd.forceMonochrome >>> monocle.epd.noWait >>> monocle.epd.rotate >>> monocle.epd.useDitheringY1 >>> monocle.epd.useDitheringY4 >>> monocle.epd.waveformMode >>> monocle.epd.y8inverted >>> monocle.input..flipXY >>> monocle.input..maxX >>> monocle.input..maxY >>> monocle.input..minX >>> monocle.input..minY >>> monocle.input..touchFilters >>> monocle.input.touchFilters >>> monocle.input.touchRadius >>> monocle.input.traceEvents >>> monocle.input.traceEvents.verbose >>> monocle.maliSignedStruct >>> monocle.platform >>> monocle.platform.traceConfig >>> monocle.screen.fb >>> monocle.stackSize >>> >>> I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. >> >> if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) > > On second thought, let's remove `monocle.debugcursor` and use a [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). The JavaFX loggers are available from [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). In retrospect, that's how I managed to avoid any new *debug* properties for Monocle EPD even though it's packed with debugging and trace messages. For examples, see the variable `logger` in [EPDFrameBuffer](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), where `logger.fine` is called for messages printed once per run, while `logger.finer` is called for messages printed once per rendered frame. OK, that looks a better way to go. I'll sort out out an additional pull request when back in work Monday. Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? PR: https://git.openjdk.java.net/jfx/pull/5 From ebresie at gmail.com Sat Nov 16 13:52:16 2019 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 16 Nov 2019 07:52:16 -0600 Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> Message-ID: First time poster so forgive my inexperience...not really anything against the specific changes just seeking insight... (1) Notice some of these packages are still in com/sun/glass namespace. Is this still valid or at some point should this transition to a more open jfx equivalent or has that part still not fully been considered yet? (2) General practices...When should a property be a system environment (1) in system specific way - Windows environment variable, UNIX shell based property user or global, (2) app specific properties - internal as a resource or META-INF type or external to a given jar, (3) application specific in a give jfx component or class specific properties, or some css type properties, etc.), (4) command line type parameter passed in, etc? And that said which type would the properties discussed here for in? I ask because curious when and where these are needing to be setup as well (I.e when installing the app set the system environment variable once, delivered with a property set, run with defaults and later customized in case by case basis, etc.) Eric Bresie ebresie at gmail.com On Sat, Nov 16, 2019 at 12:14 AM Dell Green wrote: > On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger 1413266+jgneff at openjdk.org> wrote: > > > On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green 12861109+dellgreen at openjdk.org> wrote: > > > >> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger 1413266+jgneff at openjdk.org> wrote: > >> > >>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green < > 12861109+dellgreen at users.noreply.github.com> wrote: > >>> > >>>> Often on embedded systems a cursor is not a valid input modality. On > some of these systems, when the javafx toolkit initialises the native > hardware cursor, it produces artefacts which can be seen on screen (in the > framebuffer for example). This change adds a system property > "monocle.cursor.enabled" that can disable the creation of a native cursor > in each of the Monocle NativePlatform implementations in favour of a > NullCursor which is a no-op implementation of the NativeCursor abstract > class that all native cursors have to implement. > >>>> > >>>> NullCursor class already existed and was being returned for some > implementations like AndroidPlatform and HeadlessPlatform. This change > builds upon that and conditionally returns NullCursor for all platforms. > >>>> > >>>> A system property "monocle.debugcursor" has also been added to turn > on logging of which NativeCursor has been selected when the toolkit > initialises. > >>>> > >>>> ---------------- > >>>> > >>>> Commits: > >>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor > >>>> > >>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files > >>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 > >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > >>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod > >>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff > >>>> Fetch: git fetch https://git.openjdk.java.net/jfx > pull/5/head:pull/5 > >>> > >>> > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java > line 50: > >>> > >>>> 49: AccessController.doPrivileged((PrivilegedAction) > () -> { > >>>> 50: final String str = > >>>> 51: System.getProperty("monocle.debugcursor", ""); > >>> > >>> Just a nit, but why `monocle.debugcursor` rather than > `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? > Below is the full list, for comparison, including the two added by this > pull request. > >>> > >>> monocle.cursor.enabled > >>> monocle.debugcursor > >>> monocle.epd.bitsPerPixel > >>> monocle.epd.enableInversion > >>> monocle.epd.forceMonochrome > >>> monocle.epd.noWait > >>> monocle.epd.rotate > >>> monocle.epd.useDitheringY1 > >>> monocle.epd.useDitheringY4 > >>> monocle.epd.waveformMode > >>> monocle.epd.y8inverted > >>> monocle.input..flipXY > >>> monocle.input..maxX > >>> monocle.input..maxY > >>> monocle.input..minX > >>> monocle.input..minY > >>> monocle.input..touchFilters > >>> monocle.input.touchFilters > >>> monocle.input.touchRadius > >>> monocle.input.traceEvents > >>> monocle.input.traceEvents.verbose > >>> monocle.maliSignedStruct > >>> monocle.platform > >>> monocle.platform.traceConfig > >>> monocle.screen.fb > >>> monocle.stackSize > >>> > >>> I'm nervous about our hidden API of system properties, and I'm as > guilty as anyone with the nine properties I added for Monocle EPD. I think > it might be okay as long as the code gets the property values only during > class initialization. That should restrict their use to startup scripts and > keep them out of application code trying to modify them *on-the-fly* at run > time. > >> > >> if i recall i originally started with the format you recommend as it > made more sense, and when looking for other debug logging across the javafx > stack I picked up on somewhat of a loose existing convention so changed to > match it. I guess it can be whatever everyone agrees upon. :) > > > > On second thought, let's remove `monocle.debugcursor` and use a > [PlatformLogger]( > https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). > The JavaFX loggers are available from [Logging]( > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). > In retrospect, that's how I managed to avoid any new *debug* properties for > Monocle EPD even though it's packed with debugging and trace messages. For > examples, see the variable `logger` in [EPDFrameBuffer]( > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), > where `logger.fine` is called for messages printed once per run, while > `logger.finer` is called for messages printed once per rendered frame. > > OK, that looks a better way to go. I'll sort out out an additional pull > request when back in work Monday. Off the top of your head can you remember > the syntax to change the logger level from command line when starting the > JVM? > > PR: https://git.openjdk.java.net/jfx/pull/5 > -- Eric Bresie ebresie at gmail.com From arapte at openjdk.org Sat Nov 16 16:02:17 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Sat, 16 Nov 2019 16:02:17 GMT Subject: [Approved] RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: References: Message-ID: <9QhO6lA3GeNywiSU_qa3xbBsISqzubXUGxTSul774IE=.35f08295-7b16-407f-bab8-f2dd02ed41ed@github.com> On Fri, 15 Nov 2019 22:38:56 GMT, Kevin Rushforth wrote: > On Fri, 15 Nov 2019 10:33:16 GMT, Ambarish Rapte wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - e7856f6e: reenable some more tests and fix review comment >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/39/files >> - new: https://git.openjdk.java.net/jfx/pull/39/files/5df00884..e7856f6e >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/39/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/39/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234194 >> Stats: 14 lines in 3 files changed: 6 ins; 3 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/39.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/39/head:pull/39 > > Looks good. > > modules/javafx.graphics/src/test/java/test/javafx/css/Node_cssStyleMap_Test.java line 102: > >> 101: } >> 102: >> 103: @Ignore("JDK-8234241") > > Based on the description in JBS, I presume that [JDK-8234241](https://bugs.openjdk.java.net/browse/JDK-8234241) is a test bug? If so, can you label the new bug as such? > > ---------------- > > Approved by kcr (Lead). Hi Kevin, I have updated the JBS. PR: https://git.openjdk.java.net/jfx/pull/39 From arapte at openjdk.org Sat Nov 16 16:08:20 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Sat, 16 Nov 2019 16:08:20 GMT Subject: [Integrated] RFR: 8234194: [TEST_BUG] Reenable few graphics unit tests In-Reply-To: References: Message-ID: <18c5a2e6-1bac-491f-9275-4ace2f6168f8@openjdk.org> Changeset: 4f496d41 Author: Ambarish Rapte Date: 2019-11-16 16:07:10 +0000 URL: https://git.openjdk.java.net/jfx/commit/4f496d41 8234194: [TEST_BUG] Reenable few graphics unit tests Reviewed-by: kcr ! modules/javafx.graphics/src/test/java/test/com/sun/javafx/scene/layout/region/BackgroundRepeatConverterTest.java ! modules/javafx.graphics/src/test/java/test/com/sun/scenario/animation/shared/TimelineClipCoreTest.java ! modules/javafx.graphics/src/test/java/test/javafx/css/Node_cssStyleMap_Test.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/Node_cssMethods_Test.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionCSSTest.java From github.com+1413266+jgneff at openjdk.org Sat Nov 16 17:51:56 2019 From: github.com+1413266+jgneff at openjdk.org (John Neffenger) Date: Sat, 16 Nov 2019 17:51:56 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> Message-ID: On Sat, 16 Nov 2019 06:09:35 GMT, Dell Green wrote: > On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger wrote: > >> On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: >> >>> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: >>> >>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>> >>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>> >>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>> >>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>> >>>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: >>>> >>>>> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >>>>> 50: final String str = >>>>> 51: System.getProperty("monocle.debugcursor", ""); >>>> >>>> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. >>>> >>>> monocle.cursor.enabled >>>> monocle.debugcursor >>>> monocle.epd.bitsPerPixel >>>> monocle.epd.enableInversion >>>> monocle.epd.forceMonochrome >>>> monocle.epd.noWait >>>> monocle.epd.rotate >>>> monocle.epd.useDitheringY1 >>>> monocle.epd.useDitheringY4 >>>> monocle.epd.waveformMode >>>> monocle.epd.y8inverted >>>> monocle.input..flipXY >>>> monocle.input..maxX >>>> monocle.input..maxY >>>> monocle.input..minX >>>> monocle.input..minY >>>> monocle.input..touchFilters >>>> monocle.input.touchFilters >>>> monocle.input.touchRadius >>>> monocle.input.traceEvents >>>> monocle.input.traceEvents.verbose >>>> monocle.maliSignedStruct >>>> monocle.platform >>>> monocle.platform.traceConfig >>>> monocle.screen.fb >>>> monocle.stackSize >>>> >>>> I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. >>> >>> if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) >> >> On second thought, let's remove `monocle.debugcursor` and use a [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). The JavaFX loggers are available from [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). In retrospect, that's how I managed to avoid any new *debug* properties for Monocle EPD even though it's packed with debugging and trace messages. For examples, see the variable `logger` in [EPDFrameBuffer](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), where `logger.fine` is called for messages printed once per run, while `logger.finer` is called for messages printed once per rendered frame. > > OK, that looks a better way to go. I'll sort out out an additional pull request when back in work Monday. Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? > Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? Here's how I use it. My Bash run script is **bin/run.sh**: #!/bin/bash # Runs the EPD JavaFX Animator program JAVA_HOME=$HOME/opt/jdk-13.0.1+9 JAVAFX_LIB=$HOME/lib/armv6hf-sdk/lib app_dir=$HOME/src/epd-javafx app_jar=$app_dir/dist/epd-javafx.jar logging=$app_dir/conf/logging.properties $JAVA_HOME/bin/java -Djava.util.logging.config.file=$logging \ --add-modules=javafx.graphics --module-path=$JAVAFX_LIB \ -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ -Dmonocle.epd.waveformMode=4 -jar $app_jar $@ The logging properties are defined in **conf/logging.properties**: Properties # Global properties handlers = java.util.logging.ConsoleHandler .level = INFO # Handler specific properties java.util.logging.ConsoleHandler.level = ALL java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter java.util.logging.SimpleFormatter.format=%4$s: %5$s%n # Facility specific properties javafx.level = FINE The output looks like the following: $ sudo bin/run.sh --pattern=3 --loops=0 FINE: EPD system properties: {monocle.epd.waveformMode=4} FINE: Frame buffer geometry: 800 600 800 640 32 FINE: Frame buffer rgba: 8/16,8/8,8/0,8/24 FINE: Frame buffer grayscale: 0 FINE: Mapping frame buffer: 1,920,000 bytes Frame rate: 80 frames in 11.93 s = 6.70 fps (149 ms/frame) Frame rate: 80 frames in 9.97 s = 8.03 fps (125 ms/frame) Frame rate: 80 frames in 9.96 s = 8.03 fps (125 ms/frame) You can just add a new commit to this pull request branch. (I think that's what you meant, but just in case.) The commits get *squashed* into a single commit when they are integrated into the target branch. PR: https://git.openjdk.java.net/jfx/pull/5 From github.com+12861109+dellgreen at openjdk.org Sun Nov 17 10:04:36 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Sun, 17 Nov 2019 10:04:36 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> Message-ID: On Sat, 16 Nov 2019 17:51:56 GMT, John Neffenger wrote: > On Sat, 16 Nov 2019 06:09:35 GMT, Dell Green wrote: > >> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger wrote: >> >>> On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: >>> >>>> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: >>>> >>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>> >>>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>>> >>>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>>> >>>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>>> >>>>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: >>>>> >>>>>> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >>>>>> 50: final String str = >>>>>> 51: System.getProperty("monocle.debugcursor", ""); >>>>> >>>>> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. >>>>> >>>>> monocle.cursor.enabled >>>>> monocle.debugcursor >>>>> monocle.epd.bitsPerPixel >>>>> monocle.epd.enableInversion >>>>> monocle.epd.forceMonochrome >>>>> monocle.epd.noWait >>>>> monocle.epd.rotate >>>>> monocle.epd.useDitheringY1 >>>>> monocle.epd.useDitheringY4 >>>>> monocle.epd.waveformMode >>>>> monocle.epd.y8inverted >>>>> monocle.input..flipXY >>>>> monocle.input..maxX >>>>> monocle.input..maxY >>>>> monocle.input..minX >>>>> monocle.input..minY >>>>> monocle.input..touchFilters >>>>> monocle.input.touchFilters >>>>> monocle.input.touchRadius >>>>> monocle.input.traceEvents >>>>> monocle.input.traceEvents.verbose >>>>> monocle.maliSignedStruct >>>>> monocle.platform >>>>> monocle.platform.traceConfig >>>>> monocle.screen.fb >>>>> monocle.stackSize >>>>> >>>>> I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. >>>> >>>> if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) >>> >>> On second thought, let's remove `monocle.debugcursor` and use a [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). The JavaFX loggers are available from [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). In retrospect, that's how I managed to avoid any new *debug* properties for Monocle EPD even though it's packed with debugging and trace messages. For examples, see the variable `logger` in [EPDFrameBuffer](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), where `logger.fine` is called for messages printed once per run, while `logger.finer` is called for messages printed once per rendered frame. >> >> OK, that looks a better way to go. I'll sort out out an additional pull request when back in work Monday. Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? > >> Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? > > Here's how I use it. My Bash run script is **bin/run.sh**: > > #!/bin/bash > # Runs the EPD JavaFX Animator program > JAVA_HOME=$HOME/opt/jdk-13.0.1+9 > JAVAFX_LIB=$HOME/lib/armv6hf-sdk/lib > > app_dir=$HOME/src/epd-javafx > app_jar=$app_dir/dist/epd-javafx.jar > logging=$app_dir/conf/logging.properties > > $JAVA_HOME/bin/java -Djava.util.logging.config.file=$logging \ > --add-modules=javafx.graphics --module-path=$JAVAFX_LIB \ > -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ > -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ > -Dmonocle.epd.waveformMode=4 -jar $app_jar $@ > > The logging properties are defined in **conf/logging.properties**: > > Properties > # Global properties > handlers = java.util.logging.ConsoleHandler > .level = INFO > > # Handler specific properties > java.util.logging.ConsoleHandler.level = ALL > java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter > java.util.logging.SimpleFormatter.format=%4$s: %5$s%n > > # Facility specific properties > javafx.level = FINE > > The output looks like the following: > > $ sudo bin/run.sh --pattern=3 --loops=0 > FINE: EPD system properties: {monocle.epd.waveformMode=4} > FINE: Frame buffer geometry: 800 600 800 640 32 > FINE: Frame buffer rgba: 8/16,8/8,8/0,8/24 > FINE: Frame buffer grayscale: 0 > FINE: Mapping frame buffer: 1,920,000 bytes > Frame rate: 80 frames in 11.93 s = 6.70 fps (149 ms/frame) > Frame rate: 80 frames in 9.97 s = 8.03 fps (125 ms/frame) > Frame rate: 80 frames in 9.96 s = 8.03 fps (125 ms/frame) > > You can just add a new commit to this pull request branch. (I think that's what you meant, but just in case.) The commits get *squashed* into a single commit when they are integrated into the target branch. cool thanks, apologies i meant commit. :) PR: https://git.openjdk.java.net/jfx/pull/5 From ajoseph at openjdk.org Sun Nov 17 12:08:44 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Sun, 17 Nov 2019 12:08:44 GMT Subject: [Rev 02] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 8c2b988d: Modified LeakTest.testOleg Changes: - all: https://git.openjdk.java.net/jfx/pull/42/files - new: https://git.openjdk.java.net/jfx/pull/42/files/ca460353..8c2b988d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/42/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.01-02 Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 PR: https://git.openjdk.java.net/jfx/pull/42 From ajoseph at openjdk.org Sun Nov 17 12:09:46 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Sun, 17 Nov 2019 12:09:46 GMT Subject: [Rev 01] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: On Fri, 15 Nov 2019 23:03:46 GMT, Kevin Rushforth wrote: > On Fri, 15 Nov 2019 10:01:51 GMT, Arun Joseph wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - ca460353: Remove ignore imports and update copyright >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/42/files >> - new: https://git.openjdk.java.net/jfx/pull/42/files/f2f121d9..ca460353 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/42/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 >> Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/42.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 > > I added some questions and one requested change below. > > modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 82: > >> 81: } >> 82: >> 83: @Test public void testGarbageCollectability() throws InterruptedException { > > RT-26710, aka [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139), is still listed as open. Since these tests no longer hang, can you close [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139) as "Cannot reproduce"? > > modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 58: > >> 57: >> 58: @Test public void testOleg() throws InterruptedException{ >> 59: final String URL = new File("src/test/resources/test/html/guimark2-vector.html").toURI().toASCIIString(); > > This test takes 80 seconds (`16 * 5 * 1sec`) to run, which is too long for a simple unit test, when the entire rest of the test suite takes about 5 minutes. I recommend decreasing the duration of the key frame to 200 msec, which would allow the test to run in 16 seconds. > > modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java line 90: > >> 89: >> 90: @Test public void testDefaultPopup() { >> 91: clear(); > > This test, along with `testCustomPopup` is listed as unstable. Have you run it multiple times on different systems? > > ---------------- > > Changes requested by kcr (Lead). Yes, I've run the test multiple times in all 3 platforms and it's passing everytime. PR: https://git.openjdk.java.net/jfx/pull/42 From arapte at openjdk.org Sun Nov 17 16:41:27 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Sun, 17 Nov 2019 16:41:27 GMT Subject: RFR: 8234303: [TEST_BUG] Correct ignore tag in graphics unit tests Message-ID: This is a simple fix to correct all the ignored tag in graphics unit tests. Corrections are: 1. Each ignored test must be associated with a bug. There are new bugs reported for all the tests which are missing a bug. 2. Replace @org.junit.Ignore with @Ignore. 3. Remove unused import statement. Test count is same before and after this change on all three platforms. tests: 22982, failures: 0, ignored: 273 ---------------- Commits: - 90b132f5: 8234303: [TEST_BUG] Correct ignore tag in graphics unit tests Changes: https://git.openjdk.java.net/jfx/pull/44/files Webrev: https://webrevs.openjdk.java.net/jfx/44/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234303 Stats: 114 lines in 14 files changed: 15 ins; 4 del; 95 mod Patch: https://git.openjdk.java.net/jfx/pull/44.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/44/head:pull/44 PR: https://git.openjdk.java.net/jfx/pull/44 From aghaisas at openjdk.org Sun Nov 17 17:30:20 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Sun, 17 Nov 2019 17:30:20 GMT Subject: [Integrated] RFR: 8234150: Address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest In-Reply-To: References: Message-ID: <159b8e54-c7b0-4776-a46a-bece8e7f1781@openjdk.org> Changeset: e37cb370 Author: Ajit Ghaisas Date: 2019-11-17 17:29:26 +0000 URL: https://git.openjdk.java.net/jfx/commit/e37cb370 8234150: Address ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and TextInputControlTest Reviewed-by: kcr ! modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/HyperlinkTest.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTest.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java From arapte at openjdk.org Mon Nov 18 12:14:42 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 18 Nov 2019 12:14:42 GMT Subject: [Approved] RFR: 8232063: Upgrade gradle to version 6.0 In-Reply-To: References: Message-ID: <-laQwTloYe8etP2y_IT3D8FvewvotYAtvreeYUOM0nw=.556a4032-a438-473c-8c51-81cd1ae0d1b1@github.com> On Mon, 11 Nov 2019 15:22:48 GMT, Kevin Rushforth wrote: > This PR upgrades the version of gradle used to build JavaFX to 6.0. In addition to keeping up to date, this will allow us to subsequently upgrade the boot JDK to JDK 13. > > This change does the following: > > 1. Use ivy `patternLayout ...` instead of `layout "pattern" ...` and specify no metadata for ivy repositories. This was split out of [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754), PR #9, because the replacement API is documented as unstable in gradle 5.x (although it works fine) and isn't needed until we actually upgrade to 6.0. > > 2. Bump the gradle version used by the build from 5.3 to 6.0. > > Note that this does not change the minimum required version of gradle, which remains at 5.3. > > I have compared the artifacts produced before and after this change and there are no differences. > > ---------------- > > Commits: > - 5b224e5d: 8232063: Upgrade gradle to version 6.0 > > Changes: https://git.openjdk.java.net/jfx/pull/33/files > Webrev: https://webrevs.openjdk.java.net/jfx/33/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232063 > Stats: 24 lines in 5 files changed: 15 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/33.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/33/head:pull/33 Change looks good to me. I also verified that the build artifacts are same before and after this change, and gradle 5.3 works as it used to. ---------------- Approved by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/33 From kcr at openjdk.org Mon Nov 18 13:24:33 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 13:24:33 GMT Subject: [Approved] RFR: 8234303: [TEST_BUG] Correct ignore tag in graphics unit tests In-Reply-To: References: Message-ID: On Sun, 17 Nov 2019 16:41:27 GMT, Ambarish Rapte wrote: > This is a simple fix to correct all the ignored tag in graphics unit tests. > > Corrections are: > 1. Each ignored test must be associated with a bug. There are new bugs reported for all the tests which are missing a bug. > 2. Replace @org.junit.Ignore with @Ignore. > 3. Remove unused import statement. > > Test count is same before and after this change on all three platforms. > tests: 22982, failures: 0, ignored: 273 > > ---------------- > > Commits: > - 90b132f5: 8234303: [TEST_BUG] Correct ignore tag in graphics unit tests > > Changes: https://git.openjdk.java.net/jfx/pull/44/files > Webrev: https://webrevs.openjdk.java.net/jfx/44/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234303 > Stats: 114 lines in 14 files changed: 15 ins; 4 del; 95 mod > Patch: https://git.openjdk.java.net/jfx/pull/44.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/44/head:pull/44 Looks good. A single reviewer is sufficient for this. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/44 From ajoseph at openjdk.org Mon Nov 18 13:29:32 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Mon, 18 Nov 2019 13:29:32 GMT Subject: RFR: 8234056: Upgrade to libxslt 1.1.34 Message-ID: We need to update the version of libxslt to the latest version, 1.1.34. ---------------- Commits: - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34 Changes: https://git.openjdk.java.net/jfx/pull/45/files Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234056 Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod Patch: https://git.openjdk.java.net/jfx/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45 PR: https://git.openjdk.java.net/jfx/pull/45 From github.com+12861109+dellgreen at openjdk.org Mon Nov 18 14:04:25 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Mon, 18 Nov 2019 14:04:25 GMT Subject: [Rev 01] RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 1f6e282d: changed from system propert debug logging to javafx platform logger Changes: - all: https://git.openjdk.java.net/jfx/pull/5/files - new: https://git.openjdk.java.net/jfx/pull/5/files/cfbbc7dd..1f6e282d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/5/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/5/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 Stats: 14 lines in 1 file changed: 5 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 PR: https://git.openjdk.java.net/jfx/pull/5 From github.com+12861109+dellgreen at openjdk.org Mon Nov 18 14:07:23 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Mon, 18 Nov 2019 14:07:23 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> Message-ID: On Sun, 17 Nov 2019 10:04:36 GMT, Dell Green wrote: > On Sat, 16 Nov 2019 17:51:56 GMT, John Neffenger wrote: > >> On Sat, 16 Nov 2019 06:09:35 GMT, Dell Green wrote: >> >>> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger wrote: >>> >>>> On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: >>>> >>>>> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: >>>>> >>>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>> >>>>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>>>> >>>>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>>>> >>>>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>>>> >>>>>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: >>>>>> >>>>>>> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >>>>>>> 50: final String str = >>>>>>> 51: System.getProperty("monocle.debugcursor", ""); >>>>>> >>>>>> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. >>>>>> >>>>>> monocle.cursor.enabled >>>>>> monocle.debugcursor >>>>>> monocle.epd.bitsPerPixel >>>>>> monocle.epd.enableInversion >>>>>> monocle.epd.forceMonochrome >>>>>> monocle.epd.noWait >>>>>> monocle.epd.rotate >>>>>> monocle.epd.useDitheringY1 >>>>>> monocle.epd.useDitheringY4 >>>>>> monocle.epd.waveformMode >>>>>> monocle.epd.y8inverted >>>>>> monocle.input..flipXY >>>>>> monocle.input..maxX >>>>>> monocle.input..maxY >>>>>> monocle.input..minX >>>>>> monocle.input..minY >>>>>> monocle.input..touchFilters >>>>>> monocle.input.touchFilters >>>>>> monocle.input.touchRadius >>>>>> monocle.input.traceEvents >>>>>> monocle.input.traceEvents.verbose >>>>>> monocle.maliSignedStruct >>>>>> monocle.platform >>>>>> monocle.platform.traceConfig >>>>>> monocle.screen.fb >>>>>> monocle.stackSize >>>>>> >>>>>> I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. >>>>> >>>>> if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) >>>> >>>> On second thought, let's remove `monocle.debugcursor` and use a [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). The JavaFX loggers are available from [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). In retrospect, that's how I managed to avoid any new *debug* properties for Monocle EPD even though it's packed with debugging and trace messages. For examples, see the variable `logger` in [EPDFrameBuffer](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), where `logger.fine` is called for messages printed once per run, while `logger.finer` is called for messages printed once per rendered frame. >>> >>> OK, that looks a better way to go. I'll sort out out an additional pull request when back in work Monday. Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? >> >>> Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? >> >> Here's how I use it. My Bash run script is **bin/run.sh**: >> >> #!/bin/bash >> # Runs the EPD JavaFX Animator program >> JAVA_HOME=$HOME/opt/jdk-13.0.1+9 >> JAVAFX_LIB=$HOME/lib/armv6hf-sdk/lib >> >> app_dir=$HOME/src/epd-javafx >> app_jar=$app_dir/dist/epd-javafx.jar >> logging=$app_dir/conf/logging.properties >> >> $JAVA_HOME/bin/java -Djava.util.logging.config.file=$logging \ >> --add-modules=javafx.graphics --module-path=$JAVAFX_LIB \ >> -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ >> -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ >> -Dmonocle.epd.waveformMode=4 -jar $app_jar $@ >> >> The logging properties are defined in **conf/logging.properties**: >> >> Properties >> # Global properties >> handlers = java.util.logging.ConsoleHandler >> .level = INFO >> >> # Handler specific properties >> java.util.logging.ConsoleHandler.level = ALL >> java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter >> java.util.logging.SimpleFormatter.format=%4$s: %5$s%n >> >> # Facility specific properties >> javafx.level = FINE >> >> The output looks like the following: >> >> $ sudo bin/run.sh --pattern=3 --loops=0 >> FINE: EPD system properties: {monocle.epd.waveformMode=4} >> FINE: Frame buffer geometry: 800 600 800 640 32 >> FINE: Frame buffer rgba: 8/16,8/8,8/0,8/24 >> FINE: Frame buffer grayscale: 0 >> FINE: Mapping frame buffer: 1,920,000 bytes >> Frame rate: 80 frames in 11.93 s = 6.70 fps (149 ms/frame) >> Frame rate: 80 frames in 9.97 s = 8.03 fps (125 ms/frame) >> Frame rate: 80 frames in 9.96 s = 8.03 fps (125 ms/frame) >> >> You can just add a new commit to this pull request branch. (I think that's what you meant, but just in case.) The commits get *squashed* into a single commit when they are integrated into the target branch. > > cool thanks, apologies i meant commit. :) system property has now been changed to use platform logger as advised. has been tested successfully on my imx6 board. PR: https://git.openjdk.java.net/jfx/pull/5 From arapte at openjdk.org Mon Nov 18 16:05:24 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 18 Nov 2019 16:05:24 GMT Subject: [Integrated] RFR: 8234303: [TEST_BUG] Correct ignore tag in graphics unit tests In-Reply-To: References: Message-ID: Changeset: 3e0557a8 Author: Ambarish Rapte Date: 2019-11-18 16:04:06 +0000 URL: https://git.openjdk.java.net/jfx/commit/3e0557a8 8234303: [TEST_BUG] Correct ignore tag in graphics unit tests Reviewed-by: kcr ! modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/RenderRootTest.java ! modules/javafx.graphics/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java ! modules/javafx.graphics/src/test/java/test/javafx/concurrent/ServiceWithSecurityManagerTest.java ! modules/javafx.graphics/src/test/java/test/javafx/css/CssMetaDataTest.java ! modules/javafx.graphics/src/test/java/test/javafx/css/Node_cssStateTransition_Test.java ! modules/javafx.graphics/src/test/java/test/javafx/css/RuleTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/Node_effectiveOrientation_Css_Test.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/input/TouchEventTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundSizeTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionCSSTest.java ! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/ResizabilityTest.java ! modules/javafx.graphics/src/test/java/test/javafx/stage/PopupTest.java ! modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_parentWindow_Test.java From arapte at openjdk.org Mon Nov 18 16:34:43 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 18 Nov 2019 16:34:43 GMT Subject: [Approved] RFR: 8233420: Upgrade to gcc 8.3 on Linux In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 23:34:49 GMT, Kevin Rushforth wrote: > [JDK-8233420](https://bugs.openjdk.java.net/browse/JDK-8233420) > > This bumps the Linux compiler version to gcc 8.3 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - ab06dc58: 8233420: Upgrade to gcc 8.3 on Linux > > Changes: https://git.openjdk.java.net/jfx/pull/41/files > Webrev: https://webrevs.openjdk.java.net/jfx/41/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233420 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/41.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/41/head:pull/41 lgtm, verified build artifacts on Ubuntu18.04 LTS. ---------------- Approved by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/41 From arapte at openjdk.org Mon Nov 18 17:48:43 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 18 Nov 2019 17:48:43 GMT Subject: [Rev 01] RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Wed, 6 Nov 2019 14:28:20 GMT, Nir Lisker wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - a1cdb37b: Removed whitespaces in @Deprecated comments > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/30/files > - new: https://git.openjdk.java.net/jfx/pull/30/files/6d29e034..a1cdb37b > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/30/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/30/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 Please add @deprecated javadoc tag in the description for all constructors. modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 66: > 65: * This constructor was exposed erroneously and will be removed in the next version. Use {@link #create()} instead. > 66: */ > 67: @Deprecated(since="14", forRemoval=true) I think @deprecated javadoc tag should be added to all the descriptions. It will change the way Description gets shown in both, Constructor Summary and Constructor Detail section. ---------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/30 From arapte at openjdk.org Mon Nov 18 17:52:34 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 18 Nov 2019 17:52:34 GMT Subject: [Approved] RFR: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 23:31:34 GMT, Kevin Rushforth wrote: > [JDK-8233421](https://bugs.openjdk.java.net/browse/JDK-8233421) > > This bumps the windows compiler version to VS2017 version 15.9.16 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - aab19fa8: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 > > Changes: https://git.openjdk.java.net/jfx/pull/40/files > Webrev: https://webrevs.openjdk.java.net/jfx/40/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233421 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/40.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/40/head:pull/40 lgtm, verified that build artifacts are same before and after change on Windows 10, Visual Studio 2017. ---------------- Approved by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/40 From kcr at openjdk.org Mon Nov 18 17:58:44 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 17:58:44 GMT Subject: [Rev 01] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: On Fri, 15 Nov 2019 23:03:46 GMT, Kevin Rushforth wrote: > On Fri, 15 Nov 2019 10:01:51 GMT, Arun Joseph wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - ca460353: Remove ignore imports and update copyright >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/42/files >> - new: https://git.openjdk.java.net/jfx/pull/42/files/f2f121d9..ca460353 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/42/webrev.01 >> - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.00-01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 >> Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod >> Patch: https://git.openjdk.java.net/jfx/pull/42.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 > > I added some questions and one requested change below. > > modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 82: > >> 81: } >> 82: >> 83: @Test public void testGarbageCollectability() throws InterruptedException { > > RT-26710, aka [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139), is still listed as open. Since these tests no longer hang, can you close [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139) as "Cannot reproduce"? > > modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 58: > >> 57: >> 58: @Test public void testOleg() throws InterruptedException{ >> 59: final String URL = new File("src/test/resources/test/html/guimark2-vector.html").toURI().toASCIIString(); > > This test takes 80 seconds (`16 * 5 * 1sec`) to run, which is too long for a simple unit test, when the entire rest of the test suite takes about 5 minutes. I recommend decreasing the duration of the key frame to 200 msec, which would allow the test to run in 16 seconds. > > modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java line 90: > >> 89: >> 90: @Test public void testDefaultPopup() { >> 91: clear(); > > This test, along with `testCustomPopup` is listed as unstable. Have you run it multiple times on different systems? > > ---------------- > > Changes requested by kcr (Lead). OK. In that case, please close RT-34508, aka [JDK-8090082](https://bugs.openjdk.java.net/browse/JDK-8090082), as "Cannot reproduce". PR: https://git.openjdk.java.net/jfx/pull/42 From kcr at openjdk.org Mon Nov 18 17:58:43 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 17:58:43 GMT Subject: [Approved] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: On Sun, 17 Nov 2019 12:08:44 GMT, Arun Joseph wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 8c2b988d: Modified LeakTest.testOleg > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/42/files > - new: https://git.openjdk.java.net/jfx/pull/42/files/ca460353..8c2b988d > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/42/webrev.02 > - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.01-02 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8234239 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/42.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42 Looks good. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/42 From nlisker at openjdk.org Mon Nov 18 18:00:45 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 18 Nov 2019 18:00:45 GMT Subject: RFR: 8217472: Add attenuation for PointLight Message-ID: CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 ---------------- Commits: - a388fb92: Fixed whitespaces - 415927e6: Correction for indexes - 3450ffe9: Docs and year update - 4b63a01f: Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into 8217472_Add_attenuation_for_PointLight - 52e1ae1a: Separate range from attenuation - d39bceeb: GL pipeline - a590f09a: Initial push of 8217472 Changes: https://git.openjdk.java.net/jfx/pull/43/files Webrev: https://webrevs.openjdk.java.net/jfx/43/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8217472 Stats: 498 lines in 27 files changed: 385 ins; 13 del; 100 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.org Mon Nov 18 18:00:46 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 18 Nov 2019 18:00:46 GMT Subject: RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Mon, 18 Nov 2019 18:00:45 GMT, Nir Lisker wrote: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > ---------------- > > Commits: > - a388fb92: Fixed whitespaces > - 415927e6: Correction for indexes > - 3450ffe9: Docs and year update > - 4b63a01f: Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into 8217472_Add_attenuation_for_PointLight > - 52e1ae1a: Separate range from attenuation > - d39bceeb: GL pipeline > - a590f09a: Initial push of 8217472 > > Changes: https://git.openjdk.java.net/jfx/pull/43/files > Webrev: https://webrevs.openjdk.java.net/jfx/43/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8217472 > Stats: 498 lines in 27 files changed: 385 ins; 13 del; 100 mod > Patch: https://git.openjdk.java.net/jfx/pull/43.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 Tested D3D on Win 10 and GL on Ubuntu 18.04. There is still a bug (at least on Win) for some certain combinations of values as shown in this picture: ![image](https://user-images.githubusercontent.com/37422899/69054658-c2ad9180-0a14-11ea-809c-15c8ae485fd0.png) This sample program can be used to test the changes. Controls: mouse wheel zooms, RMB drag rotates, LMB pans. [sample.zip](https://github.com/openjdk/jfx/files/3858700/sample.zip) Kevin, Ambarish, You can start the review, especially the API. I will hunt that specific values bug this week. I'll need to know what kind of tests are needed in terms of functionality and performance. PR: https://git.openjdk.java.net/jfx/pull/43 From jvos at openjdk.org Mon Nov 18 18:08:42 2019 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Nov 2019 18:08:42 GMT Subject: [Approved] RFR: 8232063: Upgrade gradle to version 6.0 In-Reply-To: References: Message-ID: On Mon, 11 Nov 2019 15:22:48 GMT, Kevin Rushforth wrote: > This PR upgrades the version of gradle used to build JavaFX to 6.0. In addition to keeping up to date, this will allow us to subsequently upgrade the boot JDK to JDK 13. > > This change does the following: > > 1. Use ivy `patternLayout ...` instead of `layout "pattern" ...` and specify no metadata for ivy repositories. This was split out of [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754), PR #9, because the replacement API is documented as unstable in gradle 5.x (although it works fine) and isn't needed until we actually upgrade to 6.0. > > 2. Bump the gradle version used by the build from 5.3 to 6.0. > > Note that this does not change the minimum required version of gradle, which remains at 5.3. > > I have compared the artifacts produced before and after this change and there are no differences. > > ---------------- > > Commits: > - 5b224e5d: 8232063: Upgrade gradle to version 6.0 > > Changes: https://git.openjdk.java.net/jfx/pull/33/files > Webrev: https://webrevs.openjdk.java.net/jfx/33/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232063 > Stats: 24 lines in 5 files changed: 15 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/33.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/33/head:pull/33 build and sanity checks pass on win/mac/linux ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/33 From jvos at openjdk.org Mon Nov 18 18:09:33 2019 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Nov 2019 18:09:33 GMT Subject: [Approved] RFR: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 In-Reply-To: References: Message-ID: <2VAX-b0NtM57TorOKHdr93MEs6GhPGsxDQaLrrdZ6GI=.7c6436e4-c8d1-4ae3-98e4-e48f9974aff0@github.com> On Thu, 14 Nov 2019 23:31:34 GMT, Kevin Rushforth wrote: > [JDK-8233421](https://bugs.openjdk.java.net/browse/JDK-8233421) > > This bumps the windows compiler version to VS2017 version 15.9.16 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - aab19fa8: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 > > Changes: https://git.openjdk.java.net/jfx/pull/40/files > Webrev: https://webrevs.openjdk.java.net/jfx/40/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233421 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/40.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/40/head:pull/40 build and sanity check pass on windows (and, fwiw, other platforms) ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/40 From jvos at openjdk.org Mon Nov 18 18:10:04 2019 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Nov 2019 18:10:04 GMT Subject: [Approved] RFR: 8233420: Upgrade to gcc 8.3 on Linux In-Reply-To: References: Message-ID: On Thu, 14 Nov 2019 23:34:49 GMT, Kevin Rushforth wrote: > [JDK-8233420](https://bugs.openjdk.java.net/browse/JDK-8233420) > > This bumps the Linux compiler version to gcc 8.3 to match JDK 14. I have run a full build and test, including WebKit and media. > > ---------------- > > Commits: > - ab06dc58: 8233420: Upgrade to gcc 8.3 on Linux > > Changes: https://git.openjdk.java.net/jfx/pull/41/files > Webrev: https://webrevs.openjdk.java.net/jfx/41/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233420 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/41.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/41/head:pull/41 build and sanity checks pass on linux (and fwiw, on mac/win too) ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/41 From kcr at openjdk.org Mon Nov 18 18:12:13 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:12:13 GMT Subject: RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: <_1kwgRzlZ9hO4BHRV29HK0K87bPrS3_4e8xsvinr1MU=.71c948c8-a3e3-464c-bb90-a8a6f5fe40ce@github.com> References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> <_1kwgRzlZ9hO4BHRV29HK0K87bPrS3_4e8xsvinr1MU=.71c948c8-a3e3-464c-bb90-a8a6f5fe40ce@github.com> Message-ID: On Wed, 13 Nov 2019 23:47:58 GMT, Kevin Rushforth wrote: > On Wed, 6 Nov 2019 12:54:40 GMT, Kevin Rushforth wrote: > >> On Wed, 6 Nov 2019 11:50:27 GMT, Nir Lisker wrote: >> >>> On Wed, 6 Nov 2019 07:12:26 GMT, Robin Westberg wrote: >>> >>>> On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: >>>> >>>>> On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>>> >>>>>>> CSR will be created after the changes are approved. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - 6d29e034: Initial push of 8229472 >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >>>>>> >>>>>> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >>>>>> >>>>>>> 67: @Deprecated(since = "14", forRemoval = true) >>>>>>> 68: public JavaBeanBooleanPropertyBuilder() {} >>>>>>> 69: >>>>>> >>>>>> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. >>>>> >>>>> I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? >>>> >>>> Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) >>> >>> For both `since` and `forRemoval`? >> >> Yes. The pattern used consistently (in all cases that I could find) would be: >> >> @Deprecated(since="14", forRemoval=true) > > @arapte can you also review this? > Please add @deprecated javadoc tag in the description for all constructors. Good idea. PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Mon Nov 18 18:16:04 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:16:04 GMT Subject: RFR: 8233420: Upgrade to gcc 8.3 on Linux In-Reply-To: <0058FZLr3zGXhdZpc_-wVgNEA6i39UM30cuCg3WyzLY=.ee37a722-b162-4c45-b549-6282a90ad326@github.com> References: <0058FZLr3zGXhdZpc_-wVgNEA6i39UM30cuCg3WyzLY=.ee37a722-b162-4c45-b549-6282a90ad326@github.com> Message-ID: On Thu, 14 Nov 2019 23:34:50 GMT, Kevin Rushforth wrote: > On Thu, 14 Nov 2019 23:34:49 GMT, Kevin Rushforth wrote: > >> [JDK-8233420](https://bugs.openjdk.java.net/browse/JDK-8233420) >> >> This bumps the Linux compiler version to gcc 8.3 to match JDK 14. I have run a full build and test, including WebKit and media. >> >> ---------------- >> >> Commits: >> - ab06dc58: 8233420: Upgrade to gcc 8.3 on Linux >> >> Changes: https://git.openjdk.java.net/jfx/pull/41/files >> Webrev: https://webrevs.openjdk.java.net/jfx/41/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8233420 >> Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod >> Patch: https://git.openjdk.java.net/jfx/pull/41.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/41/head:pull/41 > > Reviewers: @arapte @johanvos After integrating PR #40 (VS2017 15.9.16 upgrade) I will need to merge in the changes from master to resolve a trivial merge conflict, because the modified lines for the two PRs are adjacent to one another. There will be no change in the diffs other than the surrounding context. PR: https://git.openjdk.java.net/jfx/pull/41 From kcr at openjdk.org Mon Nov 18 18:18:17 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:18:17 GMT Subject: [Integrated] RFR: 8233421: Upgrade to Visual Studio 2017 version 15.9.16 In-Reply-To: References: Message-ID: <1720327a-1595-48bc-86e9-e15faf87037f@openjdk.org> Changeset: 95ad6017 Author: Kevin Rushforth Date: 2019-11-18 18:17:14 +0000 URL: https://git.openjdk.java.net/jfx/commit/95ad6017 8233421: Upgrade to Visual Studio 2017 version 15.9.16 Reviewed-by: prr, arapte, jvos ! build.properties From kcr at openjdk.org Mon Nov 18 18:18:22 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:18:22 GMT Subject: [Integrated] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests In-Reply-To: References: Message-ID: <457eaf9b-41c7-400b-ba09-250edfb886cc@openjdk.org> Changeset: aab07a4d Author: Arun Joseph Committer: Kevin Rushforth Date: 2019-11-18 18:17:39 +0000 URL: https://git.openjdk.java.net/jfx/commit/aab07a4d 8234239: [TEST_BUG] Reenable few ignored web tests Reviewed-by: kcr ! modules/javafx.web/src/test/java/test/com/sun/webkit/network/CookieManagerTest.java ! modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java ! modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java ! modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java From kcr at openjdk.org Mon Nov 18 18:23:16 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:23:16 GMT Subject: [Integrated] RFR: 8232063: Upgrade gradle to version 6.0 In-Reply-To: References: Message-ID: <4b936037-e160-47b9-8bd7-d3409c954fe7@openjdk.org> Changeset: 42040c4c Author: Kevin Rushforth Date: 2019-11-18 18:22:51 +0000 URL: https://git.openjdk.java.net/jfx/commit/42040c4c 8232063: Upgrade gradle to version 6.0 Reviewed-by: arapte, jvos ! build.gradle ! build.properties ! buildSrc/build.gradle ! gradle/legal/gradle.md ! gradle/wrapper/gradle-wrapper.properties From kcr at openjdk.org Mon Nov 18 18:28:48 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:28:48 GMT Subject: [Rev 01] RFR: 8233420: Upgrade to gcc 8.3 on Linux In-Reply-To: References: Message-ID: The pull request has been updated with a complete new set of changes (possibly due to a rebase). ---------------- Commits: - f538e26b: Merge branch 'master' into 8233420-gcc-8.3 - ab06dc58: 8233420: Upgrade to gcc 8.3 on Linux Changes: https://git.openjdk.java.net/jfx/pull/41/files Webrev: https://webrevs.openjdk.java.net/jfx/41/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8233420 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/41/head:pull/41 PR: https://git.openjdk.java.net/jfx/pull/41 From kcr at openjdk.org Mon Nov 18 18:40:16 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Nov 2019 18:40:16 GMT Subject: [Integrated] RFR: 8233420: Upgrade to gcc 8.3 on Linux In-Reply-To: References: Message-ID: <73ee31d2-b9ec-4041-9417-b12dae46113f@openjdk.org> Changeset: aad17206 Author: Kevin Rushforth Date: 2019-11-18 18:40:00 +0000 URL: https://git.openjdk.java.net/jfx/commit/aad17206 8233420: Upgrade to gcc 8.3 on Linux Reviewed-by: arapte, jvos ! build.properties From ajoseph at openjdk.org Tue Nov 19 07:11:40 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Tue, 19 Nov 2019 07:11:40 GMT Subject: RFR: 8210955: DOMTest::testEventListenerCascade fails Message-ID: Modified the test to work with WebView's ordering of capturing and bubbling event listeners. ---------------- Commits: - cbef0069: DOMTest::testEventListenerCascade fails Changes: https://git.openjdk.java.net/jfx/pull/46/files Webrev: https://webrevs.openjdk.java.net/jfx/46/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210955 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/46.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/46/head:pull/46 PR: https://git.openjdk.java.net/jfx/pull/46 From aghaisas at openjdk.org Tue Nov 19 10:48:52 2019 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 19 Nov 2019 10:48:52 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: > On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: > >> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >> >>> **Issue :** >>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>> >>> **Background :** >>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>> >>> **Description :** >>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>> For ease of review, I have made two separate commits - >>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>> >>> **Root Cause :** >>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>> >>> **Fix :** >>> Fixed the identified root cause. See commit 2. >>> >>> **Testing :** >>> 1. All passing unit tests continue to pass >>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>> 3. System test JDK8183100Test continues to pass >>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>> >>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>> >>> ---------------- >>> >>> Commits: >>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >> >> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >> >> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >> >>> 25: >>> 26: package test.robot.javafx.scene; >>> 27: >> >> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >> >> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >> >>> 54: >>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>> 56: >> >> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >> >> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >> >>> 77: HBox hbox = new HBox(); >>> 78: for (int i = 0; i < 300; i++) { >>> 79: hbox = new HBox(new Text("y"), hbox); >> >> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >> >> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >> >>> 93: // It is good enough to catch the regression in performance, if any >>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>> 95: } >> >> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. > >> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >> >> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >> >> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >> >> ``` >> if (cssFlag == CssFlags.UPDATE) { >> cssFlag = CssFlags.REAPPLY; >> notifyParentsOfInvalidatedCSS(); >> return; >> } >> ``` >> >> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >> >> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. > > It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. > Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. Test from JDK-8151756 with additional one level of Node hierarchy. Parent1<--Parent2<--Parent3<--Rectangle (leaf child) Log from test program ---- Parent 1 : VBox at 1d9e402b Parent 2 : VBox at 4cc2dcce Parent 3 : VBox at 4cc2dcce Rectangle **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN Proposed New Fix : ------------------- I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java index 877e0fd6c8..8606dfb575 100644 --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { if (cssFlag == CssFlags.REAPPLY) return; // RT-36838 - don't reapply CSS in the middle of an update - if (cssFlag == CssFlags.UPDATE) { + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { cssFlag = CssFlags.REAPPLY; notifyParentsOfInvalidatedCSS(); return; With this fix - Log from test program ---- Parent 1 : VBox at 36d24c70 Parent 2 : VBox at 35af5cea Parent 3 : VBox at 35af5cea Rectangle **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN I verified that all graphics/controls unit tests & all system tests pass with this fix. I launched and played with Ensemble app. I did not see any visible artifacts. PR: https://git.openjdk.java.net/jfx/pull/34 From github.com+4412658+dsgrieve at openjdk.org Tue Nov 19 14:29:16 2019 From: github.com+4412658+dsgrieve at openjdk.org (David Grieve) Date: Tue, 19 Nov 2019 14:29:16 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas wrote: > On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: > >> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: >> >>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>> >>>> **Issue :** >>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>> >>>> **Background :** >>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>> >>>> **Description :** >>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>> For ease of review, I have made two separate commits - >>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>> >>>> **Root Cause :** >>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>> >>>> **Fix :** >>>> Fixed the identified root cause. See commit 2. >>>> >>>> **Testing :** >>>> 1. All passing unit tests continue to pass >>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>> 3. System test JDK8183100Test continues to pass >>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>> >>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>> >>> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >>> >>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >>> >>>> 25: >>>> 26: package test.robot.javafx.scene; >>>> 27: >>> >>> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >>> >>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >>> >>>> 54: >>>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>>> 56: >>> >>> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >>> >>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >>> >>>> 77: HBox hbox = new HBox(); >>>> 78: for (int i = 0; i < 300; i++) { >>>> 79: hbox = new HBox(new Text("y"), hbox); >>> >>> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >>> >>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >>> >>>> 93: // It is good enough to catch the regression in performance, if any >>>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>>> 95: } >>> >>> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. >> >>> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >>> >>> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >>> >>> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >>> >>> ``` >>> if (cssFlag == CssFlags.UPDATE) { >>> cssFlag = CssFlags.REAPPLY; >>> notifyParentsOfInvalidatedCSS(); >>> return; >>> } >>> ``` >>> >>> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >>> >>> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. >> >> It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. > >> Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. > > This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. > > > Test from JDK-8151756 with additional one level of Node hierarchy. > > Parent1<--Parent2<--Parent3<--Rectangle (leaf child) > > Log from test program ---- > Parent 1 : VBox at 1d9e402b > Parent 2 : VBox at 4cc2dcce > Parent 3 : VBox at 4cc2dcce > Rectangle > > **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN > REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** > reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN > **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** > reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH > reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN > **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** > reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH > reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE > reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN > **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** > reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH > reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE > reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE > reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN > > > Proposed New Fix : > ------------------- > I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - > > diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java > index 877e0fd6c8..8606dfb575 100644 > --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java > +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java > @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { > if (cssFlag == CssFlags.REAPPLY) return; > > // RT-36838 - don't reapply CSS in the middle of an update > - if (cssFlag == CssFlags.UPDATE) { > + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { > cssFlag = CssFlags.REAPPLY; > notifyParentsOfInvalidatedCSS(); > return; > > With this fix - > Log from test program ---- > Parent 1 : VBox at 36d24c70 > Parent 2 : VBox at 35af5cea > Parent 3 : VBox at 35af5cea > Rectangle > > **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** > **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** > reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN > **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH > REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH > REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** > reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY > reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY > reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY > reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN > > > I verified that all graphics/controls unit tests & all system tests pass with this fix. > I launched and played with Ensemble app. I did not see any visible artifacts. @aghaisas You can avoid the call to notifyParentsOfInvalidatedCSS in the case where the flag is DIRTY_BRANCH. I like the looks of this. From the 10,000 foot view, when a node's parent changes, or a node's scene changes, CSS should be reapplied. This is exactly what 'if (sceneChanged) reapplyCSS()' says, and what happens in parent property's invalidated method. All of the optimizations (do I _really_ need to reapply css?) happen elsewhere, so I like this solution better than passing a boolean around (the original patch). PR: https://git.openjdk.java.net/jfx/pull/34 From nlisker at openjdk.org Tue Nov 19 18:02:23 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 19 Nov 2019 18:02:23 GMT Subject: RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> <_1kwgRzlZ9hO4BHRV29HK0K87bPrS3_4e8xsvinr1MU=.71c948c8-a3e3-464c-bb90-a8a6f5fe40ce@github.com> Message-ID: On Mon, 18 Nov 2019 18:12:13 GMT, Kevin Rushforth wrote: > On Wed, 13 Nov 2019 23:47:58 GMT, Kevin Rushforth wrote: > >> On Wed, 6 Nov 2019 12:54:40 GMT, Kevin Rushforth wrote: >> >>> On Wed, 6 Nov 2019 11:50:27 GMT, Nir Lisker wrote: >>> >>>> On Wed, 6 Nov 2019 07:12:26 GMT, Robin Westberg wrote: >>>> >>>>> On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: >>>>>> >>>>>>> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>>>> >>>>>>>> CSR will be created after the changes are approved. >>>>>>>> >>>>>>>> ---------------- >>>>>>>> >>>>>>>> Commits: >>>>>>>> - 6d29e034: Initial push of 8229472 >>>>>>>> >>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>>>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >>>>>>> >>>>>>> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >>>>>>> >>>>>>>> 67: @Deprecated(since = "14", forRemoval = true) >>>>>>>> 68: public JavaBeanBooleanPropertyBuilder() {} >>>>>>>> 69: >>>>>>> >>>>>>> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. >>>>>> >>>>>> I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? >>>>> >>>>> Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) >>>> >>>> For both `since` and `forRemoval`? >>> >>> Yes. The pattern used consistently (in all cases that I could find) would be: >>> >>> @Deprecated(since="14", forRemoval=true) >> >> @arapte can you also review this? > >> Please add @deprecated javadoc tag in the description for all constructors. > > Good idea. Good suggestion. I will change to /** * @deprecated This constructor was exposed erroneously and will be removed in the next version. Use {@link #create()} instead. */ @Deprecated(since="14", forRemoval=true) I noticed that the `ReadOnlyJavaBeanXxxPropertyBuilder`s also have the same issue. Can I fix them in this PR too or do we need a new one? Also, the CSR is finalized, can I change it at this point? PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Tue Nov 19 18:13:26 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 19 Nov 2019 18:13:26 GMT Subject: RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: <4Z05Bx7xEff4Hpdwg55xZCmHtuKGqoECPR2A2NztLfw=.91fcecbb-98c0-4d71-86ec-f78e05715d45@github.com> <_1kwgRzlZ9hO4BHRV29HK0K87bPrS3_4e8xsvinr1MU=.71c948c8-a3e3-464c-bb90-a8a6f5fe40ce@github.com> Message-ID: On Tue, 19 Nov 2019 18:02:23 GMT, Nir Lisker wrote: > On Mon, 18 Nov 2019 18:12:13 GMT, Kevin Rushforth wrote: > >> On Wed, 13 Nov 2019 23:47:58 GMT, Kevin Rushforth wrote: >> >>> On Wed, 6 Nov 2019 12:54:40 GMT, Kevin Rushforth wrote: >>> >>>> On Wed, 6 Nov 2019 11:50:27 GMT, Nir Lisker wrote: >>>> >>>>> On Wed, 6 Nov 2019 07:12:26 GMT, Robin Westberg wrote: >>>>> >>>>>> On Wed, 6 Nov 2019 05:07:56 GMT, Kevin Rushforth wrote: >>>>>> >>>>>>> On Wed, 6 Nov 2019 05:04:28 GMT, Kevin Rushforth wrote: >>>>>>> >>>>>>>> On Tue, 5 Nov 2019 18:10:57 GMT, Nir Lisker wrote: >>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>>>>> >>>>>>>>> CSR will be created after the changes are approved. >>>>>>>>> >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>> Commits: >>>>>>>>> - 6d29e034: Initial push of 8229472 >>>>>>>>> >>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/30/files >>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/30/webrev.00 >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 >>>>>>>>> Stats: 14 lines in 7 files changed: 7 ins; 0 del; 7 mod >>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/30.diff >>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 >>>>>>>> >>>>>>>> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java line 68: >>>>>>>> >>>>>>>>> 67: @Deprecated(since = "14", forRemoval = true) >>>>>>>>> 68: public JavaBeanBooleanPropertyBuilder() {} >>>>>>>>> 69: >>>>>>>> >>>>>>>> Minor: I checked other places in JavaFX and JDK, and they consistently omit the spaces surrounding the `=`. >>>>>>> >>>>>>> I changed the bug summary to include `for removal` in the title. Can you change the PR title to match? >>>>>> >>>>>> Thanks for the notification, looks like GitHub returned 500 for a few minutes. This seem to happen from time to time, so nice to know that the retry logic works. :) >>>>> >>>>> For both `since` and `forRemoval`? >>>> >>>> Yes. The pattern used consistently (in all cases that I could find) would be: >>>> >>>> @Deprecated(since="14", forRemoval=true) >>> >>> @arapte can you also review this? >> >>> Please add @deprecated javadoc tag in the description for all constructors. >> >> Good idea. > > Good suggestion. I will change to > > /** > * @deprecated This constructor was exposed erroneously and will be removed in the next version. Use {@link #create()} instead. > */ > @Deprecated(since="14", forRemoval=true) > > I noticed that the `ReadOnlyJavaBeanXxxPropertyBuilder`s also have the same issue. Can I fix them in this PR too or do we need a new one? > > Also, the CSR is finalized, can I change it at this point? > I noticed that the ReadOnlyJavaBeanXxxPropertyBuilders also have the same issue. Can I fix them in this PR too or do we need a new one? Good catch. Not sure how we missed this before now (the change for JavaFX 13 also missed it), but yes, I'd prefer to fix this now for the ReadOnlyJavaBeanXxxPropertyBuilders, too. For the CSR, you can move it back to Draft, edit it, and then once the review is done, Finalize it again (no need to go through the Proposed phase a second time). PR: https://git.openjdk.java.net/jfx/pull/30 From nlisker at openjdk.org Tue Nov 19 19:17:00 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 19 Nov 2019 19:17:00 GMT Subject: [Rev 02] RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - ae9ee73e: Added @deprecated javadoc annotation and fixed ReadOnly variants Changes: - all: https://git.openjdk.java.net/jfx/pull/30/files - new: https://git.openjdk.java.net/jfx/pull/30/files/a1cdb37b..ae9ee73e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/30/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/30/webrev.01-02 Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 Stats: 56 lines in 14 files changed: 42 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 PR: https://git.openjdk.java.net/jfx/pull/30 From kcr at openjdk.org Wed Nov 20 00:30:02 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Nov 2019 00:30:02 GMT Subject: [Approved] RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Tue, 19 Nov 2019 19:17:00 GMT, Nir Lisker wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - ae9ee73e: Added @deprecated javadoc annotation and fixed ReadOnly variants > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/30/files > - new: https://git.openjdk.java.net/jfx/pull/30/files/a1cdb37b..ae9ee73e > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/30/webrev.02 > - incr: https://webrevs.openjdk.java.net/jfx/30/webrev.01-02 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 56 lines in 14 files changed: 42 ins; 0 del; 14 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 The updated version looks good. I checked the javadoc-generated API docs as well. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/30 From nlisker at openjdk.org Wed Nov 20 00:32:42 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 20 Nov 2019 00:32:42 GMT Subject: RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: <8rYgugRQG-zrAZsJc8I2KCABvRgf6yJ7F-AOMgUvKV8=.267cc5a7-c8b5-4b6e-87ed-3cbdab895020@github.com> On Mon, 18 Nov 2019 18:00:46 GMT, Nir Lisker wrote: > On Mon, 18 Nov 2019 18:00:45 GMT, Nir Lisker wrote: > >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 >> >> ---------------- >> >> Commits: >> - a388fb92: Fixed whitespaces >> - 415927e6: Correction for indexes >> - 3450ffe9: Docs and year update >> - 4b63a01f: Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into 8217472_Add_attenuation_for_PointLight >> - 52e1ae1a: Separate range from attenuation >> - d39bceeb: GL pipeline >> - a590f09a: Initial push of 8217472 >> >> Changes: https://git.openjdk.java.net/jfx/pull/43/files >> Webrev: https://webrevs.openjdk.java.net/jfx/43/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8217472 >> Stats: 498 lines in 27 files changed: 385 ins; 13 del; 100 mod >> Patch: https://git.openjdk.java.net/jfx/pull/43.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 > > Tested D3D on Win 10 and GL on Ubuntu 18.04. > > There is still a bug (at least on Win) for some certain combinations of values as shown in this picture: > ![image](https://user-images.githubusercontent.com/37422899/69054658-c2ad9180-0a14-11ea-809c-15c8ae485fd0.png) > > This sample program can be used to test the changes. > Controls: mouse wheel zooms, RMB drag rotates, LMB pans. > > [sample.zip](https://github.com/openjdk/jfx/files/3858700/sample.zip) > > Kevin, Ambarish, > > You can start the review, especially the API. I will hunt that specific values bug this week. > > I'll need to know what kind of tests are needed in terms of functionality and performance. The bug I mentioned above is not a bug actually. There are rapid changes over a small distance that make it looks like a jump in the lighting values, but when working with a finer scale the lighting dynamics seem correct. PR: https://git.openjdk.java.net/jfx/pull/43 From github.com+1413266+jgneff at openjdk.org Wed Nov 20 03:32:33 2019 From: github.com+1413266+jgneff at openjdk.org (John Neffenger) Date: Wed, 20 Nov 2019 03:32:33 GMT Subject: [Rev 01] RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> Message-ID: On Mon, 18 Nov 2019 14:04:25 GMT, Dell Green wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 1f6e282d: changed from system propert debug logging to javafx platform logger > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/5/files > - new: https://git.openjdk.java.net/jfx/pull/5/files/cfbbc7dd..1f6e282d > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/5/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/5/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > Stats: 14 lines in 1 file changed: 5 ins; 7 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/5.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 Yeah?one less system property! Thanks, Dell. ---------------- Approved by jgneff at github.com (no OpenJDK username). PR: https://git.openjdk.java.net/jfx/pull/5 From arapte at openjdk.org Wed Nov 20 04:43:23 2019 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 20 Nov 2019 04:43:23 GMT Subject: [Approved] RFR: 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors In-Reply-To: References: Message-ID: On Tue, 19 Nov 2019 19:17:00 GMT, Nir Lisker wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - ae9ee73e: Added @deprecated javadoc annotation and fixed ReadOnly variants > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/30/files > - new: https://git.openjdk.java.net/jfx/pull/30/files/a1cdb37b..ae9ee73e > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/30/webrev.02 > - incr: https://webrevs.openjdk.java.net/jfx/30/webrev.01-02 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8229472 > Stats: 56 lines in 14 files changed: 42 ins; 0 del; 14 mod > Patch: https://git.openjdk.java.net/jfx/pull/30.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/30/head:pull/30 lgtm. ---------------- Approved by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/30 From nlisker at openjdk.org Wed Nov 20 06:54:16 2019 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 20 Nov 2019 06:54:16 GMT Subject: [Integrated] RFR: 8229472: Deprecate JavaBeanXxxPropertyBuilders public constructors In-Reply-To: References: Message-ID: <311afb2f-f76f-4114-b1ad-159d60f2fac6@openjdk.org> Changeset: 8bea7b71 Author: Nir Lisker Date: 2019-11-20 06:53:00 +0000 URL: https://git.openjdk.java.net/jfx/commit/8bea7b71 8229472: Deprecate for removal JavaBeanXxxPropertyBuilders constructors Reviewed-by: kcr, arapte ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanDoublePropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanIntegerPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanLongPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanObjectPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanStringPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyBuilder.java ! modules/javafx.base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyBuilder.java From ajoseph at openjdk.org Wed Nov 20 07:05:40 2019 From: ajoseph at openjdk.org (Arun Joseph) Date: Wed, 20 Nov 2019 07:05:40 GMT Subject: RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Message-ID: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com> Issue: Native part of WebView throws a DOMException and then, continues executing the rest of the function assuming that value is present. This causes the JVM to crash when retrieving the value. Fix: Return from the function if exception was raised (code is similar to exception handling in [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp)) This fix also needs to be applied to all function calls in [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM) functions which raises DOMError similar to createAttributeImpl(). ---------------- Commits: - acc52780: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Changes: https://git.openjdk.java.net/jfx/pull/47/files Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233747 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47 PR: https://git.openjdk.java.net/jfx/pull/47 From github.com+12861109+dellgreen at openjdk.org Wed Nov 20 11:50:43 2019 From: github.com+12861109+dellgreen at openjdk.org (Dell Green) Date: Wed, 20 Nov 2019 11:50:43 GMT Subject: RFR: 8087980: Add property to disable Monocle cursor In-Reply-To: References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com> <2DMU8EFFAb1A2iiMLQBt5_hqmE8tNMmoCsc9iUhn0xc=.ac547810-fa4d-4b30-8d00-3d8b0cb42bf9@github.com> <7KRNa55Hl22WWsYZN3j8NeZu3VqXe_orl_l0N5d3bhM=.7e6d6d64-b542-4068-8f00-5cad180fce18@github.com> Message-ID: On Mon, 18 Nov 2019 14:07:23 GMT, Dell Green wrote: > On Sun, 17 Nov 2019 10:04:36 GMT, Dell Green wrote: > >> On Sat, 16 Nov 2019 17:51:56 GMT, John Neffenger wrote: >> >>> On Sat, 16 Nov 2019 06:09:35 GMT, Dell Green wrote: >>> >>>> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger wrote: >>>> >>>>> On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: >>>>> >>>>>> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger wrote: >>>>>> >>>>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgreen at users.noreply.github.com> wrote: >>>>>>> >>>>>>>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement. >>>>>>>> >>>>>>>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms. >>>>>>>> >>>>>>>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises. >>>>>>>> >>>>>>>> ---------------- >>>>>>>> >>>>>>>> Commits: >>>>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>>>>> >>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>>>>> >>>>>>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java line 50: >>>>>>> >>>>>>>> 49: AccessController.doPrivileged((PrivilegedAction) () -> { >>>>>>>> 50: final String str = >>>>>>>> 51: System.getProperty("monocle.debugcursor", ""); >>>>>>> >>>>>>> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`? Below is the full list, for comparison, including the two added by this pull request. >>>>>>> >>>>>>> monocle.cursor.enabled >>>>>>> monocle.debugcursor >>>>>>> monocle.epd.bitsPerPixel >>>>>>> monocle.epd.enableInversion >>>>>>> monocle.epd.forceMonochrome >>>>>>> monocle.epd.noWait >>>>>>> monocle.epd.rotate >>>>>>> monocle.epd.useDitheringY1 >>>>>>> monocle.epd.useDitheringY4 >>>>>>> monocle.epd.waveformMode >>>>>>> monocle.epd.y8inverted >>>>>>> monocle.input..flipXY >>>>>>> monocle.input..maxX >>>>>>> monocle.input..maxY >>>>>>> monocle.input..minX >>>>>>> monocle.input..minY >>>>>>> monocle.input..touchFilters >>>>>>> monocle.input.touchFilters >>>>>>> monocle.input.touchRadius >>>>>>> monocle.input.traceEvents >>>>>>> monocle.input.traceEvents.verbose >>>>>>> monocle.maliSignedStruct >>>>>>> monocle.platform >>>>>>> monocle.platform.traceConfig >>>>>>> monocle.screen.fb >>>>>>> monocle.stackSize >>>>>>> >>>>>>> I'm nervous about our hidden API of system properties, and I'm as guilty as anyone with the nine properties I added for Monocle EPD. I think it might be okay as long as the code gets the property values only during class initialization. That should restrict their use to startup scripts and keep them out of application code trying to modify them *on-the-fly* at run time. >>>>>> >>>>>> if i recall i originally started with the format you recommend as it made more sense, and when looking for other debug logging across the javafx stack I picked up on somewhat of a loose existing convention so changed to match it. I guess it can be whatever everyone agrees upon. :) >>>>> >>>>> On second thought, let's remove `monocle.debugcursor` and use a [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java). The JavaFX loggers are available from [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java). In retrospect, that's how I managed to avoid any new *debug* properties for Monocle EPD even though it's packed with debugging and trace messages. For examples, see the variable `logger` in [EPDFrameBuffer](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDFrameBuffer.java), where `logger.fine` is called for messages printed once per run, while `logger.finer` is called for messages printed once per rendered frame. >>>> >>>> OK, that looks a better way to go. I'll sort out out an additional pull request when back in work Monday. Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? >>> >>>> Off the top of your head can you remember the syntax to change the logger level from command line when starting the JVM? >>> >>> Here's how I use it. My Bash run script is **bin/run.sh**: >>> >>> #!/bin/bash >>> # Runs the EPD JavaFX Animator program >>> JAVA_HOME=$HOME/opt/jdk-13.0.1+9 >>> JAVAFX_LIB=$HOME/lib/armv6hf-sdk/lib >>> >>> app_dir=$HOME/src/epd-javafx >>> app_jar=$app_dir/dist/epd-javafx.jar >>> logging=$app_dir/conf/logging.properties >>> >>> $JAVA_HOME/bin/java -Djava.util.logging.config.file=$logging \ >>> --add-modules=javafx.graphics --module-path=$JAVAFX_LIB \ >>> -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ >>> -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ >>> -Dmonocle.epd.waveformMode=4 -jar $app_jar $@ >>> >>> The logging properties are defined in **conf/logging.properties**: >>> >>> Properties >>> # Global properties >>> handlers = java.util.logging.ConsoleHandler >>> .level = INFO >>> >>> # Handler specific properties >>> java.util.logging.ConsoleHandler.level = ALL >>> java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter >>> java.util.logging.SimpleFormatter.format=%4$s: %5$s%n >>> >>> # Facility specific properties >>> javafx.level = FINE >>> >>> The output looks like the following: >>> >>> $ sudo bin/run.sh --pattern=3 --loops=0 >>> FINE: EPD system properties: {monocle.epd.waveformMode=4} >>> FINE: Frame buffer geometry: 800 600 800 640 32 >>> FINE: Frame buffer rgba: 8/16,8/8,8/0,8/24 >>> FINE: Frame buffer grayscale: 0 >>> FINE: Mapping frame buffer: 1,920,000 bytes >>> Frame rate: 80 frames in 11.93 s = 6.70 fps (149 ms/frame) >>> Frame rate: 80 frames in 9.97 s = 8.03 fps (125 ms/frame) >>> Frame rate: 80 frames in 9.96 s = 8.03 fps (125 ms/frame) >>> >>> You can just add a new commit to this pull request branch. (I think that's what you meant, but just in case.) The commits get *squashed* into a single commit when they are integrated into the target branch. >> >> cool thanks, apologies i meant commit. :) > > system property has now been changed to use platform logger as advised. has been tested successfully on my imx6 board. no probs, thanks for approving :) PR: https://git.openjdk.java.net/jfx/pull/5 From kcr at openjdk.org Wed Nov 20 14:07:15 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Nov 2019 14:07:15 GMT Subject: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34 In-Reply-To: References: Message-ID: On Mon, 18 Nov 2019 13:29:32 GMT, Arun Joseph wrote: > We need to update the version of libxslt to the latest version, 1.1.34. > > ---------------- > > Commits: > - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34 > > Changes: https://git.openjdk.java.net/jfx/pull/45/files > Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234056 > Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod > Patch: https://git.openjdk.java.net/jfx/pull/45.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45 Looks good. This will need a second reviewer. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/45 From amnojeeuw at gmail.com Wed Nov 20 14:42:35 2019 From: amnojeeuw at gmail.com (amnojeeuw) Date: Wed, 20 Nov 2019 09:42:35 -0500 Subject: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34 In-Reply-To: Message-ID: <5dd550de.1c69fb81.97db.53d9@mx.google.com> Hello folks!How can I remove myself from this mailing list?Thank in advance.Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Kevin Rushforth Date: 2019-11-20 9:07 AM (GMT-05:00) To: openjfx-dev at openjdk.java.net Subject: Re: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34 On Mon, 18 Nov 2019 13:29:32 GMT, Arun Joseph wrote:> We need to update the version of libxslt to the latest version, 1.1.34.> > ----------------> > Commits:>? - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34> > Changes: https://git.openjdk.java.net/jfx/pull/45/files>? Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00>?? Issue: https://bugs.openjdk.java.net/browse/JDK-8234056>?? Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod>?? Patch: https://git.openjdk.java.net/jfx/pull/45.diff>?? Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45Looks good. This will need a second reviewer.----------------Approved by kcr (Lead).PR: https://git.openjdk.java.net/jfx/pull/45 From kcr at openjdk.org Wed Nov 20 15:04:07 2019 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Nov 2019 15:04:07 GMT Subject: RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute In-Reply-To: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com> References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com> Message-ID: On Wed, 20 Nov 2019 07:05:40 GMT, Arun Joseph wrote: > Issue: Native part of WebView throws a DOMException and then, continues executing the rest of the function assuming that value is present. This causes the JVM to crash when retrieving the value. > > Fix: Return from the function if exception was raised (code is similar to exception handling in [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp)) > > This fix also needs to be applied to all function calls in [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM) functions which raises DOMError similar to createAttributeImpl(). > > ---------------- > > Commits: > - acc52780: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute > > Changes: https://git.openjdk.java.net/jfx/pull/47/files > Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233747 > Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/47.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47 The proposed fix seems more like a workaround to me. There are dozens of very similar calls to `raiseOnDOMError` in this and other files, so I would think a more general solution is needed. PR: https://git.openjdk.java.net/jfx/pull/47 From swpalmer at gmail.com Wed Nov 20 15:07:13 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 20 Nov 2019 10:07:13 -0500 Subject: Typo in native-glass/win/OleUtils.h checkJavaException Message-ID: I discovered this by accident while trying to figure out where a certain console message was coming from while debugging. I saw this printed to the console when testing my (broken) code: Java Messsge:com/openalpr/jni/AlprException Note the typo in "Messsge" (the class name that follows is specific to what I was testing). I couldn't find the string "Java Messsge" in any of my code or the library I was trying out (OpenALPR). Eventually I found it was in glass.dll and traced it to the checkJavaException function in OleUtils.h, line 230. On another note, I see that function is declared as "inline", though I suspect the body of the "else" really doesn't need to be inlined and the extra size it adds to the method could make it less likely to actually get inlined. It seems the part that you want inlined is the if (!env-ExceptionCheck()) { return S_OK; }. Wouldn't the rest run very rarely and not benefit from being inlined? If that code does get inlined it would bloat the code unnecessarily. The premature optimizer in me (it's an evil I have trouble controlling) thinks this just makes stuff less cache-friendly. I would put it in another not-inlined method. Also note that using "else" is redundant. Scott From mp at jugs.org Wed Nov 20 21:20:13 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 20 Nov 2019 22:20:13 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) Message-ID: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> Hi, I would just like to know where JavaFX problems or bugs should be reported which are strictly related to running on the just released GraalVM 19.3 with Java 11 support. Should they go into the regular JBS or should they be reported elsewhere? For example: I have observed that a large JavaFX application seems to work correctly at first but then suddenly all text on all controls turns white and white on white or light grey is not really readable anymore. I've never observed such a behaviour on any other VM before. There is also no error message or warning associated with this. It just happens. There even seem to be more issues when you try to use native-image. --Michael From dlemmermann at gmail.com Thu Nov 21 07:47:43 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 21 Nov 2019 08:47:43 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> Message-ID: <03508E1E-C7FB-4BF2-97B0-EB49E5F092E9@gmail.com> I am also observing issues related to text color. All of my labels show up in blue instead of the color defined globally in my css file. > On 20 Nov 2019, at 22:20, Michael Paus wrote: > > Hi, > > I would just like to know where JavaFX problems or bugs should be reported > which are strictly related to running on the just released GraalVM 19.3 with > Java 11 support. Should they go into the regular JBS or should they be reported > elsewhere? > > For example: I have observed that a large JavaFX application seems to work > correctly at first but then suddenly all text on all controls turns white and > white on white or light grey is not really readable anymore. I've never observed > such a behaviour on any other VM before. There is also no error message or > warning associated with this. It just happens. > > There even seem to be more issues when you try to use native-image. > > --Michael > From kevin.rushforth at oracle.com Thu Nov 21 13:45:08 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Nov 2019 05:45:08 -0800 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: <03508E1E-C7FB-4BF2-97B0-EB49E5F092E9@gmail.com> References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <03508E1E-C7FB-4BF2-97B0-EB49E5F092E9@gmail.com> Message-ID: <10f0d10c-0adb-5b51-374f-0ff74171ca93@oracle.com> My guess is that these are GraalVM bugs rather than JavaFX bugs, but without debugging them it's hard to know for sure. Johan has spent a fair bit of time looking into running JavaFX on GraalVM, so might have some additional insights. As for bug tracking, I don't have a problem with using the javafx component in JBS as long as we use a consistent label to indicate bugs that are specific to Graal so we can filter on that label. I might suggest "javafx-graal" but am open to others (I don't want to just use "graal" since the Graal team already use that as well as a couple other labels prefixed with "graal-"). -- Kevin On 11/20/2019 11:47 PM, Dirk Lemmermann wrote: > I am also observing issues related to text color. All of my labels show up in blue instead of the color defined globally in my css file. > >> On 20 Nov 2019, at 22:20, Michael Paus wrote: >> >> Hi, >> >> I would just like to know where JavaFX problems or bugs should be reported >> which are strictly related to running on the just released GraalVM 19.3 with >> Java 11 support. Should they go into the regular JBS or should they be reported >> elsewhere? >> >> For example: I have observed that a large JavaFX application seems to work >> correctly at first but then suddenly all text on all controls turns white and >> white on white or light grey is not really readable anymore. I've never observed >> such a behaviour on any other VM before. There is also no error message or >> warning associated with this. It just happens. >> >> There even seem to be more issues when you try to use native-image. >> >> --Michael >> From kevin.rushforth at oracle.com Thu Nov 21 13:51:13 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Nov 2019 05:51:13 -0800 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: <10f0d10c-0adb-5b51-374f-0ff74171ca93@oracle.com> References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <03508E1E-C7FB-4BF2-97B0-EB49E5F092E9@gmail.com> <10f0d10c-0adb-5b51-374f-0ff74171ca93@oracle.com> Message-ID: <2d95a7b8-9e3e-2134-5fae-39ee20d66427@oracle.com> In thinking about it further, since these are likely Graal bugs, it seems better to file them with the Graal team. -- Kevin On 11/21/2019 5:45 AM, Kevin Rushforth wrote: > My guess is that these are GraalVM bugs rather than JavaFX bugs, but > without debugging them it's hard to know for sure. > > Johan has spent a fair bit of time looking into running JavaFX on > GraalVM, so might have some additional insights. > > As for bug tracking, I don't have a problem with using the javafx > component in JBS as long as we use a consistent label to indicate bugs > that are specific to Graal so we can filter on that label. I might > suggest "javafx-graal" but am open to others (I don't want to just use > "graal" since the Graal team already use that as well as a couple > other labels prefixed with "graal-"). > > -- Kevin > > > On 11/20/2019 11:47 PM, Dirk Lemmermann wrote: >> I am also observing issues related to text color. All of my? labels >> show up in blue instead of the color defined globally in my css file. >> >>> On 20 Nov 2019, at 22:20, Michael Paus wrote: >>> >>> Hi, >>> >>> I would just like to know where JavaFX problems or bugs should be >>> reported >>> which are strictly related to running on the just released GraalVM >>> 19.3 with >>> Java 11 support. Should they go into the regular JBS or should they >>> be reported >>> elsewhere? >>> >>> For example: I have observed that a large JavaFX application seems >>> to work >>> correctly at first but then suddenly all text on all controls turns >>> white and >>> white on white or light grey is not really readable anymore. I've >>> never observed >>> such a behaviour on any other VM before. There is also no error >>> message or >>> warning associated with this. It just happens. >>> >>> There even seem to be more issues when you try to use native-image. >>> >>> --Michael >>> > From almatvee at openjdk.java.net Thu Nov 21 01:00:33 2019 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 21 Nov 2019 01:00:33 GMT Subject: RFR: 8230610: Upgrade GStreamer to the latest 1.16.1 Message-ID: - Upgraded GStreamer to 1.16.1 - Upgraded GLib to 2.62.2. - Removed glib-liteD.def, since it almost identical to release version glib-lite.def. Debug build will use glib-lite.def. - No changes to other parts of code, except minor changes to makefiles. ---------------- Commits: - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 Changes: https://git.openjdk.java.net/jfx/pull/48/files Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod Patch: https://git.openjdk.java.net/jfx/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 PR: https://git.openjdk.java.net/jfx/pull/48 From jvos at openjdk.java.net Thu Nov 21 10:23:29 2019 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 21 Nov 2019 10:23:29 GMT Subject: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34 In-Reply-To: References: Message-ID: On Mon, 18 Nov 2019 13:29:32 GMT, Arun Joseph wrote: > We need to update the version of libxslt to the latest version, 1.1.34. > > ---------------- > > Commits: > - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34 > > Changes: https://git.openjdk.java.net/jfx/pull/45/files > Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234056 > Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod > Patch: https://git.openjdk.java.net/jfx/pull/45.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45 Builds and sanity checks passed on Linux/Mac/Win ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/45 From kcr at openjdk.java.net Thu Nov 21 13:18:47 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Nov 2019 13:18:47 GMT Subject: RFR: 8230610: Upgrade GStreamer to the latest 1.16.1 In-Reply-To: References: Message-ID: On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev wrote: > - Upgraded GStreamer to 1.16.1 > - Upgraded GLib to 2.62.2. > - Removed glib-liteD.def, since it almost identical to release version glib-lite.def. Debug build will use glib-lite.def. > - No changes to other parts of code, except minor changes to makefiles. > > ---------------- > > Commits: > - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 > > Changes: https://git.openjdk.java.net/jfx/pull/48/files > Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 > Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod > Patch: https://git.openjdk.java.net/jfx/pull/48.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 This will need two reviewers. I will review it and also suggest @johanvos to review. PR: https://git.openjdk.java.net/jfx/pull/48 From kcr at openjdk.java.net Thu Nov 21 14:18:41 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Nov 2019 14:18:41 GMT Subject: [Integrated] RFR: 8234056: Upgrade to libxslt 1.1.34 In-Reply-To: References: Message-ID: <634052b0-1a1d-40af-b6d4-0041ade6187f@openjdk.org> Changeset: 5a398244 Author: Arun Joseph Committer: Kevin Rushforth Date: 2019-11-21 14:17:35 +0000 URL: https://git.openjdk.java.net/jfx/commit/5a398244 8234056: Upgrade to libxslt 1.1.34 Reviewed-by: kcr, jvos ! modules/javafx.web/src/main/legal/libxslt.md ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/linux/config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/linux/libexslt/exsltconfig.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/linux/libxslt/xsltwin32config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/mac/config.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/Makefile.am ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/config.h.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/configure.ac ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libexslt.pc.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.pc.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.spec ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.spec.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/Makefile.am ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/attrvt.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/functions.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/keys.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/libxslt.syms ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/numbers.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/pattern.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/pattern.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/security.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/templates.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/transform.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/variables.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/xslt.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/xsltInternals.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/xsltconfig.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/xsltconfig.h.in ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/xsltutils.c ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/xsltutils.h ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/win32/Makefile.mingw ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/win32/Makefile.msvc ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/win32/libxslt.def.src ! modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/xsltConf.sh.in From nlisker at gmail.com Thu Nov 21 14:22:26 2019 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 21 Nov 2019 16:22:26 +0200 Subject: Typo in native-glass/win/OleUtils.h checkJavaException In-Reply-To: References: Message-ID: I can fix the typo via https://bugs.openjdk.java.net/browse/JDK-8228867. On Wed, Nov 20, 2019 at 5:07 PM Scott Palmer wrote: > I discovered this by accident while trying to figure out where a certain > console message was coming from while debugging. > > I saw this printed to the console when testing my (broken) code: > > Java Messsge:com/openalpr/jni/AlprException > > Note the typo in "Messsge" (the class name that follows is specific to what > I was testing). > > I couldn't find the string "Java Messsge" in any of my code or the library > I was trying out (OpenALPR). Eventually I found it was in glass.dll and > traced it to the checkJavaException function in OleUtils.h, line 230. > > On another note, I see that function is declared as "inline", though I > suspect the body of the "else" really doesn't need to be inlined and the > extra size it adds to the method could make it less likely to actually get > inlined. It seems the part that you want inlined is the if > (!env-ExceptionCheck()) { return S_OK; }. Wouldn't the rest run very rarely > and not benefit from being inlined? If that code does get inlined it would > bloat the code unnecessarily. The premature optimizer in me (it's an evil > I have trouble controlling) thinks this just makes stuff less > cache-friendly. I would put it in another not-inlined method. Also note > that using "else" is redundant. > > > Scott > From Rony.Flatscher at wu.ac.at Thu Nov 21 14:29:52 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 21 Nov 2019 15:29:52 +0100 Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com> <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at> Message-ID: On 15.11.2019 16:08, Rony G. Flatscher wrote: > On 14.11.2019 22:57, Kevin Rushforth wrote: >> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote: >>> On 14.11.2019 16:34, Rony G. Flatscher wrote: >>>> On 13.11.2019 19:50, Kevin Rushforth wrote: >>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: >>> ... cut ... >>>>>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all >>>>>> opensource) for >>>>>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a >>>>>> script to >>>>>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be >>>>>> o.k.? >>>>> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to >>>>> use that for a regression test / unit test. >>> If test units really seem to be important in this particular case, one possibility would be to >>> create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow >>> the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and >>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval() >>> methods return the ScriptContext at invocation time in order to allow inspection of the Bindings. >>> This way it would become also possible to write in addition test units that also check whether all >>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings. >> Something like that seems reasonable, and would avoid a dependence on Nashorn, which in addition >> to having all the problems you mentioned, is deprecated for removal. >> >>> However, >> Did you have something more to add? > No, sorry for that. Rewrote my e-mail and had sent it too early by mistake and without noticing. > > Will study all the procedures and create a testcase to be submitted at > as per your advice (and will report back under this thread once submitted). The testcase would use > an artificial ScriptEngine implementation that could be used for testunit testing as well. This > might take a while due to other obligations that I will have to meet during the next few days. > > ---rony O.K., so came up with a test case that contains an artificial script engine implementation for logging the eval() invocations together with the scripts to execute and the ScriptContext ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is meant to be also usable for creating script engine related test units for Java script hosts.) Packaged the source and binaries of that script engine as jar file that one merely needs to put on the CLASSPATH or add as a module. An updated FXMLLoader patch suggesting a fix is included as well. This version appends the line number to the file name if the script to be evaluated is embedded in the fxml-file, such that in case of an error it becomes possible to quickly find it in larger fxml files. With the zip-archive done I went to the Oracle Java Bug Database and just entered a bug report at got the internal "ID : 9062887". As it was not possible to attach/upload the zip-archive at this point, I will attach the zip-archive (contains all sources and binaries) to this e-mail. The contained reads: Testcase that demonstrates that FXMLLoader does not set [1] ScriptEngine.FILENAME and [2] ScriptEngine.ARGV entries in ScriptContext.ENGINE_SCOPE Bindings. To run the test case: - unzip testcaseFXMLLoaderScriptEngines.zip, - change into "testcaseFXMLLoaderScriptEngines" subdirectory, - run the testcase by issuing the following command: ? - Unix: ??????? java -cp .:RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope ? - Windows: ??????? java -cp .;RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope FXMLLoaderTestCase4ScriptEngineScope loads "demo_01.fxml" which is a controller that uses the pseudo script language rgf.scriptEngine.RgfPseudoScriptEngine, which logs the eval() invocations with the script code and the Bindings of the ScriptContext. Comparing "demo_01.fxml" and the output of the above test case demonstrates that FXMLLoader does not popuplate the [3] ENGINE_SCOPE Bindings with the filename of the script that gets evaluated, nor does add the ARGV entry to the ENGINE_SCOPE Bindings in the case of events (just an entry named "event"). In case of errors (during development or deployment) it is not possible therefore to point to the file (external file or the fxml-file defining explicitly script code) in which a runtime error has occurred. In the case of an event callback, if ARGV was defined the script code could directly fetch and interact with the supplied event object argument.? In the case that a script engine does not automatically make Bindings entry available as implicit variables (e.g.? for scoping reasons) it becomes cumbersome or even impossible in some script engine implementations (if they do not provide access to the Bindings) to get at the event argument of the callback invocation. The JSR-223 specifications lists all the (reserved) ScriptEngine constants that are meant to be used as reserved keys for the ENGINE_SCOPE Bindings, whenever appropriate cf.? [0] p.? l50 ff.? (A ScriptEngine is supposed to populate and maintain the ENGINE_SCOPE Bindings hence the definition of these constants with the class.) Running the above program on Windows yields the output captured and supplied in [4]. The supplied patch [5] changes FXMLLoader.java such, - that the ScriptEngine.FILENAME entry is always set in the ENGINE_SCOPE ? Bindings. In the case that the scripts are hosted in a fxml-file that file ? path will be used together with an appended string that hints at the location ? in the fxml file from where the script has been taken for evaluation. In the ? case of event handling scripts that appended string hints at the location in ? the fxml-file where the event attribute with the script code got used. - and that the ScriptEngine.ARGV entry is always set in the ENGINE_SCOPE ? Bindings for event callbacks using the 'event' object as the single argument. Applying the patch and running the above program on Linux yields the output captured and supplied in [6]. --- The jar-file [7] needs merely to be put on the CLASSPATH (or MODULE_PATH as a proper module-info.class is included, the module name is "rgf.scriptEngine") to make the pseudo scripting language available and to run the supplied testcase. The RgfPseudoScriptEngine (script engine name and extension is "rpsl") implementation should also make it possible to create test units for asserting that Java script hosts are populating the ScriptContext Bindings according to specifications. All Java classes come with their source code (the script engine service file and module-info.{java|class} are contained in the jar file). Having signed the OCA you may use all of the supplied code freely. If there is anything you need or that I could provide, please let me know. ---rony [0] JSR-223 specification at , download ??? : ??? "java_scripting-1_0-fr-spec.pdf" [1] [2] [3] [4] Output of running the testcase on Windows (Java 8): "info/Demo_output_without_fix.txt" [5] FXMLLoader patch: "info/diff_add_FILENAME_ARGV_to_FXMLLoader_preferable_20191121.txt" [6] Output of running the testcase after patching FXMLLoader with [5] on Linux (OpenJDK 11.0.5): ??? "info/Demo_output_with_fix_and_linenumbers.txt" [7] Pseudo script engine implementation to be put on the CLASSPATH or MODULE_PATH (module ??? name "rgf.scriptEngine"): [8] FXML test case: ??? - FXMLLoaderTestCase4ScriptEngineScope.{java|class} ????? ... loads "demo_01.rxml" and dumps the engine and global Bindings ??? - demo_01.fxml ??? ... FXML file using scripts in the pseudo script language [7] as controller, ??????? either as external or embedded scripts, including scripts for event ??????? handling Action and MouseClicked events ??? - demo_01_bottomscript.rpsl? ... serving as external script file ??? - demo_01_middlescript.rpsl? ... serving as external script file ??? - demo_01_topscript.rpsl???? ... serving as external script file If there is anything else I can/should do, please advise. (Being on the road in the next few days it might take me until the beginning of next week to get back.) ---rony From Rony.Flatscher at wu.ac.at Thu Nov 21 14:39:19 2019 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 21 Nov 2019 15:39:19 +0100 Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com> <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at> Message-ID: <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at> As the zip-archive attachment got stripped, for a brief time the zip-archive can be fetched from . ---rony On 21.11.2019 15:29, Rony G. Flatscher wrote: > On 15.11.2019 16:08, Rony G. Flatscher wrote: >> On 14.11.2019 22:57, Kevin Rushforth wrote: >>> On 11/14/2019 10:12 AM, Rony G. Flatscher wrote: >>>> On 14.11.2019 16:34, Rony G. Flatscher wrote: >>>>> On 13.11.2019 19:50, Kevin Rushforth wrote: >>>>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote: >>>> ... cut ... >>>>>>> To reproduce the testcase one would need ooRexx and the Java bridge BSF4ooRexx (all >>>>>>> opensource) for >>>>>>> which I could come up with a zip-archive (assuming binaries within should be 64-bit) and a >>>>>>> script to >>>>>>> set up the environment either for Windows, Linux or MacOS, whatever you advise. Would that be >>>>>>> o.k.? >>>>>> We prefer not to rely on third-party libraries for test cases. In any case we would not be able to >>>>>> use that for a regression test / unit test. >>>> If test units really seem to be important in this particular case, one possibility would be to >>>> create a minimalistic ScriptEngine implementation in pure Java just for the sole purpose to allow >>>> the creation of a test unit that is able to assert that FXMLLoader puts the ScriptEngine.ARGV and >>>> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having the ScriptEngine's eval() >>>> methods return the ScriptContext at invocation time in order to allow inspection of the Bindings. >>>> This way it would become also possible to write in addition test units that also check whether all >>>> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE Bindings. >>> Something like that seems reasonable, and would avoid a dependence on Nashorn, which in addition >>> to having all the problems you mentioned, is deprecated for removal. >>> >>>> However, >>> Did you have something more to add? >> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake and without noticing. >> >> Will study all the procedures and create a testcase to be submitted at >> as per your advice (and will report back under this thread once submitted). The testcase would use >> an artificial ScriptEngine implementation that could be used for testunit testing as well. This >> might take a while due to other obligations that I will have to meet during the next few days. >> >> ---rony > O.K., so came up with a test case that contains an artificial script engine implementation for > logging the eval() invocations together with the scripts to execute and the ScriptContext > ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is meant to be also usable > for creating script engine related test units for Java script hosts.) > > Packaged the source and binaries of that script engine as jar file that one merely needs to put on > the CLASSPATH or add as a module. > > An updated FXMLLoader patch suggesting a fix is included as well. This version appends the line > number to the file name if the script to be evaluated is embedded in the fxml-file, such that in > case of an error it becomes possible to quickly find it in larger fxml files. > > With the zip-archive done I went to the Oracle Java Bug Database and just entered a bug report at > got the internal "ID : 9062887". > > As it was not possible to attach/upload the zip-archive at this point, I will attach the zip-archive > (contains all sources and binaries) to this e-mail. The contained reads: > > Testcase that demonstrates that FXMLLoader does not set [1] > ScriptEngine.FILENAME and [2] ScriptEngine.ARGV entries in > ScriptContext.ENGINE_SCOPE Bindings. > > To run the test case: > > - unzip testcaseFXMLLoaderScriptEngines.zip, > > - change into "testcaseFXMLLoaderScriptEngines" subdirectory, > > - run the testcase by issuing the following command: > > ? - Unix: > > ??????? java -cp .:RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope > > ? - Windows: > > ??????? java -cp .;RgfPseudoScriptEngine.jar FXMLLoaderTestCase4ScriptEngineScope > > FXMLLoaderTestCase4ScriptEngineScope loads "demo_01.fxml" which is a controller > that uses the pseudo script language rgf.scriptEngine.RgfPseudoScriptEngine, > which logs the eval() invocations with the script code and the Bindings of the > ScriptContext. > > Comparing "demo_01.fxml" and the output of the above test case demonstrates that > FXMLLoader does not popuplate the [3] ENGINE_SCOPE Bindings with the filename of > the script that gets evaluated, nor does add the ARGV entry to the ENGINE_SCOPE > Bindings in the case of events (just an entry named "event"). > > In case of errors (during development or deployment) it is not possible > therefore to point to the file (external file or the fxml-file defining > explicitly script code) in which a runtime error has occurred. > > In the case of an event callback, if ARGV was defined the script code could > directly fetch and interact with the supplied event object argument.? In the > case that a script engine does not automatically make Bindings entry available > as implicit variables (e.g.? for scoping reasons) it becomes cumbersome or even > impossible in some script engine implementations (if they do not provide access > to the Bindings) to get at the event argument of the callback invocation. > > The JSR-223 specifications lists all the (reserved) ScriptEngine constants that > are meant to be used as reserved keys for the ENGINE_SCOPE Bindings, whenever > appropriate cf.? [0] p.? l50 ff.? (A ScriptEngine is supposed to populate and > maintain the ENGINE_SCOPE Bindings hence the definition of these constants with > the class.) > > Running the above program on Windows yields the output captured and supplied in > [4]. > > The supplied patch [5] changes FXMLLoader.java such, > > - that the ScriptEngine.FILENAME entry is always set in the ENGINE_SCOPE > ? Bindings. In the case that the scripts are hosted in a fxml-file that file > ? path will be used together with an appended string that hints at the location > ? in the fxml file from where the script has been taken for evaluation. In the > ? case of event handling scripts that appended string hints at the location in > ? the fxml-file where the event attribute with the script code got used. > > - and that the ScriptEngine.ARGV entry is always set in the ENGINE_SCOPE > ? Bindings for event callbacks using the 'event' object as the single argument. > > Applying the patch and running the above program on Linux yields the output > captured and supplied in [6]. > > --- > > The jar-file [7] needs merely to be put on the CLASSPATH (or MODULE_PATH as a > proper module-info.class is included, the module name is "rgf.scriptEngine") to > make the pseudo scripting language available and to run the supplied testcase. > The RgfPseudoScriptEngine (script engine name and extension is "rpsl") > implementation should also make it possible to create test units for asserting > that Java script hosts are populating the ScriptContext Bindings according to > specifications. > > All Java classes come with their source code (the script engine service file and > module-info.{java|class} are contained in the jar file). > > Having signed the OCA you may use all of the supplied code freely. > > If there is anything you need or that I could provide, please let me know. > > ---rony > > [0] JSR-223 specification at , download > ??? : > ??? "java_scripting-1_0-fr-spec.pdf" > > [1] > > > [2] > > > [3] > > > [4] Output of running the testcase on Windows (Java 8): "info/Demo_output_without_fix.txt" > > [5] FXMLLoader patch: "info/diff_add_FILENAME_ARGV_to_FXMLLoader_preferable_20191121.txt" > > [6] Output of running the testcase after patching FXMLLoader with [5] on Linux (OpenJDK 11.0.5): > ??? "info/Demo_output_with_fix_and_linenumbers.txt" > > [7] Pseudo script engine implementation to be put on the CLASSPATH or MODULE_PATH (module > ??? name "rgf.scriptEngine"): > > [8] FXML test case: > > ??? - FXMLLoaderTestCase4ScriptEngineScope.{java|class} > ????? ... loads "demo_01.rxml" and dumps the engine and global Bindings > > ??? - demo_01.fxml > ??? ... FXML file using scripts in the pseudo script language [7] as controller, > ??????? either as external or embedded scripts, including scripts for event > ??????? handling Action and MouseClicked events > > ??? - demo_01_bottomscript.rpsl? ... serving as external script file > > ??? - demo_01_middlescript.rpsl? ... serving as external script file > > ??? - demo_01_topscript.rpsl???? ... serving as external script file > > If there is anything else I can/should do, please advise. > (Being on the road in the next few days it might take me until the beginning of next week to get back.) > > ---rony > From fastegal at openjdk.java.net Thu Nov 21 15:38:51 2019 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 21 Nov 2019 15:38:51 GMT Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual code implementation In-Reply-To: References: Message-ID: On Wed, 13 Nov 2019 11:26:35 GMT, Hadzic Samir wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - e1a9d2d0: Add more unit tests upon review > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/6/files > - new: https://git.openjdk.java.net/jfx/pull/6/files/2b088993..e1a9d2d0 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/6/webrev.05 > - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.04-05 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8207957 > Stats: 185 lines in 2 files changed: 117 ins; 48 del; 20 mod > Patch: https://git.openjdk.java.net/jfx/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6 looks okay to me :) ---------------- Approved by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/6 From ajoseph at openjdk.java.net Thu Nov 21 16:56:06 2019 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 21 Nov 2019 16:56:06 GMT Subject: RFR: 8234593: Mark LeakTest.testGarbageCollectability as unstable Message-ID: <7rjvx2ohguek17MvoLP7sRaKVJAD9CCDMOljbM60b0E=.c3d6e435-91c9-4c1b-9da3-06925c2d54a3@github.com> The test.javafx.scene.web.LeakTest.testGarbageCollectability unit test is failing intermittently. ---------------- Commits: - 1f7c5c8e: 8234593: Mark LeakTest.testGarbageCollectability as unstable Changes: https://git.openjdk.java.net/jfx/pull/49/files Webrev: https://webrevs.openjdk.java.net/jfx/49/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234593 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/49/head:pull/49 PR: https://git.openjdk.java.net/jfx/pull/49 From johan.vos at gluonhq.com Thu Nov 21 17:26:39 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 21 Nov 2019 18:26:39 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> Message-ID: We have samples showing how to build and run JavaFX applications using GraalVM. See our blog post [1] with samples [2]. Keep in mind that JavaFX has some characteristics that make it non-trivial to apply native-image out of the box (reflection/jni configuration, platform-specific static libraries, including resources and bundles...). This is why we created Gluon Substrate [3], which does most of this work: Developers use a maven plugin [4] (gradle will be ready soon too) and this is used in the samples [2]. If you use GraalVM native-image without all the parameters that Gluon Substrate adds, you will most likely create a "fallback-image" that still require a JVM and some other resources to be available at runtime, and this can give strange results. While I don't exclude JavaFX bugs will surface using this approach, I think it's more likely you're seeing issues due to this "mixed mode". - Johan [1] https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ [2] https://github.com/gluonhq/client-samples [3] https://github.com/gluonhq/substrate [4] https://github.com/gluonhq/client-maven-plugin On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: > Hi, > > I would just like to know where JavaFX problems or bugs should be reported > which are strictly related to running on the just released GraalVM 19.3 > with > Java 11 support. Should they go into the regular JBS or should they be > reported > elsewhere? > > For example: I have observed that a large JavaFX application seems to work > correctly at first but then suddenly all text on all controls turns > white and > white on white or light grey is not really readable anymore. I've never > observed > such a behaviour on any other VM before. There is also no error message or > warning associated with this. It just happens. > > There even seem to be more issues when you try to use native-image. > > --Michael > > From kcr at openjdk.java.net Thu Nov 21 17:28:17 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Nov 2019 17:28:17 GMT Subject: [Approved] RFR: 8234593: Mark LeakTest.testGarbageCollectability as unstable In-Reply-To: <7rjvx2ohguek17MvoLP7sRaKVJAD9CCDMOljbM60b0E=.c3d6e435-91c9-4c1b-9da3-06925c2d54a3@github.com> References: <7rjvx2ohguek17MvoLP7sRaKVJAD9CCDMOljbM60b0E=.c3d6e435-91c9-4c1b-9da3-06925c2d54a3@github.com> Message-ID: On Thu, 21 Nov 2019 16:56:06 GMT, Arun Joseph wrote: > The test.javafx.scene.web.LeakTest.testGarbageCollectability unit test is failing intermittently. > > ---------------- > > Commits: > - 1f7c5c8e: 8234593: Mark LeakTest.testGarbageCollectability as unstable > > Changes: https://git.openjdk.java.net/jfx/pull/49/files > Webrev: https://webrevs.openjdk.java.net/jfx/49/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234593 > Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/49.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/49/head:pull/49 Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/49 From dlemmermann at gmail.com Thu Nov 21 17:30:28 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 21 Nov 2019 18:30:28 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> Message-ID: <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> After experimenting a lot today with the Gluon client plugin I must assume that currently not all of Java is supported via the substrate / GraalVM duo. For example I was unable to use the java.util.Preferences API. I also got an error that said Integer.parseInt() does not exist. Is that correct? > On 21 Nov 2019, at 18:26, Johan Vos wrote: > > We have samples showing how to build and run JavaFX applications using > GraalVM. See our blog post [1] with samples [2]. > > Keep in mind that JavaFX has some characteristics that make it non-trivial > to apply native-image out of the box (reflection/jni configuration, > platform-specific static libraries, including resources and bundles...). > This is why we created Gluon Substrate [3], which does most of this work: > Developers use a maven plugin [4] (gradle will be ready soon too) and this > is used in the samples [2]. > > If you use GraalVM native-image without all the parameters that Gluon > Substrate adds, you will most likely create a "fallback-image" that still > require a JVM and some other resources to be available at runtime, and this > can give strange results. While I don't exclude JavaFX bugs will surface > using this approach, I think it's more likely you're seeing issues due to > this "mixed mode". > > - Johan > > [1] > https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ > [2] https://github.com/gluonhq/client-samples > [3] https://github.com/gluonhq/substrate > [4] https://github.com/gluonhq/client-maven-plugin > > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: > >> Hi, >> >> I would just like to know where JavaFX problems or bugs should be reported >> which are strictly related to running on the just released GraalVM 19.3 >> with >> Java 11 support. Should they go into the regular JBS or should they be >> reported >> elsewhere? >> >> For example: I have observed that a large JavaFX application seems to work >> correctly at first but then suddenly all text on all controls turns >> white and >> white on white or light grey is not really readable anymore. I've never >> observed >> such a behaviour on any other VM before. There is also no error message or >> warning associated with this. It just happens. >> >> There even seem to be more issues when you try to use native-image. >> >> --Michael >> >> From kcr at openjdk.java.net Thu Nov 21 18:12:39 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Nov 2019 18:12:39 GMT Subject: [Integrated] RFR: 8234593: Mark LeakTest.testGarbageCollectability as unstable In-Reply-To: <7rjvx2ohguek17MvoLP7sRaKVJAD9CCDMOljbM60b0E=.c3d6e435-91c9-4c1b-9da3-06925c2d54a3@github.com> References: <7rjvx2ohguek17MvoLP7sRaKVJAD9CCDMOljbM60b0E=.c3d6e435-91c9-4c1b-9da3-06925c2d54a3@github.com> Message-ID: <4cdfd37e-9cfc-48a1-8b80-a16f722c537d@openjdk.org> Changeset: 4d3c723e Author: Arun Joseph Committer: Kevin Rushforth Date: 2019-11-21 18:12:26 +0000 URL: https://git.openjdk.java.net/jfx/commit/4d3c723e 8234593: Mark LeakTest.testGarbageCollectability as unstable Reviewed-by: kcr ! modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java From johan.vos at gluonhq.com Thu Nov 21 18:24:03 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 21 Nov 2019 19:24:03 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> Message-ID: Please file issues if you run into them: * JavaFX related: http://bugs.openjdk.java.net/ * GraalVM related: https://github.com/oracle/graal/issues/ * Substrate related: https://github.com/gluonhq/substrate/issues Keep in mind that with these new approaches come new docs, so make sure to read them. What you're saying sounds like you're not specifying the classes that are accessed via Reflection. (Integer.parseInt for example). In the future, agents will automatically add these for you, but for now you specify them (e.g. via the client-maven-plugin by specifying it in the reflectionlist property). The GraalVM native-image docs are pretty good in explaining the reasons behind this. All reflection/JNI required by the JavaFX framework should be handled by Substrate already. But if you use e.g. injection frameworks, you'll have to add the classes. See https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md and see the code in e.g. https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95 how this can be done with Substrate. - Johan On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann wrote: > After experimenting a lot today with the Gluon client plugin I must assume > that currently not all of Java is supported via the substrate / GraalVM duo. > For example I was unable to use the java.util.Preferences API. I also got > an error that said Integer.parseInt() does not exist. > > Is that correct? > > > On 21 Nov 2019, at 18:26, Johan Vos wrote: > > > > We have samples showing how to build and run JavaFX applications using > > GraalVM. See our blog post [1] with samples [2]. > > > > Keep in mind that JavaFX has some characteristics that make it > non-trivial > > to apply native-image out of the box (reflection/jni configuration, > > platform-specific static libraries, including resources and bundles...). > > This is why we created Gluon Substrate [3], which does most of this work: > > Developers use a maven plugin [4] (gradle will be ready soon too) and > this > > is used in the samples [2]. > > > > If you use GraalVM native-image without all the parameters that Gluon > > Substrate adds, you will most likely create a "fallback-image" that still > > require a JVM and some other resources to be available at runtime, and > this > > can give strange results. While I don't exclude JavaFX bugs will surface > > using this approach, I think it's more likely you're seeing issues due to > > this "mixed mode". > > > > - Johan > > > > [1] > > > https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ > > [2] https://github.com/gluonhq/client-samples > > [3] https://github.com/gluonhq/substrate > > [4] https://github.com/gluonhq/client-maven-plugin > > > > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: > > > >> Hi, > >> > >> I would just like to know where JavaFX problems or bugs should be > reported > >> which are strictly related to running on the just released GraalVM 19.3 > >> with > >> Java 11 support. Should they go into the regular JBS or should they be > >> reported > >> elsewhere? > >> > >> For example: I have observed that a large JavaFX application seems to > work > >> correctly at first but then suddenly all text on all controls turns > >> white and > >> white on white or light grey is not really readable anymore. I've never > >> observed > >> such a behaviour on any other VM before. There is also no error message > or > >> warning associated with this. It just happens. > >> > >> There even seem to be more issues when you try to use native-image. > >> > >> --Michael > >> > >> > > From dlemmermann at gmail.com Thu Nov 21 18:29:35 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 21 Nov 2019 19:29:35 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> Message-ID: <35059F92-7BA6-4318-98F3-DACEBD772F3E@gmail.com> OK, I understand. But a real world application that already consists of say 100000 lines of code with tons of dependencies would require an enormous amount of work before the list of classes that need to be added to the reflections list is complete. This would be a trial and error approach. Launch ?. ?oh, that is missing? ?. launch ?. ?oh that is missing? ?. etc ?. correct? Dirk > On 21 Nov 2019, at 19:24, Johan Vos wrote: > > Please file issues if you run into them: > * JavaFX related: http://bugs.openjdk.java.net/ > * GraalVM related: https://github.com/oracle/graal/issues/ > * Substrate related: https://github.com/gluonhq/substrate/issues > > Keep in mind that with these new approaches come new docs, so make sure to read them. > > What you're saying sounds like you're not specifying the classes that are accessed via Reflection. (Integer.parseInt for example). In the future, agents will automatically add these for you, but for now you specify them (e.g. via the client-maven-plugin by specifying it in the reflectionlist property). > The GraalVM native-image docs are pretty good in explaining the reasons behind this. > All reflection/JNI required by the JavaFX framework should be handled by Substrate already. But if you use e.g. injection frameworks, you'll have to add the classes. See https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md and see the code in e.g. https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95 how this can be done with Substrate. > > - Johan > > > > On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann > wrote: > After experimenting a lot today with the Gluon client plugin I must assume that currently not all of Java is supported via the substrate / GraalVM duo. > For example I was unable to use the java.util.Preferences API. I also got an error that said Integer.parseInt() does not exist. > > Is that correct? > > > On 21 Nov 2019, at 18:26, Johan Vos > wrote: > > > > We have samples showing how to build and run JavaFX applications using > > GraalVM. See our blog post [1] with samples [2]. > > > > Keep in mind that JavaFX has some characteristics that make it non-trivial > > to apply native-image out of the box (reflection/jni configuration, > > platform-specific static libraries, including resources and bundles...). > > This is why we created Gluon Substrate [3], which does most of this work: > > Developers use a maven plugin [4] (gradle will be ready soon too) and this > > is used in the samples [2]. > > > > If you use GraalVM native-image without all the parameters that Gluon > > Substrate adds, you will most likely create a "fallback-image" that still > > require a JVM and some other resources to be available at runtime, and this > > can give strange results. While I don't exclude JavaFX bugs will surface > > using this approach, I think it's more likely you're seeing issues due to > > this "mixed mode". > > > > - Johan > > > > [1] > > https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ > > [2] https://github.com/gluonhq/client-samples > > [3] https://github.com/gluonhq/substrate > > [4] https://github.com/gluonhq/client-maven-plugin > > > > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus > wrote: > > > >> Hi, > >> > >> I would just like to know where JavaFX problems or bugs should be reported > >> which are strictly related to running on the just released GraalVM 19.3 > >> with > >> Java 11 support. Should they go into the regular JBS or should they be > >> reported > >> elsewhere? > >> > >> For example: I have observed that a large JavaFX application seems to work > >> correctly at first but then suddenly all text on all controls turns > >> white and > >> white on white or light grey is not really readable anymore. I've never > >> observed > >> such a behaviour on any other VM before. There is also no error message or > >> warning associated with this. It just happens. > >> > >> There even seem to be more issues when you try to use native-image. > >> > >> --Michael > >> > >> > From johan.vos at gluonhq.com Thu Nov 21 18:44:46 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 21 Nov 2019 19:44:46 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: <35059F92-7BA6-4318-98F3-DACEBD772F3E@gmail.com> References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> <35059F92-7BA6-4318-98F3-DACEBD772F3E@gmail.com> Message-ID: As I said a number of times, this is ground-breaking new area, and still work in progress. There is a reason we start with "Hello, FX" and not with "Launch Apollo 11". If you expect a 100,000 lines of code application to run without any issue from day 1 on a new platform, yes, you might be disappointed. Although reading the docs will probably making it not extremely hard. Worst case you add all classes you have to the reflection list -- at the price of a big footprint. The native-image agent does a great job too, but that should be discussed in the GraalVM slack or on the GraalVM issue tracker. (we actually used the agent to come up with the required reflection list for the FX core classes and it worked very well). All components are written in Java though (OpenJFX, GraalVM, Substrate) and open-source. So you're very welcome to make them better. - Johan On Thu, Nov 21, 2019 at 7:29 PM Dirk Lemmermann wrote: > OK, I understand. But a real world application that already consists of > say 100000 lines of code with tons of dependencies would require an > enormous amount of work before the list of classes that need to be added to > the reflections list is complete. This would be a trial and error approach. > Launch ?. ?oh, that is missing? ?. launch ?. ?oh that is missing? ?. etc ?. > correct? > > Dirk > > On 21 Nov 2019, at 19:24, Johan Vos wrote: > > Please file issues if you run into them: > * JavaFX related: http://bugs.openjdk.java.net/ > * GraalVM related: https://github.com/oracle/graal/issues/ > * Substrate related: https://github.com/gluonhq/substrate/issues > > Keep in mind that with these new approaches come new docs, so make sure to > read them. > > What you're saying sounds like you're not specifying the classes that are > accessed via Reflection. (Integer.parseInt for example). In the future, > agents will automatically add these for you, but for now you specify them > (e.g. via the client-maven-plugin by specifying it in the reflectionlist > property). > The GraalVM native-image docs are pretty good in explaining the reasons > behind this. > All reflection/JNI required by the JavaFX framework should be handled by > Substrate already. But if you use e.g. injection frameworks, you'll have to > add the classes. See > https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md and > see the code in e.g. > https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95 how > this can be done with Substrate. > > - Johan > > > > On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann > wrote: > >> After experimenting a lot today with the Gluon client plugin I must >> assume that currently not all of Java is supported via the substrate / >> GraalVM duo. >> For example I was unable to use the java.util.Preferences API. I also got >> an error that said Integer.parseInt() does not exist. >> >> Is that correct? >> >> > On 21 Nov 2019, at 18:26, Johan Vos wrote: >> > >> > We have samples showing how to build and run JavaFX applications using >> > GraalVM. See our blog post [1] with samples [2]. >> > >> > Keep in mind that JavaFX has some characteristics that make it >> non-trivial >> > to apply native-image out of the box (reflection/jni configuration, >> > platform-specific static libraries, including resources and bundles...). >> > This is why we created Gluon Substrate [3], which does most of this >> work: >> > Developers use a maven plugin [4] (gradle will be ready soon too) and >> this >> > is used in the samples [2]. >> > >> > If you use GraalVM native-image without all the parameters that Gluon >> > Substrate adds, you will most likely create a "fallback-image" that >> still >> > require a JVM and some other resources to be available at runtime, and >> this >> > can give strange results. While I don't exclude JavaFX bugs will surface >> > using this approach, I think it's more likely you're seeing issues due >> to >> > this "mixed mode". >> > >> > - Johan >> > >> > [1] >> > >> https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ >> > [2] https://github.com/gluonhq/client-samples >> > [3] https://github.com/gluonhq/substrate >> > [4] https://github.com/gluonhq/client-maven-plugin >> > >> > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: >> > >> >> Hi, >> >> >> >> I would just like to know where JavaFX problems or bugs should be >> reported >> >> which are strictly related to running on the just released GraalVM 19.3 >> >> with >> >> Java 11 support. Should they go into the regular JBS or should they be >> >> reported >> >> elsewhere? >> >> >> >> For example: I have observed that a large JavaFX application seems to >> work >> >> correctly at first but then suddenly all text on all controls turns >> >> white and >> >> white on white or light grey is not really readable anymore. I've never >> >> observed >> >> such a behaviour on any other VM before. There is also no error >> message or >> >> warning associated with this. It just happens. >> >> >> >> There even seem to be more issues when you try to use native-image. >> >> >> >> --Michael >> >> >> >> >> >> > From thiago.sayao at clamed.com.br Thu Nov 21 19:38:25 2019 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Thu, 21 Nov 2019 19:38:25 +0000 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> <35059F92-7BA6-4318-98F3-DACEBD772F3E@gmail.com>, Message-ID: Well, GraalVM page says it's production ready. By production ready I understand something way beyond "Hello, FX". Although, I would not expert perfection, since it's new technology. The blue text also happens on my machine, running Linux. Probably a bug on graalvm, as it does not happen with standard jre. Seems like a very hard to find bug. Cheers. ________________________________ De: openjfx-dev em nome de Johan Vos Enviado: quinta-feira, 21 de novembro de 2019 15:44 Para: Dirk Lemmermann Cc: OpenJFX Assunto: Re: JavaFX-Bugs on GraalVM 19.3 (Java 11) As I said a number of times, this is ground-breaking new area, and still work in progress. There is a reason we start with "Hello, FX" and not with "Launch Apollo 11". If you expect a 100,000 lines of code application to run without any issue from day 1 on a new platform, yes, you might be disappointed. Although reading the docs will probably making it not extremely hard. Worst case you add all classes you have to the reflection list -- at the price of a big footprint. The native-image agent does a great job too, but that should be discussed in the GraalVM slack or on the GraalVM issue tracker. (we actually used the agent to come up with the required reflection list for the FX core classes and it worked very well). All components are written in Java though (OpenJFX, GraalVM, Substrate) and open-source. So you're very welcome to make them better. - Johan On Thu, Nov 21, 2019 at 7:29 PM Dirk Lemmermann wrote: > OK, I understand. But a real world application that already consists of > say 100000 lines of code with tons of dependencies would require an > enormous amount of work before the list of classes that need to be added to > the reflections list is complete. This would be a trial and error approach. > Launch ?. ?oh, that is missing? ?. launch ?. ?oh that is missing? ?. etc ?. > correct? > > Dirk > > On 21 Nov 2019, at 19:24, Johan Vos wrote: > > Please file issues if you run into them: > * JavaFX related: http://bugs.openjdk.java.net/ > * GraalVM related: https://github.com/oracle/graal/issues/ > * Substrate related: https://github.com/gluonhq/substrate/issues > > Keep in mind that with these new approaches come new docs, so make sure to > read them. > > What you're saying sounds like you're not specifying the classes that are > accessed via Reflection. (Integer.parseInt for example). In the future, > agents will automatically add these for you, but for now you specify them > (e.g. via the client-maven-plugin by specifying it in the reflectionlist > property). > The GraalVM native-image docs are pretty good in explaining the reasons > behind this. > All reflection/JNI required by the JavaFX framework should be handled by > Substrate already. But if you use e.g. injection frameworks, you'll have to > add the classes. See > https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md and > see the code in e.g. > https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95 how > this can be done with Substrate. > > - Johan > > > > On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann > wrote: > >> After experimenting a lot today with the Gluon client plugin I must >> assume that currently not all of Java is supported via the substrate / >> GraalVM duo. >> For example I was unable to use the java.util.Preferences API. I also got >> an error that said Integer.parseInt() does not exist. >> >> Is that correct? >> >> > On 21 Nov 2019, at 18:26, Johan Vos wrote: >> > >> > We have samples showing how to build and run JavaFX applications using >> > GraalVM. See our blog post [1] with samples [2]. >> > >> > Keep in mind that JavaFX has some characteristics that make it >> non-trivial >> > to apply native-image out of the box (reflection/jni configuration, >> > platform-specific static libraries, including resources and bundles...). >> > This is why we created Gluon Substrate [3], which does most of this >> work: >> > Developers use a maven plugin [4] (gradle will be ready soon too) and >> this >> > is used in the samples [2]. >> > >> > If you use GraalVM native-image without all the parameters that Gluon >> > Substrate adds, you will most likely create a "fallback-image" that >> still >> > require a JVM and some other resources to be available at runtime, and >> this >> > can give strange results. While I don't exclude JavaFX bugs will surface >> > using this approach, I think it's more likely you're seeing issues due >> to >> > this "mixed mode". >> > >> > - Johan >> > >> > [1] >> > >> https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ >> > [2] https://github.com/gluonhq/client-samples >> > [3] https://github.com/gluonhq/substrate >> > [4] https://github.com/gluonhq/client-maven-plugin >> > >> > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: >> > >> >> Hi, >> >> >> >> I would just like to know where JavaFX problems or bugs should be >> reported >> >> which are strictly related to running on the just released GraalVM 19.3 >> >> with >> >> Java 11 support. Should they go into the regular JBS or should they be >> >> reported >> >> elsewhere? >> >> >> >> For example: I have observed that a large JavaFX application seems to >> work >> >> correctly at first but then suddenly all text on all controls turns >> >> white and >> >> white on white or light grey is not really readable anymore. I've never >> >> observed >> >> such a behaviour on any other VM before. There is also no error >> message or >> >> warning associated with this. It just happens. >> >> >> >> There even seem to be more issues when you try to use native-image. >> >> >> >> --Michael >> >> >> >> >> >> > From johan at lodgon.com Thu Nov 21 20:36:16 2019 From: johan at lodgon.com (Johan Vos) Date: Thu, 21 Nov 2019 21:36:16 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> <35059F92-7BA6-4318-98F3-DACEBD772F3E@gmail.com> Message-ID: We're running pretty complex apps already, way beyond HelloFX. Startup time is amazing. GraalVM itself is already great. Tooling and configuration are the area where lots of work is still needed, and where Gluon Substrate is filling the gap. It still requires much more work, and documentation -- fully agree with that. The color-bug is an interesting one. Would you mind filing an issue at https://github.com/oracle/graal/issues/ ? I'll look into it, but it would be good to have it in the appropriate issue tracker so we can easily circle back to other developers in case it is relevant. - Johan Op do 21 nov. 2019 om 20:39 schreef Thiago Milczarek Sayao < thiago.sayao at clamed.com.br>: > Well, GraalVM page says it's production ready. > > By production ready I understand something way beyond "Hello, FX". > Although, I would not expert perfection, since it's new technology. > > The blue text also happens on my machine, running Linux. Probably a bug on > graalvm, as it does not happen with standard jre. > > Seems like a very hard to find bug. > > Cheers. > > ________________________________ > De: openjfx-dev em nome de Johan > Vos > Enviado: quinta-feira, 21 de novembro de 2019 15:44 > Para: Dirk Lemmermann > Cc: OpenJFX > Assunto: Re: JavaFX-Bugs on GraalVM 19.3 (Java 11) > > As I said a number of times, this is ground-breaking new area, and still > work in progress. There is a reason we start with "Hello, FX" and not with > "Launch Apollo 11". > If you expect a 100,000 lines of code application to run without any issue > from day 1 on a new platform, yes, you might be disappointed. Although > reading the docs will probably making it not extremely hard. Worst case you > add all classes you have to the reflection list -- at the price of a big > footprint. > > The native-image agent does a great job too, but that should be discussed > in the GraalVM slack or on the GraalVM issue tracker. (we actually used the > agent to come up with the required reflection list for the FX core classes > and it worked very well). > > All components are written in Java though (OpenJFX, GraalVM, Substrate) and > open-source. So you're very welcome to make them better. > > - Johan > > On Thu, Nov 21, 2019 at 7:29 PM Dirk Lemmermann > wrote: > > > OK, I understand. But a real world application that already consists of > > say 100000 lines of code with tons of dependencies would require an > > enormous amount of work before the list of classes that need to be added > to > > the reflections list is complete. This would be a trial and error > approach. > > Launch ?. ?oh, that is missing? ?. launch ?. ?oh that is missing? ?. etc > ?. > > correct? > > > > Dirk > > > > On 21 Nov 2019, at 19:24, Johan Vos wrote: > > > > Please file issues if you run into them: > > * JavaFX related: http://bugs.openjdk.java.net/ > > * GraalVM related: https://github.com/oracle/graal/issues/ > > * Substrate related: https://github.com/gluonhq/substrate/issues > > > > Keep in mind that with these new approaches come new docs, so make sure > to > > read them. > > > > What you're saying sounds like you're not specifying the classes that are > > accessed via Reflection. (Integer.parseInt for example). In the future, > > agents will automatically add these for you, but for now you specify them > > (e.g. via the client-maven-plugin by specifying it in the reflectionlist > > property). > > The GraalVM native-image docs are pretty good in explaining the reasons > > behind this. > > All reflection/JNI required by the JavaFX framework should be handled by > > Substrate already. But if you use e.g. injection frameworks, you'll have > to > > add the classes. See > > https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md > and > > see the code in e.g. > > > https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95 > how > > this can be done with Substrate. > > > > - Johan > > > > > > > > On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann > > wrote: > > > >> After experimenting a lot today with the Gluon client plugin I must > >> assume that currently not all of Java is supported via the substrate / > >> GraalVM duo. > >> For example I was unable to use the java.util.Preferences API. I also > got > >> an error that said Integer.parseInt() does not exist. > >> > >> Is that correct? > >> > >> > On 21 Nov 2019, at 18:26, Johan Vos wrote: > >> > > >> > We have samples showing how to build and run JavaFX applications using > >> > GraalVM. See our blog post [1] with samples [2]. > >> > > >> > Keep in mind that JavaFX has some characteristics that make it > >> non-trivial > >> > to apply native-image out of the box (reflection/jni configuration, > >> > platform-specific static libraries, including resources and > bundles...). > >> > This is why we created Gluon Substrate [3], which does most of this > >> work: > >> > Developers use a maven plugin [4] (gradle will be ready soon too) and > >> this > >> > is used in the samples [2]. > >> > > >> > If you use GraalVM native-image without all the parameters that Gluon > >> > Substrate adds, you will most likely create a "fallback-image" that > >> still > >> > require a JVM and some other resources to be available at runtime, and > >> this > >> > can give strange results. While I don't exclude JavaFX bugs will > surface > >> > using this approach, I think it's more likely you're seeing issues due > >> to > >> > this "mixed mode". > >> > > >> > - Johan > >> > > >> > [1] > >> > > >> > https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ > >> > [2] https://github.com/gluonhq/client-samples > >> > [3] https://github.com/gluonhq/substrate > >> > [4] https://github.com/gluonhq/client-maven-plugin > >> > > >> > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: > >> > > >> >> Hi, > >> >> > >> >> I would just like to know where JavaFX problems or bugs should be > >> reported > >> >> which are strictly related to running on the just released GraalVM > 19.3 > >> >> with > >> >> Java 11 support. Should they go into the regular JBS or should they > be > >> >> reported > >> >> elsewhere? > >> >> > >> >> For example: I have observed that a large JavaFX application seems to > >> work > >> >> correctly at first but then suddenly all text on all controls turns > >> >> white and > >> >> white on white or light grey is not really readable anymore. I've > never > >> >> observed > >> >> such a behaviour on any other VM before. There is also no error > >> message or > >> >> warning associated with this. It just happens. > >> >> > >> >> There even seem to be more issues when you try to use native-image. > >> >> > >> >> --Michael > >> >> > >> >> > >> > >> > > > From mp at jugs.org Thu Nov 21 22:45:36 2019 From: mp at jugs.org (Michael Paus) Date: Thu, 21 Nov 2019 23:45:36 +0100 Subject: JavaFX-Bugs on GraalVM 19.3 (Java 11) In-Reply-To: References: <3038293f-c5a2-d7d0-d1a8-bd243c921466@jugs.org> <5ABF747F-C698-424E-8651-3E6F943D88D5@gmail.com> <35059F92-7BA6-4318-98F3-DACEBD772F3E@gmail.com> Message-ID: I have filed this issue as: https://github.com/oracle/graal/issues/1867 This issue can be seen if you just use the GraalVM 19.3(11) in JIT mode as well as with a native-image via --force-fallback. When trying to create a real native-image of my application via the gluon client-plugin I just get lots of errors which I still have to sort out. The samples all work (there is a bug in one of the POMs though), so my system setup seems to be correct. It is just for large apps where the build process freaks out. --Michael Am 21.11.19 um 21:36 schrieb Johan Vos: > We're running pretty complex apps already, way beyond HelloFX. > Startup time is amazing. GraalVM itself is already great. > > Tooling and configuration are the area where lots of work is still needed, > and where Gluon Substrate is filling the gap. It still requires much more > work, and documentation -- fully agree with that. > > The color-bug is an interesting one. Would you mind filing an issue at > https://github.com/oracle/graal/issues/ ? I'll look into it, but it would > be good to have it in the appropriate issue tracker so we can easily circle > back to other developers in case it is relevant. > > - Johan > > > Op do 21 nov. 2019 om 20:39 schreef Thiago Milczarek Sayao < > thiago.sayao at clamed.com.br>: > >> Well, GraalVM page says it's production ready. >> >> By production ready I understand something way beyond "Hello, FX". >> Although, I would not expert perfection, since it's new technology. >> >> The blue text also happens on my machine, running Linux. Probably a bug on >> graalvm, as it does not happen with standard jre. >> >> Seems like a very hard to find bug. >> >> Cheers. >> >> ________________________________ >> De: openjfx-dev em nome de Johan >> Vos >> Enviado: quinta-feira, 21 de novembro de 2019 15:44 >> Para: Dirk Lemmermann >> Cc: OpenJFX >> Assunto: Re: JavaFX-Bugs on GraalVM 19.3 (Java 11) >> >> As I said a number of times, this is ground-breaking new area, and still >> work in progress. There is a reason we start with "Hello, FX" and not with >> "Launch Apollo 11". >> If you expect a 100,000 lines of code application to run without any issue >> from day 1 on a new platform, yes, you might be disappointed. Although >> reading the docs will probably making it not extremely hard. Worst case you >> add all classes you have to the reflection list -- at the price of a big >> footprint. >> >> The native-image agent does a great job too, but that should be discussed >> in the GraalVM slack or on the GraalVM issue tracker. (we actually used the >> agent to come up with the required reflection list for the FX core classes >> and it worked very well). >> >> All components are written in Java though (OpenJFX, GraalVM, Substrate) and >> open-source. So you're very welcome to make them better. >> >> - Johan >> >> On Thu, Nov 21, 2019 at 7:29 PM Dirk Lemmermann >> wrote: >> >>> OK, I understand. But a real world application that already consists of >>> say 100000 lines of code with tons of dependencies would require an >>> enormous amount of work before the list of classes that need to be added >> to >>> the reflections list is complete. This would be a trial and error >> approach. >>> Launch ?. ?oh, that is missing? ?. launch ?. ?oh that is missing? ?. etc >> ?. >>> correct? >>> >>> Dirk >>> >>> On 21 Nov 2019, at 19:24, Johan Vos wrote: >>> >>> Please file issues if you run into them: >>> * JavaFX related: http://bugs.openjdk.java.net/ >>> * GraalVM related: https://github.com/oracle/graal/issues/ >>> * Substrate related: https://github.com/gluonhq/substrate/issues >>> >>> Keep in mind that with these new approaches come new docs, so make sure >> to >>> read them. >>> >>> What you're saying sounds like you're not specifying the classes that are >>> accessed via Reflection. (Integer.parseInt for example). In the future, >>> agents will automatically add these for you, but for now you specify them >>> (e.g. via the client-maven-plugin by specifying it in the reflectionlist >>> property). >>> The GraalVM native-image docs are pretty good in explaining the reasons >>> behind this. >>> All reflection/JNI required by the JavaFX framework should be handled by >>> Substrate already. But if you use e.g. injection frameworks, you'll have >> to >>> add the classes. See >>> https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md >> and >>> see the code in e.g. >>> >> https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95 >> how >>> this can be done with Substrate. >>> >>> - Johan >>> >>> >>> >>> On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann >>> wrote: >>> >>>> After experimenting a lot today with the Gluon client plugin I must >>>> assume that currently not all of Java is supported via the substrate / >>>> GraalVM duo. >>>> For example I was unable to use the java.util.Preferences API. I also >> got >>>> an error that said Integer.parseInt() does not exist. >>>> >>>> Is that correct? >>>> >>>>> On 21 Nov 2019, at 18:26, Johan Vos wrote: >>>>> >>>>> We have samples showing how to build and run JavaFX applications using >>>>> GraalVM. See our blog post [1] with samples [2]. >>>>> >>>>> Keep in mind that JavaFX has some characteristics that make it >>>> non-trivial >>>>> to apply native-image out of the box (reflection/jni configuration, >>>>> platform-specific static libraries, including resources and >> bundles...). >>>>> This is why we created Gluon Substrate [3], which does most of this >>>> work: >>>>> Developers use a maven plugin [4] (gradle will be ready soon too) and >>>> this >>>>> is used in the samples [2]. >>>>> >>>>> If you use GraalVM native-image without all the parameters that Gluon >>>>> Substrate adds, you will most likely create a "fallback-image" that >>>> still >>>>> require a JVM and some other resources to be available at runtime, and >>>> this >>>>> can give strange results. While I don't exclude JavaFX bugs will >> surface >>>>> using this approach, I think it's more likely you're seeing issues due >>>> to >>>>> this "mixed mode". >>>>> >>>>> - Johan >>>>> >>>>> [1] >>>>> >> https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ >>>>> [2] https://github.com/gluonhq/client-samples >>>>> [3] https://github.com/gluonhq/substrate >>>>> [4] https://github.com/gluonhq/client-maven-plugin >>>>> >>>>> On Wed, Nov 20, 2019 at 10:22 PM Michael Paus wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I would just like to know where JavaFX problems or bugs should be >>>> reported >>>>>> which are strictly related to running on the just released GraalVM >> 19.3 >>>>>> with >>>>>> Java 11 support. Should they go into the regular JBS or should they >> be >>>>>> reported >>>>>> elsewhere? >>>>>> >>>>>> For example: I have observed that a large JavaFX application seems to >>>> work >>>>>> correctly at first but then suddenly all text on all controls turns >>>>>> white and >>>>>> white on white or light grey is not really readable anymore. I've >> never >>>>>> observed >>>>>> such a behaviour on any other VM before. There is also no error >>>> message or >>>>>> warning associated with this. It just happens. >>>>>> >>>>>> There even seem to be more issues when you try to use native-image. >>>>>> >>>>>> --Michael >>>>>> >>>>>> >>>> From kcr at openjdk.java.net Thu Nov 21 23:39:36 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Nov 2019 23:39:36 GMT Subject: [Approved] RFR: 8230610: Upgrade GStreamer to the latest 1.16.1 In-Reply-To: References: Message-ID: On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev wrote: > - Upgraded GStreamer to 1.16.1 > - Upgraded GLib to 2.62.2. > - Removed glib-liteD.def, since it almost identical to release version glib-lite.def. Debug build will use glib-lite.def. > - No changes to other parts of code, except minor changes to makefiles. > > ---------------- > > Commits: > - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 > > Changes: https://git.openjdk.java.net/jfx/pull/48/files > Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 > Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod > Patch: https://git.openjdk.java.net/jfx/pull/48.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 Looks good to me. I did have one question, but it's just for my information. modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.c line 2601: > 2600: #pragma GCC diagnostic push > 2601: #pragma GCC diagnostic ignored "-Wformat-nonliteral" > 2602: #endif // G_OS_WIN32 Did you add this because it will fail on 32-bit Windows without it? This logic is otherwise untouched as part of the upgrade. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/48 From almatvee at openjdk.java.net Fri Nov 22 00:33:21 2019 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 22 Nov 2019 00:33:21 GMT Subject: [Approved] RFR: 8230610: Upgrade GStreamer to the latest 1.16.1 In-Reply-To: References: Message-ID: On Thu, 21 Nov 2019 23:39:36 GMT, Kevin Rushforth wrote: > On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev wrote: > >> - Upgraded GStreamer to 1.16.1 >> - Upgraded GLib to 2.62.2. >> - Removed glib-liteD.def, since it almost identical to release version glib-lite.def. Debug build will use glib-lite.def. >> - No changes to other parts of code, except minor changes to makefiles. >> >> ---------------- >> >> Commits: >> - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 >> >> Changes: https://git.openjdk.java.net/jfx/pull/48/files >> Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 >> Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod >> Patch: https://git.openjdk.java.net/jfx/pull/48.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 > > Looks good to me. I did have one question, but it's just for my information. > > modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.c line 2601: > >> 2600: #pragma GCC diagnostic push >> 2601: #pragma GCC diagnostic ignored "-Wformat-nonliteral" >> 2602: #endif // G_OS_WIN32 > > Did you add this because it will fail on 32-bit Windows without it? This logic is otherwise untouched as part of the upgrade. > > ---------------- > > Approved by kcr (Lead). G_OS_WIN32 defined for both 32 and 64-bit Windows. Yes, I disable it because build fails on Windows due to unknown GCC pragma. PR: https://git.openjdk.java.net/jfx/pull/48 From kcr at openjdk.java.net Fri Nov 22 21:13:06 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Nov 2019 21:13:06 GMT Subject: RFR: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK In-Reply-To: References: Message-ID: On Fri, 22 Nov 2019 21:13:05 GMT, Kevin Rushforth wrote: > Now that we have switched to using gradle 6 we can switch to using JDK 13 as the boot JDK for JavaFX 14 builds. The latest JDK 13 update release is JDK 13.0.1. > > This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to generate class files using `-source 11 -target 11`. > > ---------------- > > Commits: > - 741414f1: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK > > Changes: https://git.openjdk.java.net/jfx/pull/51/files > Webrev: https://webrevs.openjdk.java.net/jfx/51/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232064 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/51.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/51/head:pull/51 Reviewers: @arapte, @johanvos PR: https://git.openjdk.java.net/jfx/pull/51 From kcr at openjdk.java.net Fri Nov 22 21:13:05 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Nov 2019 21:13:05 GMT Subject: RFR: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK Message-ID: Now that we have switched to using gradle 6 we can switch to using JDK 13 as the boot JDK for JavaFX 14 builds. The latest JDK 13 update release is JDK 13.0.1. This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to generate class files using `-source 11 -target 11`. ---------------- Commits: - 741414f1: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK Changes: https://git.openjdk.java.net/jfx/pull/51/files Webrev: https://webrevs.openjdk.java.net/jfx/51/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232064 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/51/head:pull/51 PR: https://git.openjdk.java.net/jfx/pull/51 From prr at openjdk.java.net Fri Nov 22 22:54:17 2019 From: prr at openjdk.java.net (Phil Race) Date: Fri, 22 Nov 2019 22:54:17 GMT Subject: [Approved] RFR: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK In-Reply-To: References: Message-ID: On Fri, 22 Nov 2019 21:13:05 GMT, Kevin Rushforth wrote: > Now that we have switched to using gradle 6 we can switch to using JDK 13 as the boot JDK for JavaFX 14 builds. The latest JDK 13 update release is JDK 13.0.1. > > This will not change the minimum JDK version needed to build or run JavaFX, which remains at 11. We will continue to generate class files using `-source 11 -target 11`. > > ---------------- > > Commits: > - 741414f1: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK > > Changes: https://git.openjdk.java.net/jfx/pull/51/files > Webrev: https://webrevs.openjdk.java.net/jfx/51/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8232064 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/51.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/51/head:pull/51 Approved by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/51 From kcr at openjdk.java.net Sat Nov 23 16:40:11 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 23 Nov 2019 16:40:11 GMT Subject: RFR: 8234704: Fix attribution in libxslt.md Message-ID: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> We discovered three minor differences between the `libxslt.md` file and the libxslt-1.1.34 source bundle: 1. The copyright years didn't match the source 2. The following line was missing: Licence for libxslt except libexslt 3. The terms currently lists `BLFS` rather than `DANIEL VEILLARD` in one place. Note to reviewers: I pushed this in two commits as an aid to reviewing it (as with any other PR, it will be squashed during integration). The first commit just fixes the above three issues without any reformatting of the lines. The second commit has no changes in the content itself, but re-wraps the lines to match the source. ---------------- Commits: - 07be5f50: Reformat to match format of original source -- no changes in content - 68adb259: 8234704: Fix attribution in libxslt.md Changes: https://git.openjdk.java.net/jfx/pull/52/files Webrev: https://webrevs.openjdk.java.net/jfx/52/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234704 Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jfx/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/52/head:pull/52 PR: https://git.openjdk.java.net/jfx/pull/52 From kcr at openjdk.java.net Sat Nov 23 16:40:56 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 23 Nov 2019 16:40:56 GMT Subject: RFR: 8234704: Fix attribution in libxslt.md In-Reply-To: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> References: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> Message-ID: On Sat, 23 Nov 2019 16:40:11 GMT, Kevin Rushforth wrote: > We discovered three minor differences between the `libxslt.md` file and the libxslt-1.1.34 source bundle: > > 1. The copyright years didn't match the source > > 2. The following line was missing: > Licence for libxslt except libexslt > > 3. The terms currently lists `BLFS` rather than `DANIEL VEILLARD` in one place. > > Note to reviewers: > > I pushed this in two commits as an aid to reviewing it (as with any other PR, it will be squashed during integration). The first commit just fixes the above three issues without any reformatting of the lines. The second commit has no changes in the content itself, but re-wraps the lines to match the source. > > ---------------- > > Commits: > - 07be5f50: Reformat to match format of original source -- no changes in content > - 68adb259: 8234704: Fix attribution in libxslt.md > > Changes: https://git.openjdk.java.net/jfx/pull/52/files > Webrev: https://webrevs.openjdk.java.net/jfx/52/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234704 > Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod > Patch: https://git.openjdk.java.net/jfx/pull/52.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/52/head:pull/52 Reviewers: @prrace or @guruhb (only one reviewer should be needed) PR: https://git.openjdk.java.net/jfx/pull/52 From prr at openjdk.java.net Sat Nov 23 16:51:28 2019 From: prr at openjdk.java.net (Phil Race) Date: Sat, 23 Nov 2019 16:51:28 GMT Subject: RFR: 8234704: Fix attribution in libxslt.md In-Reply-To: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> References: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> Message-ID: On Sat, 23 Nov 2019 16:40:11 GMT, Kevin Rushforth wrote: > We discovered three minor differences between the `libxslt.md` file and the libxslt-1.1.34 source bundle: > > 1. The copyright years didn't match the source > > 2. The following line was missing: > Licence for libxslt except libexslt > > 3. The terms currently lists `BLFS` rather than `DANIEL VEILLARD` in one place. > > Note to reviewers: > > I pushed this in two commits as an aid to reviewing it (as with any other PR, it will be squashed during integration). The first commit just fixes the above three issues without any reformatting of the lines. The second commit has no changes in the content itself, but re-wraps the lines to match the source. > > ---------------- > > Commits: > - 07be5f50: Reformat to match format of original source -- no changes in content > - 68adb259: 8234704: Fix attribution in libxslt.md > > Changes: https://git.openjdk.java.net/jfx/pull/52/files > Webrev: https://webrevs.openjdk.java.net/jfx/52/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234704 > Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod > Patch: https://git.openjdk.java.net/jfx/pull/52.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/52/head:pull/52 "THE DANIEL VEILLARD" The one and only ? Was THE supposed to be here ? ---------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/52 From kcr at openjdk.java.net Sat Nov 23 16:53:57 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 23 Nov 2019 16:53:57 GMT Subject: RFR: 8234704: Fix attribution in libxslt.md In-Reply-To: References: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> Message-ID: On Sat, 23 Nov 2019 16:51:28 GMT, Phil Race wrote: > On Sat, 23 Nov 2019 16:40:11 GMT, Kevin Rushforth wrote: > >> We discovered three minor differences between the `libxslt.md` file and the libxslt-1.1.34 source bundle: >> >> 1. The copyright years didn't match the source >> >> 2. The following line was missing: >> Licence for libxslt except libexslt >> >> 3. The terms currently lists `BLFS` rather than `DANIEL VEILLARD` in one place. >> >> Note to reviewers: >> >> I pushed this in two commits as an aid to reviewing it (as with any other PR, it will be squashed during integration). The first commit just fixes the above three issues without any reformatting of the lines. The second commit has no changes in the content itself, but re-wraps the lines to match the source. >> >> ---------------- >> >> Commits: >> - 07be5f50: Reformat to match format of original source -- no changes in content >> - 68adb259: 8234704: Fix attribution in libxslt.md >> >> Changes: https://git.openjdk.java.net/jfx/pull/52/files >> Webrev: https://webrevs.openjdk.java.net/jfx/52/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8234704 >> Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod >> Patch: https://git.openjdk.java.net/jfx/pull/52.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/52/head:pull/52 > > "THE DANIEL VEILLARD" > > The one and only ? Was THE supposed to be here ? > > ---------------- > > Changes requested by prr (Reviewer). > "THE DANIEL VEILLARD" Strange as it may seem, yes. This is taken exactly from the `COPYING` file in the `libxslt-1.1.34.tar.gz` bundle. PR: https://git.openjdk.java.net/jfx/pull/52 From prr at openjdk.java.net Sat Nov 23 17:29:27 2019 From: prr at openjdk.java.net (Phil Race) Date: Sat, 23 Nov 2019 17:29:27 GMT Subject: [Approved] RFR: 8234704: Fix attribution in libxslt.md In-Reply-To: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> References: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> Message-ID: On Sat, 23 Nov 2019 16:40:11 GMT, Kevin Rushforth wrote: > We discovered three minor differences between the `libxslt.md` file and the libxslt-1.1.34 source bundle: > > 1. The copyright years didn't match the source > > 2. The following line was missing: > Licence for libxslt except libexslt > > 3. The terms currently lists `BLFS` rather than `DANIEL VEILLARD` in one place. > > Note to reviewers: > > I pushed this in two commits as an aid to reviewing it (as with any other PR, it will be squashed during integration). The first commit just fixes the above three issues without any reformatting of the lines. The second commit has no changes in the content itself, but re-wraps the lines to match the source. > > ---------------- > > Commits: > - 07be5f50: Reformat to match format of original source -- no changes in content > - 68adb259: 8234704: Fix attribution in libxslt.md > > Changes: https://git.openjdk.java.net/jfx/pull/52/files > Webrev: https://webrevs.openjdk.java.net/jfx/52/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234704 > Stats: 20 lines in 1 file changed: 2 ins; 0 del; 18 mod > Patch: https://git.openjdk.java.net/jfx/pull/52.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/52/head:pull/52 Approved by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/52 From kcr at openjdk.java.net Sat Nov 23 17:43:39 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 23 Nov 2019 17:43:39 GMT Subject: [Integrated] RFR: 8234704: Fix attribution in libxslt.md In-Reply-To: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> References: <7zFiqED5eUsT3LrtAiZ6lpQdRrqIVNbjL8ai2PZhZyA=.cb74ad8e-070a-4f4b-8c3d-a451ffef92cd@github.com> Message-ID: <7c1d63f6-cee2-4db6-981d-8fd9882e6a12@openjdk.org> Changeset: 126896db Author: Kevin Rushforth Date: 2019-11-23 17:42:53 +0000 URL: https://git.openjdk.java.net/jfx/commit/126896db 8234704: Fix attribution in libxslt.md Reviewed-by: prr ! modules/javafx.web/src/main/legal/libxslt.md From jvos at openjdk.java.net Tue Nov 26 07:55:01 2019 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 26 Nov 2019 07:55:01 GMT Subject: [Approved] RFR: 8230610: Upgrade GStreamer to version 1.16.1 In-Reply-To: References: Message-ID: On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev wrote: > - Upgraded GStreamer to 1.16.1 > - Upgraded GLib to 2.62.2. > - Removed glib-liteD.def, since it almost identical to release version glib-lite.def. Debug build will use glib-lite.def. > - No changes to other parts of code, except minor changes to makefiles. > > ---------------- > > Commits: > - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 > > Changes: https://git.openjdk.java.net/jfx/pull/48/files > Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 > Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod > Patch: https://git.openjdk.java.net/jfx/pull/48.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 build + sanity checks pass on windows/linux/mac ---------------- Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/48 From aghaisas at openjdk.java.net Tue Nov 26 09:22:01 2019 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 26 Nov 2019 09:22:01 GMT Subject: [Rev 01] RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 2054da4c: Address review comments on test - 4dade6e5: Simpler fix + System test corrections - bd4a306a: Revert commit1 and commit 2 Changes: - all: https://git.openjdk.java.net/jfx/pull/34/files - new: https://git.openjdk.java.net/jfx/pull/34/files/12ea8220..2054da4c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/34/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/34/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 Stats: 253 lines in 6 files changed: 132 ins; 104 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 PR: https://git.openjdk.java.net/jfx/pull/34 From aghaisas at openjdk.java.net Tue Nov 26 09:22:01 2019 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 26 Nov 2019 09:22:01 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> References: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> Message-ID: On Tue, 19 Nov 2019 14:29:16 GMT, David Grieve wrote: > On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas wrote: > >> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: >> >>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>> >>>>> **Issue :** >>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>> >>>>> **Background :** >>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>> >>>>> **Description :** >>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>> For ease of review, I have made two separate commits - >>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>> >>>>> **Root Cause :** >>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>> >>>>> **Fix :** >>>>> Fixed the identified root cause. See commit 2. >>>>> >>>>> **Testing :** >>>>> 1. All passing unit tests continue to pass >>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>> 3. System test JDK8183100Test continues to pass >>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>> >>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>> >>>> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >>>> >>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >>>> >>>>> 25: >>>>> 26: package test.robot.javafx.scene; >>>>> 27: >>>> >>>> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >>>> >>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >>>> >>>>> 54: >>>>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>>>> 56: >>>> >>>> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >>>> >>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >>>> >>>>> 77: HBox hbox = new HBox(); >>>>> 78: for (int i = 0; i < 300; i++) { >>>>> 79: hbox = new HBox(new Text("y"), hbox); >>>> >>>> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >>>> >>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >>>> >>>>> 93: // It is good enough to catch the regression in performance, if any >>>>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>>>> 95: } >>>> >>>> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. >>> >>>> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >>>> >>>> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >>>> >>>> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >>>> >>>> ``` >>>> if (cssFlag == CssFlags.UPDATE) { >>>> cssFlag = CssFlags.REAPPLY; >>>> notifyParentsOfInvalidatedCSS(); >>>> return; >>>> } >>>> ``` >>>> >>>> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >>>> >>>> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. >>> >>> It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. >> >>> Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. >> >> This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. >> >> >> Test from JDK-8151756 with additional one level of Node hierarchy. >> >> Parent1<--Parent2<--Parent3<--Rectangle (leaf child) >> >> Log from test program ---- >> Parent 1 : VBox at 1d9e402b >> Parent 2 : VBox at 4cc2dcce >> Parent 3 : VBox at 4cc2dcce >> Rectangle >> >> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN >> REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >> **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** >> reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH >> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >> **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** >> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH >> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** >> reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH >> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE >> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >> >> >> Proposed New Fix : >> ------------------- >> I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - >> >> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >> index 877e0fd6c8..8606dfb575 100644 >> --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >> @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { >> if (cssFlag == CssFlags.REAPPLY) return; >> >> // RT-36838 - don't reapply CSS in the middle of an update >> - if (cssFlag == CssFlags.UPDATE) { >> + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { >> cssFlag = CssFlags.REAPPLY; >> notifyParentsOfInvalidatedCSS(); >> return; >> >> With this fix - >> Log from test program ---- >> Parent 1 : VBox at 36d24c70 >> Parent 2 : VBox at 35af5cea >> Parent 3 : VBox at 35af5cea >> Rectangle >> >> **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** >> **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >> **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH >> REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH >> REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** >> reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY >> reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY >> reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY >> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >> >> >> I verified that all graphics/controls unit tests & all system tests pass with this fix. >> I launched and played with Ensemble app. I did not see any visible artifacts. > > @aghaisas You can avoid the call to notifyParentsOfInvalidatedCSS in the case where the flag is DIRTY_BRANCH. > > I like the looks of this. From the 10,000 foot view, when a node's parent changes, or a node's scene changes, CSS should be reapplied. This is exactly what 'if (sceneChanged) reapplyCSS()' says, and what happens in parent property's invalidated method. All of the optimizations (do I _really_ need to reapply css?) happen elsewhere, so I like this solution better than passing a boolean around (the original patch). Thanks @dsgrieve for having a look. I have updated the PR as suggested to avoid call to notifyParentsOfInvalidatedCSS in case the flag is DIRTY_BRANCH. Also, I have modified the system test as suggested by @kevinrushforth. Kindly review. Limited testing shows that this fix holds up good. PR: https://git.openjdk.java.net/jfx/pull/34 From aghaisas at openjdk.java.net Tue Nov 26 09:22:02 2019 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 26 Nov 2019 09:22:02 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> Message-ID: On Tue, 26 Nov 2019 09:22:01 GMT, David Grieve wrote: > On Tue, 26 Nov 2019 09:22:01 GMT, Ajit Ghaisas wrote: > >> On Tue, 19 Nov 2019 14:29:16 GMT, David Grieve wrote: >> >>> On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas wrote: >>> >>>> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: >>>> >>>>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: >>>>> >>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>>> >>>>>>> **Issue :** >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>> >>>>>>> **Background :** >>>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>>> >>>>>>> **Description :** >>>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>> For ease of review, I have made two separate commits - >>>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>>> >>>>>>> **Root Cause :** >>>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>>> >>>>>>> **Fix :** >>>>>>> Fixed the identified root cause. See commit 2. >>>>>>> >>>>>>> **Testing :** >>>>>>> 1. All passing unit tests continue to pass >>>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>>> 3. System test JDK8183100Test continues to pass >>>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>>> >>>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Commits: >>>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>>> >>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>>> >>>>>> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >>>>>> >>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >>>>>> >>>>>>> 25: >>>>>>> 26: package test.robot.javafx.scene; >>>>>>> 27: >>>>>> >>>>>> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >>>>>> >>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >>>>>> >>>>>>> 54: >>>>>>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>>>>>> 56: >>>>>> >>>>>> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >>>>>> >>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >>>>>> >>>>>>> 77: HBox hbox = new HBox(); >>>>>>> 78: for (int i = 0; i < 300; i++) { >>>>>>> 79: hbox = new HBox(new Text("y"), hbox); >>>>>> >>>>>> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >>>>>> >>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >>>>>> >>>>>>> 93: // It is good enough to catch the regression in performance, if any >>>>>>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>>>>>> 95: } >>>>>> >>>>>> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. >>>>> >>>>>> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >>>>>> >>>>>> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >>>>>> >>>>>> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >>>>>> >>>>>> ``` >>>>>> if (cssFlag == CssFlags.UPDATE) { >>>>>> cssFlag = CssFlags.REAPPLY; >>>>>> notifyParentsOfInvalidatedCSS(); >>>>>> return; >>>>>> } >>>>>> ``` >>>>>> >>>>>> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >>>>>> >>>>>> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. >>>>> >>>>> It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. >>>> >>>>> Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. >>>> >>>> This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. >>>> >>>> >>>> Test from JDK-8151756 with additional one level of Node hierarchy. >>>> >>>> Parent1<--Parent2<--Parent3<--Rectangle (leaf child) >>>> >>>> Log from test program ---- >>>> Parent 1 : VBox at 1d9e402b >>>> Parent 2 : VBox at 4cc2dcce >>>> Parent 3 : VBox at 4cc2dcce >>>> Rectangle >>>> >>>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN >>>> REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>> **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** >>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH >>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>> **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** >>>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH >>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** >>>> reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH >>>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE >>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>> >>>> >>>> Proposed New Fix : >>>> ------------------- >>>> I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - >>>> >>>> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>> index 877e0fd6c8..8606dfb575 100644 >>>> --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>> @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { >>>> if (cssFlag == CssFlags.REAPPLY) return; >>>> >>>> // RT-36838 - don't reapply CSS in the middle of an update >>>> - if (cssFlag == CssFlags.UPDATE) { >>>> + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { >>>> cssFlag = CssFlags.REAPPLY; >>>> notifyParentsOfInvalidatedCSS(); >>>> return; >>>> >>>> With this fix - >>>> Log from test program ---- >>>> Parent 1 : VBox at 36d24c70 >>>> Parent 2 : VBox at 35af5cea >>>> Parent 3 : VBox at 35af5cea >>>> Rectangle >>>> >>>> **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** >>>> **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>> **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH >>>> REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH >>>> REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** >>>> reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY >>>> reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY >>>> reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY >>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>> >>>> >>>> I verified that all graphics/controls unit tests & all system tests pass with this fix. >>>> I launched and played with Ensemble app. I did not see any visible artifacts. >>> >>> @aghaisas You can avoid the call to notifyParentsOfInvalidatedCSS in the case where the flag is DIRTY_BRANCH. >>> >>> I like the looks of this. From the 10,000 foot view, when a node's parent changes, or a node's scene changes, CSS should be reapplied. This is exactly what 'if (sceneChanged) reapplyCSS()' says, and what happens in parent property's invalidated method. All of the optimizations (do I _really_ need to reapply css?) happen elsewhere, so I like this solution better than passing a boolean around (the original patch). >> >> Thanks @dsgrieve for having a look. I have updated the PR as suggested to avoid call to notifyParentsOfInvalidatedCSS in case the flag is DIRTY_BRANCH. >> Also, I have modified the system test as suggested by @kevinrushforth. >> >> Kindly review. >> >> Limited testing shows that this fix holds up good. > > Trying to run this, but have to build on Windows. Ugh! Request to @DeanWookey, @tomsontom, @swpalmer - can you please confirm if this fix helps your application or tests? PR: https://git.openjdk.java.net/jfx/pull/34 From github.com+1680611+Groostav at openjdk.java.net Tue Nov 26 09:22:02 2019 From: github.com+1680611+Groostav at openjdk.java.net (Geoff) Date: Tue, 26 Nov 2019 09:22:02 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> Message-ID: <2R4mNNzw2oupYjd_3XjJgRf74eci3Lfe7M0lLHIN4kQ=.e7dcc8f7-788d-479d-bf3b-72b78cfcd24a@github.com> On Tue, 26 Nov 2019 09:22:02 GMT, Ajit Ghaisas wrote: > On Tue, 26 Nov 2019 09:22:01 GMT, David Grieve wrote: > >> On Tue, 26 Nov 2019 09:22:01 GMT, Ajit Ghaisas wrote: >> >>> On Tue, 19 Nov 2019 14:29:16 GMT, David Grieve wrote: >>> >>>> On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas wrote: >>>> >>>>> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: >>>>> >>>>>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: >>>>>> >>>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>>>> >>>>>>>> **Issue :** >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>>> >>>>>>>> **Background :** >>>>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>>>> >>>>>>>> **Description :** >>>>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>>> For ease of review, I have made two separate commits - >>>>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>>>> >>>>>>>> **Root Cause :** >>>>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>>>> >>>>>>>> **Fix :** >>>>>>>> Fixed the identified root cause. See commit 2. >>>>>>>> >>>>>>>> **Testing :** >>>>>>>> 1. All passing unit tests continue to pass >>>>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>>>> 3. System test JDK8183100Test continues to pass >>>>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>>>> >>>>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>>>> >>>>>>>> ---------------- >>>>>>>> >>>>>>>> Commits: >>>>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>>>> >>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>>>> >>>>>>> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >>>>>>> >>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >>>>>>> >>>>>>>> 25: >>>>>>>> 26: package test.robot.javafx.scene; >>>>>>>> 27: >>>>>>> >>>>>>> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >>>>>>> >>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >>>>>>> >>>>>>>> 54: >>>>>>>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>>>>>>> 56: >>>>>>> >>>>>>> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >>>>>>> >>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >>>>>>> >>>>>>>> 77: HBox hbox = new HBox(); >>>>>>>> 78: for (int i = 0; i < 300; i++) { >>>>>>>> 79: hbox = new HBox(new Text("y"), hbox); >>>>>>> >>>>>>> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >>>>>>> >>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >>>>>>> >>>>>>>> 93: // It is good enough to catch the regression in performance, if any >>>>>>>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>>>>>>> 95: } >>>>>>> >>>>>>> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. >>>>>> >>>>>>> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >>>>>>> >>>>>>> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >>>>>>> >>>>>>> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >>>>>>> >>>>>>> ``` >>>>>>> if (cssFlag == CssFlags.UPDATE) { >>>>>>> cssFlag = CssFlags.REAPPLY; >>>>>>> notifyParentsOfInvalidatedCSS(); >>>>>>> return; >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >>>>>>> >>>>>>> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. >>>>>> >>>>>> It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. >>>>> >>>>>> Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. >>>>> >>>>> This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. >>>>> >>>>> >>>>> Test from JDK-8151756 with additional one level of Node hierarchy. >>>>> >>>>> Parent1<--Parent2<--Parent3<--Rectangle (leaf child) >>>>> >>>>> Log from test program ---- >>>>> Parent 1 : VBox at 1d9e402b >>>>> Parent 2 : VBox at 4cc2dcce >>>>> Parent 3 : VBox at 4cc2dcce >>>>> Rectangle >>>>> >>>>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN >>>>> REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>> **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** >>>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH >>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>> **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** >>>>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH >>>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** >>>>> reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH >>>>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE >>>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>> >>>>> >>>>> Proposed New Fix : >>>>> ------------------- >>>>> I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - >>>>> >>>>> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>>> index 877e0fd6c8..8606dfb575 100644 >>>>> --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>>> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>>> @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { >>>>> if (cssFlag == CssFlags.REAPPLY) return; >>>>> >>>>> // RT-36838 - don't reapply CSS in the middle of an update >>>>> - if (cssFlag == CssFlags.UPDATE) { >>>>> + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { >>>>> cssFlag = CssFlags.REAPPLY; >>>>> notifyParentsOfInvalidatedCSS(); >>>>> return; >>>>> >>>>> With this fix - >>>>> Log from test program ---- >>>>> Parent 1 : VBox at 36d24c70 >>>>> Parent 2 : VBox at 35af5cea >>>>> Parent 3 : VBox at 35af5cea >>>>> Rectangle >>>>> >>>>> **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** >>>>> **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>> **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH >>>>> REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH >>>>> REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** >>>>> reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY >>>>> reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY >>>>> reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY >>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>> >>>>> >>>>> I verified that all graphics/controls unit tests & all system tests pass with this fix. >>>>> I launched and played with Ensemble app. I did not see any visible artifacts. >>>> >>>> @aghaisas You can avoid the call to notifyParentsOfInvalidatedCSS in the case where the flag is DIRTY_BRANCH. >>>> >>>> I like the looks of this. From the 10,000 foot view, when a node's parent changes, or a node's scene changes, CSS should be reapplied. This is exactly what 'if (sceneChanged) reapplyCSS()' says, and what happens in parent property's invalidated method. All of the optimizations (do I _really_ need to reapply css?) happen elsewhere, so I like this solution better than passing a boolean around (the original patch). >>> >>> Thanks @dsgrieve for having a look. I have updated the PR as suggested to avoid call to notifyParentsOfInvalidatedCSS in case the flag is DIRTY_BRANCH. >>> Also, I have modified the system test as suggested by @kevinrushforth. >>> >>> Kindly review. >>> >>> Limited testing shows that this fix holds up good. >> >> Trying to run this, but have to build on Windows. Ugh! > > Request to @DeanWookey, @tomsontom, @swpalmer - can you please confirm if this fix helps your application or tests? Does the performance problem addressed here relate to reducing heap space allocations? My profiler pointed me at this issue, and around the same time I'm seeing `OutOfMemoryError`s. I'm wondering if (or rather, _hoping_) they're the same problem. PR: https://git.openjdk.java.net/jfx/pull/34 From dgrieve at openjdk.java.net Tue Nov 26 09:22:01 2019 From: dgrieve at openjdk.java.net (David Grieve) Date: Tue, 26 Nov 2019 09:22:01 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> Message-ID: On Tue, 26 Nov 2019 09:22:01 GMT, Ajit Ghaisas wrote: > On Tue, 19 Nov 2019 14:29:16 GMT, David Grieve wrote: > >> On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas wrote: >> >>> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: >>> >>>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>> >>>>>> **Issue :** >>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>> >>>>>> **Background :** >>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>> >>>>>> **Description :** >>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>> For ease of review, I have made two separate commits - >>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>> >>>>>> **Root Cause :** >>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>> >>>>>> **Fix :** >>>>>> Fixed the identified root cause. See commit 2. >>>>>> >>>>>> **Testing :** >>>>>> 1. All passing unit tests continue to pass >>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>> 3. System test JDK8183100Test continues to pass >>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>> >>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>> >>>>> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >>>>> >>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >>>>> >>>>>> 25: >>>>>> 26: package test.robot.javafx.scene; >>>>>> 27: >>>>> >>>>> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >>>>> >>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >>>>> >>>>>> 54: >>>>>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>>>>> 56: >>>>> >>>>> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >>>>> >>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >>>>> >>>>>> 77: HBox hbox = new HBox(); >>>>>> 78: for (int i = 0; i < 300; i++) { >>>>>> 79: hbox = new HBox(new Text("y"), hbox); >>>>> >>>>> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >>>>> >>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >>>>> >>>>>> 93: // It is good enough to catch the regression in performance, if any >>>>>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>>>>> 95: } >>>>> >>>>> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. >>>> >>>>> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >>>>> >>>>> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >>>>> >>>>> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >>>>> >>>>> ``` >>>>> if (cssFlag == CssFlags.UPDATE) { >>>>> cssFlag = CssFlags.REAPPLY; >>>>> notifyParentsOfInvalidatedCSS(); >>>>> return; >>>>> } >>>>> ``` >>>>> >>>>> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >>>>> >>>>> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. >>>> >>>> It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. >>> >>>> Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. >>> >>> This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. >>> >>> >>> Test from JDK-8151756 with additional one level of Node hierarchy. >>> >>> Parent1<--Parent2<--Parent3<--Rectangle (leaf child) >>> >>> Log from test program ---- >>> Parent 1 : VBox at 1d9e402b >>> Parent 2 : VBox at 4cc2dcce >>> Parent 3 : VBox at 4cc2dcce >>> Rectangle >>> >>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN >>> REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>> **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** >>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH >>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>> **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** >>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH >>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** >>> reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH >>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE >>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>> >>> >>> Proposed New Fix : >>> ------------------- >>> I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - >>> >>> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>> index 877e0fd6c8..8606dfb575 100644 >>> --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>> @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { >>> if (cssFlag == CssFlags.REAPPLY) return; >>> >>> // RT-36838 - don't reapply CSS in the middle of an update >>> - if (cssFlag == CssFlags.UPDATE) { >>> + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { >>> cssFlag = CssFlags.REAPPLY; >>> notifyParentsOfInvalidatedCSS(); >>> return; >>> >>> With this fix - >>> Log from test program ---- >>> Parent 1 : VBox at 36d24c70 >>> Parent 2 : VBox at 35af5cea >>> Parent 3 : VBox at 35af5cea >>> Rectangle >>> >>> **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** >>> **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>> **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH >>> REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH >>> REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** >>> reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY >>> reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY >>> reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY >>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>> >>> >>> I verified that all graphics/controls unit tests & all system tests pass with this fix. >>> I launched and played with Ensemble app. I did not see any visible artifacts. >> >> @aghaisas You can avoid the call to notifyParentsOfInvalidatedCSS in the case where the flag is DIRTY_BRANCH. >> >> I like the looks of this. From the 10,000 foot view, when a node's parent changes, or a node's scene changes, CSS should be reapplied. This is exactly what 'if (sceneChanged) reapplyCSS()' says, and what happens in parent property's invalidated method. All of the optimizations (do I _really_ need to reapply css?) happen elsewhere, so I like this solution better than passing a boolean around (the original patch). > > Thanks @dsgrieve for having a look. I have updated the PR as suggested to avoid call to notifyParentsOfInvalidatedCSS in case the flag is DIRTY_BRANCH. > Also, I have modified the system test as suggested by @kevinrushforth. > > Kindly review. > > Limited testing shows that this fix holds up good. Trying to run this, but have to build on Windows. Ugh! PR: https://git.openjdk.java.net/jfx/pull/34 From aghaisas at openjdk.java.net Tue Nov 26 09:22:03 2019 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 26 Nov 2019 09:22:03 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: <2R4mNNzw2oupYjd_3XjJgRf74eci3Lfe7M0lLHIN4kQ=.e7dcc8f7-788d-479d-bf3b-72b78cfcd24a@github.com> References: <13gbpDw5Ze22Xt8jygcex-CWiY6uTNzXC_T_DfK6gpo=.1131fb4d-e5c1-439e-ad2d-081367ffd208@github.com> <2R4mNNzw2oupYjd_3XjJgRf74eci3Lfe7M0lLHIN4kQ=.e7dcc8f7-788d-479d-bf3b-72b78cfcd24a@github.com> Message-ID: On Tue, 26 Nov 2019 09:22:02 GMT, Geoff wrote: > On Tue, 26 Nov 2019 09:22:02 GMT, Ajit Ghaisas wrote: > >> On Tue, 26 Nov 2019 09:22:01 GMT, David Grieve wrote: >> >>> On Tue, 26 Nov 2019 09:22:01 GMT, Ajit Ghaisas wrote: >>> >>>> On Tue, 19 Nov 2019 14:29:16 GMT, David Grieve wrote: >>>> >>>>> On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas wrote: >>>>> >>>>>> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas wrote: >>>>>> >>>>>>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth wrote: >>>>>>> >>>>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: >>>>>>>> >>>>>>>>> **Issue :** >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>>>> >>>>>>>>> **Background :** >>>>>>>>> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >>>>>>>>> >>>>>>>>> **Description :** >>>>>>>>> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >>>>>>>>> For ease of review, I have made two separate commits - >>>>>>>>> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >>>>>>>>> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >>>>>>>>> >>>>>>>>> **Root Cause :** >>>>>>>>> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >>>>>>>>> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >>>>>>>>> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >>>>>>>>> >>>>>>>>> **Fix :** >>>>>>>>> Fixed the identified root cause. See commit 2. >>>>>>>>> >>>>>>>>> **Testing :** >>>>>>>>> 1. All passing unit tests continue to pass >>>>>>>>> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >>>>>>>>> 3. System test JDK8183100Test continues to pass >>>>>>>>> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >>>>>>>>> >>>>>>>>> In addition, testing by community with specific CSS performance / functionality will be helpful. >>>>>>>>> >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>> Commits: >>>>>>>>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >>>>>>>>> - d964675e: Reintroduce JDK-8151756 CSS performance fix >>>>>>>>> >>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files >>>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >>>>>>>>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >>>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >>>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 >>>>>>>> >>>>>>>> While we are still discussing the fix itself, I added a few comments on the new test. It generally looks good, but should be run on a variety of systems, with and without the fix (once we have a final fix that we are satisfied with). >>>>>>>> >>>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 26: >>>>>>>> >>>>>>>>> 25: >>>>>>>>> 26: package test.robot.javafx.scene; >>>>>>>>> 27: >>>>>>>> >>>>>>>> There is no need for this test to require robot. I recommend moving it to `test.javafx.scene` (and not inherit from `VisualTestBase`). >>>>>>>> >>>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 55: >>>>>>>> >>>>>>>>> 54: >>>>>>>>> 55: public class CSSPerf_JDK8193445Test extends VisualTestBase { >>>>>>>>> 56: >>>>>>>> >>>>>>>> We have moved away from putting the bug ID in the test class name, so I recommend renaming it. >>>>>>>> >>>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 78: >>>>>>>> >>>>>>>>> 77: HBox hbox = new HBox(); >>>>>>>>> 78: for (int i = 0; i < 300; i++) { >>>>>>>>> 79: hbox = new HBox(new Text("y"), hbox); >>>>>>>> >>>>>>>> In my testing on various machines, the bug is more pronounced, and less prone to system differences with `500` nodes instead of `300`. >>>>>>>> >>>>>>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java line 94: >>>>>>>> >>>>>>>>> 93: // It is good enough to catch the regression in performance, if any >>>>>>>>> 94: assertTrue("Time to add 300 Nodes is more than 400 mSec", mSec < 400); >>>>>>>>> 95: } >>>>>>>> >>>>>>>> If you increase the number of nodes to `500` then I recommend bumping the time threshold to `800` msec in case it is run on a very slow system. >>>>>>> >>>>>>>> I think inverting the call is fine. That's what I did in my fix ([DeanWookey/openjdk-jfx at 65a1ed8](https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6)) and we've been testing that out thoroughly for over a year. >>>>>>>> >>>>>>>> It's as if you are adding nodes 1 by 1 to the scene graph, something we know works and is fast. My change tries to emulate that more accurately to avoid side effects. Theoretically, we should be able to do better when many nodes are added at once because we have all the information upfront. >>>>>>>> >>>>>>>> The one side effect I can see by only applying commit 2 is that the first call of reapplyCSS() calls reapplyCss on every node in the tree and that sets the cssFlag = CssFlags.UPDATE;. The subsequent calls will hit this in reapplyCSS(): >>>>>>>> >>>>>>>> ``` >>>>>>>> if (cssFlag == CssFlags.UPDATE) { >>>>>>>> cssFlag = CssFlags.REAPPLY; >>>>>>>> notifyParentsOfInvalidatedCSS(); >>>>>>>> return; >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> and return without doing all the unnecessary work. As a result however, instead of leaving with cssFlag = CssFlags.UPDATE, all the nodes leave with CssFlags.REAPPLY. That might cause an unnecessary css pass later? >>>>>>>> >>>>>>>> Doing it in the order it happens now, that check for the update flag shouldn't be true because its bottom up. >>>>>>> >>>>>>> It is a good observation about cssFlag. I have not seen any side effect with the limited testing that I have done. It may be possible that the "unnecessary css pass later" scenario is not covered by the test cases that we have. >>>>>> >>>>>>> Perhaps short-circuiting the call to reapplyCss() from the reapplyCSS() method is the thing to do. >>>>>> >>>>>> This comment from @dsgrieve got me interested. I checked the test code JDK-8151756 with cssFlags logged, it became evident that the cssFlag gets set to DIRTY_BRANCH for every parent and reapplyCss() gets invoked for each of the children. This is the exact redundant processing. >>>>>> >>>>>> >>>>>> Test from JDK-8151756 with additional one level of Node hierarchy. >>>>>> >>>>>> Parent1<--Parent2<--Parent3<--Rectangle (leaf child) >>>>>> >>>>>> Log from test program ---- >>>>>> Parent 1 : VBox at 1d9e402b >>>>>> Parent 2 : VBox at 4cc2dcce >>>>>> Parent 3 : VBox at 4cc2dcce >>>>>> Rectangle >>>>>> >>>>>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.CLEAN >>>>>> REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>>> **REAPPLY_CSS called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH** >>>>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.DIRTY_BRANCH >>>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>>> **REAPPLY_CSS called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH** >>>>>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.DIRTY_BRANCH >>>>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>>> **REAPPLY_CSS called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH** >>>>>> reapplyCss called for : VBox at 1d9e402b ----- CssFlags.DIRTY_BRANCH >>>>>> reapplyCss called for : VBox at 4cc2dcce ----- CssFlags.UPDATE >>>>>> reapplyCss called for : VBox at 19234c0d ----- CssFlags.UPDATE >>>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>>> >>>>>> >>>>>> Proposed New Fix : >>>>>> ------------------- >>>>>> I added a simple check to avoid reapplyCss() call for each Node with DIRTY_BRANCH cssFlag. Here is the patch - >>>>>> >>>>>> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>>>> index 877e0fd6c8..8606dfb575 100644 >>>>>> --- a/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>>>> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/Node.java >>>>>> @@ -9416,7 +9416,7 @@ public abstract class Node implements EventTarget, Styleable { >>>>>> if (cssFlag == CssFlags.REAPPLY) return; >>>>>> >>>>>> // RT-36838 - don't reapply CSS in the middle of an update >>>>>> - if (cssFlag == CssFlags.UPDATE) { >>>>>> + if (cssFlag == CssFlags.UPDATE || cssFlag == CssFlags.DIRTY_BRANCH) { >>>>>> cssFlag = CssFlags.REAPPLY; >>>>>> notifyParentsOfInvalidatedCSS(); >>>>>> return; >>>>>> >>>>>> With this fix - >>>>>> Log from test program ---- >>>>>> Parent 1 : VBox at 36d24c70 >>>>>> Parent 2 : VBox at 35af5cea >>>>>> Parent 3 : VBox at 35af5cea >>>>>> Rectangle >>>>>> >>>>>> **REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.CLEAN** >>>>>> **REAPPLY_CSS called for : Rectangle[...] ----- CssFlags.CLEAN** >>>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>>> **REAPPLY_CSS called for : VBox at 5d4b6983 ----- CssFlags.DIRTY_BRANCH >>>>>> REAPPLY_CSS called for : VBox at 35af5cea ----- CssFlags.DIRTY_BRANCH >>>>>> REAPPLY_CSS called for : VBox at 36d24c70 ----- CssFlags.DIRTY_BRANCH** >>>>>> reapplyCss called for : VBox at 36d24c70 ----- CssFlags.REAPPLY >>>>>> reapplyCss called for : VBox at 35af5cea ----- CssFlags.REAPPLY >>>>>> reapplyCss called for : VBox at 5d4b6983 ----- CssFlags.REAPPLY >>>>>> reapplyCss called for : Rectangle[...] ----- CssFlags.CLEAN >>>>>> >>>>>> >>>>>> I verified that all graphics/controls unit tests & all system tests pass with this fix. >>>>>> I launched and played with Ensemble app. I did not see any visible artifacts. >>>>> >>>>> @aghaisas You can avoid the call to notifyParentsOfInvalidatedCSS in the case where the flag is DIRTY_BRANCH. >>>>> >>>>> I like the looks of this. From the 10,000 foot view, when a node's parent changes, or a node's scene changes, CSS should be reapplied. This is exactly what 'if (sceneChanged) reapplyCSS()' says, and what happens in parent property's invalidated method. All of the optimizations (do I _really_ need to reapply css?) happen elsewhere, so I like this solution better than passing a boolean around (the original patch). >>>> >>>> Thanks @dsgrieve for having a look. I have updated the PR as suggested to avoid call to notifyParentsOfInvalidatedCSS in case the flag is DIRTY_BRANCH. >>>> Also, I have modified the system test as suggested by @kevinrushforth. >>>> >>>> Kindly review. >>>> >>>> Limited testing shows that this fix holds up good. >>> >>> Trying to run this, but have to build on Windows. Ugh! >> >> Request to @DeanWookey, @tomsontom, @swpalmer - can you please confirm if this fix helps your application or tests? > > Does the performance problem addressed here relate to reducing heap space allocations? My profiler pointed me at this issue, and around the same time I'm seeing `OutOfMemoryError`s. I'm wondering if (or rather, _hoping_) they're the same problem. I did a quick check w.r.t. memory using profiler. This patch significantly reduces the heap allocations as well. There is a win on both - performance & memory fronts. PR: https://git.openjdk.java.net/jfx/pull/34 From dgrieve at openjdk.java.net Tue Nov 26 09:22:03 2019 From: dgrieve at openjdk.java.net (David Grieve) Date: Tue, 26 Nov 2019 09:22:03 GMT Subject: [Approved] RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > **Issue :** > https://bugs.openjdk.java.net/browse/JDK-8193445 > > **Background :** > The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. > > **Description :** > This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > For ease of review, I have made two separate commits - > 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. > 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test > > **Root Cause :** > CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. > What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. > This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) > > **Fix :** > Fixed the identified root cause. See commit 2. > > **Testing :** > 1. All passing unit tests continue to pass > 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix > 3. System test JDK8183100Test continues to pass > 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix > > In addition, testing by community with specific CSS performance / functionality will be helpful. > > ---------------- > > Commits: > - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test > - d964675e: Reintroduce JDK-8151756 CSS performance fix > > Changes: https://git.openjdk.java.net/jfx/pull/34/files > Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 > Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/34.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 Approved by dgrieve (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/34 From kcr at openjdk.java.net Tue Nov 26 09:22:04 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 09:22:04 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > **Issue :** > https://bugs.openjdk.java.net/browse/JDK-8193445 > > **Background :** > The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. > > **Description :** > This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). > For ease of review, I have made two separate commits - > 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. > 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test > > **Root Cause :** > CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. > What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. > This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) > > **Fix :** > Fixed the identified root cause. See commit 2. > > **Testing :** > 1. All passing unit tests continue to pass > 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix > 3. System test JDK8183100Test continues to pass > 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix > > In addition, testing by community with specific CSS performance / functionality will be helpful. > > ---------------- > > Commits: > - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test > - d964675e: Reintroduce JDK-8151756 CSS performance fix > > Changes: https://git.openjdk.java.net/jfx/pull/34/files > Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 > Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/34.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 The fix itself looks good and is a much safer approach than the previous one. I've done a fair bit of testing and can see no regressions as a result of this fix. I did find one unrelated issue while testing (a visual bug introduced back in JDK 10) that I will file separately. The test is pretty close, but still needs a few changes. The main problem is that it does not catch the performance problem, meaning if you run it without the fix, it will still pass. Your test class extends `javafx.application.Application`, which can cause problems, since JUnit will create a new instance of the test class that is different from the one created by the call to `Application.launch` in the `@BeforeClass` method. This in turn leads to the `rootPane` instance used by the test method being different from the one used as the root of the visible scene. The fix is to use a separate nested (static) subclass of Application, and make the rootPane field a static field. I have left inline comments for this and a few other things I noticed. tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 63: > 62: > 63: public class QuadraticCssTimeTest extends Application { > 64: Remove `extends Application` tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 66: > 65: static private CountDownLatch startupLatch; > 66: static private Stage stage; > 67: private BorderPane rootPane = new BorderPane(); Minor: our convention is `private static`. tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 67: > 66: static private Stage stage; > 67: private BorderPane rootPane = new BorderPane(); > 68: Based on how it is used, this needs to be a `static` field (this will not compile anyway once you move the `start method` to a nested class). Also, there is no need to initialize it both here and in the `Application::start` method. One or the other will do. tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 70: > 69: @Override > 70: public void start(Stage primaryStage) throws Exception { > 71: stage = primaryStage; Enclose this method in a nested subclass of Application: public static class TestApp extends Application { @Override public void start(Stage primaryStage) throws Exception { ... } } tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 81: > 80: @BeforeClass > 81: public static void initFX() { > 82: startupLatch = new CountDownLatch(1); If you add `throws Exception` to the method signature you can avoid the try / catch (most of our newer tests do this). tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 86: > 85: try { > 86: if (!startupLatch.await(15, TimeUnit.SECONDS)) { > 87: Assert.fail("Timeout waiting for FX runtime to start"); The entire try / catch block, including the `if` test, can be simplified to this: assertTrue(startupLatch.await(15, TimeUnit.SECONDS)); tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 96: > 95: public void testTimeForAdding500NodesToScene() throws Exception { > 96: > 97: // Compute time for adding 500 Nodes Adding a node to a live scene graph must be done on the JavaFX Application thread. I recommend wrapping the body of this method in a `Util.runAndWait` call. tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 83: > 82: startupLatch = new CountDownLatch(1); > 83: new Thread(() -> Application.launch(QuadraticCssTimeTest.class, (String[]) null)).start(); > 84: Change `QuadraticCssTimeTest.class` to `TestApp.class`. ---------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/34 From fkirmaier at openjdk.java.net Tue Nov 26 09:23:58 2019 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 26 Nov 2019 09:23:58 GMT Subject: [Rev 03] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: The pull request has been updated with a complete new set of changes (possibly due to a rebase). ---------------- Commits: - 44774dfb: JDK-8200224 - d1309fb6: JDK-8200224 - 53a66b8f: JDK-8200224 - 0be3cb5b: JDK-8200224 - 03b59288: Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8200224 - 5cd96a56: JDK-8200224 - 85c87628: JDK-8200224 - 314e423c: JDK-8200224 - 725e5fef: JDK-8200224 Changes: https://git.openjdk.java.net/jfx/pull/25/files Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.03 Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 Stats: 272 lines in 3 files changed: 147 ins; 120 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.java.net Tue Nov 26 09:24:04 2019 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 26 Nov 2019 09:24:04 GMT Subject: [Rev 02] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Wed, 13 Nov 2019 21:53:13 GMT, Kevin Rushforth wrote: > On Tue, 12 Nov 2019 10:23:16 GMT, Florian Kirmaier wrote: > >> The pull request has been updated with additional changes. >> >> ---------------- >> >> Added commits: >> - 5cd96a56: JDK-8200224 >> >> Changes: >> - all: https://git.openjdk.java.net/jfx/pull/25/files >> - new: https://git.openjdk.java.net/jfx/pull/25/files/85c87628..5cd96a56 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/jfx/25/webrev.02 >> - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.01-02 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >> Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod >> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 > > I see that when you made your earlier comment regarding `System.exit`, you really meant that the existing swing test was calling `Platform.exit`, which isn't the same thing; it does shut down the JavaFX runtime, which is intended. > > The problem you are running into is that gradle runs multiple tests in the same VM and in an undefined, and unpredicable, order. This means that tests need to take care not to alter or rely on global state such as threads, static fields, global JavaFX state, and the running (or lack thereof) of the JavaFX runtime. The swing tests violate this rule and are therefore inherently unstable. The only reason this hasn't been a problem up to now is that the javafx.swing module contains a single test class. I will file a new test bug to address it -- probably by moving that test to the `systemTests` project. > > You will need to move your test into the `systemTests` project under the `tests/system/` directory. Such tests are valid in the system tests project because we run each test in that project in its own VM. Once your proposed test is robust (meaning consistently catches the bug without your fix and consistently passes with your fix) on all platforms without using Robot, then `tests/system/src/test/java/test/javafx/embed/swing/` would be the best place to put your new test. > > Regarding the test itself, it still doesn't fail for me on Windows without your fix. I ran the test program attached to the bug and I see something that might help explain this. That test program creates a pair of JFXPanel objects and adds both to the JPanel. If I first click on the first one, then it only shows a single click. Every time after that, if I click on a new JFXPanel, then I get 2 clicks. If, instead, I click on the second JFXPanel right after starting the program, I get 2 clicks the first time. With that in mind, I modified your test to add a dummy JFXPanel to the JPanel before the one you are sending the mouse pressed event to, and then it then does what I expect: it catches the bug without your fix and passes with your fix. That might help you come up with a more robust test. I added some specific comments on the test as well. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java line 46: > >> 45: >> 46: >> 47: public class SwingFXUtilsTest { > > Your proposed fix for this test class is not the right fix, and needs to be reverted. It highlights an existing bug with the swing tests, which I will address in general comments. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 100: > >> 99: jpanel.add(fxPnl); >> 100: jframe.setContentPane(jpanel); >> 101: jframe.setVisible(true); > > You should call `jframe.pack()` here. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 128: > >> 127: >> 128: Thread.sleep(100); // there should be no pressed event after the initial one. Let's wait for 0.1s and check again. >> 129: assertEquals(1, pressedEventCounter[0]); > > I recommend using 500 msec so we don't risk missing a failing click on slower systems. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 60: > >> 59: public static void doSetupOnce() { >> 60: if (setupIsDone) return; >> 61: Platform.startup(() -> { > > This is not needed if you revert the changes to the other test class. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 130: > >> 129: assertEquals(1, pressedEventCounter[0]); >> 130: } >> 131: } > > You will want to add a cleanup method, annotated with `@AfterClass` to call `Platform.exit` and dispose of the JFrame. > > modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 106: > >> 105: Scene scene = new Scene(new Group()); >> 106: scene.getRoot().requestFocus(); >> 107: > > I don't think requesting focus is necessary (or desired). > > ---------------- > > Changes requested by kcr (Lead). It's now removed done I've kept the logic of the other JFXPanelTest. Should i change it? removed I've removed it PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.java.net Tue Nov 26 09:24:00 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 09:24:00 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: <7WnTi-Wi_U03MOSxYt6B-I5gK_UqlQbyl6G87G6Pd7E=.8be0859b-cdda-47fc-8c44-2198fe8841d6@github.com> References: <5XRJyBGYagcqRuOygjHubkkI_twGh8i3N2UUwnT7p9k=.197bf17a-13ef-4b61-a337-e310e39f1044@github.com> <_c3s21NA3wisUO6yXmpSQEt9QRfpRRHx2LoFgbS8ARM=.5da17758-6f78-41b5-813b-2c6586d277bb@github.com> <7WnTi-Wi_U03MOSxYt6B-I5gK_UqlQbyl6G87G6Pd7E=.8be0859b-cdda-47fc-8c44-2198fe8841d6@github.com> Message-ID: On Tue, 26 Nov 2019 09:23:59 GMT, Florian Kirmaier wrote: > On Wed, 13 Nov 2019 22:11:14 GMT, Kevin Rushforth wrote: > >> On Wed, 13 Nov 2019 01:17:44 GMT, Kevin Rushforth wrote: >> >>> On Tue, 12 Nov 2019 10:35:36 GMT, Florian Kirmaier wrote: >>> >>>> On Wed, 6 Nov 2019 08:30:47 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >>>>> >>>>>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>>>>> >>>>>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>>>>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>>>>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>>>>> >>>>>> The pull request introduces a new fix for the problem. >>>>>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>>>>> We do so, by using setFocused. >>>>>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>>>>> because calling setFocused just sets the value of a boolean property. >>>>>> >>>>>> I've now also added a unit-test for the problem. >>>>>> >>>>>> ---------------- >>>>>> >>>>>> Commits: >>>>>> - 314e423c: JDK-8200224 >>>>>> - 725e5fef: JDK-8200224 >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>>>>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >>>>> >>>>> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: >>>>> >>>>>> 456: >>>>>> 457: sendMouseEventToFX(e); >>>>>> 458: super.processMouseEvent(e); >>>>> >>>>> typo: save --> safe >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: >>>>> >>>>>> 1: /* >>>>>> 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. >>>>>> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> >>>>> replace `2014, 2016` with `2019,` >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: >>>>> >>>>>> 27: >>>>>> 28: import javafx.application.Application; >>>>>> 29: import javafx.application.Platform; >>>>> >>>>> Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: >>>>> >>>>>> 47: >>>>>> 48: import static junit.framework.Assert.assertEquals; >>>>>> 49: import static org.junit.Assert.assertNotNull; >>>>> >>>>> This method should be imported from `org.junit` package. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: >>>>> >>>>>> 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, >>>>>> 116: 5, 5, 1, false, MouseEvent.BUTTON1); >>>>>> 117: >>>>> >>>>> This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: >>>>> >>>>>> 56: >>>>>> 57: >>>>>> 58: @BeforeClass >>>>> >>>>> You can remove the extra blank line. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: >>>>> >>>>>> 64: >>>>>> 65: >>>>>> 66: try { >>>>> >>>>> You can remove the extra blank line. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: >>>>> >>>>>> 78: >>>>>> 79: class TestFXPanel extends JFXPanel { >>>>>> 80: protected void processMouseEventPublic(MouseEvent e) { >>>>> >>>>> I think this can be a static class. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: >>>>> >>>>>> 87: >>>>>> 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); >>>>>> 89: >>>>> >>>>> This can be final. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: >>>>> >>>>>> 90: // It's an array, so we can mutate it inside of lambda statement >>>>>> 91: int[] pressedEventCounter = {0}; >>>>>> 92: >>>>> >>>>> This can be final. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: >>>>> >>>>>> 131: >>>>>> 132: >>>>>> 133: } >>>>> >>>>> You can remove the extra blank line. >>>>> >>>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: >>>>> >>>>>> 122: >>>>>> 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >>>>>> 124: throw new Exception(); >>>>> >>>>> Add a space after the `if`. >>>>> >>>>> The fix seems fine. Have you tested it on all three platforms? >>>>> >>>>> I have several comments on the test. >>>>> >>>>> ---------------- >>>>> >>>>> Disapproved by kcr (Lead). >>>> >>>> Maybe try `./gradlew -PFULL_TEST=true swing:clean swing:test`. >>>> I'm sure, it can be reproduced on windows. >>>> If you still can not reproduce it, then I will add a test for the Robot. >>> >>> I'll try it again with the updated test. >>> >>>> You can run the AWT_TESTS with the following statement: >>>> >>>> ``` >>>> ./gradlew -PFULL_TEST=true swing:clean swing:test >>>> ``` >>> >>> Yes, I know that it needs `-PFULL_TEST=true`, but the earlier test wasn't failing for me. And yes, it is intentional; for reasons I can't recall, the swing tests don't work in headless mode. Anyway, I don't want to revisit this right now. >>> >>>> The tests are now stable. The previous version had some problems because the other test for Swing was calling System.exit. >>> >>> Tests should not call `System.exit`. If they do, then that's almost certainly a bug. >> >> FYI, I filed [JDK-8234110](https://bugs.openjdk.java.net/browse/JDK-8234110) to move the existing `:swing` test to `:systemTests`. > > I've updated the pull request and merged it with master. > Later, I will retest it with a Windows VM. > > I've done now the requested changes. > Now only retesting it with Windows is left. > > I've now tested on Windows. > I can confirm, that the test doesn't reproduce the error on Windows. Yes, I confirmed this last Friday, but ran out of time to reply. You also need to restore the test that you moved from `test.robot.*` to its original state (so we preserve the previous Mac-only test). PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.java.net Tue Nov 26 09:23:59 2019 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 26 Nov 2019 09:23:59 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: <_c3s21NA3wisUO6yXmpSQEt9QRfpRRHx2LoFgbS8ARM=.5da17758-6f78-41b5-813b-2c6586d277bb@github.com> References: <5XRJyBGYagcqRuOygjHubkkI_twGh8i3N2UUwnT7p9k=.197bf17a-13ef-4b61-a337-e310e39f1044@github.com> <_c3s21NA3wisUO6yXmpSQEt9QRfpRRHx2LoFgbS8ARM=.5da17758-6f78-41b5-813b-2c6586d277bb@github.com> Message-ID: <7WnTi-Wi_U03MOSxYt6B-I5gK_UqlQbyl6G87G6Pd7E=.8be0859b-cdda-47fc-8c44-2198fe8841d6@github.com> On Wed, 13 Nov 2019 22:11:14 GMT, Kevin Rushforth wrote: > On Wed, 13 Nov 2019 01:17:44 GMT, Kevin Rushforth wrote: > >> On Tue, 12 Nov 2019 10:35:36 GMT, Florian Kirmaier wrote: >> >>> On Wed, 6 Nov 2019 08:30:47 GMT, Kevin Rushforth wrote: >>> >>>> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >>>> >>>>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>>>> >>>>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>>>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>>>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>>>> >>>>> The pull request introduces a new fix for the problem. >>>>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>>>> We do so, by using setFocused. >>>>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>>>> because calling setFocused just sets the value of a boolean property. >>>>> >>>>> I've now also added a unit-test for the problem. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 314e423c: JDK-8200224 >>>>> - 725e5fef: JDK-8200224 >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>>>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >>>> >>>> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 457: >>>> >>>>> 456: >>>>> 457: sendMouseEventToFX(e); >>>>> 458: super.processMouseEvent(e); >>>> >>>> typo: save --> safe >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: >>>> >>>>> 1: /* >>>>> 2: * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. >>>>> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> >>>> replace `2014, 2016` with `2019,` >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 28: >>>> >>>>> 27: >>>>> 28: import javafx.application.Application; >>>>> 29: import javafx.application.Platform; >>>> >>>> Remove unused import (several of the below imports are similarly unused). Also, since this is a new test, please sort the imports. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 48: >>>> >>>>> 47: >>>>> 48: import static junit.framework.Assert.assertEquals; >>>>> 49: import static org.junit.Assert.assertNotNull; >>>> >>>> This method should be imported from `org.junit` package. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 116: >>>> >>>>> 115: MouseEvent e = new MouseEvent(fxPnl, MouseEvent.MOUSE_PRESSED, 0, MouseEvent.BUTTON1_DOWN_MASK, >>>>> 116: 5, 5, 1, false, MouseEvent.BUTTON1); >>>>> 117: >>>> >>>> This doesn't appear to trigger the bug -- at least on Windows. The test passes for me with or without your fix. You might consider moving it to the system tests project, under `tests/system/src/test/java/test/robot` and using `Robot` to effect the mouse press. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 57: >>>> >>>>> 56: >>>>> 57: >>>>> 58: @BeforeClass >>>> >>>> You can remove the extra blank line. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 65: >>>> >>>>> 64: >>>>> 65: >>>>> 66: try { >>>> >>>> You can remove the extra blank line. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 79: >>>> >>>>> 78: >>>>> 79: class TestFXPanel extends JFXPanel { >>>>> 80: protected void processMouseEventPublic(MouseEvent e) { >>>> >>>> I think this can be a static class. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 88: >>>> >>>>> 87: >>>>> 88: CountDownLatch firstPressedEventLatch = new CountDownLatch(1); >>>>> 89: >>>> >>>> This can be final. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 91: >>>> >>>>> 90: // It's an array, so we can mutate it inside of lambda statement >>>>> 91: int[] pressedEventCounter = {0}; >>>>> 92: >>>> >>>> This can be final. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 132: >>>> >>>>> 131: >>>>> 132: >>>>> 133: } >>>> >>>> You can remove the extra blank line. >>>> >>>> modules/javafx.swing/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 123: >>>> >>>>> 122: >>>>> 123: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >>>>> 124: throw new Exception(); >>>> >>>> Add a space after the `if`. >>>> >>>> The fix seems fine. Have you tested it on all three platforms? >>>> >>>> I have several comments on the test. >>>> >>>> ---------------- >>>> >>>> Disapproved by kcr (Lead). >>> >>> Maybe try `./gradlew -PFULL_TEST=true swing:clean swing:test`. >>> I'm sure, it can be reproduced on windows. >>> If you still can not reproduce it, then I will add a test for the Robot. >> >> I'll try it again with the updated test. >> >>> You can run the AWT_TESTS with the following statement: >>> >>> ``` >>> ./gradlew -PFULL_TEST=true swing:clean swing:test >>> ``` >> >> Yes, I know that it needs `-PFULL_TEST=true`, but the earlier test wasn't failing for me. And yes, it is intentional; for reasons I can't recall, the swing tests don't work in headless mode. Anyway, I don't want to revisit this right now. >> >>> The tests are now stable. The previous version had some problems because the other test for Swing was calling System.exit. >> >> Tests should not call `System.exit`. If they do, then that's almost certainly a bug. > > FYI, I filed [JDK-8234110](https://bugs.openjdk.java.net/browse/JDK-8234110) to move the existing `:swing` test to `:systemTests`. I've updated the pull request and merged it with master. Later, I will retest it with a Windows VM. I've done now the requested changes. Now only retesting it with Windows is left. I've now tested on Windows. I can confirm, that the test doesn't reproduce the error on Windows. PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.java.net Tue Nov 26 09:24:01 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 09:24:01 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 > > A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. > The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). > This fix introduced synthesized press-events, which is an unsafe fix for the problem. > > The pull request introduces a new fix for the problem. > Instead of simulating new input-events, we set JavaFX Scene/Window to focused. > We do so, by using setFocused. > When the original Swing-Focus event is called slightly later, it won't have any side-effects, > because calling setFocused just sets the value of a boolean property. > > I've now also added a unit-test for the problem. > > ---------------- > > Commits: > - 314e423c: JDK-8200224 > - 725e5fef: JDK-8200224 > > Changes: https://git.openjdk.java.net/jfx/pull/25/files > Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 I left a couple additional comments about the test changes. Namely: 1. You didn't fully revert the changes to `SwingFXUtilsTest` 2. Your new test should be put in its own class in `test.javafx.embed.swing` (and not in the exist mac-only Robot test) tests/system/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java line 87: > 86: testFromFXImg("opaque.gif"); > 87: testFromFXImg("opaque.jpg"); > 88: testFromFXImg("opaque.png"); You didn't fully revert your change to this file. The above needs to be restored such that when you are done, this file is unchanged versus master, and not part of the PR. tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 25: > 24: */ > 25: package test.robot.javafx.embed.swing; > 26: Since you aren't using `Robot` I'll repeat my earlier recommendation to put your new test in `test.javafx.embed.swing` (as a new test class) rather than modifying this existing test class. This class isn't suitable anyway, since it is only run on Mac. tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 40: > 39: import javax.swing.*; > 40: import java.awt.*; > 41: import java.awt.event.InputEvent; The use of wild card imports is discouraged (except for static imports). tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 129: > 128: JPanel jpanel = new JPanel(); > 129: jpanel.add(fxPnl); > 130: jframe.setContentPane(jpanel); You didn't add an initial dummy `JFXPanel` so I suspect it will still not catch the bug (meaning it will still pass even without your patch). ---------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.java.net Tue Nov 26 09:24:01 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 09:24:01 GMT Subject: [Rev 03] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 09:23:58 GMT, Florian Kirmaier wrote: > The pull request has been updated with a complete new set of changes (possibly due to a rebase). > > ---------------- > > Commits: > - 44774dfb: JDK-8200224 > - d1309fb6: JDK-8200224 > - 53a66b8f: JDK-8200224 > - 0be3cb5b: JDK-8200224 > - 03b59288: Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8200224 > - 5cd96a56: JDK-8200224 > - 85c87628: JDK-8200224 > - 314e423c: JDK-8200224 > - 725e5fef: JDK-8200224 > > Changes: https://git.openjdk.java.net/jfx/pull/25/files > Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.03 > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 272 lines in 3 files changed: 147 ins; 120 del; 5 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 To follow-up on my previous comment here are the requested changes: 1. Restore ` tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java`, which was removed by your last commit, so that it doesn't show up in the PR. 2. In the new test, add a dummy `JFXPanel` to the `JPanel` so that the test `JFXPanel` is the second one added (see my inline comments). This will allow the test to catch the error on Windows by failing without your fix. 3. A few other inline comments on the new test. tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: > 1: /* > 2: * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. That should be `2019` tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 35: > 34: > 35: > 36: import javax.swing.JFrame; You only need one blank line here. tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 94: > 93: > 94: class TestFXPanel extends JFXPanel { > 95: protected void processMouseEventPublic(MouseEvent e) { This class can be `static` tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 108: > 107: > 108: SwingUtilities.invokeLater(() -> { > 109: TestFXPanel fxPnl = new TestFXPanel(); Add the following here: JFXPanel dummyFXPanel = new JFXPanel(); dummyFXPanel.setPreferredSize(new Dimension(100, 100)); tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 112: > 111: JFrame jframe = new JFrame(); > 112: JPanel jpanel = new JPanel(); > 113: jpanel.add(fxPnl); Add the following here: jpanel.add(dummyFXPanel); tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 118: > 117: > 118: Platform.runLater(() -> { > 119: Group grp = new Group(); Add the following here: Scene dummyScene = new Scene(new Group()); dummyFXPanel.setScene(dummyScene); tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 138: > 137: > 138: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { > 139: throw new Exception(); This `if` test can be written more succinctly as: assertTrue(firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)); tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 72: > 71: @BeforeClass > 72: public static void doSetupOnce() { > 73: // Start the Application If you add `throws Exception` then you don't need the try/catch around the `launchLatch.await`. tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 119: > 118: Platform.runLater(() -> { > 119: Group grp = new Group(); > 120: Scene scene = new Scene(new Group()); This variable is unused. ---------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.java.net Tue Nov 26 13:06:36 2019 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 26 Nov 2019 13:06:36 GMT Subject: [Rev 04] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: The pull request has been updated with additional changes. ---------------- Added commits: - 24385eb8: JDK-8200224 - e0829ad3: JDK-8200224 - c190384f: JDK-8200224 - 17b458b1: JDK-8200224 Changes: - all: https://git.openjdk.java.net/jfx/pull/25/files - new: https://git.openjdk.java.net/jfx/pull/25/files/44774dfb..24385eb8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/25/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.03-04 Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 Stats: 141 lines in 2 files changed: 123 ins; 11 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.java.net Tue Nov 26 13:06:38 2019 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 26 Nov 2019 13:06:38 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 09:24:01 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: > >> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >> >> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >> >> The pull request introduces a new fix for the problem. >> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >> We do so, by using setFocused. >> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >> because calling setFocused just sets the value of a boolean property. >> >> I've now also added a unit-test for the problem. >> >> ---------------- >> >> Commits: >> - 314e423c: JDK-8200224 >> - 725e5fef: JDK-8200224 >> >> Changes: https://git.openjdk.java.net/jfx/pull/25/files >> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 > > I left a couple additional comments about the test changes. Namely: > > 1. You didn't fully revert the changes to `SwingFXUtilsTest` > 2. Your new test should be put in its own class in `test.javafx.embed.swing` (and not in the exist mac-only Robot test) > > tests/system/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java line 87: > >> 86: testFromFXImg("opaque.gif"); >> 87: testFromFXImg("opaque.jpg"); >> 88: testFromFXImg("opaque.png"); > > You didn't fully revert your change to this file. The above needs to be restored such that when you are done, this file is unchanged versus master, and not part of the PR. > > tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 25: > >> 24: */ >> 25: package test.robot.javafx.embed.swing; >> 26: > > Since you aren't using `Robot` I'll repeat my earlier recommendation to put your new test in `test.javafx.embed.swing` (as a new test class) rather than modifying this existing test class. This class isn't suitable anyway, since it is only run on Mac. > > tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 40: > >> 39: import javax.swing.*; >> 40: import java.awt.*; >> 41: import java.awt.event.InputEvent; > > The use of wild card imports is discouraged (except for static imports). > > tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 129: > >> 128: JPanel jpanel = new JPanel(); >> 129: jpanel.add(fxPnl); >> 130: jframe.setContentPane(jpanel); > > You didn't add an initial dummy `JFXPanel` so I suspect it will still not catch the bug (meaning it will still pass even without your patch). > > ---------------- > > Changes requested by kcr (Lead). 1. I've restored the test. But the git history is now very chaotic. Especially the moves might cause problems. Do the commits get squashed after merging? Otherwise, it might make sense, to redo the changes on a fresh branch and create a new pull request. 2. The test works now on windows. : ) PR: https://git.openjdk.java.net/jfx/pull/25 From fkirmaier at openjdk.java.net Tue Nov 26 13:06:41 2019 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 26 Nov 2019 13:06:41 GMT Subject: [Rev 03] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 09:24:01 GMT, Kevin Rushforth wrote: > On Tue, 26 Nov 2019 09:23:58 GMT, Florian Kirmaier wrote: > >> The pull request has been updated with a complete new set of changes (possibly due to a rebase). >> >> ---------------- >> >> Commits: >> - 44774dfb: JDK-8200224 >> - d1309fb6: JDK-8200224 >> - 53a66b8f: JDK-8200224 >> - 0be3cb5b: JDK-8200224 >> - 03b59288: Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8200224 >> - 5cd96a56: JDK-8200224 >> - 85c87628: JDK-8200224 >> - 314e423c: JDK-8200224 >> - 725e5fef: JDK-8200224 >> >> Changes: https://git.openjdk.java.net/jfx/pull/25/files >> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.03 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >> Stats: 272 lines in 3 files changed: 147 ins; 120 del; 5 mod >> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 > > To follow-up on my previous comment here are the requested changes: > > 1. Restore ` tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java`, which was removed by your last commit, so that it doesn't show up in the PR. > 2. In the new test, add a dummy `JFXPanel` to the `JPanel` so that the test `JFXPanel` is the second one added (see my inline comments). This will allow the test to catch the error on Windows by failing without your fix. > 3. A few other inline comments on the new test. > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > That should be `2019` > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 35: > >> 34: >> 35: >> 36: import javax.swing.JFrame; > > You only need one blank line here. > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 94: > >> 93: >> 94: class TestFXPanel extends JFXPanel { >> 95: protected void processMouseEventPublic(MouseEvent e) { > > This class can be `static` > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 108: > >> 107: >> 108: SwingUtilities.invokeLater(() -> { >> 109: TestFXPanel fxPnl = new TestFXPanel(); > > Add the following here: > JFXPanel dummyFXPanel = new JFXPanel(); > dummyFXPanel.setPreferredSize(new Dimension(100, 100)); > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 112: > >> 111: JFrame jframe = new JFrame(); >> 112: JPanel jpanel = new JPanel(); >> 113: jpanel.add(fxPnl); > > Add the following here: > jpanel.add(dummyFXPanel); > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 118: > >> 117: >> 118: Platform.runLater(() -> { >> 119: Group grp = new Group(); > > Add the following here: > Scene dummyScene = new Scene(new Group()); > dummyFXPanel.setScene(dummyScene); > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 138: > >> 137: >> 138: if(!firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)) { >> 139: throw new Exception(); > > This `if` test can be written more succinctly as: > > assertTrue(firstPressedEventLatch.await(5000, TimeUnit.MILLISECONDS)); > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 72: > >> 71: @BeforeClass >> 72: public static void doSetupOnce() { >> 73: // Start the Application > > If you add `throws Exception` then you don't need the try/catch around the `launchLatch.await`. > > tests/system/src/test/java/test/javafx/embed/swing/JFXPanelTest.java line 119: > >> 118: Platform.runLater(() -> { >> 119: Group grp = new Group(); >> 120: Scene scene = new Scene(new Group()); > > This variable is unused. > > ---------------- > > Changes requested by kcr (Lead). The if is triggered, when the time runs out. remvoed done done It's now simplified. done PR: https://git.openjdk.java.net/jfx/pull/25 From kcr at openjdk.java.net Tue Nov 26 13:14:46 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 13:14:46 GMT Subject: RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: <0WfZwq0WJvyFs8azelFiuwBKmxj222FRepOKWGlOgB0=.d9f659bf-aeb2-42d8-9ab1-8f452e5fe44c@github.com> On Tue, 26 Nov 2019 13:06:38 GMT, Florian Kirmaier wrote: > On Tue, 26 Nov 2019 09:24:01 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 11:27:35 GMT, Florian Kirmaier wrote: >> >>> Original PR: https://github.com/javafxports/openjdk-jfx/pull/591 >>> >>> A side effect of JDK-8200224 is, that the first click on a JFXPanel is always a double click. >>> The cause for JDK-8200224 is the fix for JDK-8087914 (Clicking on Menu in JFXPanel ignored if another swing component has focus). >>> This fix introduced synthesized press-events, which is an unsafe fix for the problem. >>> >>> The pull request introduces a new fix for the problem. >>> Instead of simulating new input-events, we set JavaFX Scene/Window to focused. >>> We do so, by using setFocused. >>> When the original Swing-Focus event is called slightly later, it won't have any side-effects, >>> because calling setFocused just sets the value of a boolean property. >>> >>> I've now also added a unit-test for the problem. >>> >>> ---------------- >>> >>> Commits: >>> - 314e423c: JDK-8200224 >>> - 725e5fef: JDK-8200224 >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/25/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/25/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 >>> Stats: 140 lines in 2 files changed: 133 ins; 2 del; 5 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/25.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 >> >> I left a couple additional comments about the test changes. Namely: >> >> 1. You didn't fully revert the changes to `SwingFXUtilsTest` >> 2. Your new test should be put in its own class in `test.javafx.embed.swing` (and not in the exist mac-only Robot test) >> >> tests/system/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java line 87: >> >>> 86: testFromFXImg("opaque.gif"); >>> 87: testFromFXImg("opaque.jpg"); >>> 88: testFromFXImg("opaque.png"); >> >> You didn't fully revert your change to this file. The above needs to be restored such that when you are done, this file is unchanged versus master, and not part of the PR. >> >> tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 25: >> >>> 24: */ >>> 25: package test.robot.javafx.embed.swing; >>> 26: >> >> Since you aren't using `Robot` I'll repeat my earlier recommendation to put your new test in `test.javafx.embed.swing` (as a new test class) rather than modifying this existing test class. This class isn't suitable anyway, since it is only run on Mac. >> >> tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 40: >> >>> 39: import javax.swing.*; >>> 40: import java.awt.*; >>> 41: import java.awt.event.InputEvent; >> >> The use of wild card imports is discouraged (except for static imports). >> >> tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelTest.java line 129: >> >>> 128: JPanel jpanel = new JPanel(); >>> 129: jpanel.add(fxPnl); >>> 130: jframe.setContentPane(jpanel); >> >> You didn't add an initial dummy `JFXPanel` so I suspect it will still not catch the bug (meaning it will still pass even without your patch). >> >> ---------------- >> >> Changes requested by kcr (Lead). > > 1. I've restored the test. But the git history is now very chaotic. Especially the moves might cause problems. Do the commits get squashed after merging? Otherwise, it might make sense, to redo the changes on a fresh branch and create a new pull request. > 2. The test works now on windows. : ) Yes, the commits are squashed, so don't worry about the history (in worst case I would ask you to do a squash-rebase / force push rather than create a new PR, but that isn't needed here). At first glance the changes you made look good. I'll take a closer look later. @prsadhuk please also review this. PR: https://git.openjdk.java.net/jfx/pull/25 From github.com+3070076+DJViking at openjdk.java.net Tue Nov 26 15:04:51 2019 From: github.com+3070076+DJViking at openjdk.java.net (Sverre Moe) Date: Tue, 26 Nov 2019 15:04:51 GMT Subject: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 09:22:04 GMT, Kevin Rushforth wrote: > On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote: > >> **Issue :** >> https://bugs.openjdk.java.net/browse/JDK-8193445 >> >> **Background :** >> The CSS performance improvement done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be backed out due to functional regressions reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for more details on this backout. >> >> **Description :** >> This PR reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while addressing the functional regressions that were reported in [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951). >> For ease of review, I have made two separate commits - >> 1) [Commit 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334) - Reintroduces the CSS performance improvement fix done in [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the patch applied cleanly. >> 2) [Commit 2 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)- fixes the functional regressions keeping performance improvement intact + adds a system test >> >> **Root Cause :** >> CSS performance improvement fix proposed in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the redundant CSS reapplication to children of a Parent. >> What was missed earlier in [JDK-8151756 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication to the Parent itself?. >> This missing piece was the root cause of all functional regressions reported against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) >> >> **Fix :** >> Fixed the identified root cause. See commit 2. >> >> **Testing :** >> 1. All passing unit tests continue to pass >> 2. New system test (based on [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in this PR - fails before this fix and passes after the fix >> 3. System test JDK8183100Test continues to pass >> 4. All test cases attached to regressions [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with this fix >> >> In addition, testing by community with specific CSS performance / functionality will be helpful. >> >> ---------------- >> >> Commits: >> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test >> - d964675e: Reintroduce JDK-8151756 CSS performance fix >> >> Changes: https://git.openjdk.java.net/jfx/pull/34/files >> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 >> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod >> Patch: https://git.openjdk.java.net/jfx/pull/34.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 > > The fix itself looks good and is a much safer approach than the previous one. I've done a fair bit of testing and can see no regressions as a result of this fix. I did find one unrelated issue while testing (a visual bug introduced back in JDK 10) that I will file separately. > > The test is pretty close, but still needs a few changes. The main problem is that it does not catch the performance problem, meaning if you run it without the fix, it will still pass. Your test class extends `javafx.application.Application`, which can cause problems, since JUnit will create a new instance of the test class that is different from the one created by the call to `Application.launch` in the `@BeforeClass` method. This in turn leads to the `rootPane` instance used by the test method being different from the one used as the root of the visible scene. The fix is to use a separate nested (static) subclass of Application, and make the rootPane field a static field. I have left inline comments for this and a few other things I noticed. > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 63: > >> 62: >> 63: public class QuadraticCssTimeTest extends Application { >> 64: > > Remove `extends Application` > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 66: > >> 65: static private CountDownLatch startupLatch; >> 66: static private Stage stage; >> 67: private BorderPane rootPane = new BorderPane(); > > Minor: our convention is `private static`. > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 67: > >> 66: static private Stage stage; >> 67: private BorderPane rootPane = new BorderPane(); >> 68: > > Based on how it is used, this needs to be a `static` field (this will not compile anyway once you move the `start method` to a nested class). Also, there is no need to initialize it both here and in the `Application::start` method. One or the other will do. > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 70: > >> 69: @Override >> 70: public void start(Stage primaryStage) throws Exception { >> 71: stage = primaryStage; > > Enclose this method in a nested subclass of Application: > > public static class TestApp extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > ... > } > } > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 81: > >> 80: @BeforeClass >> 81: public static void initFX() { >> 82: startupLatch = new CountDownLatch(1); > > If you add `throws Exception` to the method signature you can avoid the try / catch (most of our newer tests do this). > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 86: > >> 85: try { >> 86: if (!startupLatch.await(15, TimeUnit.SECONDS)) { >> 87: Assert.fail("Timeout waiting for FX runtime to start"); > > The entire try / catch block, including the `if` test, can be simplified to this: > > assertTrue(startupLatch.await(15, TimeUnit.SECONDS)); > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 96: > >> 95: public void testTimeForAdding500NodesToScene() throws Exception { >> 96: >> 97: // Compute time for adding 500 Nodes > > Adding a node to a live scene graph must be done on the JavaFX Application thread. I recommend wrapping the body of this method in a `Util.runAndWait` call. > > tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line 83: > >> 82: startupLatch = new CountDownLatch(1); >> 83: new Thread(() -> Application.launch(QuadraticCssTimeTest.class, (String[]) null)).start(); >> 84: > > Change `QuadraticCssTimeTest.class` to `TestApp.class`. > > ---------------- > > Changes requested by kcr (Lead). I am curious. Will?Could this CSS performance improvement be backported to JavaFX 11? The bug report says only that it will be fixed in JavaFX 14. PR: https://git.openjdk.java.net/jfx/pull/34 From arapte at openjdk.java.net Tue Nov 26 15:16:38 2019 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 26 Nov 2019 15:16:38 GMT Subject: RFR: 8196587: Remove use of deprecated finalize method from JPEGImageLoader Message-ID: The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html). And so the JPEGImageLoader.finalize() method should be removed. The change is, 1. Remove finalize method from JPEGImageLoader class. 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method. 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added. Verification: Verified :graphics:test and system tests on all three platforms. Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load() ---------------- Commits: - b48c8087: 8196587: Remove use of deprecated finalize method from JPEGImageLoader Changes: https://git.openjdk.java.net/jfx/pull/50/files Webrev: https://webrevs.openjdk.java.net/jfx/50/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196587 Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50 PR: https://git.openjdk.java.net/jfx/pull/50 From kcr at openjdk.java.net Tue Nov 26 15:16:41 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 15:16:41 GMT Subject: RFR: 8196587: Remove use of deprecated finalize method from JPEGImageLoader In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte wrote: > The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html). > And so the JPEGImageLoader.finalize() method should be removed. > > The change is, > 1. Remove finalize method from JPEGImageLoader class. > > 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method. > > 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added. > > Verification: > Verified :graphics:test and system tests on all three platforms. > Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load() > > ---------------- > > Commits: > - b48c8087: 8196587: Remove use of deprecated finalize method from JPEGImageLoader > > Changes: https://git.openjdk.java.net/jfx/pull/50/files > Webrev: https://webrevs.openjdk.java.net/jfx/50/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8196587 > Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/50.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50 I still need to double-check all calls to dispose, but I think this is essentially the right solution, and is ready to be submitted for review. I added one comment inline. modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 273: > 272: } else { > 273: throw new ImageStorageException("No loader for image data"); > 274: } Now that this is moved inside a try/catch, this `ImageStorageException` will get wrapped in another `ImageStorageException` if it is ever thrown. You probably want to catch `ImageStorageException` below and re-throw it without wrapping it. PR: https://git.openjdk.java.net/jfx/pull/50 From swpalmer at openjdk.java.net Tue Nov 26 17:26:33 2019 From: swpalmer at openjdk.java.net (Scott Palmer) Date: Tue, 26 Nov 2019 17:26:33 GMT Subject: [Rev 02] RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: The pull request has been updated with a complete new set of changes (possibly due to a rebase). ---------------- Commits: - 254c40de: Merge remote-tracking branch 'upstream/master' - a670c4f8: 8130738: TextFlow's tab width is static - 68d221c7: 8130738: TextFlow's tab width is static Changes: https://git.openjdk.java.net/jfx/pull/32/files Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.02 Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 Stats: 325 lines in 8 files changed: 261 ins; 0 del; 64 mod Patch: https://git.openjdk.java.net/jfx/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 PR: https://git.openjdk.java.net/jfx/pull/32 From prr at openjdk.java.net Tue Nov 26 17:45:31 2019 From: prr at openjdk.java.net (Phil Race) Date: Tue, 26 Nov 2019 17:45:31 GMT Subject: [Rev 02] RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 17:26:33 GMT, Scott Palmer wrote: > The pull request has been updated with a complete new set of changes (possibly due to a rebase). > > ---------------- > > Commits: > - 254c40de: Merge remote-tracking branch 'upstream/master' > - a670c4f8: 8130738: TextFlow's tab width is static > - 68d221c7: 8130738: TextFlow's tab width is static > > Changes: https://git.openjdk.java.net/jfx/pull/32/files > Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.02 > Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 > Stats: 325 lines in 8 files changed: 261 ins; 0 del; 64 mod > Patch: https://git.openjdk.java.net/jfx/pull/32.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 Why do we have a ton of extraneous white space changes in the Stylesheet Handling sections of Text.java and TextFlow.java ? PR: https://git.openjdk.java.net/jfx/pull/32 From swpalmer at openjdk.java.net Tue Nov 26 18:40:10 2019 From: swpalmer at openjdk.java.net (Scott Palmer) Date: Tue, 26 Nov 2019 18:40:10 GMT Subject: RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: On Thu, 7 Nov 2019 14:56:58 GMT, Kevin Rushforth wrote: > On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer wrote: > >> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both. TextFlow's tab size overrides that of contained Text nodes. >> >> ---------------- >> >> Commits: >> - 68d221c7: 8130738: TextFlow's tab width is static >> >> Changes: https://git.openjdk.java.net/jfx/pull/32/files >> Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 >> Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod >> Patch: https://git.openjdk.java.net/jfx/pull/32.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 > >> I should clamp so it reads back as 1 - Fixed. > > This has implications for binding, etc., so I suspect this is not what we want. I'll look into this more when I review it. > > NOTE: This will need a CSR in addition to two reviewers. You can file the CSR any time, but I suggest leaving it in Draft state until Phil and I have had a first pass look at the API. The indenting was wrong in that section and I had to make some minor changes, so I corrected the bad indenting. Kevin indicated, "In your specific case, reformatting the methods in the StyleableProperties nested class that are adjacent to code you add or modify seems fine, as long as you only change the indentation and not the line wrapping." I didn't intend to trigger an update to this pull request...I find Git awkward to work with (Mercurial makes more sense to me) so I'm making mistakes as I bumble around. I do expect an update to address the way I've clamped to 1. I agree with Kevin that it is probable wrong. Just waiting for feedback. PR: https://git.openjdk.java.net/jfx/pull/32 From kcr at openjdk.java.net Tue Nov 26 18:48:38 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 18:48:38 GMT Subject: RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 18:40:10 GMT, Scott Palmer wrote: > On Thu, 7 Nov 2019 14:56:58 GMT, Kevin Rushforth wrote: > >> On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer wrote: >> >>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both. TextFlow's tab size overrides that of contained Text nodes. >>> >>> ---------------- >>> >>> Commits: >>> - 68d221c7: 8130738: TextFlow's tab width is static >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/32/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 >>> Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/32.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 >> >>> I should clamp so it reads back as 1 - Fixed. >> >> This has implications for binding, etc., so I suspect this is not what we want. I'll look into this more when I review it. >> >> NOTE: This will need a CSR in addition to two reviewers. You can file the CSR any time, but I suggest leaving it in Draft state until Phil and I have had a first pass look at the API. > > The indenting was wrong in that section and I had to make some minor changes, so I corrected the bad indenting. Kevin indicated, "In your specific case, reformatting the methods in the StyleableProperties nested class that are adjacent to code you add or modify seems fine, as long as you only change the indentation and not the line wrapping." > > I didn't intend to trigger an update to this pull request...I find Git awkward to work with (Mercurial makes more sense to me) so I'm making mistakes as I bumble around. > > I do expect an update to address the way I've clamped to 1. I agree with Kevin that it is probable wrong. Just waiting for feedback. I'll take a preliminary look today. I also plan to change the bug title to make it more clear that it is an enhancement request, since it currently reads like a bug report (I'll also change the CSR and PR title to match). PR: https://git.openjdk.java.net/jfx/pull/32 From kcr at openjdk.java.net Tue Nov 26 18:52:30 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Nov 2019 18:52:30 GMT Subject: [Approved] RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 09:22:01 GMT, Ajit Ghaisas wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 2054da4c: Address review comments on test > - 4dade6e5: Simpler fix + System test corrections > - bd4a306a: Revert commit1 and commit 2 > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/34/files > - new: https://git.openjdk.java.net/jfx/pull/34/files/12ea8220..2054da4c > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/34/webrev.01 > - incr: https://webrevs.openjdk.java.net/jfx/34/webrev.00-01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8193445 > Stats: 253 lines in 6 files changed: 132 ins; 104 del; 17 mod > Patch: https://git.openjdk.java.net/jfx/pull/34.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34 Looks good. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/34 From almatvee at openjdk.java.net Tue Nov 26 22:33:52 2019 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 26 Nov 2019 22:33:52 GMT Subject: [Integrated] RFR: 8230610: Upgrade GStreamer to the latest 1.16.1 In-Reply-To: References: Message-ID: <8841f928-33f3-449e-a4ef-5c15fed04986@openjdk.org> Changeset: 798afbca Author: Alexander Matveev Date: 2019-11-26 22:33:00 +0000 URL: https://git.openjdk.java.net/jfx/commit/798afbca 8230610: Upgrade GStreamer to version 1.16.1 8230609: Upgrade glib to version 2.62.2 Reviewed-by: kcr, jvos ! modules/javafx.media/src/main/legal/glib.md ! modules/javafx.media/src/main/legal/gstreamer.md ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/osx/config.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/osx/glibconfig.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/dirent/dirent.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/dirent/dirent.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/config.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/glib-lite.def - modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/glib-liteD.def ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/glibconfig.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/gmoduleconf.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/msvc_recommended_pragmas.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/deprecated/gthread.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/galloca.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/garray.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/garray.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gasyncqueue.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gasyncqueue.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gatomic.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gatomic.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbacktrace.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbase64.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbitlock.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbitlock.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbookmarkfile.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbookmarkfile.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbytes.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbytes.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gcharset.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gcharset.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gchecksum.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gconstructor.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gconvert.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gconvert.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdataset.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdataset.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdatasetprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdatetime.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdatetime.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdir.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdir.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/genviron.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gerror.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gerror.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gfileutils.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gfileutils.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ggettext.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghash.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghash.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghmac.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghook.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghook.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghostutils.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/giochannel.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/giochannel.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/giounix.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/giowin32.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gkeyfile.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gkeyfile.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib-autocleanups.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib-init.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib-init.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib-object.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib-private.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib-unix.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glib.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glist.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/glist.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmacros.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmain.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmain.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmappedfile.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmappedfile.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmarkup.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmarkup.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmem.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmem.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmessages.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmessages.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gmirroringtable.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnode.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnode.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/asnprintf.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/printf-args.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/printf-args.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/printf-parse.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/printf-parse.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/printf.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/vasnprintf.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/vasnprintf.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/verify.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gnulib/xsize.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/goption.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/goption.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gpattern.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gpattern.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gpoll.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gpoll.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gprimes.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gprimes.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gprintf.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gprintf.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gprintfint.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gqsort.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gqsort.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gquark.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gqueue.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gqueue.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/grand.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/grand.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/grcbox.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/grcboxprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/grefcount.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/grefcount.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gregex.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gregex.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gscanner.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gscanner.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gscripttable.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gsequence.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gshell.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gslice.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gslice.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gslist.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gslist.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gspawn-win32-helper.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gspawn-win32.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gspawn.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gspawn.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstdio-private.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstdio.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstdio.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstdioprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstrfuncs.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstrfuncs.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstring.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gstring.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtestutils.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtestutils.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gthread-posix.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gthread-win32.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gthread.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gthread.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gthreadpool.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gthreadprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtimer.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtimer.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtimezone.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtimezone.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtranslit.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtrashstack.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtrashstack.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtree.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtree.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gtypes.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunibreak.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunichartables.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunicode.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunicodeprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunicollate.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunidecomp.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gunidecomp.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/guniprop.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gurifuncs.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gurifuncs.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gutf8.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gutils.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gutils.h + modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gutilsprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant-core.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant-core.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant-internal.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant-parser.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant-serialiser.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant-serialiser.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvariant.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvarianttype.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvarianttype.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvarianttypeinfo.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gvarianttypeinfo.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gversionmacros.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gwakeup.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gwakeup.h + modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gwin32-private.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gwin32.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gwin32.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/libcharset/libcharset.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/libcharset/localcharset.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/win_iconv.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gmodule/gmodule-dl.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gmodule/gmodule-dyld.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gmodule/gmodule-win32.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gmodule/gmodule.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gmodule/gmodule.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gatomicarray.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gatomicarray.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gbinding.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gboxed.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gclosure.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gclosure.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/genums.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/genums.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gmarshal.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gmarshal.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gobject-autocleanups.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gobject.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gobject.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gparam.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gparam.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gparamspecs.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gparamspecs.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gsignal.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gsignal.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gsourceclosure.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gsourceclosure.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtype-private.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtype.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtype.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtypemodule.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtypemodule.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtypeplugin.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gtypeplugin.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvalue.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvalue.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvaluearray.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvaluearray.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvaluecollector.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvaluetransform.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvaluetypes.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/gobject/gvaluetypes.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-bad/gst/aiff/aiffparse.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-bad/gst/aiff/aiffparse.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/COPYING ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/ext/alsa/gstalsa.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/ext/alsa/gstalsasink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/ext/alsa/gstalsasink.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/app/app-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/app/gstappsink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/app/gstappsrc.c + modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c + modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-channel-mixer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-channels.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-converter.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-converter.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-format.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-format.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-quantize.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-resampler.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiobasesink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiobasesrc.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiodecoder.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiodecoder.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudioencoder.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudioencoder.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiometa.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiometa.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudioringbuffer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudioringbuffer.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiosink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudiosrc.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudioutilsprivate.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/gstaudioutilsprivate.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/fft/_kiss_fft_guts_f32.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/fft/fft-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/codec-utils.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/descriptions.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/gstaudiovisualizer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/gstaudiovisualizer.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/gstdiscoverer-types.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/gstdiscoverer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/gstdiscoverer.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/gstpluginsbaseversion.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/pbutils-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/pbutils-private.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/pbutils/pbutils.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/riff/riff-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/gstid3tag.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/gsttageditingprivate.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/lang-tables.dat ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/mklangtables.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/tag-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/tag/tag.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/convertframe.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideoencoder.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideoencoder.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideometa.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideometa.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideopool.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideosink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideotimecode.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideotimecode.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideoutils.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/gstvideoutils.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/navigation.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-chroma.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-color.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-color.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-converter.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-converter.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-dither.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-event.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-format.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-format.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-frame.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-frame.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-info.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-info.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-multiview.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-orc-dist.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-orc-dist.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-orc.orc ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-overlay-composition.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-overlay-composition.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video-tile.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/video.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/videooverlay.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst-libs/gst/video/videooverlay.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst/audioconvert/gstaudioconvert.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst/typefind/gsttypefindfunctions.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/gst/volume/gstvolume.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-base/win32/common/config.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audiofx/audiofx.c - modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c - modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/parsersplugin.c - modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/plugin.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/equalizer/gstiirequalizer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/fourcc.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/properties.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/qtdemux.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/qtdemux.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/qtdemux_dump.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/qtdemux_types.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/spectrum/gstspectrum.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/wavparse/gstwavparse.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/wavparse/gstwavparse.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/directsound/gstdirectsoundplugin.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/directsound/gstdirectsoundsink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/directsound/gstdirectsoundsink.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/osxaudio/gstosxaudiosink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/osxaudio/gstosxcoreaudio.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst_private.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstallocator.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstallocator.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbin.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbin.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbuffer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbuffer.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbufferlist.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbufferlist.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbufferpool.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbufferpool.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstbus.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstcaps.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstcaps.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstcapsfeatures.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstchildproxy.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstclock.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstclock.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstcontext.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstcontrolbinding.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstcontrolbinding.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstdatetime.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstdebugutils.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstdebugutils.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstelement.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstelement.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstelementfactory.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstelementfactory.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsterror.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstevent.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstevent.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstghostpad.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstinfo.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstinfo.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmacros.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmemory.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmemory.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmessage.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmessage.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmeta.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstmeta.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstminiobject.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstminiobject.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstobject.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstobject.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpad.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpad.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpadtemplate.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpadtemplate.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstparamspecs.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstparse.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstparse.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpipeline.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstplugin.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstplugin.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpluginfeature.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpoll.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstpoll.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstprotection.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstprotection.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstquark.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstquark.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstquery.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstquery.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstregistry.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstregistrybinary.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstregistrychunks.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstsample.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstsample.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstsegment.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstsegment.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gststreamcollection.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gststreams.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gststreams.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gststructure.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gststructure.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstsystemclock.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstsystemclock.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttaglist.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttaglist.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttask.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttaskpool.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttaskpool.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttoc.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttracer.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttracerrecord.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttracerrecord.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttracerutils.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttracerutils.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttypefind.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsttypefindfactory.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsturi.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gsturi.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstutils.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstutils.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstvalue.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstvalue.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/base-prelude.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/base.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstadapter.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbaseparse.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbaseparse.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbasesink.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbasesink.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbasesrc.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbasetransform.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstbasetransform.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstcollectpads.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstcollectpads.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstdataqueue.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstdataqueue.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstflowcombiner.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstindex.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstqueuearray.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gstqueuearray.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gsttypefindhelper.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/base/gsttypefindhelper.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gstargbcontrolbinding.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gstdirectcontrolbinding.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gstinterpolationcontrolsource.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gstinterpolationcontrolsource.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gstlfocontrolsource.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gsttimedvaluecontrolsource.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/libs/gst/controller/gsttriggercontrolsource.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/plugins/elements/gstqueue.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/plugins/elements/gsttypefindelement.c ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/plugins/elements/gsttypefindelement.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/osx/common/x86_64/config.h ! modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/win32/common/config.h ! modules/javafx.media/src/main/native/gstreamer/projects/linux/gstreamer-lite/Makefile ! modules/javafx.media/src/main/native/gstreamer/projects/mac/gstreamer-lite/Makefile ! modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite/Makefile ! modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite/Makefile.glib ! modules/javafx.media/src/main/native/gstreamer/projects/win/gstreamer-lite/Makefile.gstreamer ! modules/javafx.media/src/tools/native/def-glib.pl From kcr at openjdk.java.net Wed Nov 27 00:58:22 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Nov 2019 00:58:22 GMT Subject: [Rev 02] RFR: 8130738: TextFlow's tab width is static In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 17:26:33 GMT, Scott Palmer wrote: > The pull request has been updated with a complete new set of changes (possibly due to a rebase). > > ---------------- > > Commits: > - 254c40de: Merge remote-tracking branch 'upstream/master' > - a670c4f8: 8130738: TextFlow's tab width is static > - 68d221c7: 8130738: TextFlow's tab width is static > > Changes: https://git.openjdk.java.net/jfx/pull/32/files > Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.02 > Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 > Stats: 325 lines in 8 files changed: 261 ins; 0 del; 64 mod > Patch: https://git.openjdk.java.net/jfx/pull/32.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 I did a first pass review focusing mostly on the public API. Once we get that solidified I'll look at the implementation and tests more closely. Also, once the public API is done, you can update the CSR with the API. modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 3035: > 3034:   > 3035: > 3036: -fx-text-alignment the `` should be on the next line (once you do, you can remove the trailing white space that will then be present). modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 655: > 654: if (spaces < 1) > 655: spaces = 1; > 656: if (tabSize != spaces) { Please surround the statement with curly braces (our coding style is to always surround the target of a conditional in curly braces unless it is on the same line). modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1289: > 1288: * @since 14 > 1289: */ > 1290: public final int getTabSize() { The javadoc property support only requires one of the setXxxx/getXxxx/xxxxProperty methods to have a javadoc comment block. The javadoc tool takes care of documenting the property itself and all three methods. See `wrappingWidth` for a good example. modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1302: > 1301: * @since 14 > 1302: */ > 1303: public final void setTabSize(int spaces) { Same comment as on the set method. You can move the comment about values being clamped to 1 to the property method (which will then be the only method with javadoc comments). If we use my recommendation of clamping on usage, I recommend the following language, borrowed from `Node::opacity`: Values less than 1 are treated as 1. modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1895: > 1894: } > 1895: @Override public void set(int v) { super.set((v < 1) ? 1 : v); } > 1896: @Override protected void invalidated() { For mutable properties, we usually clamp on usage, so that we don't have problems binding to the value. This preserves the invariant that `set(val); get() == val` for all values. If that is what we end up doing, then this overridden method should be removed. modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 515: > 514: * @since 14 > 515: */ > 516: public final void setTabSize(int spaces) { Same comments about the javadoc comments as for `Text.java` modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 528: > 527: } > 528: @Override public void set(int v) { super.set((v < 1) ? 1 : v); } > 529: @Override protected void invalidated() { Same clamp-on-use comment as in `Text.java` modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubTextLayout.java line 200: > 199: if (spaces < 1) > 200: spaces = 1; > 201: if (tabSize != spaces) { Either surround with braces or put onto the same line as the `if` test. modules/javafx.graphics/src/test/java/test/javafx/scene/text/TextTest.java line 271: > 270: } > 271: } > 272: } In addition to the above test, I recommend some (very basic) tests of the setter / getting / property methods. modules/javafx.graphics/src/test/java/test/javafx/scene/text/TextTest.java line 251: > 250: tk.firePulse(); > 251: assertEquals(text.getTabSize(),8); > 252: // initial width with default 8-space tab This is backwards. The expected value should be the first argument. PR: https://git.openjdk.java.net/jfx/pull/32 From swpalmer at openjdk.java.net Wed Nov 27 01:17:42 2019 From: swpalmer at openjdk.java.net (Scott Palmer) Date: Wed, 27 Nov 2019 01:17:42 GMT Subject: RFR: 8130738: Add tabSize property to Text and TextFlow In-Reply-To: References: Message-ID: <-TilTci_6QluCKYrfE8qHXjn2xfAvyI9PwBRjyvxMzo=.d83851b2-2501-4a22-b330-b090da4199a5@github.com> On Tue, 26 Nov 2019 18:48:38 GMT, Kevin Rushforth wrote: > On Tue, 26 Nov 2019 18:40:10 GMT, Scott Palmer wrote: > >> On Thu, 7 Nov 2019 14:56:58 GMT, Kevin Rushforth wrote: >> >>> On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer wrote: >>> >>>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both. TextFlow's tab size overrides that of contained Text nodes. >>>> >>>> ---------------- >>>> >>>> Commits: >>>> - 68d221c7: 8130738: TextFlow's tab width is static >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/32/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 >>>> Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/32.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 >>> >>>> I should clamp so it reads back as 1 - Fixed. >>> >>> This has implications for binding, etc., so I suspect this is not what we want. I'll look into this more when I review it. >>> >>> NOTE: This will need a CSR in addition to two reviewers. You can file the CSR any time, but I suggest leaving it in Draft state until Phil and I have had a first pass look at the API. >> >> The indenting was wrong in that section and I had to make some minor changes, so I corrected the bad indenting. Kevin indicated, "In your specific case, reformatting the methods in the StyleableProperties nested class that are adjacent to code you add or modify seems fine, as long as you only change the indentation and not the line wrapping." >> >> I didn't intend to trigger an update to this pull request...I find Git awkward to work with (Mercurial makes more sense to me) so I'm making mistakes as I bumble around. >> >> I do expect an update to address the way I've clamped to 1. I agree with Kevin that it is probable wrong. Just waiting for feedback. > > I'll take a preliminary look today. I also plan to change the bug title to make it more clear that it is an enhancement request, since it currently reads like a bug report (I'll also change the CSR and PR title to match). I just noticed that Text.toString is missing any indication of the tabSize. (Found by accident when I search for wrappingWidth to see how the javadocs were done.) Is there any rule as to where in the order of properties ", tabSize = X" should be in the string? I assume it should only be included when not set to the default value, much like lineSpacing? PR: https://git.openjdk.java.net/jfx/pull/32 From kcr at openjdk.java.net Wed Nov 27 01:30:22 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Nov 2019 01:30:22 GMT Subject: RFR: 8130738: Add tabSize property to Text and TextFlow In-Reply-To: <-TilTci_6QluCKYrfE8qHXjn2xfAvyI9PwBRjyvxMzo=.d83851b2-2501-4a22-b330-b090da4199a5@github.com> References: <-TilTci_6QluCKYrfE8qHXjn2xfAvyI9PwBRjyvxMzo=.d83851b2-2501-4a22-b330-b090da4199a5@github.com> Message-ID: On Wed, 27 Nov 2019 01:17:42 GMT, Scott Palmer wrote: > On Tue, 26 Nov 2019 18:48:38 GMT, Kevin Rushforth wrote: > >> On Tue, 26 Nov 2019 18:40:10 GMT, Scott Palmer wrote: >> >>> On Thu, 7 Nov 2019 14:56:58 GMT, Kevin Rushforth wrote: >>> >>>> On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer wrote: >>>> >>>>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both. TextFlow's tab size overrides that of contained Text nodes. >>>>> >>>>> ---------------- >>>>> >>>>> Commits: >>>>> - 68d221c7: 8130738: TextFlow's tab width is static >>>>> >>>>> Changes: https://git.openjdk.java.net/jfx/pull/32/files >>>>> Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8130738 >>>>> Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod >>>>> Patch: https://git.openjdk.java.net/jfx/pull/32.diff >>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32 >>>> >>>>> I should clamp so it reads back as 1 - Fixed. >>>> >>>> This has implications for binding, etc., so I suspect this is not what we want. I'll look into this more when I review it. >>>> >>>> NOTE: This will need a CSR in addition to two reviewers. You can file the CSR any time, but I suggest leaving it in Draft state until Phil and I have had a first pass look at the API. >>> >>> The indenting was wrong in that section and I had to make some minor changes, so I corrected the bad indenting. Kevin indicated, "In your specific case, reformatting the methods in the StyleableProperties nested class that are adjacent to code you add or modify seems fine, as long as you only change the indentation and not the line wrapping." >>> >>> I didn't intend to trigger an update to this pull request...I find Git awkward to work with (Mercurial makes more sense to me) so I'm making mistakes as I bumble around. >>> >>> I do expect an update to address the way I've clamped to 1. I agree with Kevin that it is probable wrong. Just waiting for feedback. >> >> I'll take a preliminary look today. I also plan to change the bug title to make it more clear that it is an enhancement request, since it currently reads like a bug report (I'll also change the CSR and PR title to match). > > I just noticed that Text.toString is missing any indication of the tabSize. (Found by accident when I search for wrappingWidth to see how the javadocs were done.) > Is there any rule as to where in the order of properties ", tabSize = X" should be in the string? I assume it should only be included when not set to the default value, much like lineSpacing? Yes, I think your idea of including `tabSize` in `Text.toString` when != default is a good one. PR: https://git.openjdk.java.net/jfx/pull/32 From kcr at openjdk.java.net Wed Nov 27 02:06:34 2019 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Nov 2019 02:06:34 GMT Subject: [Approved] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: <8NW6tVYwi-unwgrYUAoOfPUsgIFf1lPBb1dQtZYaD2A=.b2a40c74-2adb-458c-ac0b-c7ec59b0e0ea@github.com> On Tue, 26 Nov 2019 13:06:36 GMT, Florian Kirmaier wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 24385eb8: JDK-8200224 > - e0829ad3: JDK-8200224 > - c190384f: JDK-8200224 > - 17b458b1: JDK-8200224 > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/25/files > - new: https://git.openjdk.java.net/jfx/pull/25/files/44774dfb..24385eb8 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/25/webrev.04 > - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.03-04 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 141 lines in 2 files changed: 123 ins; 11 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 All looks good now. As a reminder, this will need a second reviewer. ---------------- Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/25 From psadhukhan at openjdk.java.net Wed Nov 27 05:31:27 2019 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 27 Nov 2019 05:31:27 GMT Subject: [Rev 04] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 13:06:36 GMT, Florian Kirmaier wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 24385eb8: JDK-8200224 > - e0829ad3: JDK-8200224 > - c190384f: JDK-8200224 > - 17b458b1: JDK-8200224 > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/25/files > - new: https://git.openjdk.java.net/jfx/pull/25/files/44774dfb..24385eb8 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/25/webrev.04 > - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.03-04 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 141 lines in 2 files changed: 123 ins; 11 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 449: > 448: requestFocus(); > 449: // This fixes JDK-8087914 without causing JDK-8200224 > 450: // It is safe, because in JavaFX only the method "setFocused(true)" is called, We actually do not clutter source code with bugids, it will be good if it can be removed with proper comments maybe something like "extra simulated mouse pressed event is removed by making the JavaFX scene focused" PR: https://git.openjdk.java.net/jfx/pull/25 From aghaisas at openjdk.java.net Wed Nov 27 07:05:51 2019 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 27 Nov 2019 07:05:51 GMT Subject: [Integrated] RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation In-Reply-To: References: Message-ID: <369a1aca-7f0e-4efa-9d37-7f630d628690@openjdk.org> Changeset: 83eb0a7c Author: Ajit Ghaisas Date: 2019-11-27 07:05:15 +0000 URL: https://git.openjdk.java.net/jfx/commit/83eb0a7c 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation Reviewed-by: kcr, dgrieve ! modules/javafx.graphics/src/main/java/javafx/scene/Node.java + tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java From psadhukhan at openjdk.java.net Wed Nov 27 07:18:36 2019 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 27 Nov 2019 07:18:36 GMT Subject: [Approved] RFR: 8200224: Multiple press event when JFXPanel gains focus In-Reply-To: References: Message-ID: On Tue, 26 Nov 2019 13:06:36 GMT, Florian Kirmaier wrote: > The pull request has been updated with additional changes. > > ---------------- > > Added commits: > - 24385eb8: JDK-8200224 > - e0829ad3: JDK-8200224 > - c190384f: JDK-8200224 > - 17b458b1: JDK-8200224 > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/25/files > - new: https://git.openjdk.java.net/jfx/pull/25/files/44774dfb..24385eb8 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/25/webrev.04 > - incr: https://webrevs.openjdk.java.net/jfx/25/webrev.03-04 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8200224 > Stats: 141 lines in 2 files changed: 123 ins; 11 del; 7 mod > Patch: https://git.openjdk.java.net/jfx/pull/25.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/25/head:pull/25 Looks good albeit with minor suggestion regarding presence of bugid in comment ---------------- Approved by psadhukhan (Reviewer). PR: https://git