From tsayao at openjdk.java.net Wed Apr 1 00:47:06 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 00:47:06 GMT Subject: [Rev 34] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/3855e16f..b1222f85 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.34 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.33-34 Stats: 51 lines in 2 files changed: 13 ins; 18 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 01:09:07 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 01:09:07 GMT Subject: [Rev 35] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Better comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/b1222f85..381e8d14 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.35 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.34-35 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 01:18:44 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 01:18:44 GMT Subject: [Rev 36] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Fix Tab - JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/381e8d14..142073d1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.36 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.35-36 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 03:09:20 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 03:09:20 GMT Subject: [Rev 37] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Prefer content size over window size. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/142073d1..f367c9a3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.37 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.36-37 Stats: 24 lines in 1 file changed: 4 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Apr 1 03:23:40 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Apr 2020 03:23:40 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Tue, 24 Mar 2020 13:33:33 GMT, Thiago Milczarek Sayao wrote: >> I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 >> and Scenebuilder. >> Will have to do some tests on 16.04. > > Ubuntu 20.04 Test Results > > Updated 31 march 2020. > > ![image](https://user-images.githubusercontent.com/30704286/78094606-5459e200-73ab-11ea-8de9-e6c1c569c318.png) > > Note: ColorPickerTest worked on a "solo" run, Test on 16.04 (without Webkit - it does not build on 16.04 anymore) ![image](https://user-images.githubusercontent.com/30704286/78095942-b9fb9d80-73ae-11ea-9dfa-108daa3479e5.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From guru.hb at oracle.com Wed Apr 1 03:46:16 2020 From: guru.hb at oracle.com (Guru) Date: Wed, 1 Apr 2020 09:16:16 +0530 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: <13839C1E-C790-4AF6-8263-5F45D785B91D@oracle.com> Vote: YES > On 26-Mar-2020, at 5:14 PM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > Arun is a member of JavaFX team at Oracle, who has contributed 13 commits [2][3] to OpenJFX. > > Votes are due by April 9, 2020. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph > > [3] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From ajit.ghaisas at oracle.com Wed Apr 1 04:35:24 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 1 Apr 2020 10:05:24 +0530 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: Vote: YES Regards, Ajit > On 26-Mar-2020, at 5:14 PM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > Arun is a member of JavaFX team at Oracle, who has contributed 13 commits [2][3] to OpenJFX. > > Votes are due by April 9, 2020. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph > > [3] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From prasanta.sadhukhan at oracle.com Wed Apr 1 04:47:32 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 1 Apr 2020 10:17:32 +0530 Subject: CFV: New OpenJFX Committer: Arun Joseph In-Reply-To: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> References: <21560b0a-6504-3995-21ca-d1629c73044f@oracle.com> Message-ID: <8dc55f9b-f85a-afd3-74ab-7027a2c9e6c5@oracle.com> Vote: YES Regards Prasanta On 26-Mar-20 5:14 PM, Kevin Rushforth wrote: > I hereby nominate Arun Joseph [1] to OpenJFX Committer. > > Arun is a member of JavaFX team at Oracle, who has contributed 13 > commits [2][3] to OpenJFX. > > Votes are due by April 9, 2020. > > Only current OpenJFX Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/commits?author=arun-Joseph > > [3] > https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > From aghaisas at openjdk.java.net Wed Apr 1 10:55:13 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 1 Apr 2020 10:55:13 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) Message-ID: Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 Root Cause : Turned out to be a simpler issue than thought. Atomicity check was missed while updating toolbar state (which in turn updates styles). Fix : Added the missed atomicity check at two places that handle text selection using keyboard keys. Testing : Added two system test cases. They fail without this fix and pass with it. ------------- Commit messages: - Fix_8230809 Changes: https://git.openjdk.java.net/jfx/pull/155/files Webrev: https://webrevs.openjdk.java.net/jfx/155/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230809 Stats: 115 lines in 2 files changed: 112 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/155.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/155/head:pull/155 PR: https://git.openjdk.java.net/jfx/pull/155 From mp at jugs.org Wed Apr 1 11:31:11 2020 From: mp at jugs.org (Michael Paus) Date: Wed, 1 Apr 2020 13:31:11 +0200 Subject: Strange window snapshots Message-ID: <74cf165f-9121-95cc-f838-da968591814a@jugs.org> Hi, I am just debugging a JavaFX application which behaves strangely. Occasionally I am getting strange error messages like this: 2020-03-29 17:43:34.485 java[6134:499599] -[NSPersistentUIWindowSnapshotter writeWindowSnapshot:length:width:height:bytesPerRow:toFile:inDirectory:encryptingWithKey:uuid:checksum:fd:]: 0 == ftruncate(fd, finalFileSize) failed on line 797: No such file or directory 2020-03-29 17:43:34.486 java[6134:499599] -[NSPersistentUIWindowSnapshotter writeWindowSnapshot:length:width:height:bytesPerRow:toFile:inDirectory:encryptingWithKey:uuid:checksum:fd:]: 0 == ftruncate(fd, fileLength) failed on line 868: No such file or directory I am wondering now who or what is trying to do window snapshots of my machine? It seems I am only seeing this because of some error. Otherwise I would not have even noticed this. Can anybody here provide me with some insight? I am on macOS 10.14.6 OpenJDK 15-ea+14-561 OpenJFX 15-ea+2 Michael From kcr at openjdk.java.net Wed Apr 1 13:46:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Apr 2020 13:46:42 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: On Tue, 31 Mar 2020 05:33:35 GMT, Ambarish Rapte wrote: > This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). > When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was > implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. > > Call to jpeg_read_header() may fail when the partial image data has incomplete header information. > > In the given case the jpeg_read_header() call fails and code execution flow enters the 'if > (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls > imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) > crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test > passes with fix and causes a native crash without the fix. The fix looks good. I can also confirm that the test fails (crashes) without your fix and passes with your fix. The new LoadCorruptJPEGTest.java test doesn't use Robot, so it should be moved to a package not underneath `test.robot`. For consistency with similar tests in `javafx.graphics`, I recommend `test.com.sun.javafx.iio`. I left a few other comments on the test. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 64: > 63: Util.runAndWait(() -> { > 64: URL resource = this.getClass().getResource("corrupt.jpg"); > 65: FileInputStream input = null; Minor: It's generally preferred to use `LoadCorruptJPEGTest.class` rather than the `getClass()` method call. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 69: > 68: } catch (FileNotFoundException e) { > 69: e.printStackTrace(); > 70: } The `FileNotFoundException` should cause the test to fail. Rather than doing a try / catch, I recommend adding `throws Exception` to the test method. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 88: > 87: }); > 88: stage.setAlwaysOnTop(true); > 89: stage.show(); This call is not needed. tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 116: > 115: > 116: private static void waitForLatch(CountDownLatch latch, int seconds, String msg) { > 117: try { This method is unused and can be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From kcr at openjdk.java.net Wed Apr 1 13:46:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Apr 2020 13:46:42 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: <1b81pvO1zucSM1lTAzmsMIRLZkdz_wlu__X8xpFgD_c=.dde1f658-3a01-40f8-a97c-76ad32c0cc31@github.com> On Wed, 1 Apr 2020 13:43:39 GMT, Kevin Rushforth wrote: >> This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). >> When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was >> implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. >> >> Call to jpeg_read_header() may fail when the partial image data has incomplete header information. >> >> In the given case the jpeg_read_header() call fails and code execution flow enters the 'if >> (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls >> imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) >> crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test >> passes with fix and causes a native crash without the fix. > > The fix looks good. I can also confirm that the test fails (crashes) without your fix and passes with your fix. > > The new LoadCorruptJPEGTest.java test doesn't use Robot, so it should be moved to a package not underneath > `test.robot`. For consistency with similar tests in `javafx.graphics`, I recommend `test.com.sun.javafx.iio`. > I left a few other comments on the test. @johanvos This is a simple enough fix that I don't think it needs a second reviewer. Feel free to review it if you like. ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From kcr at openjdk.java.net Wed Apr 1 13:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Apr 2020 13:52:25 GMT Subject: RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: <0H21P45OAGNizY072nIoDLs_XCo_Egdr2cUiY2xIg2c=.5d938008-3298-49fc-910a-09ea2e34692c@github.com> On Wed, 1 Apr 2020 13:39:35 GMT, Kevin Rushforth wrote: >> This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). >> When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was >> implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. >> >> Call to jpeg_read_header() may fail when the partial image data has incomplete header information. >> >> In the given case the jpeg_read_header() call fails and code execution flow enters the 'if >> (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls >> imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) >> crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test >> passes with fix and causes a native crash without the fix. > > tests/system/src/test/java/test/robot/javafx/iio/LoadCorruptJPEGTest.java line 69: > >> 68: } catch (FileNotFoundException e) { >> 69: e.printStackTrace(); >> 70: } > > The `FileNotFoundException` should cause the test to fail. Rather than doing a try / catch, I recommend adding `throws > Exception` to the test method. Actually, I see that `Util.runAndWait` does not declare `throws Exception`, so you will need to keep the try/catch here. I recommend to fail the test with `Assert.fail` or `throw new AssertionFailedError(e)` ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From arapte at openjdk.java.net Wed Apr 1 19:45:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 1 Apr 2020 19:45:45 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: On Fri, 27 Mar 2020 11:46:30 GMT, Jeanette Winzenburg wrote: >> Several controls with selection/focusModels leave memory leaks on replacing the model. >> >> Added tests for all such, those for the misbehaving models fail before and pass after the fix. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > widened issue/fix/test for all controls with selection/focus models Change looks good to me. Similar to Skin classes the listeners here are also not explicitly removed. But I don't see any problematic scenario even if the listeners of an old Model are executed before it gets GCed. Suggested minor changes in test. modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 203: > 202: ObservableList data = FXCollections.observableArrayList("Apple", "Orange", "Banana"); > 203: data.forEach(text -> control.getTabs().add(new Tab("text"))); > 204: WeakReference> weakRef = new WeakReference<>(control.getSelectionModel()); `new Tab("text")` -> `new Tab(text)` modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 200: > 199: // has its own issue https://bugs.openjdk.java.net/browse/JDK-8241737 > 200: if (showBeforeReplaceSM) return; > 201: TabPane control = new TabPane(); @Ignore is used to ignore the test that are known to fail, It also becomes easy to track the ignored test with the @Ignore tag. I think it will be good to tag this scenario with a commented @Ignore inside the if statement `//@Ignore("JDK-8241737")` modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 228: > 227: // will be fixed as side-effect of skin cleanup in https://bugs.openjdk.java.net/browse/JDK-8087555 > 228: if (showBeforeReplaceSM) return; > 229: ChoiceBox control = new ChoiceBox<>(FXCollections.observableArrayList("Apple", "Orange", > "Banana")); @Ignore inside the if statement, `//@Ignore("JDK-8087555")` modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 285: > 284: } > 285: root.getChildren().add(node); > 286: if (!stage.isShowing()) { Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Apr 2 07:04:08 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 07:04:08 GMT Subject: [Rev 01] RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: References: Message-ID: <6pa3txKmKqDZg5F8-ZksTDOJzR9OT6CMgfD1aL0QK4k=.e636cc21-882f-4157-b919-b230219a32ff@github.com> > This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). > When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was > implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. > > Call to jpeg_read_header() may fail when the partial image data has incomplete header information. > > In the given case the jpeg_read_header() call fails and code execution flow enters the 'if > (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls > imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) > crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test > passes with fix and causes a native crash without the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Fixed reiew comments on test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/154/files - new: https://git.openjdk.java.net/jfx/pull/154/files/49cb0f36..a452cd62 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/154/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/154/webrev.00-01 Stats: 235 lines in 3 files changed: 110 ins; 125 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/154.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/154/head:pull/154 PR: https://git.openjdk.java.net/jfx/pull/154 From fastegal at openjdk.java.net Thu Apr 2 09:11:57 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Apr 2020 09:11:57 GMT Subject: [Rev 02] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: > Several controls with selection/focusModels leave memory leaks on replacing the model. > > Added tests for all such, those for the misbehaving models fail before and pass after the fix. > > for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: cleanup test as suggested in review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/148/files - new: https://git.openjdk.java.net/jfx/pull/148/files/d2918fb5..8bed244f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/148/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/148/webrev.01-02 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/148/head:pull/148 PR: https://git.openjdk.java.net/jfx/pull/148 From fastegal at openjdk.java.net Thu Apr 2 09:15:06 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Apr 2020 09:15:06 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: <006TLeKlbw4j6laP69DA94vGAHXsKHdEIfyTJBX8xO0=.a1dd2fd5-9429-4110-80a1-bd6b9276cbbc@github.com> On Wed, 1 Apr 2020 19:34:09 GMT, Ambarish Rapte wrote: > > Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? hmm .. don't think that it's necessary to clear out other children: the thing that actually matters is that the control goes active in the scenegraph and has a skin attached. Can you think of any context where any of the tests might get whacky if there are more than one nodes in the root? Actually, that's a pattern (*cough, read that's more or less c&p'ed) I use in other tests, where it sometimes is allowed and expected that there are more than one. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Apr 2 11:31:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 11:31:52 GMT Subject: [Rev 01] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: <006TLeKlbw4j6laP69DA94vGAHXsKHdEIfyTJBX8xO0=.a1dd2fd5-9429-4110-80a1-bd6b9276cbbc@github.com> References: <006TLeKlbw4j6laP69DA94vGAHXsKHdEIfyTJBX8xO0=.a1dd2fd5-9429-4110-80a1-bd6b9276cbbc@github.com> Message-ID: On Thu, 2 Apr 2020 09:12:55 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 285: >> >>> 284: } >>> 285: root.getChildren().add(node); >>> 286: if (!stage.isShowing()) { >> >> Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? > >> >> Will it be good to add a call to `root.getChildren().removeAll()` before adding the `node` to `root` ? > > hmm .. don't think that it's necessary to clear out other children: the thing that actually matters is that the control > goes active in the scenegraph and has a skin attached. Can you think of any context where any of the tests might get > whacky if there are more than one nodes in the root? Actually, that's a pattern (*cough, read that's more or less > c&p'ed) I use in other tests, where it sometimes is allowed and expected that there are more than one. Agree that It would not cause any problem in test execution. ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From arapte at openjdk.java.net Thu Apr 2 11:31:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 11:31:52 GMT Subject: [Rev 02] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 09:11:57 GMT, Jeanette Winzenburg wrote: >> Several controls with selection/focusModels leave memory leaks on replacing the model. >> >> Added tests for all such, those for the misbehaving models fail before and pass after the fix. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > cleanup test as suggested in review looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/148 From kcr at openjdk.java.net Thu Apr 2 12:24:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 12:24:53 GMT Subject: [Rev 01] RFR: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034 In-Reply-To: <6pa3txKmKqDZg5F8-ZksTDOJzR9OT6CMgfD1aL0QK4k=.e636cc21-882f-4157-b919-b230219a32ff@github.com> References: <6pa3txKmKqDZg5F8-ZksTDOJzR9OT6CMgfD1aL0QK4k=.e636cc21-882f-4157-b919-b230219a32ff@github.com> Message-ID: On Thu, 2 Apr 2020 07:04:08 GMT, Ambarish Rapte wrote: >> This is a regression of [JDK-8212034](https://bugs.openjdk.java.net/browse/JDK-8212034). >> When image is loaded in WebView usinga url, WebView attempts to load a image frames with partial image data. This was >> implemented under, JDK-8153148 -> WCImageDecoderImpl.addImageData() -> calls loadFrames() with partial image data. >> >> Call to jpeg_read_header() may fail when the partial image data has incomplete header information. >> >> In the given case the jpeg_read_header() call fails and code execution flow enters the 'if >> (setjmp(jerr->setjmp_buffer)) {}' block and results in call to disposeIIO(env, data);, which in turn calls >> imageio_dispose. This will free cinfo->err and set it to NULL, and the subsequent call to (*cinfo->err->format_message) >> crashes. Verified All test run, Sanity tests with Ensemble app and Tested different web pages. Added a test, The test >> passes with fix and causes a native crash without the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fixed reiew comments on test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/154 From nlisker at openjdk.java.net Thu Apr 2 13:01:25 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 2 Apr 2020 13:01:25 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Fri, 3 Jan 2020 09:26:43 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Attenuation and range changed internally to floats from doubles > > I have added few comments, but have not run tests and sample yet. @arapte Can you please test the performance changes too? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Thu Apr 2 12:58:11 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 12:58:11 GMT Subject: [Rev 03] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: > ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when > the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves > the issue. > Please take a look. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Fixed review comment: cleanup the accelerator ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/147/files - new: https://git.openjdk.java.net/jfx/pull/147/files/e81f175a..bf974f6a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/147/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/147/webrev.02-03 Stats: 54 lines in 2 files changed: 46 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/147.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/147/head:pull/147 PR: https://git.openjdk.java.net/jfx/pull/147 From arapte at openjdk.java.net Thu Apr 2 13:21:43 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Apr 2020 13:21:43 GMT Subject: [Rev 01] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: <7LDkD9pey1uNcKAj6ajx-TbzKdhP6zzrfZUfy_5hwFM=.e7fb5c79-d981-45e1-b440-293057c38259@github.com> Message-ID: On Mon, 30 Mar 2020 10:36:13 GMT, Jeanette Winzenburg wrote: >> Thanks for the test case, I did minor changes to it and included in the next commit. >> The NPE can occur even without `button.setDefaultButton(true);`. >> Please take a look > > good catch! You are right, without explicit removal of the listener, the NPE happens always. > > Actually, I had been sloppy and got distracted by the NPE from my actual goal which was to dig into Kevin's "not > cleaning up after itself" and .. finally found a (concededly extreme corner-case :) where that's happening: when > setting the skin to null. Two failing tests: > @Test > public void testDefaultButtonNullSkinReleased() { > Button button = new Button(); > button.setDefaultButton(true); > Group root = new Group(button); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > WeakReference defSkinRef = new WeakReference<>((ButtonSkin)button.getSkin()); > button.setSkin(null); > > attemptGC(defSkinRef); > assertNull("skin must be gc'ed", defSkinRef.get()); > } > > @Test > public void testDefaultButtonNullSkinAcceleratorRemoved() { > Button button = new Button(); > button.setDefaultButton(true); > Group root = new Group(button); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > KeyCodeCombination key = new KeyCodeCombination(KeyCode.ENTER); > > assertNotNull(scene.getAccelerators().get(key)); > button.setSkin(null); > assertNull(scene.getAccelerators().get(key)); > > } > > An explicitly cleanup in dispose makes them pass: > > @Override > public void dispose() { > setDefaultButton(false); > setCancelButton(false); > getSkinnable().sceneProperty().removeListener(weakChangeListener); I have included this change and the test, with slight modification to include same test for Cancel button. ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From fastegal at openjdk.java.net Thu Apr 2 13:42:45 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Apr 2020 13:42:45 GMT Subject: [Rev 03] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 12:58:11 GMT, Ambarish Rapte wrote: >> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when >> the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves >> the issue. >> Please take a look. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comment: cleanup the accelerator looks good :) ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/147 From Rony.Flatscher at wu.ac.at Thu Apr 2 16:47:54 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 2 Apr 2020 18:47:54 +0200 Subject: Seeking help with latest master ... In-Reply-To: References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> Message-ID: <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> Being stuck (tried the previous working gradle 5.6.4, could get "gradle clean", but not further) in the end I just tried Java 14 and that allowed me to run "gradle" successfully (currently building webkit to get going again). Just wanted to let interested readers know. (Would be great though, if it worked with the 11 LTS version as well.) ---rony On 31.03.2020 20:36, Rony G. Flatscher wrote: > On 31.03.2020 20:21, Scott Palmer wrote: >>> Could not resolve all dependencies for configuration ':apps:lucene'. >> ????? > Multiple build operations failed. >> ??????????? java.lang.ExceptionInInitializerError >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> ???????? > java.lang.ExceptionInInitializerError >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class >> ???sun.security.ssl.SSLContextImpl$TLSContext >> >> >> This to me looks like it may be failing to make an https connection to a repository when >> attempting to download?dependencies. >> >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running gradle builds, see:? >> https://github.com/gradle/gradle/issues/7842 >> >> Claims to be fixed, but maybe not? >> >> If it is related to Gradle?changing java.home while compiling, I wonder if using?--no-parallel >> might work around it? ?Of course try with --debug as well to see if it offers more clues. > Scott, thank you! > > Not having any knowledge about gradle I am unfortunately lost in this case. However, I used? "gradle > --no-parallel --debug" which did not succeed but created a 1.2 MB text file which I keep temporarily > in my DrobBox at: . > > Will have to leave in a few minutes for today so can only try other things tomorrow. > > ---rony From github.com+636962+ccavanaugh at openjdk.java.net Thu Apr 2 17:10:05 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Thu, 2 Apr 2020 17:10:05 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set Message-ID: This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. Also, I believe JDK-8196037 is a duplicate of this issue. I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. Thanks! ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jfx - Merge branch 'master' of https://github.com/openjdk/jfx - Fix for JDK-8129123 Changes: https://git.openjdk.java.net/jfx/pull/136/files Webrev: https://webrevs.openjdk.java.net/jfx/136/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8129123 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/136/head:pull/136 PR: https://git.openjdk.java.net/jfx/pull/136 From Rony.Flatscher at wu.ac.at Thu Apr 2 17:41:16 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 2 Apr 2020 19:41:16 +0200 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> Message-ID: <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> After merging master, applying some fixes and changing the title to reflect the change from WIP to a pull request I would kindly request a review of this pull request! Here the URL: , title changed to: "8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts". ---rony On 28.02.2020 19:22, Rony G. Flatscher wrote: > Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and > has an appropriate test unit going with it as well, please review. > > There should be no compatibility issue with this implementation. > > Discussion: another solution could be to not compile by default. Rather compile, if some new > information is present with the FXML file which cannot possibly be present in existing FXML files. > In this scenario one possible and probably simple solution would be to only compile scripts if the > language process instruction (e.g. ) contains an appropriate attribute with a value > indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with > PIs having this attribute set to true would be affected. If desired I could try to come up with a > respective solution as well. > > ---rony > > [1] "Implementation and test unit": > > [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile scripts": > > > [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": > > > > On 24.01.2020 16:26, Kevin Rushforth wrote: > >> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >> the concept). >> >> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >> issues, but it would be good to hear from application developers who heavily use FXML. >> >> -- Kevin >> >> >> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>> Just filed a RFE with the following information: >>> >>> ?? * Component: >>> ?????? o JavaFX >>> >>> ?? * Subcomponent: >>> ?????? o fxml: JavaFX FXML >>> >>> ?? * Synopsis: >>> ?????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>> >>> ?? * Descriptions: >>> ?????? o "FXMLLoader is able to execute scripts in Java script languages (javax.script.ScriptEngine >>> ???????? implementations) if such a Java script language gets defined as the controller language in >>> ???????? the FXML file. >>> >>> ???????? If a script engine implements the javax.script.Compilable interface, then such scripts >>> could >>> ???????? be compiled and the resulting javax.script.CompiledScript could be executed instead using >>> ???????? its eval() methods. >>> >>> ???????? Evaluating the CompiledScript objects may help speed up the execution of script >>> invocations, >>> ???????? especially for scripts defined for event attributes in FXML elements (e.g. like >>> onMouseMove) >>> ???????? which may be repetitevly invoked and evaluated." >>> >>> ?? * System /OS/Java Runtime Information: >>> ?????? o "All systems." >>> >>> Received the internal review ID: "9063426" >>> >>> ---rony From johan.vos at gluonhq.com Thu Apr 2 19:20:44 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 2 Apr 2020 21:20:44 +0200 Subject: Seeking help with latest master ... In-Reply-To: <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> Message-ID: I have no scientific evidence for this, but I remember issues related to SSL with some JDK's as well, which may or may not be related to the cacerts file that is bundled. - Johan On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher wrote: > Being stuck (tried the previous working gradle 5.6.4, could get "gradle > clean", but not further) in > the end I just tried Java 14 and that allowed me to run "gradle" > successfully (currently building > webkit to get going again). Just wanted to let interested readers know. > (Would be great though, if > it worked with the 11 LTS version as well.) > > ---rony > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > On 31.03.2020 20:21, Scott Palmer wrote: > >>> Could not resolve all dependencies for configuration ':apps:lucene'. > >> > Multiple build operations failed. > >> java.lang.ExceptionInInitializerError > >> java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> > java.lang.ExceptionInInitializerError > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> sun.security.ssl.SSLContextImpl$TLSContext > >> > >> > >> This to me looks like it may be failing to make an https connection to > a repository when > >> attempting to download dependencies. > >> > >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when > running gradle builds, see: > >> https://github.com/gradle/gradle/issues/7842 > >> > >> Claims to be fixed, but maybe not? > >> > >> If it is related to Gradle changing java.home while compiling, I wonder > if using --no-parallel > >> might work around it? Of course try with --debug as well to see if it > offers more clues. > > Scott, thank you! > > > > Not having any knowledge about gradle I am unfortunately lost in this > case. However, I used "gradle > > --no-parallel --debug" which did not succeed but created a 1.2 MB text > file which I keep temporarily > > in my DrobBox at: < > https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 > >. > > > > Will have to leave in a few minutes for today so can only try other > things tomorrow. > > > > ---rony > > From tsayao at openjdk.java.net Thu Apr 2 20:11:54 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 2 Apr 2020 20:11:54 GMT Subject: [Rev 38] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes for ubuntu 16.04 (which delays frame extents) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f367c9a3..547c3cb0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.38 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.37-38 Stats: 28 lines in 2 files changed: 16 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Thu Apr 2 21:07:12 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 2 Apr 2020 21:07:12 GMT Subject: [Rev 39] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Just comment fixing ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/547c3cb0..e499a54d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.39 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.38-39 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Thu Apr 2 21:14:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 2 Apr 2020 21:14:02 GMT Subject: [Rev 40] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/e499a54d..031d2287 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.40 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.39-40 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Thu Apr 2 22:09:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:09:09 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events Message-ID: As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer guide: [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. ------------- Commit messages: - Revert "TEMPORARY: add debugging print statements (will be reverted before final review)" - TEMPORARY: add debugging print statements (will be reverted before final review) - 8236971: [macos] Gestures handled incorrectly due to missing events Changes: https://git.openjdk.java.net/jfx/pull/156/files Webrev: https://webrevs.openjdk.java.net/jfx/156/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236971 Stats: 117 lines in 4 files changed: 85 ins; 20 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/156/head:pull/156 PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Thu Apr 2 22:09:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:09:09 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. @arapte Can you be one of the reviewers? @mipastgt I ran it against your test application, but if you have other tests you could run, that would be helpful. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Thu Apr 2 22:23:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:23:10 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> On Wed, 4 Mar 2020 22:43:45 GMT, Craig Cavanaugh wrote: > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Can you please provide a unit test? One that fails before your fix and passes after your fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From kcr at openjdk.java.net Thu Apr 2 22:23:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 22:23:10 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Thu, 2 Apr 2020 22:20:18 GMT, Kevin Rushforth wrote: >> This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. >> Also, I believe JDK-8196037 is a duplicate of this issue. >> >> I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. >> >> Thanks! > > Can you please provide a unit test? One that fails before your fix and passes after your fix. @aghaisas can you be one of the reviewers? ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From github.com+60214806+ronyfla at openjdk.java.net Thu Apr 2 23:14:03 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Thu, 2 Apr 2020 23:14:03 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts Message-ID: TODO: ADD DESCRIPTION OF PROPOSED FIX HERE. ------------- Commit messages: - Correct error constant. - appease the jcheck script, such that that important trailing Whitespace error can be resolved (why would jcheck not do it automagically as well as expanding tabs?) - Merge master, correct ovesights. - Merge master - JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile scripts - corrected wrong test string - Removed executable bit from gradlew as this causes an error when - Merge branch 'scripttest' into script as requested by reviewer Kevin - Incorporating Kevin Rushfort's review comments to this WIP. - Incorporating Kevin Rushfort's review comments to this WIP. - Removed/replaced white space. - Removed/replaced white space. - test for JDK-8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV - fix for JDK-8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV Changes: https://git.openjdk.java.net/jfx/pull/129/files Webrev: https://webrevs.openjdk.java.net/jfx/129/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238080 Stats: 1003 lines in 17 files changed: 996 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/129.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/129/head:pull/129 PR: https://git.openjdk.java.net/jfx/pull/129 From kcr at openjdk.java.net Thu Apr 2 23:15:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Apr 2020 23:15:26 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts In-Reply-To: References: Message-ID: On Fri, 28 Feb 2020 17:46:58 GMT, Rony G. Flatscher wrote: > TODO: ADD DESCRIPTION OF PROPOSED FIX HERE. We will need to finish the discussion on this proposed new feature on the openjfx-dev mailing list. The PR can be used to illustrate what you want to do, but use [this email thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025623.html), rather than as a reply to the PR, for the discussion. Once we have agreement, then the next step will be to review the proposed spec change and implementation in this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/129 From kevin.rushforth at oracle.com Thu Apr 2 23:21:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Apr 2020 16:21:49 -0700 (PDT) Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> Message-ID: <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Hi Rony, I see that you updated the PR and sent it for review. Before we formally review it in the PR, let's finish the discussion as to whether this is a useful feature, and if so, what form this feature should take. From my point of view, this does seem like a useful feature. Would other users of FXML benefit from it? I'm not certain whether we want it to be implicit, compiling the script if the script engine in question implements Compilable, or via a new keyword or tag. What are the pros / cons? What do others think? In either case, we would need to make sure that this doesn't present any security concerns in the presence of a security manager. As long as a user-provided class is on the stack, it will be fine, but we would need to ensure that. -- Kevin On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: > After merging master, applying some fixes and changing the title to reflect the change from WIP to a > pull request I would kindly request a review of this pull request! > > Here the URL: , title changed to: "8238080: FXMLLoader: if > script engines implement javax.script.Compilable compile scripts". > > ---rony > > > On 28.02.2020 19:22, Rony G. Flatscher wrote: >> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >> has an appropriate test unit going with it as well, please review. >> >> There should be no compatibility issue with this implementation. >> >> Discussion: another solution could be to not compile by default. Rather compile, if some new >> information is present with the FXML file which cannot possibly be present in existing FXML files. >> In this scenario one possible and probably simple solution would be to only compile scripts if the >> language process instruction (e.g. ) contains an appropriate attribute with a value >> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >> PIs having this attribute set to true would be affected. If desired I could try to come up with a >> respective solution as well. >> >> ---rony >> >> [1] "Implementation and test unit": >> >> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile scripts": >> >> >> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >> >> >> >> On 24.01.2020 16:26, Kevin Rushforth wrote: >> >>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>> the concept). >>> >>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>> issues, but it would be good to hear from application developers who heavily use FXML. >>> >>> -- Kevin >>> >>> >>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>> Just filed a RFE with the following information: >>>> >>>> ?? * Component: >>>> ?????? o JavaFX >>>> >>>> ?? * Subcomponent: >>>> ?????? o fxml: JavaFX FXML >>>> >>>> ?? * Synopsis: >>>> ?????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>> >>>> ?? * Descriptions: >>>> ?????? o "FXMLLoader is able to execute scripts in Java script languages (javax.script.ScriptEngine >>>> ???????? implementations) if such a Java script language gets defined as the controller language in >>>> ???????? the FXML file. >>>> >>>> ???????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>> could >>>> ???????? be compiled and the resulting javax.script.CompiledScript could be executed instead using >>>> ???????? its eval() methods. >>>> >>>> ???????? Evaluating the CompiledScript objects may help speed up the execution of script >>>> invocations, >>>> ???????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>> onMouseMove) >>>> ???????? which may be repetitevly invoked and evaluated." >>>> >>>> ?? * System /OS/Java Runtime Information: >>>> ?????? o "All systems." >>>> >>>> Received the internal review ID: "9063426" >>>> >>>> ---rony From github.com+636962+ccavanaugh at openjdk.java.net Thu Apr 2 23:30:26 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Thu, 2 Apr 2020 23:30:26 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Thu, 2 Apr 2020 22:20:18 GMT, Kevin Rushforth wrote: > Can you please provide a unit test? One that fails before your fix and passes after your fix. I can provide a manual test the next couple of days that demonstrates it before and after, but I'm not sure how to create an automated unit test because the issue is visual. ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From tsayao at openjdk.java.net Fri Apr 3 00:48:19 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 00:48:19 GMT Subject: [Rev 41] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix unfullscreen bug on older gtk+ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/031d2287..11688aee Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.41 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.40-41 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Apr 3 01:59:08 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 01:59:08 GMT Subject: [Rev 42] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/11688aee..f52f63be Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.42 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.41-42 Stats: 45 lines in 2 files changed: 27 ins; 15 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Apr 3 02:13:32 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 02:13:32 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Wed, 1 Apr 2020 03:21:31 GMT, Thiago Milczarek Sayao wrote: >> Ubuntu 20.04 Test Results >> >> Updated April 2nd. >> >> ![image](https://user-images.githubusercontent.com/30704286/78299385-28a23d80-750c-11ea-9edd-ac264f16c194.png) > > Test on 16.04 (without Webkit - it does not build on 16.04 anymore) > > Updated April 2nd. > > ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) > > Note: DatePickerTest works when run alone. I will keep testing it, but I think it's looking good. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From aghaisas at openjdk.java.net Fri Apr 3 09:46:31 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 3 Apr 2020 09:46:31 GMT Subject: [Rev 02] RFR: 8241455: Memory leak on replacing selection/focusModel In-Reply-To: References: Message-ID: <5rsifjfKxF8dd5GIcuTeHQiQMJDd9PikCg7bn8t9HtY=.1068d56f-3475-4d29-ab13-07303924694a@github.com> On Thu, 2 Apr 2020 09:11:57 GMT, Jeanette Winzenburg wrote: >> Several controls with selection/focusModels leave memory leaks on replacing the model. >> >> Added tests for all such, those for the misbehaving models fail before and pass after the fix. >> >> for convenience, the bug reference https://bugs.openjdk.java.net/browse/JDK-8241455 > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > cleanup test as suggested in review Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/148 From craig.cavanaugh at gmail.com Fri Apr 3 10:26:39 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Fri, 3 Apr 2020 06:26:39 -0400 Subject: Stuck attempting to run/develop a manual unit test Message-ID: I am trying to create a manual unit test for RFR: 8129123 and I'm using the existing ButtonMnemonicPositionTest.java as a template to make sure everything is working correctly. I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 openjdk. openjfx is successfully compiling and passing tests following the wiki instructions I'm able to compile ButtonMnemonicPositionTest successfully as shown below. javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* ButtonMnemonicPositionTest.java But attempts to run are failing despite a successful compile: java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* ButtonMnemonicPositionTest Error: JavaFX runtime components are missing, and are required to run this application I've also tried running using the modular-sdk after a Gradle build and no luck either after finding a recommendation on the list that the module approach should be used for testing. java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules --add-modules=javafx.controls ButtonMnemonicPositionTest Error occurred during initialization of boot layer java.lang.module.FindException: Module javafx.controls not found I've been search through the list archive and haven't found a solution. I'm sure I'm doing something wrong. Some help please! Regards, Craig From ajit.ghaisas at oracle.com Fri Apr 3 10:52:01 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 3 Apr 2020 16:22:01 +0530 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: References: Message-ID: Hi Craig, Here is how I run the ButtonMnemonicPositionTest. $ export FX_LIB=/Users/AG/aaa/jfx/build/sdk/lib $ cd /Users/AG/aaa/jfx/tests/manual/UI $ javac --module-path $FX_LIB --add-modules javafx.controls ButtonMnemonicPositionTest.java $ java --module-path $FX_LIB --add-modules javafx.controls ButtonMnemonicPositionTest Hope this helps. We can discuss further on your PR. Regards, Ajit > On 03-Apr-2020, at 3:56 PM, Craig Cavanaugh wrote: > > I am trying to create a manual unit test for RFR: 8129123 and I'm using the > existing ButtonMnemonicPositionTest.java as a template to make sure > everything is working correctly. > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > openjdk. > openjfx is successfully compiling and passing tests following the wiki > instructions > > I'm able to compile ButtonMnemonicPositionTest successfully as shown below. > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest.java > > But attempts to run are failing despite a successful compile: > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest > Error: JavaFX runtime components are missing, and are required to run this > application > > I've also tried running using the modular-sdk after a Gradle build and no > luck either after finding a recommendation on the list that the module > approach should be used for testing. > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > --add-modules=javafx.controls ButtonMnemonicPositionTest > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.controls not found > > I've been search through the list archive and haven't found a solution. > I'm sure I'm doing something wrong. > > Some help please! > > Regards, > Craig From github.com+7517141+yososs at openjdk.java.net Fri Apr 3 10:55:39 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 3 Apr 2020 10:55:39 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow Message-ID: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> https://bugs.openjdk.java.net/browse/JDK-8197991 The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. This greatly improves the response when selecting multiple items in ListView and TableView. However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) ListView * selectAll: 400_000-> 10_000_000 * selectRange: 7_000-> 70_000 TableView * selectAll: 8_000-> 700_000 * selectRange: 7_000-> 50_000 You can see performance improvements in the following applications: SelectListViewTest.java import javafx.application.Application; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ListView; import javafx.scene.control.SelectionMode; import javafx.scene.layout.BorderPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class SelectListViewTest extends Application { final int ROW_COUNT = 70_000; // final int ROW_COUNT = 400_000; // final int ROW_COUNT = 10_000_000; // final int ROW_COUNT = 7_000; @Override public void start(Stage stage) { ListView listView = new ListView<>(); listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); ObservableList items = listView.getItems(); for(int i=0; iselectAll(listView)); clearSelection.setOnAction((e)->clearSelection(listView)); selectToStart.setOnAction((e)->selectToStart(listView)); selectToEnd.setOnAction((e)->selectToLast(listView)); selectPrevious.setOnAction((e)->selectPrevious(listView)); selectNext.setOnAction((e)->selectNext(listView)); stage.show(); } private void selectAll(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectAll(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void clearSelection(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().clearSelection(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToStart(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToLast(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectPrevious(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectPrevious(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectNext(ListView listView) { long t = System.currentTimeMillis(); listView.getSelectionModel().selectNext(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } public static void main(String[] args) { Application.launch(args); } } SelectTableViewTest.java import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.SelectionMode; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.layout.BorderPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class SelectTableViewTest extends Application { final int ROW_COUNT = 700_000; // final int ROW_COUNT = 80_000; // final int ROW_COUNT = 50_000; // final int ROW_COUNT = 8_000; final int COL_COUNT = 3; @Override public void start(Stage stage) { TableView tableView = new TableView<>(); tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); final ObservableList> columns = tableView.getColumns(); for(int i=0; i column = new TableColumn<>("Col"+i); final int colIndex=i; column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); column.setPrefWidth(150); columns.add(column); } ObservableList items = tableView.getItems(); for(int i=0; iselectAll(tableView)); clearSelection.setOnAction((e)->clearSelection(tableView)); selectToStart.setOnAction((e)->selectToStart(tableView)); selectToEnd.setOnAction((e)->selectToLast(tableView)); selectPrevious.setOnAction((e)->selectPrevious(tableView)); selectNext.setOnAction((e)->selectNext(tableView)); stage.show(); } private void selectAll(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectAll(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void clearSelection(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().clearSelection(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToStart(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectToLast(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectPrevious(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectPrevious(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } private void selectNext(TableView tableView) { long t = System.currentTimeMillis(); tableView.getSelectionModel().selectNext(); System.out.println("time:"+ (System.currentTimeMillis() - t)); } public static void main(String[] args) { Application.launch(args); } } ------------- Commit messages: - 8197991: Fix multi-select performance issues Changes: https://git.openjdk.java.net/jfx/pull/127/files Webrev: https://webrevs.openjdk.java.net/jfx/127/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 54 lines in 2 files changed: 49 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/127/head:pull/127 PR: https://git.openjdk.java.net/jfx/pull/127 From robilad at openjdk.java.net Fri Apr 3 10:55:39 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Fri, 3 Apr 2020 10:55:39 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of > TreeUtil.getTreeItem (). > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), > tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } Hi, I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From github.com+7517141+yososs at openjdk.java.net Fri Apr 3 10:58:01 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 3 Apr 2020 10:58:01 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView Message-ID: If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column virtualization. Virtualization mode is enabled when the row height is fixed by the following method. `tableView.setFixedCellSize(height)` This proposal includes a fix because the current code does not correctly implement column virtualization. The improvement of this proposal can be seen in the following test program. Java import javafx.animation.AnimationTimer; import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class BigTableViewTest2 extends Application { private static final boolean USE_WIDTH_FIXED_SIZE = true; private static final boolean USE_HEIGHT_FIXED_SIZE = true; // private static final int COL_COUNT=300; private static final int COL_COUNT=600; // private static final int COL_COUNT=1000; private static final int ROW_COUNT=1000; @Override public void start(Stage primaryStage) throws Exception { final TableView tableView = new TableView<>(); final ObservableList> columns = tableView.getColumns(); for(int i=0; i column = new TableColumn<>("Col"+i); final int colIndex=i; column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); columns.add(column); if(USE_WIDTH_FIXED_SIZE) { column.setPrefWidth(60); column.setMaxWidth(60); column.setMinWidth(60); } } ObservableList items = tableView.getItems(); for(int i=0; i References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > > private static final boolean USE_WIDTH_FIXED_SIZE = true; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=300; > private static final int COL_COUNT=600; > // private static final int COL_COUNT=1000; > private static final int ROW_COUNT=1000; > > @Override > public void start(Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if(USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > if(USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > prepareTimeline(scene); > > } > > public static void main(String[] args) { > Application.launch(args); > } > > private void prepareTimeline(Scene scene) { > new AnimationTimer() { > @Override public void handle(long now) { > double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); > } > }.start(); > } > > } I'm signed to OCA and already a contributor. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From nlisker at openjdk.java.net Fri Apr 3 10:58:02 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 3 Apr 2020 10:58:02 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> On Thu, 27 Feb 2020 21:29:27 GMT, Martin Polakovic wrote: >> If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column >> virtualization. Virtualization mode is enabled when the row height is fixed by the following method. >> `tableView.setFixedCellSize(height)` >> >> This proposal includes a fix because the current code does not correctly implement column virtualization. >> >> The improvement of this proposal can be seen in the following test program. >> >> Java >> import javafx.animation.AnimationTimer; >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class BigTableViewTest2 extends Application { >> >> private static final boolean USE_WIDTH_FIXED_SIZE = true; >> private static final boolean USE_HEIGHT_FIXED_SIZE = true; >> // private static final int COL_COUNT=300; >> private static final int COL_COUNT=600; >> // private static final int COL_COUNT=1000; >> private static final int ROW_COUNT=1000; >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> final TableView tableView = new TableView<>(); >> >> final ObservableList> columns = tableView.getColumns(); >> for(int i=0; i> TableColumn column = new TableColumn<>("Col"+i); >> final int colIndex=i; >> column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); >> columns.add(column); >> if(USE_WIDTH_FIXED_SIZE) { >> column.setPrefWidth(60); >> column.setMaxWidth(60); >> column.setMinWidth(60); >> } >> } >> >> ObservableList items = tableView.getItems(); >> for(int i=0; i> String[] rec = new String[COL_COUNT]; >> for(int j=0; j> rec[j] = i+":"+j; >> } >> items.add(rec); >> } >> BorderPane root = new BorderPane(tableView); >> if(USE_HEIGHT_FIXED_SIZE) { >> tableView.setFixedCellSize(24); >> } >> >> Scene scene = new Scene(root, 800, 800); >> primaryStage.setScene(scene); >> primaryStage.show(); >> prepareTimeline(scene); >> >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> >> private void prepareTimeline(Scene scene) { >> new AnimationTimer() { >> @Override public void handle(long now) { >> double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); >> ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); >> } >> }.start(); >> } >> >> } > > I took the liberty of pointing out some formatting errors The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many JBS issues around this performance issue, probably one of them fits (or a new one can be created). ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From robilad at openjdk.java.net Fri Apr 3 10:58:03 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Fri, 3 Apr 2020 10:58:03 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Mon, 9 Mar 2020 17:00:06 GMT, Nir Lisker wrote: >> I took the liberty of pointing out some formatting errors > > The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a > different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't > advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many > JBS issues around this performance issue, probably one of them fits (or a new one can be created). Hi, I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+7517141+yososs at openjdk.java.net Fri Apr 3 10:58:03 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 3 Apr 2020 10:58:03 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Thu, 2 Apr 2020 17:38:00 GMT, Dalibor Topic wrote: >> The title of your PR should match the title of the JBS issue. Moreover, #108 already tackles this issue with a >> different approach and 2 PRs on the same issue can't be intetgrated. Since I'm not familiar with this code, I can't >> advise on who's solution is more suitable. I suggest you discuss both of the approaches on the mailing list. I saw many >> JBS issues around this performance issue, probably one of them fits (or a new one can be created). > > Hi, > I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail > at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. My name is "Naohiro Yoshimoto" I have received an approved email on 2019-8-3. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From github.com+5527071+sghpjuikit at openjdk.java.net Fri Apr 3 10:58:02 2020 From: github.com+5527071+sghpjuikit at openjdk.java.net (Martin Polakovic) Date: Fri, 3 Apr 2020 10:58:02 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: On Mon, 24 Feb 2020 07:39:43 GMT, yosbits wrote: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > > private static final boolean USE_WIDTH_FIXED_SIZE = true; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=300; > private static final int COL_COUNT=600; > // private static final int COL_COUNT=1000; > private static final int ROW_COUNT=1000; > > @Override > public void start(Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if(USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > if(USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > prepareTimeline(scene); > > } > > public static void main(String[] args) { > Application.launch(args); > } > > private void prepareTimeline(Scene scene) { > new AnimationTimer() { > @Override public void handle(long now) { > double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); > } > }.start(); > } > > } I took the liberty of pointing out some formatting errors modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 492: > 491: tableCell.requestLayout(); > 492: }else if(fixedCellSizeEnabled && lastVisibleColumnIndex 493: break; `}else` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 387: > 386: } > 387: }else{ > 388: // we only add/remove to the scenegraph if the fixed cell `}else` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 373: > 372: lastVisibleColumnIndex = column; > 373: }else if( firstVisibleColumnIndex != -1 ) { > 374: break; `}else` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 347: > 346: final Insets padding = getSkinnable().getPadding(); > 347: final double vfWidth = virtualFlow == null ? 0.0:virtualFlow.getWidth(); > 348: final double headerWidth = vfWidth - (padding.getLeft() + padding.getRight()); `0.0:` formatting modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 414: > 413: width = snapSizeX(tableColumn.getWidth()); > 414: if (isVisible || isOverlap(tableCell.getLayoutX(), tableCell.getLayoutX()+width, scrollX, headerWidth > + scrollX)) { 415: // if the style origin is null then the property has not been `)+w` formatting ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From mpaus at openjdk.java.net Fri Apr 3 11:34:21 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Fri, 3 Apr 2020 11:34:21 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 22:04:55 GMT, Kevin Rushforth wrote: >> As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case >> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, >> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile >> time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer >> guide: >> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) >> Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification >> works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to >> link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK >> or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information >> from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the >> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new >> local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, >> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and >> the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the >> problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have >> since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. > > @arapte Can you be one of the reviewers? > > @mipastgt I ran it against your test application, but if you have other tests you could run, that would be helpful. I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but not for the following generated inertia events. They are still equal to the delta values. Is that according to the specification? From a practical point of view a programmer who relies on the total delta values is probably much surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel generated scroll-events is still not 0 but this has probably another root cause. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From fastegal at swingempire.de Fri Apr 3 11:47:47 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 03 Apr 2020 13:47:47 +0200 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: References: Message-ID: <20200403134747.Horde.uzvz028f4rZMXjJvWfnCEQ1@webmail.df.eu> Hi Craig, no manual test needed - you can implement a normal (unit) test with the help or VirtualFlowTestUtils: grab the flow, get its first/last visible cell and check whether their range includes to cell we want to see, something like: @Test public void testScrollInSkin() { int index = 50; comboBox.getSelectionModel().select(index); comboBox.show(); VirtualFlow> virtualFlow = getFlow(); int first = virtualFlow.getFirstVisibleCell().getIndex(); int last = virtualFlow.getLastVisibleCell().getIndex(); assertTrue(" visible range [" + first + ", " + last + "] must include " + index, first <= index && index <= last); } protected VirtualFlow> getFlow() { VirtualFlow> virtualFlow = (VirtualFlow>) VirtualFlowTestUtils.getVirtualFlow(comboBox); return virtualFlow; } Have a look at the tests in test.xx.controls to understand how to setup the test context. And have fun :) Zitat von Craig Cavanaugh : > I am trying to create a manual unit test for RFR: 8129123 and I'm using the > existing ButtonMnemonicPositionTest.java as a template to make sure > everything is working correctly. > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > openjdk. > openjfx is successfully compiling and passing tests following the wiki > instructions > > I'm able to compile ButtonMnemonicPositionTest successfully as shown below. > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest.java > > But attempts to run are failing despite a successful compile: > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > ButtonMnemonicPositionTest > Error: JavaFX runtime components are missing, and are required to run this > application > > I've also tried running using the modular-sdk after a Gradle build and no > luck either after finding a recommendation on the list that the module > approach should be used for testing. > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > --add-modules=javafx.controls ButtonMnemonicPositionTest > Error occurred during initialization of boot layer > java.lang.module.FindException: Module javafx.controls not found > > I've been search through the list archive and haven't found a solution. > I'm sure I'm doing something wrong. > > Some help please! > > Regards, > Craig From fastegal at openjdk.java.net Fri Apr 3 12:06:51 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 3 Apr 2020 12:06:51 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Thu, 2 Apr 2020 23:28:19 GMT, Craig Cavanaugh wrote: >> Can you please provide a unit test? One that fails before your fix and passes after your fix. > >> Can you please provide a unit test? One that fails before your fix and passes after your fix. > > I can provide a manual test the next couple of days that demonstrates it before and after, but I'm not sure how to > create an automated unit test because the issue is visual. A quick snippet of how-to write a unit test (for setup see other tests in controls) that will fail before and pass after the change: @Test public void testScrollInSkin() { int index = 50; comboBox.getSelectionModel().select(index); comboBox.show(); VirtualFlow> virtualFlow = getFlow(); int first = virtualFlow.getFirstVisibleCell().getIndex(); int last = virtualFlow.getLastVisibleCell().getIndex(); assertTrue(" visible range [" + first + ", " + last + "] must include " + index, first <= index && index <= last); } protected VirtualFlow> getFlow() { VirtualFlow> virtualFlow = (VirtualFlow>) VirtualFlowTestUtils.getVirtualFlow(comboBox); return virtualFlow; } ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From fastegal at openjdk.java.net Fri Apr 3 12:18:43 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 3 Apr 2020 12:18:43 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: On Fri, 3 Apr 2020 12:03:33 GMT, Jeanette Winzenburg wrote: >>> Can you please provide a unit test? One that fails before your fix and passes after your fix. >> >> I can provide a manual test the next couple of days that demonstrates it before and after, but I'm not sure how to >> create an automated unit test because the issue is visual. > > A quick snippet of how-to write a unit test (for setup see other tests in controls) that will fail before and pass > after the change: > @Test > public void testScrollInSkin() { > int index = 50; > comboBox.getSelectionModel().select(index); > comboBox.show(); > VirtualFlow> virtualFlow = getFlow(); > int first = virtualFlow.getFirstVisibleCell().getIndex(); > int last = virtualFlow.getLastVisibleCell().getIndex(); > assertTrue(" visible range [" + first + ", " + last + "] must include " + index, > first <= index && index <= last); > } > > protected VirtualFlow> getFlow() { > VirtualFlow> virtualFlow = (VirtualFlow>) > VirtualFlowTestUtils.getVirtualFlow(comboBox); > return virtualFlow; > } A couple of comments to the bug (and fix) itself: - is it really a bug or a nice-to-have enhancement? couldn't find an example in win, didn't try too hard and nowadays, such plain combos are not a really frequent - while none of the virtualized controls (nor ChoiceBox) combines selection with scrolling to the selected item. For combo and choice, I see no reason not make it the default behavior. We need to make certain it behaves "naturally" when navigating in the open popup. instead of catching every list.select (and not forget the unselect) we might consider doing it in a showing handler alternatively, we might consider to go deeper and support it directly in the listView ------------- PR: https://git.openjdk.java.net/jfx/pull/136 From kcr at openjdk.java.net Fri Apr 3 12:37:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Apr 2020 12:37:51 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> On Fri, 3 Apr 2020 11:32:12 GMT, Michael Paus wrote: >> @arapte Can you be one of the reviewers? >> >> @mipastgt I ran it against your test application, but if you have other tests you could run, that would be helpful. > > I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to > be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my > expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but > not for the following generated inertia events. They are still equal to the delta values. Is that according to the > specification? From a practical point of view a programmer who relies on the total delta values is probably much > surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events > or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel > generated scroll-events is still not 0 but this has probably another root cause. These are all separate issues that could be explored with follow-on bugs. I'm not sure what the right behavior is for these or whether there is enough information from the OS to do anything about them (e.g., I suspect there is no way to get the touch count for these trackpad-generated gestures on macOS, nor do I really think it would be useful). You might file a follow-on issue for 1 and 3. Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal to be the second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From mpaus at openjdk.java.net Fri Apr 3 14:16:44 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Fri, 3 Apr 2020 14:16:44 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> References: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> Message-ID: On Fri, 3 Apr 2020 12:35:35 GMT, Kevin Rushforth wrote: >> I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to >> be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my >> expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but >> not for the following generated inertia events. They are still equal to the delta values. Is that according to the >> specification? From a practical point of view a programmer who relies on the total delta values is probably much >> surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events >> or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel >> generated scroll-events is still not 0 but this has probably another root cause. > > These are all separate issues that could be explored with follow-on bugs. I'm not sure what the right behavior is for > these or whether there is enough information from the OS to do anything about them (e.g., I suspect there is no way to > get the touch count for these trackpad-generated gestures on macOS, nor do I really think it would be useful). You > might file a follow-on issue for 1 and 3. > Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal to be the second reviewer. I think 1. is more a point for discussion and I am also not sure what is right or wrong but 3. is IMHO a bug, especially because the documentation is so explicit about this behaviour. I'll file a new issue for that. What would I have to do to formally review this? I haven't done that before. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Fri Apr 3 14:34:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Apr 2020 14:34:32 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: <-cAWoCkw-2ZKNBwsML8IgyFuuF37ZgKVzoYn5aNUw7g=.e65a0799-f827-4f26-9c83-12f9a249e8e6@github.com> Message-ID: On Fri, 3 Apr 2020 14:14:36 GMT, Michael Paus wrote: >> These are all separate issues that could be explored with follow-on bugs. I'm not sure what the right behavior is for >> these or whether there is enough information from the OS to do anything about them (e.g., I suspect there is no way to >> get the touch count for these trackpad-generated gestures on macOS, nor do I really think it would be useful). You >> might file a follow-on issue for 1 and 3. >> Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal to be the second reviewer. > > I think 1. is more a point for discussion and I am also not sure what is right or wrong but 3. is IMHO a bug, > especially because the documentation is so explicit about this behaviour. I'll file a new issue for that. > What would I have to do to formally review this? I haven't done that before. I agree about 1 being a point of discussion. Please do file a bug for 3. As for formally reviewing it, you would press the `Files changed` tab near the top of the PR, add any inline comments you might have, and then press the `Review changes` pull down. You would add any overall review comments that you have, then select one of `Comment` (to add comments or questions before approving), `Approve` (this means you have reviewed it and are OK with the changes; you will be listed as a reviewer), or `Request changes` (to indicate a bug or other serious problem), and then press `Submit Review`. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From mpaus at openjdk.java.net Fri Apr 3 15:10:39 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Fri, 3 Apr 2020 15:10:39 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. Marked as reviewed by mpaus (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Fri Apr 3 15:23:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Apr 2020 15:23:39 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Fri, 3 Apr 2020 02:11:12 GMT, Thiago Milczarek Sayao wrote: >> Test on 16.04 (without Webkit - it does not build on 16.04 anymore) >> >> Updated April 2nd. >> >> ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) >> >> Note: DatePickerTest works when run alone. > > I will keep testing it, but I think it's looking good. I see a lot of work going into this. In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the RFR thread and not a comment in the PR. @tsayao When you are ready, please send a short email (not a reply to any existing message) to openjfx-dev at openjdk.java.net with the following: 1. A short summary of the proposed enhancement 2. The goals of the proposed enhancement 3. A description of the proposed changes (basically, the bullet items from the description of this PR) 4. A pointer to this PR for reference I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; review comments in the PR aren't the best way to have that discussion. We aren't following the formal JEP process for JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. Finally, I note that this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther along in the review process. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From Rony.Flatscher at wu.ac.at Fri Apr 3 16:57:29 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Fri, 3 Apr 2020 18:57:29 +0200 Subject: Question ad CSR (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Message-ID: <25a21904-3fed-a089-6387-f8daeb524447@wu.ac.at> Hi Kevin, thank you for your feedback and actions! Ad "please create a CSR request and add link to it in JDK-8238080": preliminarily researching [CSR FAQ] (https://wiki.openjdk.java.net/display/csr/CSR+FAQs) the question "Q: How do I create a CSR ?" gets answered with: > "A: _Do not directly create a CSR from the Create Menu._ JIRA will let you do this right up until _the moment you try to save it and find your typing was in vain._ Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.". Looking at [JDK-8238080] (https://bugs.openjdk.java.net/browse/JDK-8238080) there is no possibility for me to follow the above advice as I have no "More" button/link to select! The reason probably being that I cannot log on. Once I have the CSR text formulated (may take a little while) what should I do with it? ---rony On 03.04.2020 01:21, Kevin Rushforth wrote: > Hi Rony, > > I see that you updated the PR and sent it for review. > > Before we formally review it in the PR, let's finish the discussion as to whether this is a useful > feature, and if so, what form this feature should take. > > From my point of view, this does seem like a useful feature. Would other users of FXML benefit > from it? > > I'm not certain whether we want it to be implicit, compiling the script if the script engine in > question implements Compilable, or via a new keyword or tag. What are the pros / cons? > > What do others think? > > In either case, we would need to make sure that this doesn't present any security concerns in the > presence of a security manager. As long as a user-provided class is on the stack, it will be fine, > but we would need to ensure that. > > -- Kevin > > > On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >> pull request I would kindly request a review of this pull request! >> >> Here the URL: , title changed to: "8238080: FXMLLoader: if >> script engines implement javax.script.Compilable compile scripts". >> >> ---rony >> >> >> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>> has an appropriate test unit going with it as well, please review. >>> >>> There should be no compatibility issue with this implementation. >>> >>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>> language process instruction (e.g. ) contains an appropriate attribute with a >>> value >>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>> respective solution as well. >>> >>> ---rony >>> >>> [1] "Implementation and test unit": >>> >>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>> scripts": >>> >>> >>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>> >>> >>> >>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>> >>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>> the concept). >>>> >>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>> >>>> -- Kevin >>>> >>>> >>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>> Just filed a RFE with the following information: >>>>> >>>>> ??? * Component: >>>>> ??????? o JavaFX >>>>> >>>>> ??? * Subcomponent: >>>>> ??????? o fxml: JavaFX FXML >>>>> >>>>> ??? * Synopsis: >>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>> >>>>> ??? * Descriptions: >>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>> (javax.script.ScriptEngine >>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>> language in >>>>> ????????? the FXML file. >>>>> >>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>> could >>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>> using >>>>> ????????? its eval() methods. >>>>> >>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>> invocations, >>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>> onMouseMove) >>>>> ????????? which may be repetitevly invoked and evaluated." >>>>> >>>>> ??? * System /OS/Java Runtime Information: >>>>> ??????? o "All systems." >>>>> >>>>> Received the internal review ID: "9063426" >>>>> >>>>> ---rony From kevin.rushforth at oracle.com Fri Apr 3 17:33:33 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Apr 2020 10:33:33 -0700 Subject: Question ad CSR (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <25a21904-3fed-a089-6387-f8daeb524447@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <25a21904-3fed-a089-6387-f8daeb524447@wu.ac.at> Message-ID: <72d541da-7418-1c4b-2b0c-a6b00fc72b30@oracle.com> Regarding the CSR, that's usually done after the enhancement is agreed upon in principle, and the review is far enough along that you are ready to write up the spec changes, new API, and/or new interfaces. Since you don't have direct JBS access you will need a sponsor to do that part for you, in which case, creating a comment in the PR with the contents of the CSR is the way to go (once we get to that point). Unless there ends up being new public API, this will be mainly the spec changes in FXMLLoader and the "Introduction to FXML" guide. -- Kevin On 4/3/2020 9:57 AM, Rony G. Flatscher wrote: > Hi Kevin, > > thank you for your feedback and actions! > > Ad "please create a CSR request and add link to it in JDK-8238080": preliminarily researching [CSR > FAQ] (https://wiki.openjdk.java.net/display/csr/CSR+FAQs) the question "Q: How do I create a CSR ?" > gets answered with: > >> "A: _Do not directly create a CSR from the Create Menu._ JIRA will let you do this right up until > _the moment you try to save it and find your typing was in vain._ Instead you should go to the > target bug, select "More", and from the drop down menu select "Create CSR". This is required to > properly associate the CSR with the main bug, just as is done for backports.". > > Looking at [JDK-8238080] (https://bugs.openjdk.java.net/browse/JDK-8238080) there is no possibility > for me to follow the above advice as I have no "More" button/link to select! The reason probably > being that I cannot log on. > > Once I have the CSR text formulated (may take a little while) what should I do with it? > > ---rony > > > On 03.04.2020 01:21, Kevin Rushforth wrote: >> Hi Rony, >> >> I see that you updated the PR and sent it for review. >> >> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >> feature, and if so, what form this feature should take. >> >> From my point of view, this does seem like a useful feature. Would other users of FXML benefit >> from it? >> >> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >> >> What do others think? >> >> In either case, we would need to make sure that this doesn't present any security concerns in the >> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >> but we would need to ensure that. >> >> -- Kevin >> >> >> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >>> pull request I would kindly request a review of this pull request! >>> >>> Here the URL: , title changed to: "8238080: FXMLLoader: if >>> script engines implement javax.script.Compilable compile scripts". >>> >>> ---rony >>> >>> >>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>>> has an appropriate test unit going with it as well, please review. >>>> >>>> There should be no compatibility issue with this implementation. >>>> >>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>> value >>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>>> respective solution as well. >>>> >>>> ---rony >>>> >>>> [1] "Implementation and test unit": >>>> >>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>> scripts": >>>> >>>> >>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>> >>>> >>>> >>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>> >>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>>> the concept). >>>>> >>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>> Just filed a RFE with the following information: >>>>>> >>>>>> ??? * Component: >>>>>> ??????? o JavaFX >>>>>> >>>>>> ??? * Subcomponent: >>>>>> ??????? o fxml: JavaFX FXML >>>>>> >>>>>> ??? * Synopsis: >>>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>> >>>>>> ??? * Descriptions: >>>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>> (javax.script.ScriptEngine >>>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>>> language in >>>>>> ????????? the FXML file. >>>>>> >>>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>>> could >>>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>> using >>>>>> ????????? its eval() methods. >>>>>> >>>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>> invocations, >>>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>> onMouseMove) >>>>>> ????????? which may be repetitevly invoked and evaluated." >>>>>> >>>>>> ??? * System /OS/Java Runtime Information: >>>>>> ??????? o "All systems." >>>>>> >>>>>> Received the internal review ID: "9063426" >>>>>> >>>>>> ---rony From kevin.rushforth at oracle.com Fri Apr 3 18:15:15 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Apr 2020 11:15:15 -0700 Subject: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView Message-ID: We now have two pull requests under review that propose to solve the poor scrolling performance of TableView and TreeTableView, as tracked by JDK-8185886 [1] The first one, PR #108 [2], proposes a change in the bindings ExpressionHelper code relating to the cleaning up of listeners (changing the array-based implementation to a Map). It is a change in javafx.base to make the existing operations that TableView / TreeTableView do less expensive. The second one, PR #125 [3], proposes to address the problem by eliminating the need for cleaning up a large numbers of bindings. This approach changes the javafx.controls code used by TableView, and doesn't touch the binding code. It would be helpful to discuss which approach to take on this list, so we aren't independently reviewing both PRs. I don't yet have an opinion on which way to go, but I will note a couple pros / cons of each approach. PR #108 is both a more fundamental change and a simpler change. It changes the characteristics (memory footprint, performance) of a class that is used by far more that just TableView and TreeTableView. This is both a potential benefit and risk. If done in such a way that there are no regressions (functional, memory, or performance), it could benefit more than just the scrolling issue in question. By contrast, it has the potential to impact other use cases negatively, mainly from a performance or memory point of view, since the logic changes are relatively simple, and should be largely "behavior neutral". PR #125 is a more targeted change, impacting only the two controls in question, but is a more complicated change from a logic point of view. I am concerned primarily with any unintended behavioral changes. Both of them will need to be very well tested to ensure that there are no regressions. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8185886 [2] https://github.com/openjdk/jfx/pull/108 [3] https://github.com/openjdk/jfx/pull/125 From swpalmer at gmail.com Fri Apr 3 19:15:37 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 3 Apr 2020 15:15:37 -0400 Subject: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: <0DF6AB39-810A-4E6C-960A-D30778E66B63@gmail.com> Assuming testing and performance/memory analysis leads to the conclusion that the risks are worth it, would it make sense to do both? Would we get a greater benefit from the combined effects? Or is the incremental improvement of including the second fix (whichever it may be) no longer significant enough to bother with? Scott > On Apr 3, 2020, at 2:15 PM, Kevin Rushforth wrote: > > ?We now have two pull requests under review that propose to solve the poor scrolling performance of TableView and TreeTableView, as tracked by JDK-8185886 [1] > > The first one, PR #108 [2], proposes a change in the bindings ExpressionHelper code relating to the cleaning up of listeners (changing the array-based implementation to a Map). It is a change in javafx.base to make the existing operations that TableView / TreeTableView do less expensive. > > The second one, PR #125 [3], proposes to address the problem by eliminating the need for cleaning up a large numbers of bindings. This approach changes the javafx.controls code used by TableView, and doesn't touch the binding code. > > It would be helpful to discuss which approach to take on this list, so we aren't independently reviewing both PRs. > > I don't yet have an opinion on which way to go, but I will note a couple pros / cons of each approach. > > PR #108 is both a more fundamental change and a simpler change. It changes the characteristics (memory footprint, performance) of a class that is used by far more that just TableView and TreeTableView. This is both a potential benefit and risk. If done in such a way that there are no regressions (functional, memory, or performance), it could benefit more than just the scrolling issue in question. By contrast, it has the potential to impact other use cases negatively, mainly from a performance or memory point of view, since the logic changes are relatively simple, and should be largely "behavior neutral". > > PR #125 is a more targeted change, impacting only the two controls in question, but is a more complicated change from a logic point of view. I am concerned primarily with any unintended behavioral changes. > > Both of them will need to be very well tested to ensure that there are no regressions. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8185886 > [2] https://github.com/openjdk/jfx/pull/108 > [3] https://github.com/openjdk/jfx/pull/125 > From kevin.rushforth at oracle.com Fri Apr 3 19:22:04 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Apr 2020 12:22:04 -0700 Subject: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <0DF6AB39-810A-4E6C-960A-D30778E66B63@gmail.com> References: <0DF6AB39-810A-4E6C-960A-D30778E66B63@gmail.com> Message-ID: <72cfbf06-9c6b-5b16-82ea-10cca915918c@oracle.com> That's a fair question. Hard to say, but my guess is that if we do the first, the incremental improvements of the second might not be worth the effort or risk. And if we go with the second, we would need another test case that hits the slow iteration problem when removing a listener from a large array. -- Kevin On 4/3/2020 12:15 PM, Scott Palmer wrote: > Assuming testing and performance/memory analysis leads to the conclusion that the risks are worth it, would it make sense to do both? Would we get a greater benefit from the combined effects? Or is the incremental improvement of including the second fix (whichever it may be) no longer significant enough to bother with? > > > Scott > >> On Apr 3, 2020, at 2:15 PM, Kevin Rushforth wrote: >> >> ?We now have two pull requests under review that propose to solve the poor scrolling performance of TableView and TreeTableView, as tracked by JDK-8185886 [1] >> >> The first one, PR #108 [2], proposes a change in the bindings ExpressionHelper code relating to the cleaning up of listeners (changing the array-based implementation to a Map). It is a change in javafx.base to make the existing operations that TableView / TreeTableView do less expensive. >> >> The second one, PR #125 [3], proposes to address the problem by eliminating the need for cleaning up a large numbers of bindings. This approach changes the javafx.controls code used by TableView, and doesn't touch the binding code. >> >> It would be helpful to discuss which approach to take on this list, so we aren't independently reviewing both PRs. >> >> I don't yet have an opinion on which way to go, but I will note a couple pros / cons of each approach. >> >> PR #108 is both a more fundamental change and a simpler change. It changes the characteristics (memory footprint, performance) of a class that is used by far more that just TableView and TreeTableView. This is both a potential benefit and risk. If done in such a way that there are no regressions (functional, memory, or performance), it could benefit more than just the scrolling issue in question. By contrast, it has the potential to impact other use cases negatively, mainly from a performance or memory point of view, since the logic changes are relatively simple, and should be largely "behavior neutral". >> >> PR #125 is a more targeted change, impacting only the two controls in question, but is a more complicated change from a logic point of view. I am concerned primarily with any unintended behavioral changes. >> >> Both of them will need to be very well tested to ensure that there are no regressions. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8185886 >> [2] https://github.com/openjdk/jfx/pull/108 >> [3] https://github.com/openjdk/jfx/pull/125 >> From craig.cavanaugh at gmail.com Fri Apr 3 22:52:31 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Fri, 3 Apr 2020 18:52:31 -0400 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: References: Message-ID: Thanks! That was the trick! On Fri, Apr 3, 2020 at 6:52 AM Ajit Ghaisas wrote: > Hi Craig, > > Here is how I run the ButtonMnemonicPositionTest. > > $ export FX_LIB=/Users/AG/aaa/jfx/build/sdk/lib > $ cd /Users/AG/aaa/jfx/tests/manual/UI > $ javac --module-path $FX_LIB --add-modules javafx.controls > ButtonMnemonicPositionTest.java > $ java --module-path $FX_LIB --add-modules javafx.controls > ButtonMnemonicPositionTest > > Hope this helps. > > We can discuss further on your PR. > > Regards, > Ajit > > > > On 03-Apr-2020, at 3:56 PM, Craig Cavanaugh > wrote: > > > > I am trying to create a manual unit test for RFR: 8129123 and I'm using > the > > existing ButtonMnemonicPositionTest.java as a template to make sure > > everything is working correctly. > > > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > > openjdk. > > openjfx is successfully compiling and passing tests following the wiki > > instructions > > > > I'm able to compile ButtonMnemonicPositionTest successfully as shown > below. > > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest.java > > > > But attempts to run are failing despite a successful compile: > > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest > > Error: JavaFX runtime components are missing, and are required to run > this > > application > > > > I've also tried running using the modular-sdk after a Gradle build and no > > luck either after finding a recommendation on the list that the module > > approach should be used for testing. > > > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > > --add-modules=javafx.controls ButtonMnemonicPositionTest > > Error occurred during initialization of boot layer > > java.lang.module.FindException: Module javafx.controls not found > > > > I've been search through the list archive and haven't found a solution. > > I'm sure I'm doing something wrong. > > > > Some help please! > > > > Regards, > > Craig > > From tsayao at openjdk.java.net Fri Apr 3 23:44:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 3 Apr 2020 23:44:02 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Fri, 3 Apr 2020 15:21:29 GMT, Kevin Rushforth wrote: >> I will keep testing it, but I think it's looking good. > > I see a lot of work going into this. > > In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the > openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the > RFR thread and not a comment in the PR. @tsayao When you are ready, please send a short email (not a reply to any > existing message) to openjfx-dev at openjdk.java.net with the following: > 1. A short summary of the proposed enhancement > 2. The goals of the proposed enhancement > 3. A description of the proposed changes (basically, the bullet items from the description of this PR) > 4. A pointer to this PR for reference > > I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the > details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; > review comments in the PR aren't the best way to have that discussion. We aren't following the formal JEP process for > JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large > or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. Finally, I note that > this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther > along in the review process. @kevinrushforth Ok, will do as the instructions. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From craig.cavanaugh at gmail.com Sat Apr 4 00:05:15 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Fri, 3 Apr 2020 20:05:15 -0400 Subject: Stuck attempting to run/develop a manual unit test In-Reply-To: <20200403134747.Horde.uzvz028f4rZMXjJvWfnCEQ1@webmail.df.eu> References: <20200403134747.Horde.uzvz028f4rZMXjJvWfnCEQ1@webmail.df.eu> Message-ID: Jeanette, Thank you! Much appreciated and a much better approach than a manual test. Well on my way now! Thanks, Craig On Fri, Apr 3, 2020 at 7:48 AM Jeanette Winzenburg wrote: > > Hi Craig, > > no manual test needed - you can implement a normal (unit) test with > the help or VirtualFlowTestUtils: grab the flow, get its first/last > visible cell and check whether their range includes to cell we want to > see, something like: > > @Test > public void testScrollInSkin() { > int index = 50; > comboBox.getSelectionModel().select(index); > comboBox.show(); > VirtualFlow> virtualFlow = getFlow(); > int first = virtualFlow.getFirstVisibleCell().getIndex(); > int last = virtualFlow.getLastVisibleCell().getIndex(); > assertTrue(" visible range [" + first + ", " + last + "] must > include " + index, > first <= index && index <= last); > } > > protected VirtualFlow> getFlow() { > VirtualFlow> virtualFlow = > (VirtualFlow>) > VirtualFlowTestUtils.getVirtualFlow(comboBox); > return virtualFlow; > } > > Have a look at the tests in test.xx.controls to understand how to > setup the test context. And have fun :) > > Zitat von Craig Cavanaugh : > > > I am trying to create a manual unit test for RFR: 8129123 and I'm using > the > > existing ButtonMnemonicPositionTest.java as a template to make sure > > everything is working correctly. > > > > I'm using an Ubuntu 18.04.4 build environment using the default 11.0.6 > > openjdk. > > openjfx is successfully compiling and passing tests following the wiki > > instructions > > > > I'm able to compile ButtonMnemonicPositionTest successfully as shown > below. > > javac -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest.java > > > > But attempts to run are failing despite a successful compile: > > java -classpath .:/home/craig/IdeaProjects/jfx/build/sdk/lib/* > > ButtonMnemonicPositionTest > > Error: JavaFX runtime components are missing, and are required to run > this > > application > > > > I've also tried running using the modular-sdk after a Gradle build and no > > luck either after finding a recommendation on the list that the module > > approach should be used for testing. > > > > java --module-path /home/craig/IdeaProjects/jfx/build/modular-sdk/modules > > --add-modules=javafx.controls ButtonMnemonicPositionTest > > Error occurred during initialization of boot layer > > java.lang.module.FindException: Module javafx.controls not found > > > > I've been search through the list archive and haven't found a solution. > > I'm sure I'm doing something wrong. > > > > Some help please! > > > > Regards, > > Craig > > > > From tsayao at openjdk.java.net Sat Apr 4 00:55:58 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sat, 4 Apr 2020 00:55:58 GMT Subject: [Rev 43] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > This proposed change does the following: > > - Ports DND target to use GTK reducing code size and adding extra text / image formats (such as .gif); > - Use gtk signals instead of gdk events (also to reduce code size); > - Simplifies geometry (sizing/positioning) with a more straightforward code (less special cases), making it easier to > understand and maintain; > - Replaces (pointer and focus) grabbing with a gtk approach; > - Reworked frame extents (the wm extension to get decoration sizes) to reduce size and complexity; > - Simplified cursor changing (for gtk3); > - Reduced the use of gtk/gdk deprecated functions; > - Removes Applet/Web Start code; > - Fixes https://bugs.openjdk.java.net/browse/JDK-8237491; > > In general it reduces code size and complexity and hands more work to gtk. > > Updated on 2020-01-29: > ![image](https://user-images.githubusercontent.com/30704286/73354728-2ce47d00-4275-11ea-935c-414fc26163d7.png) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f52f63be..acd54962 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.43 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.42-43 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From ebresie at gmail.com Sat Apr 4 01:25:15 2020 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 3 Apr 2020 20:25:15 -0500 Subject: Seeking help with latest master ... In-Reply-To: CABxFH2Fjkk2sNBq8524a_MK5vqbbxzsFxnpbzRez1v9Huh9J=g@mail.gmail.com References: b47033ae-9404-c870-98ab-fbd3a5687c4a@wu.ac.at 82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com 7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at e1c5f995-0d29-599b-0d19-f46308bc9182@wu.ac.at 104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com 76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at B3D01019-5F4C-47A3-AD38-79D6DF52EF8B@gmail.com cf87bdba-04f1-df69-b83d-5bb7c83dbcd6@wu.ac.at 364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at 364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at Message-ID: <029c38e1-83dd-4d08-ab13-b14cceeefa33@Erics-iPhone-X> Are you behind a proxy? I had problems with another application which required registering certificates and related credentials keys to be added for java. Eric Bresie Ebresie at gmail.com > On April 2, 2020 at 2:20:44 PM CDT, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to > SSL with some JDK's as well, which may or may not be related to the cacerts > file that is bundled. > > - Johan > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > > > Being stuck (tried the previous working gradle 5.6.4, could get "gradle > > clean", but not further) in > > the end I just tried Java 14 and that allowed me to run "gradle" > > successfully (currently building > > webkit to get going again). Just wanted to let interested readers know. > > (Would be great though, if > > it worked with the 11 LTS version as well.) > > > > ---rony > > > > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > > On 31.03.2020 20:21, Scott Palmer wrote: > > > > > Could not resolve all dependencies for configuration ':apps:lucene'. > > > > > Multiple build operations failed. > > > > java.lang.ExceptionInInitializerError > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > java.lang.ExceptionInInitializerError > > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > > > > > > > > This to me looks like it may be failing to make an https connection to > > a repository when > > > > attempting to download dependencies. > > > > > > > > There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when > > running gradle builds, see: > > > > https://github.com/gradle/gradle/issues/7842 > > > > > > > > Claims to be fixed, but maybe not? > > > > > > > > If it is related to Gradle changing java.home while compiling, I wonder > > if using --no-parallel > > > > might work around it? Of course try with --debug as well to see if it > > offers more clues. > > > Scott, thank you! > > > > > > Not having any knowledge about gradle I am unfortunately lost in this > > case. However, I used "gradle > > > --no-parallel --debug" which did not succeed but created a 1.2 MB text > > file which I keep temporarily > > > in my DrobBox at: < > > https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 > > > . > > > > > > Will have to leave in a few minutes for today so can only try other > > things tomorrow. > > > > > > ---rony > > > > From github.com+636962+ccavanaugh at openjdk.java.net Sat Apr 4 07:36:47 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sat, 4 Apr 2020 07:36:47 GMT Subject: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: <6zE9O-VX_9Xpoxv73bbW9DKjwE4LzhRXnWF_PmHyiVo=.a8cbcc0c-3000-452c-8a0f-106e155b1050@github.com> > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Craig Cavanaugh has updated the pull request incrementally with one additional commit since the last revision: Unit test for JDK_8129123 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/136/files - new: https://git.openjdk.java.net/jfx/pull/136/files/8e06c9e1..229a7fd2 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/136/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/136/webrev.00-01 Stats: 47 lines in 1 file changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/136/head:pull/136 PR: https://git.openjdk.java.net/jfx/pull/136 From craig.cavanaugh at gmail.com Sat Apr 4 07:59:10 2020 From: craig.cavanaugh at gmail.com (Craig Cavanaugh) Date: Sat, 4 Apr 2020 03:59:10 -0400 Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <-TlkRlwh9MTWV2aVEMpKgf5iPmUVbDNkKaVaw8xzwV0=.d52f9e9d-1085-493e-b0d8-5c7e7b3f5b29@github.com> Message-ID: My use case which is driving the fix for this bug is user expectation in an open source application (https://github.com/ccavanaugh/jgnash). When a user makes an edit to an existing transaction, the expectation is the prior selected ComboBox value is visible when the list is displayed, otherwise it gives the impression they made an error or something is wrong. I think the root cause of the poor experience is seeing the correct value when collapsed, and then not seeing it or it's selection when expanded. Also, scrolling automatically was the default behavior for Swing. My current work around is an extended ComboBox that listens for a mouse click or key events and then scrolls the list view. On Fri, Apr 3, 2020 at 8:19 AM Jeanette Winzenburg < fastegal at openjdk.java.net> wrote: > On Fri, 3 Apr 2020 12:03:33 GMT, Jeanette Winzenburg > wrote: > > >>> Can you please provide a unit test? One that fails before your fix and > passes after your fix. > >> > >> I can provide a manual test the next couple of days that demonstrates > it before and after, but I'm not sure how to > >> create an automated unit test because the issue is visual. > > > > A quick snippet of how-to write a unit test (for setup see other tests > in controls) that will fail before and pass > > after the change: > > @Test > > public void testScrollInSkin() { > > int index = 50; > > comboBox.getSelectionModel().select(index); > > comboBox.show(); > > VirtualFlow> virtualFlow = getFlow(); > > int first = virtualFlow.getFirstVisibleCell().getIndex(); > > int last = virtualFlow.getLastVisibleCell().getIndex(); > > assertTrue(" visible range [" + first + ", " + last + "] must > include " + index, > > first <= index && index <= last); > > } > > > > protected VirtualFlow> getFlow() { > > VirtualFlow> virtualFlow = > (VirtualFlow>) > > VirtualFlowTestUtils.getVirtualFlow(comboBox); > > return virtualFlow; > > } > > A couple of comments to the bug (and fix) itself: > > - is it really a bug or a nice-to-have enhancement? couldn't find an > example in win, didn't try too hard and nowadays, > such plain combos are not a really frequent > - while none of the virtualized controls (nor ChoiceBox) combines > selection with scrolling to the selected item. For > combo and choice, I see no reason not make it the default behavior. We > need to make certain it behaves "naturally" when > navigating in the open popup. instead of catching every list.select (and > not forget the unselect) we might consider > doing it in a showing handler alternatively, we might consider to go > deeper and support it directly in the listView > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/136 > From fastegal at swingempire.de Sat Apr 4 10:21:21 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 04 Apr 2020 12:21:21 +0200 Subject: Where to discuss options/scope of an issue (and its pull request)? Message-ID: <20200404122121.Horde.wU3DIRPGeKDh63C8wt3MZg1@webmail.df.eu> as an example take f.i. https://bugs.openjdk.java.net/browse/JDK-8129123 (and its pull request https://github.com/openjdk/jfx/pull/136 with a good starter to a solution) has open questions - for me, at least :) Places to discuss: the pull request? the mailing list? the issue? Where would such a debate - assuming there's some lasting value in it - be best done such that it wouldn't be lost? -- Jeanette From kevin.rushforth at oracle.com Sat Apr 4 13:10:21 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 4 Apr 2020 06:10:21 -0700 Subject: Where to discuss options/scope of an issue (and its pull request)? In-Reply-To: <20200404122121.Horde.wU3DIRPGeKDh63C8wt3MZg1@webmail.df.eu> References: <20200404122121.Horde.wU3DIRPGeKDh63C8wt3MZg1@webmail.df.eu> Message-ID: In general a discussion like this can happen in the pull request as part of the review. All PR comments are forwarded to the mailing list anyway. -- Kevin On 4/4/2020 3:21 AM, Jeanette Winzenburg wrote: > > as an example take f.i. > https://bugs.openjdk.java.net/browse/JDK-8129123 (and its pull request > https://github.com/openjdk/jfx/pull/136 with a good starter to a > solution) has open questions - for me, at least :) > > Places to discuss: the pull request? the mailing list? the issue? > Where would such a debate - assuming there's some lasting value in it > - be best done such that it wouldn't be lost? > > -- Jeanette > From Rony.Flatscher at wu.ac.at Sat Apr 4 13:58:27 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sat, 4 Apr 2020 15:58:27 +0200 Subject: Seeking help with latest master ... In-Reply-To: References: <82510f0d-b6a5-f4b9-e381-4cf6ce6ef25d@oracle.com> <7f4215ff-05e6-9a4b-9b74-740a452b8e71@wu.ac.at> <104989a4-6d87-7452-d8eb-6fc2fd506fa8@oracle.com> <76bf109c-78cb-7ef1-5348-ec181653a40c@wu.ac.at> <364bf017-9f78-a7b8-37cd-8d6e7bb8ef4d@wu.ac.at> Message-ID: On 02.04.2020 21:20, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to SSL with some JDK's as > well, which may or may not be related to the cacerts file that is bundled. When hitting this problem the JDK was the same that has worked flawlessly with the previous versions of OpenFX. It looks as if Java 14 is needed for the latest OpenFX master, at least for my installation. ---rony > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > > Being stuck (tried the previous working gradle 5.6.4, could get "gradle clean", but not > further) in > the end I just tried Java 14 and that allowed me to run "gradle" successfully (currently building > webkit to get going again). Just wanted to let interested readers know. (Would be great though, if > it worked with the 11 LTS version as well.) > > ---rony > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > On 31.03.2020 20:21, Scott Palmer wrote: > >>> Could not resolve all dependencies for configuration ':apps:lucene'. > >> ????? > Multiple build operations failed. > >> ??????????? java.lang.ExceptionInInitializerError > >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> ??????????? java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> ???????? > java.lang.ExceptionInInitializerError > >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> ???????? > java.lang.NoClassDefFoundError: Could not initialize class > >> ???sun.security.ssl.SSLContextImpl$TLSContext > >> > >> > >> This to me looks like it may be failing to make an https connection to a repository when > >> attempting to download?dependencies. > >> > >> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running gradle builds, > see:? > >> https://github.com/gradle/gradle/issues/7842 > >> > >> Claims to be fixed, but maybe not? > >> > >> If it is related to Gradle?changing java.home while compiling, I wonder if using?--no-parallel > >> might work around it?? Of course try with --debug as well to see if it offers more clues. > > Scott, thank you! > > > > Not having any knowledge about gradle I am unfortunately lost in this case. However, I used? > "gradle > > --no-parallel --debug" which did not succeed but created a 1.2 MB text file which I keep > temporarily > > in my DrobBox at: . > > > > Will have to leave in a few minutes for today so can only try other things tomorrow. > > > > ---rony > From Rony.Flatscher at wu.ac.at Sat Apr 4 13:59:50 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sat, 4 Apr 2020 15:59:50 +0200 Subject: Seeking help with latest master ... In-Reply-To: <029c38e1-83dd-4d08-ab13-b14cceeefa33@Erics-iPhone-X> References: <029c38e1-83dd-4d08-ab13-b14cceeefa33@Erics-iPhone-X> Message-ID: On 04.04.2020 03:25, Eric Bresie wrote: > Are you behind a proxy? I had problems with another application which required registering certificates and related credentials keys to be added for java. No, no proxy server (my setup has direct access). ---rony > On April 2, 2020 at 2:20:44 PM CDT, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to > SSL with some JDK's as well, which may or may not be related to the cacerts > file that is bundled. > > - Johan > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > >>> Being stuck (tried the previous working gradle 5.6.4, could get "gradle >>> clean", but not further) in >>> the end I just tried Java 14 and that allowed me to run "gradle" >>> successfully (currently building >>> webkit to get going again). Just wanted to let interested readers know. >>> (Would be great though, if >>> it worked with the 11 LTS version as well.) >>> >>> ---rony >>> >>> >>> On 31.03.2020 20:36, Rony G. Flatscher wrote: >>>> On 31.03.2020 20:21, Scott Palmer wrote: >>>>>> Could not resolve all dependencies for configuration ':apps:lucene'. >>>>>> Multiple build operations failed. >>>>> java.lang.ExceptionInInitializerError >>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>>> java.lang.ExceptionInInitializerError >>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>>> java.lang.NoClassDefFoundError: Could not initialize class >>>>> sun.security.ssl.SSLContextImpl$TLSContext >>>>> >>>>> >>>>> This to me looks like it may be failing to make an https connection to >>> a repository when >>>>> attempting to download dependencies. >>>>> >>>>> There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when >>> running gradle builds, see: >>>>> https://github.com/gradle/gradle/issues/7842 >>>>> >>>>> Claims to be fixed, but maybe not? >>>>> >>>>> If it is related to Gradle changing java.home while compiling, I wonder >>> if using --no-parallel >>>>> might work around it? Of course try with --debug as well to see if it >>> offers more clues. >>>> Scott, thank you! >>>> >>>> Not having any knowledge about gradle I am unfortunately lost in this >>> case. However, I used "gradle >>>> --no-parallel --debug" which did not succeed but created a 1.2 MB text >>> file which I keep temporarily >>>> in my DrobBox at: < >>> https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 >>>> . >>>> >>>> Will have to leave in a few minutes for today so can only try other >>> things tomorrow. >>>> ---rony From Rony.Flatscher at wu.ac.at Sat Apr 4 16:03:37 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sat, 4 Apr 2020 18:03:37 +0200 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Message-ID: Hi Kevin, On 03.04.2020 01:21, Kevin Rushforth wrote: > I see that you updated the PR and sent it for review. > > Before we formally review it in the PR, let's finish the discussion as to whether this is a useful > feature, and if so, what form this feature should take. > > From my point of view, this does seem like a useful feature. Would other users of FXML benefit > from it? Script code should be executed faster after compilation, so any FXML page that hosts script code may benefit. The benefits depend on the type of script (and maybe its size and its complexity) and also on the types of event handlers the scripts serve, e.g. move or drag event handlers may benefit significantly. This is because repeated invocation of compiled script event handlers do not cause the reparsing of that script's source and interpreting it on each invocation, which may be expensive depending on the script engine, but rather allows the immediate evaluation/execution of the compiled script by the script engine. > I'm not certain whether we want it to be implicit, compiling the script if the script engine in > question implements Compilable, or via a new keyword or tag. What are the pros / cons? In principle there are three possibilities: 1) If a script engine implements javax.script.Compilable, compile the script and execute the compiled version. In the case of event handlers compile and buffer the compiled script and execute the compiled script each time its registered event fires. o Pro: immediately benefits all existing FXML pages that host scripts o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail compiling but have been employed successfully in interpreted mode 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML language PI that switches on compilation of scripts hosted in FXML definitions if the script engine implements the javax.script.Compilable interface. If missing it would default to "false". (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the script engine supports it. It would be an error if the "compile" PI was present, but the "language" PI was not.) o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the language PI gets changed o Con: benefit not made available automatically to existing FXML pages that host scripts 3) Another possibility would be to define a boolean attribute/property "compile" for script and node elements and only compile the scripts, if the property is set to true o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed accordingly o Con: potential benefit not made available automatically to existing FXML pages that host scripts 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be overruled individually by 3. The question would be whether 2 or/and 3 are really necessary as it can be expected that compilation of scripts by the script engines would find the same errors as while interpreting the very same scripts (if not, the script engine is badly broken and it could be argued that then the interpretation part of the script engine might be expected to be broken as well which would be quite dangerous from an integrity POV; the same consideration applies as well if the execution of the compiled script would behave differently to interpreting the very same script by the same script engine). The current WIP implements 1 above and includes an appropriate test unit. > What do others think? > In either case, we would need to make sure that this doesn't present any security concerns in the > presence of a security manager. As long as a user-provided class is on the stack, it will be fine, > but we would need to ensure that. The compilation of scripts needs to be done by the Java script engines (implementing both, javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled scripts ([javax.script.CompiledScript] (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). ---rony > On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >> pull request I would kindly request a review of this pull request! >> >> Here the URL: , title changed to: "8238080: FXMLLoader: if >> script engines implement javax.script.Compilable compile scripts". >> >> ---rony >> >> >> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>> has an appropriate test unit going with it as well, please review. >>> >>> There should be no compatibility issue with this implementation. >>> >>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>> language process instruction (e.g. ) contains an appropriate attribute with a >>> value >>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>> respective solution as well. >>> >>> ---rony >>> >>> [1] "Implementation and test unit": >>> >>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>> scripts": >>> >>> >>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>> >>> >>> >>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>> >>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>> the concept). >>>> >>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>> >>>> -- Kevin >>>> >>>> >>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>> Just filed a RFE with the following information: >>>>> >>>>> ??? * Component: >>>>> ??????? o JavaFX >>>>> >>>>> ??? * Subcomponent: >>>>> ??????? o fxml: JavaFX FXML >>>>> >>>>> ??? * Synopsis: >>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>> >>>>> ??? * Descriptions: >>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>> (javax.script.ScriptEngine >>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>> language in >>>>> ????????? the FXML file. >>>>> >>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>> could >>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>> using >>>>> ????????? its eval() methods. >>>>> >>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>> invocations, >>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>> onMouseMove) >>>>> ????????? which may be repetitevly invoked and evaluated." >>>>> >>>>> ??? * System /OS/Java Runtime Information: >>>>> ??????? o "All systems." >>>>> >>>>> Received the internal review ID: "9063426" >>>>> >>>>> ---rony From tsayao at openjdk.java.net Sun Apr 5 00:05:43 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 00:05:43 GMT Subject: [Rev 44] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Separate the new gtk glass impl ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/acd54962..748d81bd Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.44 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.43-44 Stats: 4073 lines in 40 files changed: 2479 ins; 831 del; 763 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From thiago.sayao at clamed.com.br Sun Apr 5 00:13:58 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 00:13:58 +0000 Subject: Discussion on adding a new gtk glass backend Message-ID: Summary ------- * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. PR: https://github.com/openjdk/jfx/pull/77 Goals ----- * Make Linux a first-class OpenJFX platform (see Motivation); * Simplify the code and reduce it's size; * Update to gtk3 (it was originally a port from gtk2); * Remove unused code (such as applets and web start); * Prepare the ground for a possible future Wayland support. Non-Goals --------- * Make Wayland work now. Success Metrics --------------- * Reduced code size (999 lines removed); * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. Motivation ---------- While working with OpenJFX on Linux, I have fixed some of it's bugs: * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). Description ----------- This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. * Note: No public API was modified; * Specific Code Changes * glass_window.cpp / glass_window.h - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); - Frame Extents: Removed the code to request extents and gtk already does it by default; - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. - Other Size calculation changes: - Use gtk_window_set_default_size() for initial size which is the appropriate function; - Gravity is now ignored as it is on Windows glass impl; - Avoid sending same sizes to Java (duplicated events); - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on apply_geometry(). - Mouse grab: Reworked it to use to correct functions according to gtk+ version; - Draw: Reworked it to use the correct calls accord to gtk+ version changes; - Fixed JDK-8237491; - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; - Reorganized function order on glass_window.cpp to match glass_window.h - Only work-around Unity bug if window manager is Unity * GlassCursor.cpp - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; * GtkWindow.java - Moved the extents special case to native glass; * GlassApplication.cpp - Removed Gdk events where possible (it's now on glass_window as signals); - Removed applet/web start code; * GlassView.cpp - Changes to reflect frame extents rework on glass_window * GlassWindow.cpp - WindowContextTop -> WindowContext - Removed applet / web start code; - Removed frame extents (which is not called anymore due to GtkWindow.java change); * glass_general.cpp - Removed functions that became unused; - Added is_grab_disabled() that is used on glass_window * glass_window_ime.cpp - WindowContextTop -> WindowContext; * glass_dnd.cpp / glass_dnd.h - Ported to Gtk signals; - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); - Allow COMPOUND_TEXT; - Do not request content while dragging; - Reduce overall code size. Testing ------- While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. Note: Non-robot tests do not apply since the changes are glass specific. Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. Risks and Assumptions --------------------- * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; * It's a big change - well tested but might still break something. Dependencies ----------- * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 * Maximized undecorated stage behaves inconsistently on different platforms : https://bugs.openjdk.java.net/browse/JDK-8237491 From jvos at openjdk.java.net Sun Apr 5 10:24:17 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 5 Apr 2020 10:24:17 GMT Subject: RFR: 8242163: Android keyboard integration fails Message-ID: Fix the code that integrates TextField/TextArea with the android keyboard Fix for #8242163 ------------- Commit messages: - Fix the code that integrates TextField/TextArea with the android keyboard Changes: https://git.openjdk.java.net/jfx/pull/157/files Webrev: https://webrevs.openjdk.java.net/jfx/157/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242163 Stats: 267 lines in 9 files changed: 148 ins; 108 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/157/head:pull/157 PR: https://git.openjdk.java.net/jfx/pull/157 From jvos at openjdk.java.net Sun Apr 5 14:16:21 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 5 Apr 2020 14:16:21 GMT Subject: RFR: 8242167: ios keyboard handling Message-ID: Use JavaFX controls for TextField and TextArea instead of the native iOS ones This fixes JDK-8242167 ------------- Commit messages: - Use JavaFX controls for TextField and TextArea instead of the native iOS ones Changes: https://git.openjdk.java.net/jfx/pull/158/files Webrev: https://webrevs.openjdk.java.net/jfx/158/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242167 Stats: 367 lines in 12 files changed: 288 ins; 76 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/158/head:pull/158 PR: https://git.openjdk.java.net/jfx/pull/158 From tsayao at openjdk.java.net Sun Apr 5 18:21:24 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 18:21:24 GMT Subject: [Rev 45] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <9y6JPJ1hSwoodob6hNybRf9FbnXioKlVSiK2nCUZT2Q=.dc9b8be8-5701-405d-be15-54b750ba4c52@github.com> > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with five additional commits since the last revision: - Merge branch 'test2' into jdk_8236651 - Merge remote-tracking branch 'origin/test2' into test2 - Make gtk3 compile without deprecations - Make gtk3 compile without deprecations - Make gtk3 compile without deprecations ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/748d81bd..91d98466 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.45 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.44-45 Stats: 114 lines in 9 files changed: 77 ins; 4 del; 33 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Sun Apr 5 18:44:20 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 18:44:20 GMT Subject: [Rev 46] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). Separate the new gtk glass impl Make gtk3 compile without deprecations Make gtk3 compile without deprecations Make gtk3 compile without deprecations ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/91d98466..8973d385 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.46 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.45-46 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Sun Apr 5 20:24:13 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 5 Apr 2020 20:24:13 GMT Subject: [Rev 47] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Smooth scrolling only possible with impl on java side ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/8973d385..2f83ce7b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.47 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.46-47 Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From ajoseph at openjdk.java.net Mon Apr 6 12:03:32 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 6 Apr 2020 12:03:32 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode Message-ID: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native threads for x86 to 1 MB. ------------- Commit messages: - 8242209: Increase web native thread stack size for x86 mode Changes: https://git.openjdk.java.net/jfx/pull/159/files Webrev: https://webrevs.openjdk.java.net/jfx/159/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242209 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/159.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/159/head:pull/159 PR: https://git.openjdk.java.net/jfx/pull/159 From arapte at openjdk.java.net Mon Apr 6 12:30:32 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 12:30:32 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 868: > 867: } > 868: gesturesBeganMask |= theMask; > 869: } Rotate and Magnify gestures can be started and performed together. If Rotate is already in progress then `gesturesBeganMask` would be set to `4`. and If we start a Magnify gesture while the Rotate is not ended then `sendJavaGestureBeginEvent` will not be executed for Magnify gesture. However the application currently receives the synthetic `ZOOM_STARTED` event, which is generated as a result of call to `sendJavaGestureEvent` and not an event generated from here, A change in inner `if` statement as below can fix the issue, if ((gesturesBeganMask & theMask) == 0) { gesturesBeganMask |= theMask; [self sendJavaGestureBeginEvent:theEvent] } ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From arapte at openjdk.java.net Mon Apr 6 12:34:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 12:34:52 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 888: > 887: } > 888: } > 889: } In continuation to the change in `maybeBeginGestureWithEvent`, we would need to remove the inner `if` condition change here, if ((gesturesBeganMask & theMask) != 0) { gesturesBeganMask &= ~theMask; [self sendJavaGestureEndEvent:theEvent]; } ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From kcr at openjdk.java.net Mon Apr 6 14:19:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 14:19:11 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: On Mon, 6 Apr 2020 12:28:21 GMT, Ambarish Rapte wrote: >> As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case >> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, >> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile >> time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer >> guide: >> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) >> Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification >> works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to >> link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK >> or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information >> from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the >> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new >> local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, >> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and >> the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the >> problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have >> since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. > > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 868: > >> 867: } >> 868: gesturesBeganMask |= theMask; >> 869: } > > Rotate and Magnify gestures can be started and performed together. > If Rotate is already in progress then `gesturesBeganMask` would be set to `4`. > and If we start a Magnify gesture while the Rotate is not ended then `sendJavaGestureBeginEvent` will not be executed > for Magnify gesture. However the application currently receives the synthetic `ZOOM_STARTED` event, which is generated > as a result of call to `sendJavaGestureEvent` and not an event generated from here, > A change in inner `if` statement as below can fix the issue, > > if ((gesturesBeganMask & theMask) == 0) { > gesturesBeganMask |= theMask; > [self sendJavaGestureBeginEvent:theEvent] > } This is a good thought, and one I had initially considered, but didn't do for two related reasons: 1. The macOS NSEvent code that sends `beginGestureWithEvent` and `endGestureWithEvent` when the JDK is compiled with an older SDK doesn't send a begin call when starting a rotate gesture if a zoom gesture is already active, or vice versa. One goal of this change is to match the previous behavior to minimize risk. 2. More importantly, the existing logic is not expecting nested `sendJavaGestureBeginEvent` / `sendJavaGestureEndEvent` calls, and will not track the state correctly if they are nested. I did a quick test implementing your suggestion and confirmed that it misbehaves. Worth noting, the logic that synthesizes the begin and end gesture notifications that are sent by the Java gesture code already takes care of the case of switching from zoom to rotate and sends the correct sequence to the event listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/156 From arapte at openjdk.java.net Mon Apr 6 15:02:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 15:02:55 GMT Subject: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events In-Reply-To: References: Message-ID: <9rz1FQY9Jo0QLVHr_K6uQ2S9CZMqyHFIxdCXEgV-7rc=.1beb7dd7-cc05-4ab7-bf7f-0e1e79cf8630@github.com> On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this bug is a result of a deliberate change by Apple that affects applications (in this case > the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two methods that we are relying on, > `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation warning or any other indication at compile > time or runtime that these methods are ineffective. They just stopped calling them. It is documented in their developer > guide: > [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) > Note that it's the version of the MacOSX SDK that the JDK is linked with that matters. JavaFX gesture notification > works when run on a JDK that was linked against the 10.10 SDK or earlier (regardless of what MacOSX SDK was used to > link the JavaFX libraries). JavaFX gesture notification fails when run on a JDK that was linked against the 10.11 SDK > or later. The solution, as indicated in the Apple documentation referred to above, is to use the phase information > from gesture events to track when to call begin / end gesture. The fix does the following things: 1. Removes the > `beginGestureWithEvent` and `endGestureWithEvent` responder methods in `GlassView2D` and `GlassView3D` 2. Calls new > local methods from each gesture to track when to call the associated `GlassViewDelegate` notification methods, > `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this on macOS 10.13.6 and 10.15.3 (Catalina) and > the attached program now runs correctly. I also tested the GestureEvent sample in Ensemble8 and it reproduces the > problem before the fix and works correctly after the fix. I instrumented the code with print statements (which I have > since reverted) and verified that the stream of events is as expected, and matches JDK 8u241 with bundled FX. looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/156 From arapte at openjdk.java.net Mon Apr 6 16:20:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 6 Apr 2020 16:20:45 GMT Subject: RFR: 8241249: NPE in TabPaneSkin.perfromDrag Message-ID: This is a simple fix similar to [JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372). The NPE can occur if a MOUSE_DRAGGED is received by tab header without receiving MOUSE_PRESSED. The fix also corrects a typo error. `perfromDrag()` to `performDrag()` ------------- Commit messages: - 8241249: NPE in TabPaneSkin.perfromDrag Changes: https://git.openjdk.java.net/jfx/pull/160/files Webrev: https://webrevs.openjdk.java.net/jfx/160/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241249 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/160/head:pull/160 PR: https://git.openjdk.java.net/jfx/pull/160 From jskov at zoftcorp.dk Mon Apr 6 17:42:05 2020 From: jskov at zoftcorp.dk (Jesper Skov) Date: Mon, 6 Apr 2020 19:42:05 +0200 Subject: Fixing ToggleGroup synchronization Message-ID: Hi, I happened to fall over this issue: https://bugs.openjdk.java.net/browse/JDK-8198402 while reading another jfx PR. I have a shot at a fix: https://github.com/openjdk/jfx/compare/master...jskov:toggleGroupSync-JDK-8198402 But I was not entirely sure if just submitting a PR without saying hello first was OK? :) The OCA has been sent. Should I await some feedback from oracle-ca_us before I submit the PR? Cheers, Jesper From kevin.rushforth at oracle.com Mon Apr 6 18:42:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 6 Apr 2020 11:42:30 -0700 Subject: Fixing ToggleGroup synchronization In-Reply-To: References: Message-ID: <57514f7c-11c0-9f11-dcc9-71c24de15233@oracle.com> Hi Jesper, Welcome to OpenJFX. Yes, it's a fine idea to say hello, so that 's taken care of. I presume you have read the CONTRIBUTING guidelines (since you sent the OCA you probably have)? [1] Since your OCA has been sent, you can file a PR any time. It won't be marked as ready for review until your OCA is processed, though. When you do file it, choose "/signed" as the option to respond to the automated message. -- Kevin [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md On 4/6/2020 10:42 AM, Jesper Skov wrote: > Hi, > > I happened to fall over this issue: > > https://bugs.openjdk.java.net/browse/JDK-8198402 > > while reading another jfx PR. > > > I have a shot at a fix: > > https://github.com/openjdk/jfx/compare/master...jskov:toggleGroupSync-JDK-8198402 > > But I was not entirely sure if just submitting a PR without saying hello > first was OK? :) > > > The OCA has been sent. Should I await some feedback from oracle-ca_us > before I submit the PR? > > Cheers, > Jesper From kevin.rushforth at oracle.com Mon Apr 6 21:34:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 6 Apr 2020 14:34:03 -0700 Subject: Discussion on adding a new gtk glass backend In-Reply-To: References: Message-ID: Hi Thiago, Nice summary! As I mentioned offline, I am generally supportive of this, since I know how fragile the existing Linux Glass implementation is. Unsurprisingly, this has effectively turned into a rewrite of the Linux GTK glass port. It's going to need a very thorough review, including a security review, and that will take some time. Thank you for adding my offline suggestion of making this new implementation an optional library where the old and new versions of the glass library for Linux can coexist. This will allow making separate decisions about when it is ready to go in versus when it is ready to become the default; this is the only way it even has a chance of getting in for JavaFX 15 (and even then it's not a given). Since this is JavaFX only, the command line option should probably be "javafx.gtk..." rather than "jdk.gtk....", or at least something with "javafx" in the name, but that's a detail that can be worked out later. I have a couple high-level questions: 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? 2. How much of the reliance on GDK were you able to eliminate? I'd like to also hear from Johan and others -- especially other Linux app developers. -- Kevin On 4/4/2020 5:13 PM, Thiago Milczarek Sayao wrote: > Summary > ------- > > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > PR: https://github.com/openjdk/jfx/pull/77 > > Goals > ----- > > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > > Non-Goals > --------- > > * Make Wayland work now. > > > Success Metrics > --------------- > > * Reduced code size (999 lines removed); > * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; > * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; > * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. > > Motivation > ---------- > > While working with OpenJFX on Linux, I have fixed some of it's bugs: > > * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 > * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 > * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 > * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 > * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 > * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 > * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 > * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 > * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 > > While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). > > One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). > > I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). > > > Description > ----------- > > This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. > > * Note: No public API was modified; > > * Specific Code Changes > > * glass_window.cpp / glass_window.h > > - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); > - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; > - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); > - Frame Extents: Removed the code to request extents and gtk already does it by default; > - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. > - Other Size calculation changes: > - Use gtk_window_set_default_size() for initial size which is the appropriate function; > - Gravity is now ignored as it is on Windows glass impl; > - Avoid sending same sizes to Java (duplicated events); > - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); > - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on > apply_geometry(). > - Mouse grab: Reworked it to use to correct functions according to gtk+ version; > - Draw: Reworked it to use the correct calls accord to gtk+ version changes; > - Fixed JDK-8237491; > - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; > - Reorganized function order on glass_window.cpp to match glass_window.h > - Only work-around Unity bug if window manager is Unity > > * GlassCursor.cpp > > - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; > - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; > > * GtkWindow.java > > - Moved the extents special case to native glass; > > * GlassApplication.cpp > > - Removed Gdk events where possible (it's now on glass_window as signals); > - Removed applet/web start code; > > * GlassView.cpp > > - Changes to reflect frame extents rework on glass_window > > * GlassWindow.cpp > > - WindowContextTop -> WindowContext > - Removed applet / web start code; > - Removed frame extents (which is not called anymore due to GtkWindow.java change); > > * glass_general.cpp > > - Removed functions that became unused; > - Added is_grab_disabled() that is used on glass_window > > * glass_window_ime.cpp > > - WindowContextTop -> WindowContext; > > * glass_dnd.cpp / glass_dnd.h > > - Ported to Gtk signals; > - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); > - Allow COMPOUND_TEXT; > - Do not request content while dragging; > - Reduce overall code size. > > > Testing > ------- > > While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. > > Note: Non-robot tests do not apply since the changes are glass specific. > > Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. > > > Risks and Assumptions > --------------------- > > * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; > * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; > * It's a big change - well tested but might still break something. > > Dependencies > ----------- > > * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 > * Maximized undecorated stage behaves inconsistently on different platforms > : https://bugs.openjdk.java.net/browse/JDK-8237491 > From kcr at openjdk.java.net Mon Apr 6 23:23:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:23:30 GMT Subject: RFR: 8242167: ios keyboard handling In-Reply-To: References: Message-ID: <6xxdGVdLnJGbMQKXoggN_A_CkpK7v2_ns6U5dPYavj0=.9223af92-775a-470d-bc03-8c5f5d148524@github.com> On Sun, 5 Apr 2020 14:09:32 GMT, Johan Vos wrote: > Use JavaFX controls for TextField and TextArea instead of the native iOS ones > This fixes JDK-8242167 The new `TextAreaSkinIos` and `TextFieldSkinIos ` classes will become part of the public API for IOS, since they are in the `javafx.scene.control.skin` package. Is this intended, or might they be able to live somewhere under `com.sun.javafx`? ------------- PR: https://git.openjdk.java.net/jfx/pull/158 From kcr at openjdk.java.net Mon Apr 6 23:28:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:28:27 GMT Subject: RFR: 8242163: Android keyboard integration fails In-Reply-To: References: Message-ID: On Sun, 5 Apr 2020 10:19:07 GMT, Johan Vos wrote: > Fix the code that integrates TextField/TextArea with the android keyboard > > Fix for #8242163 Similar question as for the IOS keyboard issue: The newly moved `TextAreaSkinAndroid ` and `TextFieldSkinAndroid` classes will become part of the public API for Android, since they are in the `javafx.scene.control.skin` package. Is this intended, or might they still be able to live somewhere under `com.sun.javafx`? ------------- PR: https://git.openjdk.java.net/jfx/pull/157 From kcr at openjdk.java.net Mon Apr 6 23:39:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:39:12 GMT Subject: RFR: 8241249: NPE in TabPaneSkin.perfromDrag In-Reply-To: References: Message-ID: On Mon, 6 Apr 2020 16:14:41 GMT, Ambarish Rapte wrote: > This is a simple fix similar to [JDK-8237372](https://bugs.openjdk.java.net/browse/JDK-8237372). > The NPE can occur if a MOUSE_DRAGGED is received by tab header without receiving MOUSE_PRESSED. > The fix also corrects a typo error. `perfromDrag()` to `performDrag()` Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/160 From kcr at openjdk.java.net Mon Apr 6 23:43:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:43:40 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) In-Reply-To: References: Message-ID: <1xFGE5fJaMpANiWA_Be0C9uFUwwlhyVgKa_kTk8ksb0=.70f34efe-7c40-4f25-9d2c-88bec0e45f96@github.com> On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 > > Root Cause : > Turned out to be a simpler issue than thought. > Atomicity check was missed while updating toolbar state (which in turn updates styles). > > Fix : > Added the missed atomicity check at two places that handle text selection using keyboard keys. > > Testing : > Added two system test cases. They fail without this fix and pass with it. @guruhb can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/155 From kcr at openjdk.java.net Mon Apr 6 23:57:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Apr 2020 23:57:18 GMT Subject: [Rev 03] RFR: 8236840: Memory leak when switching ButtonSkin In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 12:58:11 GMT, Ambarish Rapte wrote: >> ButtonSkin adds a `ChangeListener` to `Control.sceneProperty()` which results in leaking the `ButtonSkin` itself when >> the `Button`'s skin is changed to a new `ButtonSkin`. Using a `WeakChangeListener` instead of `ChangeListener` solves >> the issue. >> Please take a look. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comment: cleanup the accelerator Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/147 From thiago.sayao at clamed.com.br Tue Apr 7 00:13:00 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 7 Apr 2020 00:13:00 +0000 Subject: Discussion on adding a new gtk glass backend In-Reply-To: References: , Message-ID: Hi Kevin, 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? Yes it works and was tested with gtk2. It has version checks for each API that changed since version 2. One thing that I may have to double-check is if it works with the minimum required gtk2 version. 2. How much of the reliance on GDK were you able to eliminate? It is unlikely to eliminate all of gdk because gtk itself requires gdk structures. I mostly reduced it on Drag and Drop (previously with https://github.com/openjdk/jfx/pull/4 and now with the drag dest part). The thought was "if gtk has it, use gtk". The goal was not to remove gdk but use existing gtk functionality if it fits. One example was to use gtk_widget_set_sensitive to make parent windows "insensitive" when on WINDOW_MODAL instead of custom implementation. Other example is in DND - gtk does the handling, just needed to translate it from glass to gtk. About the flag to enable the implementation, what about "javafx.gtk.experimental=true/false" ? ________________________________ De: openjfx-dev em nome de Kevin Rushforth Enviado: segunda-feira, 6 de abril de 2020 18:34 Para: openjfx-dev at openjdk.java.net Assunto: Re: Discussion on adding a new gtk glass backend Hi Thiago, Nice summary! As I mentioned offline, I am generally supportive of this, since I know how fragile the existing Linux Glass implementation is. Unsurprisingly, this has effectively turned into a rewrite of the Linux GTK glass port. It's going to need a very thorough review, including a security review, and that will take some time. Thank you for adding my offline suggestion of making this new implementation an optional library where the old and new versions of the glass library for Linux can coexist. This will allow making separate decisions about when it is ready to go in versus when it is ready to become the default; this is the only way it even has a chance of getting in for JavaFX 15 (and even then it's not a given). Since this is JavaFX only, the command line option should probably be "javafx.gtk..." rather than "jdk.gtk....", or at least something with "javafx" in the name, but that's a detail that can be worked out later. I have a couple high-level questions: 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? 2. How much of the reliance on GDK were you able to eliminate? I'd like to also hear from Johan and others -- especially other Linux app developers. -- Kevin On 4/4/2020 5:13 PM, Thiago Milczarek Sayao wrote: > Summary > ------- > > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > PR: https://github.com/openjdk/jfx/pull/77 > > Goals > ----- > > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > > Non-Goals > --------- > > * Make Wayland work now. > > > Success Metrics > --------------- > > * Reduced code size (999 lines removed); > * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; > * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; > * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. > > Motivation > ---------- > > While working with OpenJFX on Linux, I have fixed some of it's bugs: > > * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 > * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 > * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 > * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 > * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 > * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 > * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 > * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 > * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 > > While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). > > One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). > > I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). > > > Description > ----------- > > This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. > > * Note: No public API was modified; > > * Specific Code Changes > > * glass_window.cpp / glass_window.h > > - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); > - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; > - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); > - Frame Extents: Removed the code to request extents and gtk already does it by default; > - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. > - Other Size calculation changes: > - Use gtk_window_set_default_size() for initial size which is the appropriate function; > - Gravity is now ignored as it is on Windows glass impl; > - Avoid sending same sizes to Java (duplicated events); > - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); > - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on > apply_geometry(). > - Mouse grab: Reworked it to use to correct functions according to gtk+ version; > - Draw: Reworked it to use the correct calls accord to gtk+ version changes; > - Fixed JDK-8237491; > - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; > - Reorganized function order on glass_window.cpp to match glass_window.h > - Only work-around Unity bug if window manager is Unity > > * GlassCursor.cpp > > - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; > - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; > > * GtkWindow.java > > - Moved the extents special case to native glass; > > * GlassApplication.cpp > > - Removed Gdk events where possible (it's now on glass_window as signals); > - Removed applet/web start code; > > * GlassView.cpp > > - Changes to reflect frame extents rework on glass_window > > * GlassWindow.cpp > > - WindowContextTop -> WindowContext > - Removed applet / web start code; > - Removed frame extents (which is not called anymore due to GtkWindow.java change); > > * glass_general.cpp > > - Removed functions that became unused; > - Added is_grab_disabled() that is used on glass_window > > * glass_window_ime.cpp > > - WindowContextTop -> WindowContext; > > * glass_dnd.cpp / glass_dnd.h > > - Ported to Gtk signals; > - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); > - Allow COMPOUND_TEXT; > - Do not request content while dragging; > - Reduce overall code size. > > > Testing > ------- > > While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. > > Note: Non-robot tests do not apply since the changes are glass specific. > > Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. > > > Risks and Assumptions > --------------------- > > * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; > * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; > * It's a big change - well tested but might still break something. > > Dependencies > ----------- > > * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 > * Maximized undecorated stage behaves inconsistently on different platforms > : https://bugs.openjdk.java.net/browse/JDK-8237491 > From hohonuuli at icloud.com Tue Apr 7 00:36:42 2020 From: hohonuuli at icloud.com (hohonuuli at icloud.com) Date: Mon, 6 Apr 2020 17:36:42 -0700 Subject: Shared buffer in PixelBuffer References: <8ecabcf1-0781-4dbb-9388-0be3653237d7@Spark> Message-ID: Hi All, I just wanted to send a "thank you!" to all the JavaFX devs for your work on JavaFX and most especially, adding shared memory to JavaFX?s PixelBuffer. (https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html) The ?tl;dr? is that I now have a JavaFX-based video player tool, thanks to Caprica Software, that can play a wide variety of video formats well and can be easily modified to support my organization's science requirements. I?ve linked a YouTube video of the video player app, playing a ProRes 422 encoded QuickTime video and communicating with another annotation application. Thanks to the shared buffer the video playback is smoooooooth.?https://youtu.be/FKeuG8-UYC0 Again thanks for your work. Stay well! Brian Schlining Software Engineer P (831) 775-1855 ? F (831) 775-1620 Monterey Bay Aquarium Research Institute 7700 Sandholdt Road, Moss Landing CA 95039 www.mbari.org Advancing marine science and engineering to understand our changing ocean. From ajoseph at openjdk.java.net Tue Apr 7 05:41:09 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 7 Apr 2020 05:41:09 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> <807NKhSRXjlLn18IXMMGrlk72xPhRDvky1Q5t6ctc28=.ee2a0009-ba40-4232-b9ba-0c0fc9e81c46@github.com> Message-ID: On Wed, 12 Feb 2020 20:34:55 GMT, Kevin Rushforth wrote: >> I have indeed let this bug on the side. I would like to investigate but my time is limited these days. Especially that >> my patch is apparently creating another issue. I will try to give it another shot in the upcoming week. But if anyone >> has some ideas or is willing to carry the issue, feel free > > No hurry. I was just going through PRs that hadn't been updated in a while. The second issue regarding selecting texts with multiple fonts will be fixed when https://github.com/openjdk/jfx/pull/155 is merged. ------------- PR: https://git.openjdk.java.net/jfx/pull/12 From aghaisas at openjdk.java.net Tue Apr 7 07:41:48 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 07:41:48 GMT Subject: RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" Message-ID: Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT array key. Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. ------------- Commit messages: - Fix NPE Changes: https://git.openjdk.java.net/jfx/pull/161/files Webrev: https://webrevs.openjdk.java.net/jfx/161/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241710 Stats: 29 lines in 2 files changed: 20 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/161/head:pull/161 PR: https://git.openjdk.java.net/jfx/pull/161 From jvos at openjdk.java.net Tue Apr 7 08:09:30 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Apr 2020 08:09:30 GMT Subject: RFR: 8242167: ios keyboard handling In-Reply-To: <6xxdGVdLnJGbMQKXoggN_A_CkpK7v2_ns6U5dPYavj0=.9223af92-775a-470d-bc03-8c5f5d148524@github.com> References: <6xxdGVdLnJGbMQKXoggN_A_CkpK7v2_ns6U5dPYavj0=.9223af92-775a-470d-bc03-8c5f5d148524@github.com> Message-ID: On Mon, 6 Apr 2020 23:21:17 GMT, Kevin Rushforth wrote: > The new `TextAreaSkinIos` and `TextFieldSkinIos ` classes will become part of the public API for IOS, since they are in > the `javafx.scene.control.skin` package. Is this intended, or might they be able to live somewhere under > `com.sun.javafx`? That is intentional indeed, as libraries may want to change behavior. The Android classes used to be in com.sun.javafx, at the same level as the desktop classes. But the desktop classes (`TextAreaSkin` and `TextFieldSkin`) are moved to `javafx.scene.control.skin` hence it seems logic to move the Android classes to the same level, and the iOS classes as well then. Alternatively, we could completely get rid of the ios/android specific classes, and add the logic to show/hide the keyboard in the desktop classes. But that is much more intrusive, so I think it's safer to keep them separated for now. ------------- PR: https://git.openjdk.java.net/jfx/pull/158 From jvos at openjdk.java.net Tue Apr 7 08:21:09 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Apr 2020 08:21:09 GMT Subject: RFR: 8242163: Android keyboard integration fails In-Reply-To: References: Message-ID: <6gESkzr5u5TiveZFkshIioukCPug1-jC4cxxv_6forw=.1f2959d8-f4c8-4dac-a83e-09fc85572e20@github.com> On Mon, 6 Apr 2020 23:26:12 GMT, Kevin Rushforth wrote: >> Fix the code that integrates TextField/TextArea with the android keyboard >> >> Fix for #8242163 > > Similar question as for the IOS keyboard issue: The newly moved `TextAreaSkinAndroid ` and `TextFieldSkinAndroid` > classes will become part of the public API for Android, since they are in the `javafx.scene.control.skin` package. Is > this intended, or might they still be able to live somewhere under `com.sun.javafx`? Same reason as in the iOS case. The `TextFieldSkinAndroid` was in `com.sun.javafx` at the same level as `TextFieldSkin`. Since `TextFieldSkin` was moved to `javafx`, I moved `TextFieldSkinAndroid` as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/157 From mp at jugs.org Tue Apr 7 08:39:00 2020 From: mp at jugs.org (Michael Paus) Date: Tue, 7 Apr 2020 10:39:00 +0200 Subject: Shared buffer in PixelBuffer In-Reply-To: References: <8ecabcf1-0781-4dbb-9388-0be3653237d7@Spark> Message-ID: <9e20e5b0-fd73-b289-6ba2-0ca1bec1a126@jugs.org> Hi, it is nice to hear that you could make some good use of this work. Michael (mipastgt) Am 07.04.20 um 02:36 schrieb hohonuuli at icloud.com: > Hi All, > > I just wanted to send a "thank you!" to all the JavaFX devs for your work on JavaFX and most especially, adding shared memory to JavaFX?s PixelBuffer. (https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html) > > The ?tl;dr? is that I now have a JavaFX-based video player tool, thanks to Caprica Software, that can play a wide variety of video formats well and can be easily modified to support my organization's science requirements. I?ve linked a YouTube video of the video player app, playing a ProRes 422 encoded QuickTime video and communicating with another annotation application. Thanks to the shared buffer the video playback is smoooooooth.?https://youtu.be/FKeuG8-UYC0 > > Again thanks for your work. Stay well! > > Brian Schlining > Software Engineer > P (831) 775-1855 ? F (831) 775-1620 > > > Monterey Bay Aquarium Research Institute > 7700 Sandholdt Road, Moss Landing CA 95039 > www.mbari.org > Advancing marine science and engineering to understand our changing ocean. From arapte at openjdk.java.net Tue Apr 7 10:27:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Apr 2020 10:27:09 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Mon, 30 Mar 2020 13:37:51 GMT, Florian Kirmaier wrote: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Suggested some changes and query. I still need to verify the fix in detail. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77: > 76: Platform.runLater(() -> stage.close()); > 77: } > 78: Looks like the primary `stage` is not required for actual test, and this block is only used to initialize JavaFX runtime. Please check if it can be replaced by below block ``` @BeforeClass public static void initFX() throws Exception { startupLatch = new CountDownLatch(1); Platform.startup(startupLatch::countDown); Assert.assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.MILLISECONDS)); } tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 133: > 132: > 133: Assert.assertNull(weakReference.get()); > 134: } This assert check call should be added to the @Test method. I would recommend to refer [this method](https://github.com/openjdk/jfx/blob/364c64a2e55b561df4ca1afc85c91054b339eea8/modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java#L1998) from ListViewTest. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 113: > 112: }); > 113: > 114: Assert.assertTrue("Timeout, waiting for runLater. ", leakLatch.await(15, TimeUnit.SECONDS)); Is it really required to nest the `Platform.runLater()` calls ? Can you please check if this code can be simplified by making the calls sequential, Consider using `Util.runAndWait()` tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 84: > 83: counter += 1; > 84: testLeakOnce(); > 85: } If the test has constant behavior on every run, then only one run should be done. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 354: > 353: } > 354: if(Window.focusedWindow == this) { > 355: Window.focusedWindow = null; Please correct format by adding space after `if`. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53: > 52: System.setProperty("monocle.platform","Headless"); > 53: } > 54: The test will always run with Monocle. I see that if this static block is removed then the test fails on Windows 10. Can you please verify all the platforms and change the test such that it runs on all platforms/ combinations. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/153 From fastegal at openjdk.java.net Tue Apr 7 10:30:08 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 7 Apr 2020 10:30:08 GMT Subject: RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 07:36:00 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 > > Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. > > Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. Verified the fix: test is failing before and passing after. See one inline comment (just noting my personal pref :). And again me fighting the system (can't seem to review code parts that are not near a change, so doing here: - copyright year doesn't seem to be updated - there's another fishy looking code line in MenuItemContainer actionHandler: actionEventHandler = e -> { if (item instanceof Menu) { final Menu menu = (Menu) item; if (openSubmenu == menu && submenu.isShowing()) return; don't know when/if that's ever reached (could get there - an action handler on the region itself?), anyway, at other places with a similar pattern (f.i processRightKey) there's an explicit guard against a null submenu, don't know if the latter is over-caution - logic and code is rather .. well .. inter-twined ;) modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ContextMenuContent.java line 658: > 657: ContextMenuContent cmContent = (ContextMenuContent)submenu.getSkin().getNode(); > 658: if (cmContent != null) { > 659: if (cmContent.itemsContainer.getChildren().size() > 0) { just a mini-note: personally, I prefer early-return on no-match (vs. wrapping nearly the whole method inside an if match if (submenu == null) return; ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From lior.yaffe at jelurida.com Tue Apr 7 11:14:39 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Tue, 7 Apr 2020 14:14:39 +0300 Subject: Support "trust all" SSL context in OpenJFX 14 Message-ID: Some background information on why we are facing the issue. The internal implementation of WebView changed in OpenJFX 14 to use HttpClient instead of Http(s)URLConnection. Therefore, it is no longer possible to use the following methods to set a custom SSL context before instantiation of a HttpsURLConnection object: HttpsURLConnection#setDefaultSSLSocketFactory HttpsURLConnection#setDefaultHostnameVerifier The only way to set a custom SSLContext to a HttpClient is to use the method HttpClientBuilder#sslContext unfortunately this method is not accessible for the Webview code. Since there is no static method on the HttpClient to set a custom SSLContext, we hereby request to introduce a public method on WebView (or WebEngine) for the purpose of passing a custom SSL context. Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From webczat_200 at poczta.onet.pl Tue Apr 7 11:28:16 2020 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Tue, 7 Apr 2020 13:28:16 +0200 Subject: Support "trust all" SSL context in OpenJFX 14 In-Reply-To: References: Message-ID: What about global SSLContext.setDefault()? maybe it doesn't apply of course. W dniu 07.04.2020 o?13:14, Lior Yaffe pisze: > Some background information on why we are facing the issue. > The internal implementation of WebView changed in OpenJFX 14 to use > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer > possible to use the following methods to set a custom SSL context before > instantiation of a HttpsURLConnection object: > > HttpsURLConnection#setDefaultSSLSocketFactory > HttpsURLConnection#setDefaultHostnameVerifier > > The only way to set a custom SSLContext to a HttpClient is to use the > method HttpClientBuilder#sslContext unfortunately this method is not > accessible for the Webview code. > > Since there is no static method on the HttpClient to set a custom > SSLContext, we hereby request to introduce a public method on WebView (or > WebEngine) for the purpose of passing a custom SSL context. > > > Virus-free. > www.avg.com > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > From aghaisas at openjdk.java.net Tue Apr 7 11:40:20 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 11:40:20 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: <_r51eqAgNcgCLGJg-Lmzza7lNvSFDVniddpZruEx8l8=.123306bc-cb83-42c3-9303-aa0d4e2bbf52@github.com> On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 >> >> Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. >> >> Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Minor review fixes > Verified the fix: test is failing before and passing after. Thanks for the quick test. > See one inline comment (just noting my personal pref :). > > And again me fighting the system (can't seem to review code parts that are not near a change, so doing here: Well, you are part of the system :) > * copyright year doesn't seem to be updated I have updated this now. > * there's another fishy looking code line in MenuItemContainer actionHandler: > ``` > actionEventHandler = e -> { > if (item instanceof Menu) { > final Menu menu = (Menu) item; > if (openSubmenu == menu && submenu.isShowing()) return; > ``` > > > don't know when/if that's ever reached (could get there - an action handler on the region itself?), anyway, at other > places with a similar pattern (f.i processRightKey) there's an explicit guard against a null submenu, don't know if the > latter is over-caution - logic and code is rather .. well .. inter-twined ;) Yes. This code does not seem to be ideal, but, it has evolved and a lot of fixes have gone in. So rewriting is ruled out. ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From aghaisas at openjdk.java.net Tue Apr 7 11:40:09 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 11:40:09 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: > Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 > > Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. > > Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Minor review fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/161/files - new: https://git.openjdk.java.net/jfx/pull/161/files/dbb56031..aecc69c3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/161/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/161/webrev.00-01 Stats: 15 lines in 2 files changed: 1 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/161/head:pull/161 PR: https://git.openjdk.java.net/jfx/pull/161 From aghaisas at openjdk.java.net Tue Apr 7 11:40:21 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 7 Apr 2020 11:40:21 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: <4bvZiyumGdQMDYTJ4KCVYewj-Z1mU0tAY4AkwkxjXTw=.a1f4b412-36e8-4c7c-82ef-d7641f2ced44@github.com> On Tue, 7 Apr 2020 10:13:39 GMT, Jeanette Winzenburg wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor review fixes > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ContextMenuContent.java line 658: > >> 657: ContextMenuContent cmContent = (ContextMenuContent)submenu.getSkin().getNode(); >> 658: if (cmContent != null) { >> 659: if (cmContent.itemsContainer.getChildren().size() > 0) { > > just a mini-note: personally, I prefer early-return on no-match (vs. wrapping nearly the whole method inside an if match > > if (submenu == null) return; I prefer a single point of return for small methods. Anyway, this file has lot of early returns. Hence, I am modifying as per your suggestion. ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From fastegal at openjdk.java.net Tue Apr 7 11:42:46 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 7 Apr 2020 11:42:46 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 >> >> Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. >> >> Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Minor review fixes okay, thanks for the quicks changes :) ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/161 From kcr at openjdk.java.net Tue Apr 7 12:12:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 12:12:43 GMT Subject: RFR: 8242163: Android keyboard integration fails In-Reply-To: References: Message-ID: On Sun, 5 Apr 2020 10:19:07 GMT, Johan Vos wrote: > Fix the code that integrates TextField/TextArea with the android keyboard > > Fix for #8242163 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/157 From kcr at openjdk.java.net Tue Apr 7 12:12:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 12:12:33 GMT Subject: RFR: 8242167: ios keyboard handling In-Reply-To: References: Message-ID: On Sun, 5 Apr 2020 14:09:32 GMT, Johan Vos wrote: > Use JavaFX controls for TextField and TextArea instead of the native iOS ones > This fixes JDK-8242167 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/158 From kevin.rushforth at oracle.com Tue Apr 7 12:16:40 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Apr 2020 05:16:40 -0700 Subject: Shared buffer in PixelBuffer In-Reply-To: <9e20e5b0-fd73-b289-6ba2-0ca1bec1a126@jugs.org> References: <8ecabcf1-0781-4dbb-9388-0be3653237d7@Spark> <9e20e5b0-fd73-b289-6ba2-0ca1bec1a126@jugs.org> Message-ID: Thanks for sharing. -- Kevin On 4/7/2020 1:39 AM, Michael Paus wrote: > Hi, > it is nice to hear that you could make some good use of this work. > Michael > (mipastgt) > > > Am 07.04.20 um 02:36 schrieb hohonuuli at icloud.com: >> Hi All, >> >> I just wanted to send a "thank you!" to all the JavaFX devs for your >> work on JavaFX and most especially, adding shared memory to JavaFX?s >> PixelBuffer. >> (https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html) >> >> The ?tl;dr? is that I now have a JavaFX-based video player tool, >> thanks to Caprica Software, that can play a wide variety of video >> formats well and can be easily modified to support my organization's >> science requirements. I?ve linked a YouTube video of the video player >> app, playing a ProRes 422 encoded QuickTime video and communicating >> with another annotation application. Thanks to the shared buffer the >> video playback is smoooooooth.?https://youtu.be/FKeuG8-UYC0 >> >> Again thanks for your work. Stay well! >> >> Brian Schlining >> Software Engineer >> P (831) 775-1855 ? F (831) 775-1620 >> >> >> Monterey Bay Aquarium Research Institute >> 7700 Sandholdt Road, Moss Landing CA 95039 >> www.mbari.org >> Advancing marine science and engineering to understand our changing >> ocean. > > From lior.yaffe at jelurida.com Tue Apr 7 13:30:08 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Tue, 7 Apr 2020 16:30:08 +0300 Subject: Support "trust all" SSL context in OpenJFX 14 In-Reply-To: References: Message-ID: I'm not sure why but it doesn't work. The only workaround I found is: System.setProperty("com.sun.webkit.useHTTP2Loader", "false"); // Workaround to support test certificate with OpenJFX 14 Webview Then use the old code which works in OpenJFX 13 and earlier. HttpsURLConnection.setDefaultSSLSocketFactory(TrustAllSSLProvider.getSslSocketFactory()); HttpsURLConnection.setDefaultHostnameVerifier(TrustAllSSLProvider.getHostNameVerifier()); On Tue, Apr 7, 2020 at 2:28 PM Micha? Zegan wrote: > What about global SSLContext.setDefault()? maybe it doesn't apply of > course. > > W dniu 07.04.2020 o 13:14, Lior Yaffe pisze: > > Some background information on why we are facing the issue. > > The internal implementation of WebView changed in OpenJFX 14 to use > > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer > > possible to use the following methods to set a custom SSL context before > > instantiation of a HttpsURLConnection object: > > > > HttpsURLConnection#setDefaultSSLSocketFactory > > HttpsURLConnection#setDefaultHostnameVerifier > > > > The only way to set a custom SSLContext to a HttpClient is to use the > > method HttpClientBuilder#sslContext unfortunately this method is not > > accessible for the Webview code. > > > > Since there is no static method on the HttpClient to set a custom > > SSLContext, we hereby request to introduce a public method on WebView (or > > WebEngine) for the purpose of passing a custom SSL context. > > > > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > Virus-free. > > www.avg.com > > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > From kcr at openjdk.java.net Tue Apr 7 14:01:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 14:01:04 GMT Subject: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class Message-ID: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> This is a simple fix to remove some obsolete code. As noted in the JBS description, GlassView2D was made obsolete back in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is dead code, as there are no references to that class. ------------- Commit messages: - 8242106: [macos] Remove obsolete GlassView2D.m class Changes: https://git.openjdk.java.net/jfx/pull/162/files Webrev: https://webrevs.openjdk.java.net/jfx/162/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242106 Stats: 460 lines in 3 files changed: 0 ins; 460 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/162.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/162/head:pull/162 PR: https://git.openjdk.java.net/jfx/pull/162 From kcr at openjdk.java.net Tue Apr 7 14:01:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 14:01:05 GMT Subject: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class In-Reply-To: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> References: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> Message-ID: On Tue, 7 Apr 2020 13:54:43 GMT, Kevin Rushforth wrote: > This is a simple fix to remove some obsolete code. As noted in the JBS description, GlassView2D was made obsolete back > in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is dead code, as there are no references to > that class. @arapte can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/162 From ajoseph at openjdk.java.net Tue Apr 7 14:15:26 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 7 Apr 2020 14:15:26 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) In-Reply-To: References: Message-ID: On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 > > Root Cause : > Turned out to be a simpler issue than thought. > Atomicity check was missed while updating toolbar state (which in turn updates styles). > > Fix : > Added the missed atomicity check at two places that handle text selection using keyboard keys. > > Testing : > Added two system test cases. They fail without this fix and pass with it. Marked as reviewed by ajoseph (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/155 From kcr at openjdk.java.net Tue Apr 7 20:31:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 20:31:11 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode In-Reply-To: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> References: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> Message-ID: On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph wrote: > CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native > threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() > function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native > threads for x86 to 1 MB. @guruhb please also review this. ------------- PR: https://git.openjdk.java.net/jfx/pull/159 From kcr at openjdk.java.net Tue Apr 7 21:16:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 21:16:15 GMT Subject: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A) In-Reply-To: References: Message-ID: <1T7UNspBPJ0EjXROKBBCtlWJZb_BeILL4J197lSSO7g=.79c463eb-26aa-4322-8e5c-4d649e8c82c5@github.com> On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8230809 > > Root Cause : > Turned out to be a simpler issue than thought. > Atomicity check was missed while updating toolbar state (which in turn updates styles). > > Fix : > Added the missed atomicity check at two places that handle text selection using keyboard keys. > > Testing : > Added two system test cases. They fail without this fix and pass with it. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/155 From kcr at openjdk.java.net Tue Apr 7 21:45:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 21:45:53 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode In-Reply-To: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> References: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> Message-ID: On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph wrote: > CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native > threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() > function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native > threads for x86 to 1 MB. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/159 From tsayao at openjdk.java.net Tue Apr 7 22:37:14 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 7 Apr 2020 22:37:14 GMT Subject: [Rev 48] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Restore comment position - Restore deleted idea file ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/2f83ce7b..d18b5be4 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.48 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.47-48 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Tue Apr 7 22:58:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 22:58:56 GMT Subject: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right" In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710 >> >> Root Cause : A menu can have empty submenu. This was not checked while processing RIGHT arrow key. >> >> Fix : Added the null check for submenu. Added a unit test case which fails without fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Minor review fixes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/161 From kcr at openjdk.java.net Tue Apr 7 23:05:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 23:05:42 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Thu, 2 Apr 2020 12:59:11 GMT, Nir Lisker wrote: >> I have added few comments, but have not run tests and sample yet. > > @arapte Can you please test the performance changes too? I think @arapte has a similar MacBookPro model to mine. I think @prrace might be able to test it (I'll sync with him offline). ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Tue Apr 7 23:18:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Apr 2020 23:18:17 GMT Subject: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: <2c5f1R0WcHlKzFyQKLflFMwWOZK9Ks5aVBtqCxiCtgw=.c5ed7209-28f0-44ce-9755-7595dd62cb18@github.com> On Tue, 31 Mar 2020 20:45:44 GMT, Thiago Milczarek Sayao wrote: >> I took a look yesterday and came to the same conclusion that what we really want are separate C and C++ flags. For now, >> the only difference would be the presence or absence of `-Werror=implicit-function-declaration`, but it would allow for >> other differences in the future if needed. > > Please, let me know if this is the desired way to do it. If not, I will rework it. Thanks. This is roughly what I had in mind. I want to test it, and also take a look at the WebKit and media builds as well. WebKit uses the flags from `linux.gradle`, and is mostly C++, so I think it needs no changes. Media does not use any flags from `linux.gradle` -- only the jfxmedia project has C++ files on Linux. I guess it should be fine, too, but I'll see. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From almatvee at openjdk.java.net Tue Apr 7 23:49:22 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 7 Apr 2020 23:49:22 GMT Subject: RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina Message-ID: https://bugs.openjdk.java.net/browse/JDK-8240694 - Original fix JDK-8236832 was reverted. - Timestamp will be queried on event loop thread when spectrum event is received by event loop. - FIx only enabled for macOS when using OSXPlatform. ------------- Commit messages: - 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina Changes: https://git.openjdk.java.net/jfx/pull/163/files Webrev: https://webrevs.openjdk.java.net/jfx/163/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240694 Stats: 62 lines in 11 files changed: 29 ins; 13 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163 PR: https://git.openjdk.java.net/jfx/pull/163 From arapte at openjdk.java.net Wed Apr 8 04:23:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 8 Apr 2020 04:23:31 GMT Subject: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class In-Reply-To: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> References: <9ODZXPo3TDbCHKmBvGhTrC5t4IqDWTKWJfmHgWc5Kjg=.72b584b2-4cdf-4586-b9d4-24db118a8aca@github.com> Message-ID: On Tue, 7 Apr 2020 13:54:43 GMT, Kevin Rushforth wrote: > This is a simple fix to remove some obsolete code. As noted in the JBS description, GlassView2D was made obsolete back > in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is dead code, as there are no references to > that class. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/162 From ajoseph at openjdk.java.net Wed Apr 8 07:35:48 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 8 Apr 2020 07:35:48 GMT Subject: RFR: 8223298: SVG patterns are drawn wrong Message-ID: Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. Fix: Override scale() method in WCBufferedContext class to call init() before scaling. ------------- Commit messages: - 8223298: SVG patterns are drawn wrong Changes: https://git.openjdk.java.net/jfx/pull/164/files Webrev: https://webrevs.openjdk.java.net/jfx/164/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223298 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164 PR: https://git.openjdk.java.net/jfx/pull/164 From jpereda at openjdk.java.net Wed Apr 8 08:43:34 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 8 Apr 2020 08:43:34 GMT Subject: RFR: 8240264: Comment out verbose logging Message-ID: This PR comments out too verbose console logging, as it has been done with some other fprintf calls. As a follow up of this PR, a custom directive that enables this output if needed can be considered. ------------- Commit messages: - Comment out verbose logging Changes: https://git.openjdk.java.net/jfx/pull/165/files Webrev: https://webrevs.openjdk.java.net/jfx/165/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240264 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/165/head:pull/165 PR: https://git.openjdk.java.net/jfx/pull/165 From ajoseph at openjdk.java.net Wed Apr 8 11:55:03 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 8 Apr 2020 11:55:03 GMT Subject: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: > Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java > side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. > Fix: Override scale() method in WCBufferedContext class to call init() before scaling. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/164/files - new: https://git.openjdk.java.net/jfx/pull/164/files/ea66bca2..fb1c3934 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/164/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/164/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164 PR: https://git.openjdk.java.net/jfx/pull/164 From kcr at openjdk.java.net Wed Apr 8 12:44:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 12:44:14 GMT Subject: RFR: 8240264: Comment out verbose logging In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 08:37:27 GMT, Jose Pereda wrote: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. @jperedadnr Please change the title of this PR to exactly match the title of the JBS bug. So: 8240264: iOS: Unnecessary logging on every pulse when GL context changes ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From nlisker at gmail.com Wed Apr 8 16:02:29 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Apr 2020 19:02:29 +0300 Subject: JavaFX Swipe Events Glitch On Mobile In-Reply-To: References: Message-ID: Is this a bug caused by JavaFX or Gluon? On Fri, Mar 20, 2020 at 9:24 PM Debayan Sutradhar < debayansutradhar3 at gmail.com> wrote: > Swipe Events like swipeup and swipedown don't get registered and their > related set methods don't get called. OnTouch works rarely. > > JavaFX Version : 14 > Gluon Client Plugin : 0.0.18 > > Regards, > Debayan > From powers.anirvan at gmail.com Wed Apr 8 16:10:31 2020 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Thu, 9 Apr 2020 01:10:31 +0900 Subject: Support "trust all" SSL context in OpenJFX 14 In-Reply-To: References: Message-ID: Maybe it doesn't work due to JDK-8239595. It seems that HttpClient implementation does not use the default SSL context for its configuration [1]. There is an RFR mail to fix this [2][3]. [1] : https://bugs.openjdk.java.net/browse/JDK-8239595 [2] : https://mail.openjdk.java.net/pipermail/net-dev/2020-March/013705.html [3] : https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013785.html On Tue, 7 Apr 2020 at 22:33, Lior Yaffe wrote: > I'm not sure why but it doesn't work. > > The only workaround I found is: > System.setProperty("com.sun.webkit.useHTTP2Loader", "false"); // Workaround > to support test certificate with OpenJFX 14 Webview > > Then use the old code which works in OpenJFX 13 and earlier. > > HttpsURLConnection.setDefaultSSLSocketFactory(TrustAllSSLProvider.getSslSocketFactory()); > > HttpsURLConnection.setDefaultHostnameVerifier(TrustAllSSLProvider.getHostNameVerifier()); > > On Tue, Apr 7, 2020 at 2:28 PM Micha? Zegan > wrote: > > > What about global SSLContext.setDefault()? maybe it doesn't apply of > > course. > > > > W dniu 07.04.2020 o 13:14, Lior Yaffe pisze: > > > Some background information on why we are facing the issue. > > > The internal implementation of WebView changed in OpenJFX 14 to use > > > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer > > > possible to use the following methods to set a custom SSL context > before > > > instantiation of a HttpsURLConnection object: > > > > > > HttpsURLConnection#setDefaultSSLSocketFactory > > > HttpsURLConnection#setDefaultHostnameVerifier > > > > > > The only way to set a custom SSLContext to a HttpClient is to use the > > > method HttpClientBuilder#sslContext unfortunately this method is not > > > accessible for the Webview code. > > > > > > Since there is no static method on the HttpClient to set a custom > > > SSLContext, we hereby request to introduce a public method on WebView > (or > > > WebEngine) for the purpose of passing a custom SSL context. > > > > > > < > > > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > Virus-free. > > > www.avg.com > > > < > > > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > > -- Anirvan From nlisker at gmail.com Wed Apr 8 16:16:14 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 8 Apr 2020 19:16:14 +0300 Subject: Monocle as a replacement In-Reply-To: References: Message-ID: I added a note about removing Dprism.order=sw. On Wed, Mar 25, 2020 at 7:27 PM Tres Finocchiaro wrote: > With the help from a paid fx support channel, we're making headway with > this. The main help was disabling the recommended software option. At > time of writing this, I recommend this warning/detail is added to the wiki: > https://wiki.openjdk.java.net/display/OpenJFX/Monocle > > Quoting: > > > > *If you are running the desktop build of JavaFX or OpenJFX then your only > > monocle option is Headless. Desktop JavaFX does not support the > > javafx.platform system property, but you can select Monocle > > with:-Dglass.platform=Monocle -Dmonocle.platform=Headless > -Dprism.order=sw* > > > In or case, removing "*-Dprism.order=sw"* was critical to prevent crashes > on MacOS and Windows. We've yet to test on Linux. > > Last, since Monocle introduces a virtual desktop size (and we're using this > desktop for screen captures), we'll be tweaking the > "*-Dheadless.geometry=*" > parameter depending on available heap size. These details are best tracked > downstream for those interested https://github.com/qzind/tray/pull/586. > > Unless there are immediate questions, this will be the last update I > provide to the mailing list, all further updates will be specific to the > downstream implementation. > > As an aside, we may decide to sponsor the fixing of the underlying crashes > as well (for example, d2d may not be available on Windows 2016 Core?) but > at the time of writing this, we're adopting workarounds to make it viable > on a standard Desktop. > > - Tres.Finocchiaro at gmail.com > > > On Fri, Feb 21, 2020 at 5:13 PM Tres Finocchiaro < > tres.finocchiaro at gmail.com> > wrote: > > > Danny, > > > > Thanks this information is very valuable. > > > > By using the provided patch, I too am able to re-use the Monocle > framework > > without suffering this bug. > > > > For those visiting this thread (e.g. through archive) at a later time, > > it's being tracked downstream here: > > https://github.com/qzind/tray/issues/576 > > > > So applying it I was able to discover I was running into two separate > > issues... > > > > - The first was the unpredictable buffer behavior you've shared, which > > seems to be resolved that problem. I used the recommended code, just > in a > > copy of the JavaFX 11 class instead. Thanks! > > > > - The second is a nuance of reusing the WebView and Stage using > > Monocle, the stage/webview height calculation starts to grow out of > control > > (watching the DOM height -- we calculate the natural height and then > use > > that for snapshot). In my case it was growing 300, 900, 2900, 8600 > > eventually crashing somewhere in buffer allocation. Hard-coding the > sizing > > didn't suffer the same fate because it bypasses our attempts to > calculate > > the height using JavaScript. Oddly, creating a fresh WebView each > time > > didn't correct the issue either. I believe the underlying issue stems > > somewhere from the stage height never resetting back, but attempts to > do so > > manually cause other issues, so I'll see if there's a viable > workaround by > > doing more renders using Monocle. > > > > We already have an open item with Gluon regarding WebView stage sizing, > so > > this may be a race condition rearing its ugly head through a different > > symptom. We'll continue to work on it separately. > > > > Danny, thanks again for the link to the patch. We'll continue our > testing. > > > > - Tres.Finocchiaro at gmail.com > > > > > > On Wed, Feb 19, 2020 at 2:46 AM Danny Gonzalez < > > danny.gonzalez at screamingfrog.co.uk> wrote: > > > >> Hi Tres, > >> > >> We also are suffering from this crash when running our TestFX unit > tests, > >> particularly on Java 11. > >> It is due to a concurrency issue between the JavaFX thread and the > >> QuantumRenderer thread and there is an OpenJDK bug here: > >> https://bugs.openjdk.java.net/browse/JDK-8201567 > >> > >> Quoting from this bug report: > >> ?The QuantumRenderer calls the getPixels() method while trying to find a > >> buffer that's not in use, yet in doing so it can inadvertently modify a > >> buffer that's in use." > >> > >> There is also a related TestFX Bug: > >> https://github.com/TestFX/Monocle/issues/56 > >> > >> There is a fix for this issue In the first comment of the JDK-8201567, > in > >> a link to GitLab: https://gitlab.com/openjfxepd/jfxpatch/commit/ > >> < > https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258e790a049f3fdce4a956ef665c7 > > > >> > >> We have used this patch in our local OpenJFX build. > >> > >> This has never been made into a pull request however but I believe it > >> should. > >> > >> Danny > >> > >> On 17 Feb 2020, at 19:12, Tres Finocchiaro > >> wrote: > >> > >> Hi, > >> > >> I'm the developer of a printing plugin which leverages JavaFX for a few > >> HTML functions. > >> > >> One of our functions would greatly benefit from being "headless (or more > >> accurately, "silent") mode that Monocle offers and I'm evaluating the > use > >> of Monocle on (non-headless) Desktops for this. I'm currently testing a > >> monocle build by the TestFX team for MacOS. > >> > >> Although first test was positive, when invoking multiple times, I'm > >> getting > >> some internal errors similar to this: > >> https://stackoverflow.com/questions/49388497 and the framework grows > >> slower > >> and slower as it nears its final capture. (I'm using > WebView.capture(...)) > >> > >> Is this the right place for such as discussion? Where's the best place > to > >> ask about issues with Monocle? > >> > >> > >> - Tres.Finocchiaro at gmail.com > >> > >> > >> > From kcr at openjdk.java.net Wed Apr 8 18:37:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 18:37:11 GMT Subject: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04) In-Reply-To: References: Message-ID: On Sun, 29 Mar 2020 00:38:20 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to remove annoying warnings. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Sep cppFlags and cFlags The build changes in `linux.gradle` look good. I tested it, and all warnings are gone (including those in WebKit) except for the ones in the jfxmedia sub-project of javafx.media. Two comments: 1. I changed the bug title in JBS to refer to gcc 9 rather than Ubuntu to reflect the actual cause of the additional warnings. Can you update the title of this PR to match? 8241476: Linux build warnings issued on gcc 9 2. Can you add the following change to your PR as well? This will fix the remaining warnings in jfxmedia: --- a/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile +++ b/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile @@ -41,7 +41,6 @@ ifdef HOST_COMPILE -Wextra \ -Wformat-security \ -fstack-protector \ - -Werror=implicit-function-declaration \ -Werror=trampolines \ -msse2 \ -DGSTREAMER_LITE ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From kcr at openjdk.java.net Wed Apr 8 21:28:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 21:28:53 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> On Wed, 8 Apr 2020 08:37:27 GMT, Jose Pereda wrote: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From kcr at openjdk.java.net Wed Apr 8 22:54:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Apr 2020 22:54:43 GMT Subject: RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 23:44:17 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is received by event loop. > - FIx only enabled for macOS when using OSXPlatform. Can you add a root cause / evaluation either in JBS or to this PR? I also noted a few places where it might be helpful to add a comment in the code, so anyone looking at it later will know why you are querying the timestamp later from the event thread. I'll finish my testing in parallel with your addressing those comments and adding the evaluation. modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaPlayer.java line 722: > 721: if (listener != null) { > 722: if (evt.queryTimestamp()) { > 723: double timestamp = playerGetPresentationTime(); A short (one-line) comment would be useful here. modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.cpp line 194: > 193: double duration = (double) mSamplesPerInterval / (double) 44100; > 194: // Timestamp is ignored and it will be queried from event loop > 195: mSpectrumCallbackProc(mSpectrumCallbackContext, duration, -1.0); You might also note that the reason it is ignored is because it will deadlock if you read it from the media thread. modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 656: > 655: if (eventHandler) { > 656: // Always true for queryTimestamp do to JDK-8240694 > 657: eventHandler->SendAudioSpectrumEvent(timestamp, duration, true); that should be "due" to... you might also mention that we need to query on the event thread to avoid a deadlock. ------------- PR: https://git.openjdk.java.net/jfx/pull/163 From almatvee at openjdk.java.net Thu Apr 9 01:45:27 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Apr 2020 01:45:27 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is received by event loop. > - FIx only enabled for macOS when using OSXPlatform. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8240694: Improved comments per reviewers request ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/163/files - new: https://git.openjdk.java.net/jfx/pull/163/files/b43ace5c..0ea46c79 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/163/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/163/webrev.00-01 Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163 PR: https://git.openjdk.java.net/jfx/pull/163 From almatvee at openjdk.java.net Thu Apr 9 01:45:28 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Apr 2020 01:45:28 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 22:52:27 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8240694: Improved comments per reviewers request > > Can you add a root cause / evaluation either in JBS or to this PR? > > I also noted a few places where it might be helpful to add a comment in the code, so anyone looking at it later will > know why you are querying the timestamp later from the event thread. > I'll finish my testing in parallel with your addressing those comments and adding the evaluation. I updated comments in code and added a root cause / evaluation to JBS. ------------- PR: https://git.openjdk.java.net/jfx/pull/163 From github.com+636962+ccavanaugh at openjdk.java.net Thu Apr 9 09:37:50 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Thu, 9 Apr 2020 09:37:50 GMT Subject: [Rev 02] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Craig Cavanaugh has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. This pull request has been closed without being integrated. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/136/files - new: https://git.openjdk.java.net/jfx/pull/136/files/229a7fd2..159f6516 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/136/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/136/webrev.01-02 Stats: 51 lines in 2 files changed: 0 ins; 49 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/136/head:pull/136 PR: https://git.openjdk.java.net/jfx/pull/136 From kevin.rushforth at oracle.com Thu Apr 9 14:07:37 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 9 Apr 2020 07:07:37 -0700 Subject: Result: New OpenJFX Committer: Arun Joseph Message-ID: Voting for Arun Joseph [1] to to OpenJFX Committer [2] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#ajoseph [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-March/025542.html From kcr at openjdk.java.net Thu Apr 9 16:59:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Apr 2020 16:59:40 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 01:45:27 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8240694 >> >> - Original fix JDK-8236832 was reverted. >> - Timestamp will be queried on event loop thread when spectrum event is received by event loop. >> - FIx only enabled for macOS when using OSXPlatform. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8240694: Improved comments per reviewers request Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/163 From ghb at openjdk.java.net Thu Apr 9 17:22:38 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 9 Apr 2020 17:22:38 GMT Subject: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 01:45:27 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8240694 >> >> - Original fix JDK-8236832 was reverted. >> - Timestamp will be queried on event loop thread when spectrum event is received by event loop. >> - FIx only enabled for macOS when using OSXPlatform. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8240694: Improved comments per reviewers request Looks good to me, Tested on MacOS 10.12.6 (Sierra) with the use case provided in JBS). ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/163 From almatvee at openjdk.java.net Thu Apr 9 21:19:47 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 9 Apr 2020 21:19:47 GMT Subject: [Closed] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 23:44:17 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is received by event loop. > - FIx only enabled for macOS when using OSXPlatform. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/163 From nlisker at openjdk.java.net Fri Apr 10 06:39:40 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 10 Apr 2020 06:39:40 GMT Subject: RFR: 8241582: Infinite animation does not start from the end when started with a negative rate Message-ID: ### Cause `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly. This causes `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start the animation not from the end, depending on the modulo calculation. ### Fix For infinite cycles, use the `cycleDuration` as the destination since that is the effective end point. ### Tests * Added an `testJumpTo_IndefiniteCycles` test that fails without the patch and passes after it. * Added a `testJumpTo_IndefiniteCycleDuration` that passes both before and after, just to make sure that this type of infinite duration is correct. * Removed a test in `SequentialTransition` that fails with this patch, but it passed before it only because the modulo value happened to land in the right place. Changing the duration of one of the child animation can cause it to fail, so the test is faulty anyway at this stage. ### Future work Playing backwards will still not work correctly, but at least now it start from the correct value. This is the first of a series of fixes under the umbrella issue [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238). ------------- Commit messages: - Comment out erroneous test - Fix IndefiniteCycleDuration test - Fixed single loop test - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/169/files Webrev: https://webrevs.openjdk.java.net/jfx/169/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241582 Stats: 28 lines in 3 files changed: 19 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/169/head:pull/169 PR: https://git.openjdk.java.net/jfx/pull/169 From ghb at openjdk.java.net Fri Apr 10 16:08:45 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 10 Apr 2020 16:08:45 GMT Subject: RFR: 8242209: Increase web native thread stack size for x86 mode In-Reply-To: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> References: <1v6w7uwopRbEisF2Nqq26QvIGrqA8DTirYo5ggBez80=.842fcc42-0903-41c6-8baa-70fc1a82111c@github.com> Message-ID: On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph wrote: > CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time CLoop::execute() is called. For web native > threads which has a default stack size of 320 KB, a Stack Overflow Error is raised just after two calls to execute() > function. While 64-bit windows has a default stack size of 1 MB. Fix: Increase the thread stack size of web native > threads for x86 to 1 MB. Looks good to me, Tested on Windows with test case added in JBS. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/159 From ghb at openjdk.java.net Fri Apr 10 16:32:08 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 10 Apr 2020 16:32:08 GMT Subject: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> On Wed, 8 Apr 2020 11:55:03 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java >> side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Looks good to me. Tested on Windows and mac OS X. If feasible can we have Unit test for this. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/164 From tsayao at openjdk.java.net Fri Apr 10 19:00:25 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 10 Apr 2020 19:00:25 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: > Simple fix to remove annoying warnings. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Gstreamer build ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/150/files - new: https://git.openjdk.java.net/jfx/pull/150/files/67adeaee..92f1b9ab Webrevs: - full: https://webrevs.openjdk.java.net/jfx/150/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/150/webrev.02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/150.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/150/head:pull/150 PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Fri Apr 10 19:00:26 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 10 Apr 2020 19:00:26 GMT Subject: [Rev 02] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 18:34:56 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Sep cppFlags and cFlags > > The build changes in `linux.gradle` look good. I tested it, and all warnings are gone (including those in WebKit) > except for the ones in the jfxmedia sub-project of javafx.media. > Two comments: > > 1. I changed the bug title in JBS to refer to gcc 9 rather than Ubuntu to reflect the actual cause of the additional > warnings. Can you update the title of this PR to match? 8241476: Linux build warnings issued on gcc 9 > > 2. Can you add the following change to your PR as well? This will fix the remaining warnings in jfxmedia: > > --- a/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > +++ b/modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > @@ -41,7 +41,6 @@ ifdef HOST_COMPILE > -Wextra \ > -Wformat-security \ > -fstack-protector \ > - -Werror=implicit-function-declaration \ > -Werror=trampolines \ > -msse2 \ > -DGSTREAMER_LITE Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From tsayao at openjdk.java.net Fri Apr 10 19:20:34 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 10 Apr 2020 19:20:34 GMT Subject: [Rev 49] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: <2y07dBE6cmyoIk4oGlgU3_sxEnXivy3jgPQeNMMcHTE=.8d48545c-3336-4607-abf1-abfba76f1a2a@github.com> > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Rename flag to javafx.gtk.experimental - Rename flag to javafx.gtk.experimental ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/d18b5be4..85defa52 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.49 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.48-49 Stats: 27 lines in 29 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Fri Apr 10 21:59:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Apr 2020 21:59:57 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Fri, 10 Apr 2020 19:00:25 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to remove annoying warnings. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Gstreamer build Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/150 From jvos at openjdk.java.net Sat Apr 11 08:21:28 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 11 Apr 2020 08:21:28 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> References: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> Message-ID: On Wed, 8 Apr 2020 21:26:40 GMT, Kevin Rushforth wrote: >> This PR comments out too verbose console logging, as it has been done with some other fprintf calls. >> As a follow up of this PR, a custom directive that enables this output if needed can be considered. > > Marked as reviewed by kcr (Lead). The root cause for this issue is not the unnecessary logging, but the fact that the Quantum Renderer keeps running when the app is not in the foreground (causing a long list of debug lines). I'll create a separate issue for that. ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From arapte at openjdk.java.net Sat Apr 11 10:17:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 11 Apr 2020 10:17:24 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing Message-ID: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. Fix: 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. Change unrelated to fix: `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed for the fix. But this seems to be dead code. Verification: Added new unit tests to verify the change. Also verified that the behavior ListView behaves same before and after this change. ------------- Commit messages: - 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing Changes: https://git.openjdk.java.net/jfx/pull/172/files Webrev: https://webrevs.openjdk.java.net/jfx/172/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209788 Stats: 211 lines in 6 files changed: 151 ins; 49 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From aghaisas at openjdk.java.net Mon Apr 13 07:08:01 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 13 Apr 2020 07:08:01 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly Message-ID: Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 Root Cause : Incorrect implementation. Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. Fix : Added a method for IntegerSpinnerValueFactory with separate implementation. Testing : Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed separately. ------------- Commit messages: - IntegerSpinner_wrapAround Changes: https://git.openjdk.java.net/jfx/pull/174/files Webrev: https://webrevs.openjdk.java.net/jfx/174/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193286 Stats: 202 lines in 3 files changed: 195 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/174/head:pull/174 PR: https://git.openjdk.java.net/jfx/pull/174 From arapte at openjdk.java.net Mon Apr 13 08:25:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 13 Apr 2020 08:25:39 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel Message-ID: `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member `selectionModel`. The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). ------------- Commit messages: - 8241737: TabPaneSkin memory leak on replacing selectionModel Changes: https://git.openjdk.java.net/jfx/pull/175/files Webrev: https://webrevs.openjdk.java.net/jfx/175/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241737 Stats: 36 lines in 2 files changed: 26 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/175/head:pull/175 PR: https://git.openjdk.java.net/jfx/pull/175 From fastegal at swingempire.de Mon Apr 13 10:48:16 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 13 Apr 2020 12:48:16 +0200 Subject: Automate copyright year? Message-ID: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> Seeing that missing to update of copyright year in the header is rather common (in my own pull requests as well as in others :) is there any means to do so automatically or some source tool (for me that would be for Eclipse) that would do on request? -- Jeanette From fastegal at openjdk.java.net Mon Apr 13 11:00:20 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 13 Apr 2020 11:00:20 GMT Subject: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection Message-ID: Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else block when updating toggle selection state (see report for details). Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the incorrect selection state - removed listener to selected item - removed toggle selection update in showing listener The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel is null initially. Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the informally ignored test part for memory leak. ------------- Commit messages: - 8242489: ChoiceBox: initially toggle not sync'ed to selection Changes: https://git.openjdk.java.net/jfx/pull/177/files Webrev: https://webrevs.openjdk.java.net/jfx/177/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242489 Stats: 375 lines in 5 files changed: 347 ins; 25 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177 From kevin.rushforth at oracle.com Mon Apr 13 12:33:42 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Apr 2020 05:33:42 -0700 Subject: Automate copyright year? In-Reply-To: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> References: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> Message-ID: <5cbbcdc4-913f-df30-df9d-6204c23da6da@oracle.com> Not that I know of. FWIW, I'm not too bothered by this, since I run a script 2-3 times a year to update the copyright years for those files fixed in the current year. -- Kevin On 4/13/2020 3:48 AM, Jeanette Winzenburg wrote: > > Seeing that missing to update of copyright year in the header is > rather common (in my own pull requests as well as in others :) is > there any means to do so automatically or some source tool (for me > that would be for Eclipse) that would do on request? > > -- Jeanette > From kcr at openjdk.java.net Mon Apr 13 14:35:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 14:35:04 GMT Subject: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 10:36:51 GMT, Jeanette Winzenburg wrote: > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. @aghaisas can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From kcr at openjdk.java.net Mon Apr 13 14:49:50 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 14:49:50 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Fri, 10 Apr 2020 21:57:43 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Gstreamer build > > Looks good. @johanvos or @arapte Can one of you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From fastegal at openjdk.java.net Mon Apr 13 16:04:18 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 13 Apr 2020 16:04:18 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 08:03:09 GMT, Ambarish Rapte wrote: > `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being > GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. > If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member > `selectionModel`. > The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for > [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). Changes requested by fastegal (Author). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: > 269: } > 270: > 271: super.dispose(); wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you experience any side-effects if not? If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern to remember when skins are listening weakly :) ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From kcr at openjdk.java.net Mon Apr 13 16:37:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:37:28 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done > for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. > I have run a full build and test using this new compiler. /reviewers 2 ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From kcr at openjdk.java.net Mon Apr 13 16:37:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:37:28 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux Message-ID: This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. I have run a full build and test using this new compiler. ------------- Commit messages: - 8242490: Upgrade to gcc 9.2 on Linux Changes: https://git.openjdk.java.net/jfx/pull/178/files Webrev: https://webrevs.openjdk.java.net/jfx/178/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242490 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/178.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/178/head:pull/178 PR: https://git.openjdk.java.net/jfx/pull/178 From kcr at openjdk.java.net Mon Apr 13 16:37:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:37:28 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 16:13:42 GMT, Kevin Rushforth wrote: >> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done >> for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). >> On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by >> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. >> I have run a full build and test using this new compiler. > > /reviewers 2 @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From jvos at openjdk.java.net Mon Apr 13 18:58:48 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 13 Apr 2020 18:58:48 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> Message-ID: On Sat, 11 Apr 2020 08:19:16 GMT, Johan Vos wrote: >> Marked as reviewed by kcr (Lead). > > The root cause for this issue is not the unnecessary logging, but the fact that the Quantum Renderer keeps running when > the app is not in the foreground (causing a long list of debug lines). I'll create a separate issue for that. It would be nice to show this debug info when javafx.pulseLogger is true, and hide it when that property is false. It shows interesting information about the rendering phase, so when that info is requested (by enabling pulseLogger), it is useful. ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From nlisker at gmail.com Mon Apr 13 20:49:59 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 13 Apr 2020 23:49:59 +0300 Subject: Testing JavaFX with Java14 preview features Message-ID: Hi, I would like to test the preview features in Java 14 on JavaFX. What changes should I make in the build files to get it working? - Nir From kevin.rushforth at oracle.com Mon Apr 13 22:59:57 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Apr 2020 15:59:57 -0700 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: Message-ID: I guess you mean modifying the FX build in your local repo so that you can test the use of JDK 14 preview features in FX itself? (if you were just trying to use it from your app you wouldn't need any build changes in FX). At a minimum you would need to add the "--enable-preview" flag to compile.options.compilerArgs, and change "sourceCompatibility" from "11" to "14". Not sure if anything more is needed. I've never tried it. -- Kevin On 4/13/2020 1:49 PM, Nir Lisker wrote: > Hi, > > I would like to test the preview features in Java 14 on JavaFX. What > changes should I make in the build files to get it working? > > - Nir From nlisker at gmail.com Mon Apr 13 23:10:50 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 14 Apr 2020 02:10:50 +0300 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: Message-ID: Thanks, yes, testing on JavaFX itself. I made these changes. I'm getting "error: invalid source release: 14" when trying to build. These are the settings that are output during the task: Gradle Distribution: Gradle wrapper from target build Gradle Version: 6.3 Java Home: C:\Program Files\Java\jdk-14 JVM Arguments: None Program Arguments: None Build Scans Enabled: false Offline Mode Enabled: false Gradle Tasks: build This is the full error message: error: invalid source release: 14 Usage: javac use --help for a list of possible options FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':base:compileJava'. > Compilation failed with exit code 2; see the compiler error output for details. On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth wrote: > I guess you mean modifying the FX build in your local repo so that you > can test the use of JDK 14 preview features in FX itself? (if you were > just trying to use it from your app you wouldn't need any build changes > in FX). At a minimum you would need to add the "--enable-preview" flag > to compile.options.compilerArgs, and change "sourceCompatibility" from > "11" to "14". Not sure if anything more is needed. I've never tried it. > > -- Kevin > > > On 4/13/2020 1:49 PM, Nir Lisker wrote: > > Hi, > > > > I would like to test the preview features in Java 14 on JavaFX. What > > changes should I make in the build files to get it working? > > > > - Nir > > From kevin.rushforth at oracle.com Mon Apr 13 23:38:23 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Apr 2020 16:38:23 -0700 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: Message-ID: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> Not sure, but you might check here: modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt That's the list of args that gradle generates to pass to javac (using @.../java-compiler-args.txt) -- Kevin On 4/13/2020 4:10 PM, Nir Lisker wrote: > Thanks, yes, testing on JavaFX itself. > I made these changes. I'm getting "error: invalid source release: 14" > when trying to build. These are the settings that are output during > the task: > > Gradle Distribution: Gradle wrapper from target build > Gradle Version: 6.3 > Java Home: C:\Program Files\Java\jdk-14 > JVM Arguments: None > Program Arguments: None > Build Scans Enabled: false > Offline Mode Enabled: false > Gradle Tasks: build > > This is the full error message: > > error: invalid source release: 14 > Usage: javac > use --help for a list of possible options > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':base:compileJava'. > > Compilation failed with exit code 2; see the compiler error output > for details. > > On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth > > wrote: > > I guess you mean modifying the FX build in your local repo so that > you > can test the use of JDK 14 preview features in FX itself? (if you > were > just trying to use it from your app you wouldn't need any build > changes > in FX). At a minimum you would need to add the "--enable-preview" > flag > to compile.options.compilerArgs, and change "sourceCompatibility" > from > "11" to "14". Not sure if anything more is needed. I've never > tried it. > > -- Kevin > > > On 4/13/2020 1:49 PM, Nir Lisker wrote: > > Hi, > > > > I would like to test the preview features in Java 14 on JavaFX. What > > changes should I make in the build files to get it working? > > > > - Nir > From almatvee at openjdk.java.net Tue Apr 14 00:09:26 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 14 Apr 2020 00:09:26 GMT Subject: RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina Message-ID: https://bugs.openjdk.java.net/browse/JDK-8241629 We used to link with system provided libffi (due to a bug in Makefile) and for some reason GLib signals did not work correctly and thus we did not able to build dynamic pipelines. We did not switch to AVFoundation until timeout is reached while waiting for GStreamer to start playing or report us an error. Fixed by linking GLib with libffi which we build, like we do for other platforms. ------------- Commit messages: - 8241629: [macos10.15] Long startup delay playing media over https on Catalina Changes: https://git.openjdk.java.net/jfx/pull/179/files Webrev: https://webrevs.openjdk.java.net/jfx/179/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241629 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/179.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/179/head:pull/179 PR: https://git.openjdk.java.net/jfx/pull/179 From kcr at openjdk.java.net Tue Apr 14 00:16:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 00:16:27 GMT Subject: RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 23:07:12 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8241629 > > We used to link with system provided libffi (due to a bug in Makefile) and for some reason GLib signals did not work > correctly and thus we did not able to build dynamic pipelines. We did not switch to AVFoundation until timeout is > reached while waiting for GStreamer to start playing or report us an error. Fixed by linking GLib with libffi which we > build, like we do for other platforms. Looks good. I tested it on both 10.15.x (Catalina) and 10.13.x (High Sierra). I confirm that there is no more dependency on the system libffi. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/179 From nlisker at gmail.com Tue Apr 14 01:35:58 2020 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 14 Apr 2020 04:35:58 +0300 Subject: Testing JavaFX with Java14 preview features In-Reply-To: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> References: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> Message-ID: It contains: -source 14 -target 14 Looks like I'll have to do some digging. Thanks On Tue, Apr 14, 2020 at 2:38 AM Kevin Rushforth wrote: > Not sure, but you might check here: > > modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt > > That's the list of args that gradle generates to pass to javac (using > @.../java-compiler-args.txt) > > -- Kevin > > On 4/13/2020 4:10 PM, Nir Lisker wrote: > > Thanks, yes, testing on JavaFX itself. > I made these changes. I'm getting "error: invalid source release: 14" when > trying to build. These are the settings that are output during the task: > > Gradle Distribution: Gradle wrapper from target build > Gradle Version: 6.3 > Java Home: C:\Program Files\Java\jdk-14 > JVM Arguments: None > Program Arguments: None > Build Scans Enabled: false > Offline Mode Enabled: false > Gradle Tasks: build > > This is the full error message: > > error: invalid source release: 14 > Usage: javac > use --help for a list of possible options > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':base:compileJava'. > > Compilation failed with exit code 2; see the compiler error output for > details. > > On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I guess you mean modifying the FX build in your local repo so that you >> can test the use of JDK 14 preview features in FX itself? (if you were >> just trying to use it from your app you wouldn't need any build changes >> in FX). At a minimum you would need to add the "--enable-preview" flag >> to compile.options.compilerArgs, and change "sourceCompatibility" from >> "11" to "14". Not sure if anything more is needed. I've never tried it. >> >> -- Kevin >> >> >> On 4/13/2020 1:49 PM, Nir Lisker wrote: >> > Hi, >> > >> > I would like to test the preview features in Java 14 on JavaFX. What >> > changes should I make in the build files to get it working? >> > >> > - Nir >> >> > From tschindl at openjdk.java.net Tue Apr 14 04:48:31 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Tue, 14 Apr 2020 04:48:31 GMT Subject: RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Message-ID: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Extract keystate and add to the existing modifier mask, to support eg multi-select https://bugs.openjdk.java.net/browse/JDK-8202296 ------------- Commit messages: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Changes: https://git.openjdk.java.net/jfx/pull/170/files Webrev: https://webrevs.openjdk.java.net/jfx/170/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202296 Stats: 20 lines in 1 file changed: 14 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From jhendrikx at openjdk.java.net Tue Apr 14 04:54:27 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 14 Apr 2020 04:54:27 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation Message-ID: This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. ------------- Commit messages: - 8242548: Honor line spacing in Labeled reflow calculation Changes: https://git.openjdk.java.net/jfx/pull/173/files Webrev: https://webrevs.openjdk.java.net/jfx/173/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242548 Stats: 44 lines in 4 files changed: 40 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/173/head:pull/173 PR: https://git.openjdk.java.net/jfx/pull/173 From arapte at openjdk.java.net Tue Apr 14 08:43:38 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 08:43:38 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: <171xckDtVxAoZqEUFk59iUrKnGM14RfL0K-d19a9pls=.469bf2e5-809b-4369-bb19-0e6f8cfc03f9@github.com> On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done > for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. > I have run a full build and test using this new compiler. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From florian.kirmaier at gmail.com Tue Apr 14 10:15:49 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Tue, 14 Apr 2020 12:15:49 +0200 Subject: Mac: Supported MacOS JDKs Message-ID: Hi everyone, it seems to me, that the newest JDK for Mac (MacOSX10.15.sdk) doesn't work to build JavaFX. It works for me with 10.14 but not with 10.15. Can anyone confirm this? It would be great to mention this in the build instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX Greetings Florian Kirmaier From jpereda at openjdk.java.net Tue Apr 14 10:40:43 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 14 Apr 2020 10:40:43 GMT Subject: RFR: 8242577: Cell selection fails on iOS most of the times Message-ID: There are cases when iOS sends one or more NSTouchPhaseMoved for a given touch event, in between NSTouchPhaseBegan and NSTouchPhaseEnded , even if the initial event location didn't change. By default, all these events are emulated as mouse enter/down, drag and up/exit events. However, when the user taps quickly or even holds steady on a cell, if these touch moved events are generated and sent as mouse drag events, the cell selection fails, as the flag `latePress` used in [CellBehaviorBase](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java#L191) is set to false, preventing the cell selection that should happen upon touch release event. This PR prevents emulating mouse drag events when the touch event doesn't change its location. ------------- Commit messages: - Don?t emulate as mouse drag events touch moved events if location didn?t change Changes: https://git.openjdk.java.net/jfx/pull/181/files Webrev: https://webrevs.openjdk.java.net/jfx/181/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242577 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/181.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/181/head:pull/181 PR: https://git.openjdk.java.net/jfx/pull/181 From fkirmaier at openjdk.java.net Tue Apr 14 10:50:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 14 Apr 2020 10:50:13 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 09:44:34 GMT, Ambarish Rapte wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77: > >> 76: Platform.runLater(() -> stage.close()); >> 77: } >> 78: > > Looks like the primary `stage` is not required for actual test, and this block is only used to initialize JavaFX > runtime. Please check if it can be replaced by below block > ``` > @BeforeClass > public static void initFX() throws Exception { > startupLatch = new CountDownLatch(1); > Platform.startup(startupLatch::countDown); > Assert.assertTrue("Timeout waiting for FX runtime to start", > startupLatch.await(15, TimeUnit.MILLISECONDS)); > } This version doesn't work for me. With this change, I get the following error: test.javafx.stage.FocusedWindowTest > testLeak FAILED junit.framework.AssertionFailedError: Exceeded timeout limit of 10000 msec at test.util.Util.runAndWait(Util.java:163) at test.util.Util.runAndWait(Util.java:134) at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:82) ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Tue Apr 14 11:15:32 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 14 Apr 2020 11:15:32 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8241840 Some code cleanups ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/991d3ffa..20865db8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.00-01 Stats: 41 lines in 2 files changed: 9 ins; 24 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Tue Apr 14 11:15:35 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 14 Apr 2020 11:15:35 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 09:51:18 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> Some code cleanups > > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 133: > >> 132: >> 133: Assert.assertNull(weakReference.get()); >> 134: } > > This assert check call should be added to the @Test method. > I would recommend to refer [this > method](https://github.com/openjdk/jfx/blob/364c64a2e55b561df4ca1afc85c91054b339eea8/modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java#L1998) > from ListViewTest. Unifying memory-tests is something I discussed in my last PR. This code is based on my previous pull request: https://github.com/openjdk/jfx/pull/71 I would like to keep this version which I've used there. But it really has to be a library/utility-class which is used across the project instead of reinventing it on every test. > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 84: > >> 83: counter += 1; >> 84: testLeakOnce(); >> 85: } > > If the test has constant behavior on every run, then only one run should be done. done > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 354: > >> 353: } >> 354: if(Window.focusedWindow == this) { >> 355: Window.focusedWindow = null; > > Please correct format by adding space after `if`. done > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 113: > >> 112: }); >> 113: >> 114: Assert.assertTrue("Timeout, waiting for runLater. ", leakLatch.await(15, TimeUnit.SECONDS)); > > Is it really required to nest the `Platform.runLater()` calls ? Can you please check if this code can be simplified by > making the calls sequential, Consider using `Util.runAndWait()` done > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53: > >> 52: System.setProperty("monocle.platform","Headless"); >> 53: } >> 54: > > The test will always run with Monocle. I see that if this static block is removed then the test fails on Windows 10. > Can you please verify all the platforms and change the test such that it runs on all platforms/ combinations. I wasn't able to reproduce the Problem on Window10 with VirtualBox. How should I do it? Add a second test class without the static code? Do you have a good recommendation on how to add it? ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Tue Apr 14 11:43:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:43:32 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Sun, 12 Apr 2020 21:21:07 GMT, John Hendrikx wrote: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. @aghaisas can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From kcr at openjdk.java.net Tue Apr 14 11:44:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:44:45 GMT Subject: RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: On Fri, 10 Apr 2020 10:26:06 GMT, Tom Schindl wrote: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 The fix looks simple enough. Can you add a unit test? ------------- PR: https://git.openjdk.java.net/jfx/pull/170 From kcr at openjdk.java.net Tue Apr 14 11:49:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:49:32 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> Message-ID: On Sun, 9 Feb 2020 14:40:25 GMT, Jeanette Winzenburg wrote: >> I left comments inline. This will need changes. Also, you will need to provide a test that fails without the fix and >> passes with the fix. > > Just a comment on how to add a failing test: we can replace the actual typing (in the TestFx context) by > programmatically replacing the selection, actually, it doesn't even need the skin (so no scene nor parent) because all > collaborators are in TextInputControl: > /** > * Test for JDK-8176270: register changeListener on selectedText, select at > * end of text and replace selection throws. > */ > @Test > public void addingChangeListenerNoSkin() { > TextField textField = new TextField(); > textField.setText("1234 5678"); > textField.selectedTextProperty() > .addListener((o, ov, nv) -> {}); > > textField.positionCaret(5); > textField.selectEnd(); > textField.replaceSelection("d"); > } > > Similarly, an invalidationListener that access the selectedText throws, while an invalidationListener not accessing the > selected is fine. ~~So it looks like a one-off when evaluating the actual selection during the process, somehow it's > not yet ready~~ That was my wrong assumption, the culprit is really the incorrect clamping of a no-longer valid end > index when adjusting the selectedText binding (as @Kevin noted above). It shows only if the selectedText must be > re-evaluated before the selectionRange is updated, f.i. forced by a changeListener (or direct access). To make the > error show up on the test thread, replace the uncaughtExceptionHandler before (and cleanup after): > @Before public void setup() throws Exception { > Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> { > if (throwable instanceof RuntimeException) { > throw (RuntimeException)throwable; > } else { > Thread.currentThread().getThreadGroup().uncaughtException(thread, throwable); > } > }); > textInput = (TextInputControl) type.newInstance(); > } > > > @After public void cleanup() { > Thread.currentThread().setUncaughtExceptionHandler(null); > } @koppor are you planning to resume work on this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/73 From kcr at openjdk.java.net Tue Apr 14 11:54:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 11:54:19 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Thu, 27 Feb 2020 00:01:28 GMT, Kevin Rushforth wrote: >> Allow to override buildDate with `SOURCE_DATE_EPOCH` >> in order to make builds reproducible. >> See https://reproducible-builds.org/ for why this is good >> and https://reproducible-builds.org/specs/source-date-epoch/ >> for the definition of this variable. >> >> This PR was done while working on reproducible builds for openSUSE. > > Finally getting to this (sorry for the delay). This seems OK to me, as it is not an intrusive change. I do not think > that actually setting this property for production builds is a good idea, so I recommend against that (ultimately that > will be up to Gluon or whoever produces builds). I'll test it once you change it from an env variable to a gradle > property. @bmwiedemann are you planning to pursue this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Tue Apr 14 12:00:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 12:00:02 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Fri, 13 Mar 2020 13:05:29 GMT, Tobias Diez wrote: >> You must have some use case that fails without this proposed fix (else why are you proposing it), right? > > Yes, we had this exception in our application which was (temporarily) fixed with > https://github.com/JabRef/jabref/pull/5497. But JabRef is 100k lines of code, so I doubt this counts as a unit test. @tobiasdiez are you planning to pursue this? The review is pending a simple test case. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From jhendrikx at openjdk.java.net Tue Apr 14 12:22:22 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Tue, 14 Apr 2020 12:22:22 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Tue, 10 Mar 2020 06:08:25 GMT, yosbits wrote: >>> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time >>> (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, >>> we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing >>> it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin >>> has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal >>> code does it .. >> >> So we can choose to specify it as ordered. >> >> These are the 2 options I mentioned: >> 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as >> you've mentioned. 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow >> applications to rely on the behavior safely. >> Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is >> if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is >> unspecified and is planned to change in the future, so there will be at least some warning. Once we choose what to do >> here it will make sense to continue to review the code with that decision in mind. > > In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce > the performance improvement. I have attached a test program in my PR(#125) @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow.". Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when the listeners are spread out over dozens of properties, and although high in total number, the total listeners per property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Tue Apr 14 12:23:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 12:23:09 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 15:47:00 GMT, Jeanette Winzenburg wrote: >> `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being >> GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. >> If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member >> `selectionModel`. >> The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for >> [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: > >> 269: } >> 270: >> 271: super.dispose(); > > wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you > experience any side-effects if not? > If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which > is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way > round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern > to remember when skins are listening weakly :) This is needed to future safe the code from an NPE from scenarios as in below test case, class TabPaneSkin1 extends TabPaneSkin { TabPaneSkin1(TabPane tabPane) { super(tabPane); } } @Test public void testNPEOnSwitchSkinAndRemoveTabPane() { TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); Group root = new Group(testPane); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); tk.firePulse(); testPane.setSkin(new TabPaneSkin1(testPane)); tk.firePulse(); testPane.getSelectionModel().select(1); tk.firePulse(); } But currently this throws an NPE at different code, java.lang.NullPointerException at javafx.controls/javafx.scene.control.skin.TabPaneSkin.isHorizontal(TabPaneSkin.java:699) at javafx.controls/javafx.scene.control.skin.TabPaneSkin$TabHeaderArea.layoutChildren(TabPaneSkin.java:1134) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207) This is part of an another problem that skins should remove all listeners when switched. So I think we can not add this test with this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From johan.vos at gluonhq.com Tue Apr 14 12:53:41 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Apr 2020 14:53:41 +0200 Subject: RFR: backport fixes for JavaFX 14.0.1 Message-ID: Hi Kevin, I request permission to backport the following fixes into JavaFX 14.0.1 (in the jfx14 branch). https://bugs.openjdk.java.net/browse/JDK-8233942 JDK-8233942 -- Update to 609.1 version of WebKit https://bugs.openjdk.java.net/browse/JDK-8237003 JDK-8237003 -- Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree https://bugs.openjdk.java.net/browse/JDK-8238256 JDK-8238526 -- Cherry pick GTK WebKit 2.26.3 changes https://bugs.openjdk.java.net/browse/JDK-8239454 JDK-8239454 -- LLIntData : invalid opcode returned for 16 and 32 bit wide instructions https://bugs.openjdk.java.net/browse/JDK-8239109 JDK-8239109 -- Update SQLite to version 3.31.1 https://bugs.openjdk.java.net/browse/JDK-8240211 JDK-8240211 -- Stack overflow on Windows 32-bit can lead to crash https://bugs.openjdk.java.net/browse/JDK-8240832 JDK-8240832 -- Remove unused applecoreaudio.md third-party legal file The following diff would bring those fixes into JavaFX 14.0.1: https://github.com/openjdk/jfx/compare/jfx14...johanvos:jfx14 Those patches would be integrated directly, and not via a PR. Thanks, - Johan From fastegal at openjdk.java.net Tue Apr 14 13:03:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 14 Apr 2020 13:03:36 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 12:20:16 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: >> >>> 269: } >>> 270: >>> 271: super.dispose(); >> >> wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you >> experience any side-effects if not? >> If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which >> is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way >> round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern >> to remember when skins are listening weakly :) > > This is needed to future safe the code from an NPE from scenarios as in below test case, > > class TabPaneSkin1 extends TabPaneSkin { > TabPaneSkin1(TabPane tabPane) { > super(tabPane); > } > } > > @Test > public void testNPEOnSwitchSkinAndRemoveTabPane() { > TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); > Group root = new Group(testPane); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > stage.show(); > tk.firePulse(); > > testPane.setSkin(new TabPaneSkin1(testPane)); > tk.firePulse(); > testPane.getSelectionModel().select(1); > tk.firePulse(); > } > > But currently this throws an NPE at different code, > java.lang.NullPointerException > at javafx.controls/javafx.scene.control.skin.TabPaneSkin.isHorizontal(TabPaneSkin.java:699) > at javafx.controls/javafx.scene.control.skin.TabPaneSkin$TabHeaderArea.layoutChildren(TabPaneSkin.java:1134) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207) > > This is part of an another problem that skins should remove all listeners when switched. > So I think we can not add this test with this fix. thanks for the test :) Good catch, and I can reproduce it, though with a twist: - with firing the pulse I see the error you cited - without firing the pulse, I see the error in the selected item listener (because the skinnable is null) which to me appears to be "nearer" the real reason Whatever the error, though, we learned that we must be extremely careful with (even weak) listeners - at least when they fall into some categories. So far we had - listeners to path properties - listeners that change global state (like in the button skin issue) - ?? maybe all Personally, I would tend to keep and ignore that test with doc: the ignore could point to https://bugs.openjdk.java.net/browse/JDK-8242621 (memory leak on switching tab, which might or not be related), the removing code could have a code comment explaining why it is needed. What do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From github.com+5037600+tobiasdiez at openjdk.java.net Tue Apr 14 13:18:54 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Tue, 14 Apr 2020 13:18:54 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: <_axgKcUZH7Uj944P8Q61bCIcNAjo88mDaEGCwKtPkVU=.df189e62-4b82-45c4-a1b3-526ffe3a7b48@github.com> <9ldboww_bV7_i54H6uueCDdjvhX0Z4Mq_0H6eHrTDCg=.11a74f06-e538-4412-bf0f-5981b3ed493d@github.com> <4AUuODTGLQS_lu8J-Hg8xLTj87zQJ-4YaIXmwjxylTE=.0bc10738-a57a-4b30-a552-a3a9073253c8@github.com> Message-ID: On Tue, 14 Apr 2020 11:49:50 GMT, Kevin Rushforth wrote: >> Yes, we had this exception in our application which was (temporarily) fixed with >> https://github.com/JabRef/jabref/pull/5497. But JabRef is 100k lines of code, so I doubt this counts as a unit test. > > @tobiasdiez are you planning to pursue this? The review is pending a simple test case. @kevinrushforth I've now added a test. Hope it's ok like this. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Tue Apr 14 13:18:54 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Tue, 14 Apr 2020 13:18:54 GMT Subject: [Rev 01] RFR: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: Message-ID: > Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url > start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/22/files - new: https://git.openjdk.java.net/jfx/pull/22/files/391c4fa5..f58ddfca Webrevs: - full: https://webrevs.openjdk.java.net/jfx/22/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/22/webrev.00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx/pull/22 From fastegal at openjdk.java.net Tue Apr 14 13:29:02 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 14 Apr 2020 13:29:02 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 13:01:18 GMT, Jeanette Winzenburg wrote: >> This is needed to future safe the code from an NPE from scenarios as in below test case, >> >> class TabPaneSkin1 extends TabPaneSkin { >> TabPaneSkin1(TabPane tabPane) { >> super(tabPane); >> } >> } >> >> @Test >> public void testNPEOnSwitchSkinAndRemoveTabPane() { >> TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); >> Group root = new Group(testPane); >> Scene scene = new Scene(root); >> Stage stage = new Stage(); >> stage.setScene(scene); >> stage.show(); >> tk.firePulse(); >> >> testPane.setSkin(new TabPaneSkin1(testPane)); >> tk.firePulse(); >> testPane.getSelectionModel().select(1); >> tk.firePulse(); >> } >> >> But currently this throws an NPE at different code, >> java.lang.NullPointerException >> at javafx.controls/javafx.scene.control.skin.TabPaneSkin.isHorizontal(TabPaneSkin.java:699) >> at javafx.controls/javafx.scene.control.skin.TabPaneSkin$TabHeaderArea.layoutChildren(TabPaneSkin.java:1134) >> at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207) >> >> This is part of an another problem that skins should remove all listeners when switched. >> So I think we can not add this test with this fix. > > thanks for the test :) > > Good catch, and I can reproduce it, though with a twist: > > - with firing the pulse I see the error you cited > - without firing the pulse, I see the error in the selected item listener (because the skinnable is null) which to me > appears to be "nearer" the real reason > > Whatever the error, though, we learned that we must be extremely careful with (even weak) listeners - at least when > they fall into some categories. So far we had > - listeners to path properties > - listeners that change global state (like in the button skin issue) > - ?? maybe all > > Personally, I would tend to keep and ignore that test with doc: the ignore could point to > https://bugs.openjdk.java.net/browse/JDK-8242621 (memory leak on switching tab, which might or not be related), the > removing code could have a code comment explaining why it is needed. What do you think? Looked again, and actually seeing two different issues ;) A) your test - that is with firing the pulse: fails for both not/removing the listener B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener So I think we should include B as it is directly related to this fix (and verifies the need to remove the listener). As to A: we should keep it somewhere to not forget, but where? Test code B: @Test public void testNPEOnSwitchSkinAndSelect() { // want to replace the skin - test doesn't make sense without if (!showBeforeReplaceSM) return; TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); Group root = new Group(testPane); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setScene(scene); stage.show(); testPane.setSkin(new TabPaneSkin1(testPane)); testPane.getSelectionModel().select(1); } The exception (seen on the test stack when rewiring the uncaughthandler as usual, else on sysout): Exception in thread "main" java.lang.NullPointerException at javafx.controls/javafx.scene.control.skin.TabPaneSkin.lambda$0(TabPaneSkin.java:447) at javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:83) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) at javafx.base/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:74) at javafx.base/javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102) at javafx.base/javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:113) at javafx.base/javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:147) at javafx.controls/javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105) at javafx.controls/javafx.scene.control.TabPane$TabPaneSelectionModel.select(TabPane.java:736) at javafx.controls/test.javafx.scene.control.SelectionFocusModelMemoryTest.testNPEOnSwitchSkinAndRemoveTabPaneFirePulse(SelectionFocusModelMemoryTest.java:261) ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From kevin.rushforth at oracle.com Tue Apr 14 14:04:34 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 07:04:34 -0700 Subject: RFR: backport fixes for JavaFX 14.0.1 In-Reply-To: References: Message-ID: +1 Looks good. -- Kevin On 4/14/2020 5:53 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following fixes into JavaFX 14.0.1 (in > the jfx14 branch). > > > https://bugs.openjdk.java.net/browse/JDK-8233942 > JDK-8233942 -- Update to > 609.1 version of WebKit > > https://bugs.openjdk.java.net/browse/JDK-8237003 > JDK-8237003 -- Remove > hardcoded WebAnimationsCSSIntegrationEnabled flag > in DumpRenderTree > > https://bugs.openjdk.java.net/browse/JDK-8238256 > JDK-8238526 -- Cherry > pick GTK WebKit 2.26.3 changes > > https://bugs.openjdk.java.net/browse/JDK-8239454 > JDK-8239454 -- LLIntData > : invalid opcode returned for 16 and 32 bit > wide instructions > > https://bugs.openjdk.java.net/browse/JDK-8239109 > JDK-8239109 -- Update > SQLite to version 3.31.1 > > https://bugs.openjdk.java.net/browse/JDK-8240211 JDK-8240211 -- Stack > overflow on Windows 32-bit can lead to crash > > > https://bugs.openjdk.java.net/browse/JDK-8240832 > JDK-8240832 -- Remove > unused applecoreaudio.md third-party legal file > > The following diff would bring those fixes into JavaFX 14.0.1: > https://github.com/openjdk/jfx/compare/jfx14...johanvos:jfx14 > > Those patches would be integrated directly, and not via a PR. > > Thanks, > > - Johan From ajit.ghaisas at oracle.com Tue Apr 14 14:04:16 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 14 Apr 2020 19:34:16 +0530 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 Message-ID: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> Hi, Once I fix JDK-8193286, I would like to take up JDK-8242553 (IntegerSpinner does not wrap around values correctly if amountToStepBy is larger than total numbers between Max and Min) The current implementation is not as per what is documented. Refer : https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty I propose to fix the current buggy behavior of IntegerSpinner. Although it is a corner case, I would like to know if anybody relies on this buggy behavior? Regards, Ajit From fastegal at swingempire.de Tue Apr 14 14:31:45 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 14 Apr 2020 16:31:45 +0200 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> Message-ID: <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> Hi Ajit, thought the doc was simply bad (in specifying the behavior for amountPerStep = 1 and not thinking of larger amounts) - my expection is a calculated wrap, that is the target as you suggest via modulo the difference from current value. Don't know if anybody took the doc literally .. -- Jeanette Zitat von Ajit Ghaisas : > Hi, > > Once I fix JDK-8193286, I would like to take up JDK-8242553 > (IntegerSpinner does not wrap around values correctly if > amountToStepBy is larger than total numbers between Max and Min) > > The current implementation is not as per what is documented. > Refer : > https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty > > I propose to fix the current buggy behavior of IntegerSpinner. > Although it is a corner case, I would like to know if anybody > relies on this buggy behavior? > > Regards, > Ajit From jvos at openjdk.java.net Tue Apr 14 14:38:58 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Apr 2020 14:38:58 GMT Subject: [jfx14] RFR: 8242637: Change JavaFX release version in jfx14 branch to 14.0.1 Message-ID: Fix for JDK-8242637 ------------- Commit messages: - Increase release version for JavaFX 14.0.1 Changes: https://git.openjdk.java.net/jfx/pull/183/files Webrev: https://webrevs.openjdk.java.net/jfx/183/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242637 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/183/head:pull/183 PR: https://git.openjdk.java.net/jfx/pull/183 From kcr at openjdk.java.net Tue Apr 14 14:53:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Apr 2020 14:53:39 GMT Subject: [jfx14] RFR: 8242637: Change JavaFX release version in jfx14 branch to 14.0.1 In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 14:33:53 GMT, Johan Vos wrote: > Fix for JDK-8242637 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/183 From kevin.rushforth at oracle.com Tue Apr 14 15:58:40 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 08:58:40 -0700 Subject: RFR: Request to sync April 2020 CPU changes into jfx Message-ID: Johan and Phil, I request approval to sync changes from to the just-released April 2020 CPU release into the 'master' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/4d69a0d...cpu-2004-sync NOTE: Since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly into the master branch rather than via a pull request. -- Kevin From kevin.rushforth at oracle.com Tue Apr 14 16:08:13 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 09:08:13 -0700 Subject: [11][14] RFR: Request to backport April 2020 CPU changes Message-ID: Hi Johan, I request approval to backport the changes from the just-released April 2020 CPU to 11-dev (for 11.0.7) and the jfx14 branch of jfx (for 14.0.1). https://cr.openjdk.java.net/~kcr/cpu-2004-sync/11-dev/webrev/ https://github.com/kevinrushforth/jfx/compare/f8c235b...14-cpu-2004-sync Each is a straight backport (patch applies cleanly) of the one FX fix that went into the April CPU. NOTE: For the 14.0.1 backport, since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly into the jfx14 branch rather than via a pull request. The 11.0.7 backport will be pushed to the HG 11-dev repo. Thanks. -- Kevin From Rony.Flatscher at wu.ac.at Tue Apr 14 16:48:54 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 14 Apr 2020 18:48:54 +0200 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> Message-ID: <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> Hi there, as there was probably enough time that has passed by I would intend to create a CSR in the next days with the PR as per Kevin's suggestion. (For the case that this feature should not be active by default, the CSR will suggest to define a new "compile" PI in the form (default, if no PI data given: true), which is independent of the existence of a language PI (this way it becomes also possible to allow compilation of external scripts denoted with the script-element, which do not need a page language to be set as the file's extension allows the appropriate script engine to be loaded and used for execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI or ? to FXML files (and to turn off), which seems to be simple and self-documentary. In general employing such compile PIs allows for setting compilation of scripts on and off throughout an FXML file.) ---rony On 04.04.2020 18:03, Rony G. Flatscher wrote: > Hi Kevin, > > On 03.04.2020 01:21, Kevin Rushforth wrote: >> I see that you updated the PR and sent it for review. >> >> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >> feature, and if so, what form this feature should take. >> >> From my point of view, this does seem like a useful feature. Would other users of FXML benefit >> from it? > Script code should be executed faster after compilation, so any FXML page that hosts script code may > benefit. > > The benefits depend on the type of script (and maybe its size and its complexity) and also on the > types of event handlers the scripts serve, e.g. move or drag event handlers may benefit > significantly. This is because repeated invocation of compiled script event handlers do not cause > the reparsing of that script's source and interpreting it on each invocation, which may be expensive > depending on the script engine, but rather allows the immediate evaluation/execution of the compiled > script by the script engine. > >> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >> question implements Compilable, or via a new keyword or tag. What are the pros / cons? > In principle there are three possibilities: > > 1) If a script engine implements javax.script.Compilable, compile the script and execute the > compiled version. In the case of event handlers compile and buffer the compiled script and > execute the compiled script each time its registered event fires. > > o Pro: immediately benefits all existing FXML pages that host scripts > o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail > compiling but have been employed successfully in interpreted mode > > 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML > language PI that switches on compilation of scripts hosted in FXML definitions if the script > engine implements the javax.script.Compilable interface. If missing it would default to "false". > (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the > script engine supports it. It would be an error if the "compile" PI was present, but the > "language" PI was not.) > > o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the language > PI gets changed > o Con: benefit not made available automatically to existing FXML pages that host scripts > > 3) Another possibility would be to define a boolean attribute/property "compile" for script and > node elements and only compile the scripts, if the property is set to true > > o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed > accordingly > o Con: potential benefit not made available automatically to existing FXML pages that host scripts > > 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be > overruled individually by 3. > > The question would be whether 2 or/and 3 are really necessary as it can be expected that compilation > of scripts by the script engines would find the same errors as while interpreting the very same > scripts (if not, the script engine is badly broken and it could be argued that then the > interpretation part of the script engine might be expected to be broken as well which would be quite > dangerous from an integrity POV; the same consideration applies as well if the execution of the > compiled script would behave differently to interpreting the very same script by the same script > engine). > > The current WIP implements 1 above and includes an appropriate test unit. > >> What do others think? > > >> In either case, we would need to make sure that this doesn't present any security concerns in the >> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >> but we would need to ensure that. > The compilation of scripts needs to be done by the Java script engines (implementing both, > javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled > scripts ([javax.script.CompiledScript] > (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). > > ---rony > > > >> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >>> pull request I would kindly request a review of this pull request! >>> >>> Here the URL: , title changed to: "8238080: FXMLLoader: if >>> script engines implement javax.script.Compilable compile scripts". >>> >>> ---rony >>> >>> >>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>>> has an appropriate test unit going with it as well, please review. >>>> >>>> There should be no compatibility issue with this implementation. >>>> >>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>> value >>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>>> respective solution as well. >>>> >>>> ---rony >>>> >>>> [1] "Implementation and test unit": >>>> >>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>> scripts": >>>> >>>> >>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>> >>>> >>>> >>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>> >>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>>> the concept). >>>>> >>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>> Just filed a RFE with the following information: >>>>>> >>>>>> ??? * Component: >>>>>> ??????? o JavaFX >>>>>> >>>>>> ??? * Subcomponent: >>>>>> ??????? o fxml: JavaFX FXML >>>>>> >>>>>> ??? * Synopsis: >>>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>> >>>>>> ??? * Descriptions: >>>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>> (javax.script.ScriptEngine >>>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>>> language in >>>>>> ????????? the FXML file. >>>>>> >>>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>>> could >>>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>> using >>>>>> ????????? its eval() methods. >>>>>> >>>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>> invocations, >>>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>> onMouseMove) >>>>>> ????????? which may be repetitevly invoked and evaluated." >>>>>> >>>>>> ??? * System /OS/Java Runtime Information: >>>>>> ??????? o "All systems." >>>>>> >>>>>> Received the internal review ID: "9063426" >>>>>> >>>>>> ---rony > From arapte at openjdk.java.net Tue Apr 14 17:19:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 17:19:48 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: <4z-EPq_6p7kA_4V83BNCGwSUIkyIa26vElssWJSeMPk=.3d7a78c8-a999-4a47-8a3e-c603f0a0a077@github.com> On Fri, 10 Apr 2020 19:00:25 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to remove annoying warnings. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Gstreamer build Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From arapte at openjdk.java.net Tue Apr 14 17:19:48 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 14 Apr 2020 17:19:48 GMT Subject: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9 In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 14:47:35 GMT, Kevin Rushforth wrote: >> Looks good. > > @johanvos or @arapte Can one of you be the second reviewer on this? After this change below c files would be compiled without `-Werror=implicit-function-declaration` option. modules/javafx.media/src/main/native/jfxmedia/Utils/ColorConverter.c modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c modules/javafx.graphics/src/main/native-glass/gtk/launcher.c This can be addressed in follow on issue. Recording the files here for track. Looks good to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/150 From kevin.rushforth at oracle.com Tue Apr 14 17:52:44 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Apr 2020 10:52:44 -0700 Subject: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> Message-ID: Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to create the CSR until the review is far enough along to know which direction we intend to go. Unless there is a real concern about possible regressions if scripts are compiled by default, I think "enabled by default" is the way to go. Your argument that such script engines are broken seems reasonable, since this only applies to script engines that implement javax.script.Compilable in the first place. We still might want to add way to turn compilation off for individual scripts. One other thing to consider is that if compilation fails, it might make sense to log a warning and fall back to the existing interpreted mode. Does anyone else have any concerns with this? -- Kevin On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: > Hi there, > > as there was probably enough time that has passed by I would intend to create a CSR in the next days > with the PR as per Kevin's suggestion. > > (For the case that this feature should not be active by default, the CSR will suggest to define a > new "compile" PI in the form (default, if no PI data given: true), which > is independent of the existence of a language PI (this way it becomes also possible to allow > compilation of external scripts denoted with the script-element, which do not need a page language > to be set as the file's extension allows the appropriate script engine to be loaded and used for > execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI > or ? to FXML files (and to turn off), which seems to > be simple and self-documentary. In general employing such compile PIs allows for setting compilation > of scripts on and off throughout an FXML file.) > > ---rony > > > On 04.04.2020 18:03, Rony G. Flatscher wrote: > >> Hi Kevin, >> >> On 03.04.2020 01:21, Kevin Rushforth wrote: >>> I see that you updated the PR and sent it for review. >>> >>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>> feature, and if so, what form this feature should take. >>> >>> From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>> from it? >> Script code should be executed faster after compilation, so any FXML page that hosts script code may >> benefit. >> >> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >> significantly. This is because repeated invocation of compiled script event handlers do not cause >> the reparsing of that script's source and interpreting it on each invocation, which may be expensive >> depending on the script engine, but rather allows the immediate evaluation/execution of the compiled >> script by the script engine. >> >>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >> In principle there are three possibilities: >> >> 1) If a script engine implements javax.script.Compilable, compile the script and execute the >> compiled version. In the case of event handlers compile and buffer the compiled script and >> execute the compiled script each time its registered event fires. >> >> o Pro: immediately benefits all existing FXML pages that host scripts >> o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >> compiling but have been employed successfully in interpreted mode >> >> 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >> language PI that switches on compilation of scripts hosted in FXML definitions if the script >> engine implements the javax.script.Compilable interface. If missing it would default to "false". >> (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >> script engine supports it. It would be an error if the "compile" PI was present, but the >> "language" PI was not.) >> >> o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the language >> PI gets changed >> o Con: benefit not made available automatically to existing FXML pages that host scripts >> >> 3) Another possibility would be to define a boolean attribute/property "compile" for script and >> node elements and only compile the scripts, if the property is set to true >> >> o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >> accordingly >> o Con: potential benefit not made available automatically to existing FXML pages that host scripts >> >> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >> overruled individually by 3. >> >> The question would be whether 2 or/and 3 are really necessary as it can be expected that compilation >> of scripts by the script engines would find the same errors as while interpreting the very same >> scripts (if not, the script engine is badly broken and it could be argued that then the >> interpretation part of the script engine might be expected to be broken as well which would be quite >> dangerous from an integrity POV; the same consideration applies as well if the execution of the >> compiled script would behave differently to interpreting the very same script by the same script >> engine). >> >> The current WIP implements 1 above and includes an appropriate test unit. >> >>> What do others think? >> >>> In either case, we would need to make sure that this doesn't present any security concerns in the >>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>> but we would need to ensure that. >> The compilation of scripts needs to be done by the Java script engines (implementing both, >> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >> scripts ([javax.script.CompiledScript] >> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >> >> ---rony >> >> >> >>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>> After merging master, applying some fixes and changing the title to reflect the change from WIP to a >>>> pull request I would kindly request a review of this pull request! >>>> >>>> Here the URL: , title changed to: "8238080: FXMLLoader: if >>>> script engines implement javax.script.Compilable compile scripts". >>>> >>>> ---rony >>>> >>>> >>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in review, and >>>>> has an appropriate test unit going with it as well, please review. >>>>> >>>>> There should be no compatibility issue with this implementation. >>>>> >>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>> information is present with the FXML file which cannot possibly be present in existing FXML files. >>>>> In this scenario one possible and probably simple solution would be to only compile scripts if the >>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>> value >>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML with >>>>> PIs having this attribute set to true would be affected. If desired I could try to come up with a >>>>> respective solution as well. >>>>> >>>>> ---rony >>>>> >>>>> [1] "Implementation and test unit": >>>>> >>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>> scripts": >>>>> >>>>> >>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>> >>>>> >>>>> >>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>> >>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to illustrate >>>>>> the concept). >>>>>> >>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>> Just filed a RFE with the following information: >>>>>>> >>>>>>> ??? * Component: >>>>>>> ??????? o JavaFX >>>>>>> >>>>>>> ??? * Subcomponent: >>>>>>> ??????? o fxml: JavaFX FXML >>>>>>> >>>>>>> ??? * Synopsis: >>>>>>> ??????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>> >>>>>>> ??? * Descriptions: >>>>>>> ??????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>> (javax.script.ScriptEngine >>>>>>> ????????? implementations) if such a Java script language gets defined as the controller >>>>>>> language in >>>>>>> ????????? the FXML file. >>>>>>> >>>>>>> ????????? If a script engine implements the javax.script.Compilable interface, then such scripts >>>>>>> could >>>>>>> ????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>> using >>>>>>> ????????? its eval() methods. >>>>>>> >>>>>>> ????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>> invocations, >>>>>>> ????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>> onMouseMove) >>>>>>> ????????? which may be repetitevly invoked and evaluated." >>>>>>> >>>>>>> ??? * System /OS/Java Runtime Information: >>>>>>> ??????? o "All systems." >>>>>>> >>>>>>> Received the internal review ID: "9063426" >>>>>>> >>>>>>> ---rony From johan.vos at gluonhq.com Tue Apr 14 18:03:28 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Apr 2020 20:03:28 +0200 Subject: [11][14] RFR: Request to backport April 2020 CPU changes In-Reply-To: References: Message-ID: Approved, looks good. - Johan On Tue, Apr 14, 2020 at 6:10 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released April > 2020 CPU to 11-dev (for 11.0.7) and the jfx14 branch of jfx (for 14.0.1). > > https://cr.openjdk.java.net/~kcr/cpu-2004-sync/11-dev/webrev/ > https://github.com/kevinrushforth/jfx/compare/f8c235b...14-cpu-2004-sync > > Each is a straight backport (patch applies cleanly) of the one FX fix > that went into the April CPU. > > NOTE: For the 14.0.1 backport, since this is an integration of > already-reviewed fixes into the jfx repo, I will push it directly into > the jfx14 branch rather than via a pull request. The 11.0.7 backport > will be pushed to the HG 11-dev repo. > > Thanks. > > -- Kevin > > From johan.vos at gluonhq.com Tue Apr 14 19:56:53 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Apr 2020 21:56:53 +0200 Subject: RFR: Request to sync April 2020 CPU changes into jfx In-Reply-To: References: Message-ID: Approved. On Tue, Apr 14, 2020 at 5:58 PM Kevin Rushforth wrote: > Johan and Phil, > > I request approval to sync changes from to the just-released April 2020 > CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/4d69a0d...cpu-2004-sync > > NOTE: Since this is an integration of already-reviewed fixes into the > jfx repo, I will push it directly into the master branch rather than via > a pull request. > > -- Kevin > > From github.com+637990+bmwiedemann at openjdk.java.net Wed Apr 15 02:38:00 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Wed, 15 Apr 2020 02:38:00 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 11:48:55 GMT, Kevin Rushforth wrote: >> Finally getting to this (sorry for the delay). This seems OK to me, as it is not an intrusive change. I do not think >> that actually setting this property for production builds is a good idea, so I recommend against that (ultimately that >> will be up to Gluon or whoever produces builds). I'll test it once you change it from an env variable to a gradle >> property. > > @bmwiedemann are you planning to pursue this PR? Long term, yes. I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From ajit.ghaisas at oracle.com Wed Apr 15 04:25:29 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 15 Apr 2020 09:55:29 +0530 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> Message-ID: <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> Hi Jeanette, The doc never assumes amountPerStep = 1. I am quoting it here - ?The wrapAround property is used to specify whether the value factory should be circular. For example, should an integer-based value model increment from the maximum value back to the minimum value (and vice versa).? The word ?circular? clarifies that once we exceed maximum value, we should start from minimum. I think, the doc is OK in it?s current form, but implementation needs to be corrected. Regards, Ajit > On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg wrote: > > > Hi Ajit, > > thought the doc was simply bad (in specifying the behavior for amountPerStep = 1 and not thinking of larger amounts) - my expection is a calculated wrap, that is the target as you suggest via modulo the difference from current value. Don't know if anybody took the doc literally .. > > -- Jeanette > > Zitat von Ajit Ghaisas : > >> Hi, >> >> Once I fix JDK-8193286, I would like to take up JDK-8242553 (IntegerSpinner does not wrap around values correctly if amountToStepBy is larger than total numbers between Max and Min) >> >> The current implementation is not as per what is documented. >> Refer : https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >> >> I propose to fix the current buggy behavior of IntegerSpinner. >> Although it is a corner case, I would like to know if anybody relies on this buggy behavior? >> >> Regards, >> Ajit > > > From github.com+6702882+dannygonzalez at openjdk.java.net Wed Apr 15 07:13:44 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Wed, 15 Apr 2020 07:13:44 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: On Tue, 14 Apr 2020 12:20:10 GMT, John Hendrikx wrote: >> In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce >> the performance improvement. I have attached a test program in my PR(#125) > > @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the > number of nodes in a TableView this is going to be a problem if the unregistering is slow.". > Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands > of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a > single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the > problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when > the listeners are spread out over dozens of properties, and although high in total number, the total listeners per > property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost > unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. @hjohn I haven't quantified exactly where all the listeners are coming from but the Node class for example has various listeners on it. The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly (although it was still bad before this change in my previous tests): > commit e21606d3a1b73cd4b44383babc750a4b4721edfd > Author: Florian Kirmaier > > Date: Tue Jan 22 09:08:36 2019 -0800 > > 8216377: Fix memoryleak for initial nodes of Window > 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window > > Add or remove the windowShowingChangedListener when the scene changes As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all needed especially around the Node class. I went directly to the source of the problem which was the linear search to deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it has saved it from being unusable due to the JavaFx thread being swamped. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From tschindl at openjdk.java.net Wed Apr 15 08:19:38 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 15 Apr 2020 08:19:38 GMT Subject: [Rev 01] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Added Test for keyboard modifiers ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/79fe0fd7..2ca1c88a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.00-01 Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From tschindl at openjdk.java.net Wed Apr 15 08:22:47 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 15 Apr 2020 08:22:47 GMT Subject: [Rev 02] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: <-4V47sYdQyB-P5YA13ipdq5smDDHqI1218Y_-7EBHEk=.5c1ee2fc-0733-4815-aaee-b6d2bb9dc24d@github.com> > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with two additional commits since the last revision: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/2ca1c88a..64a802ca Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From tschindl at openjdk.java.net Wed Apr 15 08:28:22 2020 From: tschindl at openjdk.java.net (Tom Schindl) Date: Wed, 15 Apr 2020 08:28:22 GMT Subject: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/64a802ca..8fe96a90 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.02-03 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170 From fastegal at swingempire.de Wed Apr 15 09:23:10 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 11:23:10 +0200 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> Message-ID: <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> Hi Ajit, yes, I read the doc, probably a bit differently - could well be my misunderstanding and misunderstandable wording :) Trying again: - I read your suggestion (in https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. that being at value and incrementing a full-cycle (that is max -min +1), I will land on value again - for me the doc seemed to imply that in such a case I would land on min. Though, given the "circular" as you pointed out correctly, was my misunderstanding - the current implementation is buggy (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating the remainder (which is what the first bullet amounts to) incorrectly for min != 0 Where do I err? -- Jeanette Zitat von Ajit Ghaisas : > Hi Jeanette, > > The doc never assumes amountPerStep = 1. I am quoting it here - > ?The wrapAround property is used to specify whether the value > factory should be circular. For example, should an integer-based > value model increment from the maximum value back to the minimum > value (and vice versa).? > > The word ?circular? clarifies that once we exceed maximum value, we > should start from minimum. > I think, the doc is OK in it?s current form, but implementation > needs to be corrected. > > Regards, > Ajit > > >> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg >> wrote: >> >> >> Hi Ajit, >> >> thought the doc was simply bad (in specifying the behavior for >> amountPerStep = 1 and not thinking of larger amounts) - my >> expection is a calculated wrap, that is the target as you suggest >> via modulo the difference from current value. Don't know if anybody >> took the doc literally .. >> >> -- Jeanette >> >> Zitat von Ajit Ghaisas : >> >>> Hi, >>> >>> Once I fix JDK-8193286, I would like to take up JDK-8242553 >>> (IntegerSpinner does not wrap around values correctly if >>> amountToStepBy is larger than total numbers between Max and Min) >>> >>> The current implementation is not as per what is documented. >>> Refer : >>> https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>> >>> I propose to fix the current buggy behavior of IntegerSpinner. >>> Although it is a corner case, I would like to know if anybody >>> relies on this buggy behavior? >>> >>> Regards, >>> Ajit >> >> >> From aghaisas at openjdk.java.net Wed Apr 15 09:41:39 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 15 Apr 2020 09:41:39 GMT Subject: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 10:36:51 GMT, Jeanette Winzenburg wrote: > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. Code changes and test look OK to me. I have a minor comment that I have listed separately. modules/javafx.controls/src/main/java/javafx/scene/control/ChoiceBox.java line 185: > 184: sm.selectedItemProperty().addListener(selectedItemListener); > 185: // unfixed part of JDK-8090015 - why exclude null? > 186: if (sm.getSelectedItem() != null && ! valueProperty().isBound()) { Add a TODO: or FIXME: if you intend to work on it. Also, it will be better to create a JBS issue. If not - please remove the comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Wed Apr 15 10:02:47 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 10:02:47 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: ChoiceBox: added FIXME with reference to issue ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/177/files - new: https://git.openjdk.java.net/jfx/pull/177/files/017be222..0d3ce123 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/177/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/177/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Wed Apr 15 10:02:59 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 10:02:59 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 14:09:13 GMT, Ajit Ghaisas wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> ChoiceBox: added FIXME with reference to issue > > modules/javafx.controls/src/main/java/javafx/scene/control/ChoiceBox.java line 185: > >> 184: sm.selectedItemProperty().addListener(selectedItemListener); >> 185: // unfixed part of JDK-8090015 - why exclude null? >> 186: if (sm.getSelectedItem() != null && ! valueProperty().isBound()) { > > Add a TODO: or FIXME: if you intend to work on it. Also, it will be better to create a JBS issue. > > If not - please remove the comment. Actually forgot that comment, already filed and took the issue JDK-8242001 thanks, eagle eye :) ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From arapte at openjdk.java.net Wed Apr 15 10:19:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Apr 2020 10:19:52 GMT Subject: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 13:26:51 GMT, Jeanette Winzenburg wrote: > B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener Seems like this test randomly crashes (not always) any other test from `TabPaneTest`. It might be crashing the test executed just after this one OR the next test which does `tk.firePulse()`. Also not including `tk.firePulse()` would make the test incomplete/ unreliable. > Personally, I would tend to keep and ignore that test with doc: That is better to include the test now, else very doubtful of adding it in future. Including the test in next commit with @Ignore("JDK-8242621"). ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From arapte at openjdk.java.net Wed Apr 15 10:52:26 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Apr 2020 10:52:26 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: > `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being > GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. > If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member > `selectionModel`. > The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for > [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Add tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/175/files - new: https://git.openjdk.java.net/jfx/pull/175/files/c3e2cbf9..e4293c75 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/175/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/175/webrev.00-01 Stats: 44 lines in 1 file changed: 39 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/175/head:pull/175 PR: https://git.openjdk.java.net/jfx/pull/175 From aghaisas at openjdk.java.net Wed Apr 15 10:59:52 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 15 Apr 2020 10:59:52 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:02:47 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox: added FIXME with reference to issue Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From florian.kirmaier at gmail.com Wed Apr 15 11:14:26 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Wed, 15 Apr 2020 13:14:26 +0200 Subject: No tags for releases at github openjdk/jfx? Message-ID: Hi everyone, I can't see any tags in the GitHub project for the various releases of JavaFX. I would like to know which commit is the base for various releases. Specifically, I'm interested in the version 14 and 15-ea3. Is there a place where I can look it up? Thanks, Florian Kirmaier From fastegal at openjdk.java.net Wed Apr 15 11:17:03 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 11:17:03 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:52:26 GMT, Ambarish Rapte wrote: >> `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being >> GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. >> If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member >> `selectionModel`. >> The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for >> [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Add tests Marked as reviewed by fastegal (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From fastegal at openjdk.java.net Wed Apr 15 11:17:03 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 15 Apr 2020 11:17:03 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:17:41 GMT, Ambarish Rapte wrote: >> Looked again, and actually seeing two different issues ;) >> >> A) your test - that is with firing the pulse: fails for both not/removing the listener >> B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener >> >> So I think we should include B as it is directly related to this fix (and verifies the need to remove the listener). As >> to A: we should keep it somewhere to not forget, but where? >> Test code B: >> >> @Test >> public void testNPEOnSwitchSkinAndSelect() { >> TabPane testPane = new TabPane(new Tab("tab0"), new Tab("tab1")); >> Group root = new Group(testPane); >> Scene scene = new Scene(root); >> Stage stage = new Stage(); >> stage.setScene(scene); >> stage.show(); >> >> testPane.setSkin(new TabPaneSkin1(testPane)); >> testPane.getSelectionModel().select(1); >> } >> >> >> The exception (seen on the test stack when rewiring the uncaughthandler as usual, else on sysout): >> >> Exception in thread "main" java.lang.NullPointerException >> at javafx.controls/javafx.scene.control.skin.TabPaneSkin.lambda$0(TabPaneSkin.java:447) >> at javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:83) >> at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348) >> at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) >> at >> javafx.base/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:74) >> at javafx.base/javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102) at >> javafx.base/javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:113) at >> javafx.base/javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:147) at >> javafx.controls/javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105) at >> javafx.controls/javafx.scene.control.TabPane$TabPaneSelectionModel.select(TabPane.java:736) at >> javafx.controls/test.javafx.scene.control.SelectionFocusModelMemoryTest.testNPEOnSwitchSkinAndRemoveTabPaneFirePulse(SelectionFocusModelMemoryTest.java:261) > >> B) basically same test, but not firing the pulse - it fails without removing and passes with removing the listener > > Seems like this test randomly crashes (not always) any other test from `TabPaneTest`. It might be crashing the test > executed just after this one OR the next test which does `tk.firePulse()`. Also not including `tk.firePulse()` would > make the test incomplete/ unreliable. >> Personally, I would tend to keep and ignore that test with doc: > > That is better to include the test now, else very doubtful of adding it in future. Including the test in next commit > with @Ignore("JDK-8242621"). can't reproduce the random crashing (but then, it's random :) And don't quite understand why you think the test being incomplete/unreliable without a firePulse (there are tons of tests without) - as long as we don't want to test the result of a layout pass, we should be fine. anyway, that's a different story, to me your fix and tests look fine ------------- PR: https://git.openjdk.java.net/jfx/pull/175 From joeri.sykora at gluonhq.com Wed Apr 15 13:21:35 2020 From: joeri.sykora at gluonhq.com (Joeri Sykora) Date: Wed, 15 Apr 2020 15:21:35 +0200 Subject: No tags for releases at github openjdk/jfx? In-Reply-To: References: Message-ID: You can find all tags for each release at https://github.com/openjdk/jfx/tags For OpenJFX versions 11, 12 and 13, you can find them in the previous repository: https://github.com/javafxports/openjdk-jfx/tags Greetings, Joeri On Wed, Apr 15, 2020 at 1:18 PM Florian Kirmaier wrote: > Hi everyone, > > I can't see any tags in the GitHub project for the various releases of > JavaFX. > I would like to know which commit is the base for various releases. > Specifically, I'm interested in the version 14 and 15-ea3. > Is there a place where I can look it up? > > Thanks, > Florian Kirmaier > -- Joeri Sykora *Gluon*E: joeri.sykora at gluonhq.com From kcr at openjdk.java.net Wed Apr 15 13:37:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 13:37:24 GMT Subject: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> References: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> Message-ID: On Fri, 10 Apr 2020 16:29:57 GMT, Guru Hb wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > Looks good to me. Tested on Windows and mac OS X. > If feasible can we have Unit test for this. As discussed offline, please add a test for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/164 From ajoseph at openjdk.java.net Wed Apr 15 15:14:49 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 15 Apr 2020 15:14:49 GMT Subject: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: > Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java > side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. > Fix: Override scale() method in WCBufferedContext class to call init() before scaling. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Added SVGTest ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/164/files - new: https://git.openjdk.java.net/jfx/pull/164/files/fb1c3934..86674653 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/164/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/164/webrev.01-02 Stats: 132 lines in 1 file changed: 132 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164 PR: https://git.openjdk.java.net/jfx/pull/164 From arapte at openjdk.java.net Wed Apr 15 16:09:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Apr 2020 16:09:24 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 10:02:47 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox: added FIXME with reference to issue The change looks good to me, however I have minor concern about selecting Separator, which should be taken in a follow on issue. It may need a change in `Separator` selection test here. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 416: > 415: } else { > 416: toggleGroup.selectToggle(null); > 417: } The `else` part here means that user programmatically has selected a `Separator` or `SeparatorMenuItem`. The behavior in such scenario is not defined in doc but the methods, `select()`, `selectNext()`, `selectPrevious()` of `ChoiceBox.ChoiceBoxSelectionModel` imply that if index points to a `Separator` then a valid item should be selected. However these method do handle this correctly. If these methods are implemented such that no Separator is allowed to be selected then this `else` part would not be needed and we might be able to remove the `instanceof` checks. The fix in this PR looks good to me. But we should also decide the behavior in above scenario and may be file a JBS. If we decide that when a `Separator` is chosen for selection then the current selection should not be changed or a valid item should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a follow on issue. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 347: > 346: // Test only purpose > 347: ContextMenu getChoiceBoxPopup() { > 348: return popup; I would recommend to prefix the method name with `test_.` It is not followed across, only `TabPaneSkin` has `test_` prefixed method. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From github.com+7450507+fthevenet at openjdk.java.net Wed Apr 15 17:23:15 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 15 Apr 2020 17:23:15 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> References: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> Message-ID: On Tue, 17 Mar 2020 15:31:20 GMT, Frederic Thevenet wrote: >>> >>> >>> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back >>> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this tiling be used to fix that? >> >> It won't help with things in their current state, as the `RenderToImage` method that is modified in this PR is >> currently called only by the snapshot feature in `Scene` But of course I suspect the same technique could also be used >> to solve [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) and now is indeed a good time to investigate >> it further. I'll have a look to see if it is possible to factorize the tiling implementation for both classes of >> issues, in which case it would make sense to do prior to merging this PR. If it is different enough that the >> implementation cannot be shared but only the general idea, then I suggest we address it in a different PR. What do you >> all think ? > > At first glance, the NPE in [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) occurs in the Prism layer, > which is one level _below_ Quantum where the tiling is currently implemented, so I'm not sure tit is reachable from > there; if we want the code to be shared, it looks like it would need to be moved even further down (maybe in the > `ResourceFactory`?) Also, while reusing code is generally the way to go, in such lower layers, very closely > intertwined with the actual rendering, I'm afraid that insisting on having a "one-size-fits-all" implementation might > get in the way of necessary case-by-case optimizations, so I'd like to have someone with a deeper knowledge of the > code base to weight in before starting work in that direction. Maybe @kevinrushforth could advise? Hi everyone, This PR hasn't seen much activity in a while, so I though I would give it a gentle kick to hopefully get it moving again ;) As explained above, I feel a little stalled at the moment, as we need to decide whether or not it is a good idea to try and address all or part of JDK-8189082 within the scope of this PR, and I don't feel like I can settle that on my own. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Wed Apr 15 20:30:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 20:30:17 GMT Subject: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:14:49 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java >> side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added SVGTest Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/164 From kcr at openjdk.java.net Wed Apr 15 21:01:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 21:01:59 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> On Wed, 15 Apr 2020 20:59:29 GMT, Kevin Rushforth wrote: >> I think @arapte has a similar MacBookPro model to mine. >> >> I think @prrace might be able to test it (I'll sync with him offline). > > Here are the results on Phil's machine, which is a Mac Book Pro with a graphics accelerator (Nvidia, I think). > > Without the patch: > 2000 quads average 8.805 fps > > With the patch: > 2000 quads average 4.719 fps > > Almost a 2x performance hit. Conclusion: The new shaders that support attenuation don't seem to have much of a performance impact on machines with an Intel HD, but on systems with a graphics accelerator, it is a significant slowdown. So we are left with the two choices of doubling the number of shaders (that is, a set of shaders with attenuation and a set without) or living with the performance hit (which will only be a problem on machines with a dedicated graphics accelerator for highly fill-limited scenes). The only way we can justify a 2x drop in performance is if we are fairly certain that this is a corner case, and thus unlikely to hit real applications. If we do end up deciding to replicate the shaders, I don't think it is all that much work. I'm more worried about how well it would scale to subsequent improvements, although we could easily decide that for, say, spotlights attenuation is so common that you wouldn't create a version that doesn't do that. In the D3D HLSL shaders, ifdefs are used, so the work would be to restore the original code and add the new code under an ifdef. Then double the number of lines of gradle (at that point, I'd do it in a for-each loop), then modify the logic that loads the shaders to pick the right one. For GLSL, the different parts of the shader are in different files, so it's a matter of creating new versions of each of the three lighting shaders that handle attenuation and choosing the right one at runtime. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Wed Apr 15 21:01:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 21:01:59 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: On Tue, 7 Apr 2020 23:03:21 GMT, Kevin Rushforth wrote: >> @arapte Can you please test the performance changes too? > > I think @arapte has a similar MacBookPro model to mine. > > I think @prrace might be able to test it (I'll sync with him offline). Here are the results on Phil's machine, which is a Mac Book Pro with a graphics accelerator (Nvidia, I think). Without the patch: 2000 quads average 8.805 fps With the patch: 2000 quads average 4.719 fps Almost a 2x performance hit. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Wed Apr 15 21:46:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 21:46:18 GMT Subject: [Rev 03] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <3KFaFGV14nY90FsyOZ0VTySsogloizqfaV5FIU_iX88=.a44be05b-c0c5-43b1-b90d-0dcb793746c3@github.com> Message-ID: <5ukOjx9H6os3yhP7oj2lqZVpgr5_tpxmCTORBq8r1Xo=.8e9ed593-2362-49f7-9ffb-ad5ba677f671@github.com> On Wed, 15 Apr 2020 17:20:55 GMT, Frederic Thevenet wrote: >> At first glance, the NPE in [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082) occurs in the Prism layer, >> which is one level _below_ Quantum where the tiling is currently implemented, so I'm not sure tit is reachable from >> there; if we want the code to be shared, it looks like it would need to be moved even further down (maybe in the >> `ResourceFactory`?) Also, while reusing code is generally the way to go, in such lower layers, very closely >> intertwined with the actual rendering, I'm afraid that insisting on having a "one-size-fits-all" implementation might >> get in the way of necessary case-by-case optimizations, so I'd like to have someone with a deeper knowledge of the >> code base to weight in before starting work in that direction. Maybe @kevinrushforth could advise? > > Hi everyone, > > This PR hasn't seen much activity in a while, so I though I would give it a gentle kick to hopefully get it moving > again ;) As explained above, I feel a little stalled at the moment, as we need to decide whether or not it is a good > idea to try and address all or part of JDK-8189082 within the scope of this PR, and I don't feel like I can settle > that on my own. Thanks. Sorry for the delay. This is on my review queue, which has been growing of late. I'll take a look at it soon. To answer one of your questions: > we need to decide whether or not it is a good idea to try and address all or part of JDK-8189082 within the scope of > this PR I think your idea of addressing the other similar cases (Canvas and SubScene in particular) in a follow-up PR seems fine. If, at that time, you find you can refactor this to share some of the implementation, that would be good. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kevin.rushforth at oracle.com Wed Apr 15 22:42:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 15 Apr 2020 15:42:03 -0700 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> Message-ID: <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> I just took another look at the SpinnerValueFactory API docs. The use of the term "circular" heavily implies modulo arithmetic as the expected behavior if wrapAround is true. That the usual meaning of "wrap" versus "clamp" when you have a range bounded on both ends. Maybe the confusion comes from the fact that it isn't stated as clearly as it might be, coupled with a single example of a step by one going from max to min (if incrementing). I note that example doesn't say what the amountToStepBy is, but it wasn't trying to be prescriptive. Since the current behavior of "wrap around unless you happen to wrap a bit too much and then we'll clamp" doesn't make sense in any universe that I can think of, it is fine to treat this as a bug. I'm not worried about "bug compatibility" here. Clarifying the spec at the same time seems like a good idea to me. A related issue is that the default value of wrapAround is not specified (the default is `false`, but you wouldn't know that from reading the docs). This should also be addressed at the same time. You mentioned that this is specific to IntegerValueFactory, but it looks like DoubleValueFactory (and maybe ListValueFactory) have the same bug. Or am I missing something? On an unrelated note, I just noticed that the SpinnerValueFactory constructor has no documentation. This is because it is an implicitly added constructor, which is an anti-pattern for public API. I'll file a separate issue for that. -- Kevin On 4/15/2020 2:23 AM, Jeanette Winzenburg wrote: > Hi Ajit, > > yes, I read the doc, probably a bit differently - could well be my > misunderstanding and misunderstandable wording :) > > Trying again: > > - I read your suggestion (in > https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. that > being at value and incrementing a full-cycle (that is max -min +1), I > will land on value again > - for me the doc seemed to imply that in such a case I would land on > min. Though, given the "circular" as you pointed out correctly, was my > misunderstanding > - the current implementation is buggy > (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating the > remainder (which is what the first bullet amounts to) incorrectly for > min != 0 > > Where do I err? > > -- Jeanette > > > Zitat von Ajit Ghaisas : > >> Hi Jeanette, >> >> The doc never assumes amountPerStep = 1. I am quoting it here - >> ?The wrapAround property is used to specify whether the value factory >> should be circular. For example, should an integer-based value model >> increment from the maximum value back to the minimum value (and vice >> versa).? >> >> The word ?circular? clarifies that once we exceed maximum value, we >> should start from minimum. >> I think, the doc is OK in it?s current form, but implementation needs >> to be corrected. >> >> Regards, >> Ajit >> >> >>> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg >>> wrote: >>> >>> >>> Hi Ajit, >>> >>> thought the doc was simply bad (in specifying the behavior for >>> amountPerStep = 1 and not thinking of larger amounts) - my expection >>> is a calculated wrap, that is the target as you suggest via modulo >>> the difference from current value. Don't know if anybody took the >>> doc literally .. >>> >>> -- Jeanette >>> >>> Zitat von Ajit Ghaisas : >>> >>>> Hi, >>>> >>>> ? Once I fix JDK-8193286, I would like to take up JDK-8242553 >>>> (IntegerSpinner does not wrap around values correctly if >>>> amountToStepBy is larger than total numbers between Max and Min) >>>> >>>> ? The current implementation is not as per what is documented. >>>> ? Refer : >>>> https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>>> >>>> ? I propose to fix the current buggy behavior of IntegerSpinner. >>>> ? Although it is a corner case, I would like to know if anybody >>>> relies on this buggy behavior? >>>> >>>> Regards, >>>> Ajit >>> >>> >>> > > > From kcr at openjdk.java.net Wed Apr 15 23:20:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 23:20:58 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 06:59:08 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 > > Root Cause : > Incorrect implementation. > Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. > Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. > > Fix : > Added a method for IntegerSpinnerValueFactory with separate implementation. > > Testing : > Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. > > Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed > separately. I'm not sure this is quite right, but I need to look at it more closely. It should fix the bug in question for well-behaved values, but might make it possible to return a value outside the range of [min, max]. I also want to think about it in light of [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). While a partial fix seems OK, we need to avoid the situation where some values cause a change from one buggy behavior to a different buggy behavior on the way to fixing it right. ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From almatvee at openjdk.java.net Wed Apr 15 23:25:06 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 15 Apr 2020 23:25:06 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first Message-ID: https://bugs.openjdk.java.net/browse/JDK-8242530 - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing separate callback to send messages to AVFoundation. ------------- Commit messages: - 8242530: [macos] Some audio files miss spectrum data when another audio file plays first Changes: https://git.openjdk.java.net/jfx/pull/184/files Webrev: https://webrevs.openjdk.java.net/jfx/184/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242530 Stats: 23 lines in 3 files changed: 19 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/184.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/184/head:pull/184 PR: https://git.openjdk.java.net/jfx/pull/184 From kcr at openjdk.java.net Wed Apr 15 23:38:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 23:38:29 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8242530 > > - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is > same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This > issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing > separate callback to send messages to AVFoundation. @arapte Can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/184 From kcr at openjdk.java.net Wed Apr 15 23:54:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Apr 2020 23:54:02 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8242530 > > - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is > same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This > issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing > separate callback to send messages to AVFoundation. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/184 From github.com+7517141+yososs at openjdk.java.net Thu Apr 16 06:36:54 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 16 Apr 2020 06:36:54 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> Message-ID: <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> On Wed, 15 Apr 2020 07:11:27 GMT, dannygonzalez wrote: >> @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the >> number of nodes in a TableView this is going to be a problem if the unregistering is slow.". >> Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands >> of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a >> single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the >> problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when >> the listeners are spread out over dozens of properties, and although high in total number, the total listeners per >> property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost >> unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. > > @hjohn > I haven't quantified exactly where all the listeners are coming from but the Node class for example has various > listeners on it. > The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly > (although it was still bad before this change in my previous tests): >> commit e21606d3a1b73cd4b44383babc750a4b4721edfd >> Author: Florian Kirmaier > >> Date: Tue Jan 22 09:08:36 2019 -0800 >> >> 8216377: Fix memoryleak for initial nodes of Window >> 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window >> >> Add or remove the windowShowingChangedListener when the scene changes > > As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having > multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant > performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all > needed especially around the Node class. I went directly to the source of the problem which was the linear search to > deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it > has saved it from being unusable due to the JavaFx thread being swamped. If the lifespan of a large number of registered listeners is biased, It seems like the next simple change can improve delete performance without changing the data structure. * Change the search from the front of the list to the search from the back. This will reduce the number of long-life listeners matching. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Thu Apr 16 07:14:08 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 07:14:08 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> Message-ID: <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> On Thu, 16 Apr 2020 06:34:39 GMT, yosbits wrote: >> @hjohn >> I haven't quantified exactly where all the listeners are coming from but the Node class for example has various >> listeners on it. >> The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly >> (although it was still bad before this change in my previous tests): >>> commit e21606d3a1b73cd4b44383babc750a4b4721edfd >>> Author: Florian Kirmaier > >>> Date: Tue Jan 22 09:08:36 2019 -0800 >>> >>> 8216377: Fix memoryleak for initial nodes of Window >>> 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window >>> >>> Add or remove the windowShowingChangedListener when the scene changes >> >> As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having >> multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant >> performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all >> needed especially around the Node class. I went directly to the source of the problem which was the linear search to >> deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it >> has saved it from being unusable due to the JavaFx thread being swamped. > > The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. > > I think that it is necessary to reproduce it by testing first, but > > If you just focus on improving listener removal performance, > > If the lifespan of a large number of registered listeners is biased, > It seems like the next simple change can improve delete performance without changing the data structure. > > * Change the search from the front of the list to the search from the back. > > This will reduce the number of long-life listeners matching. Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the number of nodes. A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really need to add these listeners and for which functionality and are there alternatives? It would also be possible to target only these specific properties with an optimized listener list to reduce the impact of this change. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Thu Apr 16 07:38:45 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 07:38:45 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> Message-ID: On Thu, 16 Apr 2020 07:11:58 GMT, John Hendrikx wrote: >> The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. >> >> I think that it is necessary to reproduce it by testing first, but >> >> If you just focus on improving listener removal performance, >> >> If the lifespan of a large number of registered listeners is biased, >> It seems like the next simple change can improve delete performance without changing the data structure. >> >> * Change the search from the front of the list to the search from the back. >> >> This will reduce the number of long-life listeners matching. > > Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd > it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` > property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the > number of nodes. > > A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but > I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us > an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really > need to add these listeners and for which functionality and are there alternatives? It would also be possible to > target only these specific properties with an optimized listener list to reduce the impact of this change. The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / showing status from there. No need for so many listeners. The other classes mentioned might register their own listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty specific classes only, not classes that you'd see a lot in a TableView...) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Thu Apr 16 08:26:35 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Thu, 16 Apr 2020 08:26:35 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> Message-ID: On Thu, 16 Apr 2020 07:34:40 GMT, John Hendrikx wrote: >> Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd >> it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` >> property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the >> number of nodes. >> >> A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but >> I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us >> an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really >> need to add these listeners and for which functionality and are there alternatives? It would also be possible to >> target only these specific properties with an optimized listener list to reduce the impact of this change. > > The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and > `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of > listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of > the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / > showing status from there. No need for so many listeners. The other classes mentioned might register their own > listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily > register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty > specific classes only, not classes that you'd see a lot in a TableView...) If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using 61% of the JavaFX thread whilst running our application. [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to see which classes are calling the removeListener function. ![Screenshot 2020-04-16 at 09 16 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Thu Apr 16 08:48:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 08:48:31 GMT Subject: RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8242530 > > - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is > same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This > issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing > separate callback to send messages to AVFoundation. looks good to me... ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/184 From jhendrikx at openjdk.java.net Thu Apr 16 08:50:25 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 08:50:25 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> Message-ID: <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> On Thu, 16 Apr 2020 08:24:16 GMT, dannygonzalez wrote: >> The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and >> `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of >> listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of >> the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / >> showing status from there. No need for so many listeners. The other classes mentioned might register their own >> listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily >> register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty >> specific classes only, not classes that you'd see a lot in a TableView...) > > If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using > 61% of the JavaFX thread whilst running our application. > [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) > > If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to > see which classes are calling the removeListener function. > ![Screenshot 2020-04-16 at 09 16 > 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw about 20000 change listeners registered on this single Scene Window property. However, this custom control is not creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going on, scrolling was still smooth >30 fps. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Thu Apr 16 09:07:32 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 09:07:32 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:46:16 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> ChoiceBox: added FIXME with reference to issue > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 416: > >> 415: } else { >> 416: toggleGroup.selectToggle(null); >> 417: } > > The `else` part here means that user programmatically has selected a `Separator` or `SeparatorMenuItem`. The behavior > in such scenario is not defined in doc but the methods, `select()`, `selectNext()`, `selectPrevious()` of > `ChoiceBox.ChoiceBoxSelectionModel` imply that if index points to a `Separator` then a valid item should be selected. > However these method do handle this correctly. If these methods are implemented such that no Separator is allowed to > be selected then this `else` part would not be needed and we might be able to remove the `instanceof` checks. The fix > in this PR looks good to me. But we should also decide the behavior in above scenario and may be file a JBS. If we > decide that when a `Separator` is chosen for selection then the current selection should not be changed or a valid item > should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a > follow on issue. yeah, you are right: a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as Separator): next/previous try to move on, the others simply select. The implementation changed in fix of [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261) - before select(index) tried to handle it, after this was moved into next/previous. Arguably, the model can do what it wants without specification ;) b) the skin is responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have a corresponding toggle (f.i. if it's a separator), all toggles must be unselected. c) my test related to the Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really selectable item :) My plan: 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I think) 2. fix the test to be resistant against implementation changes of selectionModel Thanks for the extensive review, very much appreciated :) ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Thu Apr 16 09:12:24 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 09:12:24 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:52:13 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> ChoiceBox: added FIXME with reference to issue > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 347: > >> 346: // Test only purpose >> 347: ContextMenu getChoiceBoxPopup() { >> 348: return popup; > > I would recommend to prefix the method name with `test_.` It is not followed across, only `TabPaneSkin` has `test_` > prefixed method. well, as TabPaneSkin is a singularity in controls (in graphics such a pattern seems to be wider-spread), I would prefer not to do it here - also because ChoiceBoxSkin has another test-only accessor (for label text) which doesn't. Might be a candidate for a general cleanup task - if we decide to really introduce such a naming convention (which I personally wouldn't like :) ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Thu Apr 16 09:19:30 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 09:19:30 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 09:05:12 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java line 416: >> >>> 415: } else { >>> 416: toggleGroup.selectToggle(null); >>> 417: } >> >> The `else` part here means that user programmatically has selected a `Separator` or `SeparatorMenuItem`. The behavior >> in such scenario is not defined in doc but the methods, `select()`, `selectNext()`, `selectPrevious()` of >> `ChoiceBox.ChoiceBoxSelectionModel` imply that if index points to a `Separator` then a valid item should be selected. >> However these method do handle this correctly. If these methods are implemented such that no Separator is allowed to >> be selected then this `else` part would not be needed and we might be able to remove the `instanceof` checks. The fix >> in this PR looks good to me. But we should also decide the behavior in above scenario and may be file a JBS. If we >> decide that when a `Separator` is chosen for selection then the current selection should not be changed or a valid item >> should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a >> follow on issue. > > yeah, you are right: > > a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as > Separator): next/previous try to move on, the others simply select. The implementation changed in fix of > [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261) - before select(index) tried to handle it, after this > was moved into next/previous. Arguably, the model can do what it wants without specification ;) b) the skin is > responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have > a corresponding toggle (f.i. if it's a separator), all toggles must be unselected. c) my test related to the > Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really > selectable item :) My plan: > 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I > think) 2. fix the test to be resistant against implementation changes of selectionModel > > Thanks for the extensive review, very much appreciated :) btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev @Test public void test_jdk_8988261_selectNext() { @Test public void test_jdk_8988261_selectPrevious() { the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, should be 8088261 (spelling error, I think) - is it okay to change them to the right id? ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From github.com+6702882+dannygonzalez at openjdk.java.net Thu Apr 16 09:47:37 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Thu, 16 Apr 2020 09:47:37 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> Message-ID: <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> On Thu, 16 Apr 2020 08:46:26 GMT, John Hendrikx wrote: >> If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using >> 61% of the JavaFX thread whilst running our application. >> [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) >> >> If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to >> see which classes are calling the removeListener function. >> ![Screenshot 2020-04-16 at 09 16 >> 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) > > @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random > node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with > a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw > about 20000 change listeners registered on this single Scene Window property. However, this custom control is not > creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going > on, scrolling was still smooth >30 fps. @hjohn I have 12136 change listeners when debugging our application as you suggested. Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I do not see the issue. It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Thu Apr 16 11:21:07 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 11:21:07 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> On Thu, 16 Apr 2020 09:17:19 GMT, Jeanette Winzenburg wrote: >> yeah, you are right: >> >> a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as >> Separator): next/previous try to move on, the others simply select. The implementation changed in fix of >> [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261) - before select(index) tried to handle it, after this >> was moved into next/previous. Arguably, the model can do what it wants without specification ;) b) the skin is >> responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have >> a corresponding toggle (f.i. if it's a separator), all toggles must be unselected. c) my test related to the >> Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really >> selectable item :) My plan: >> 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I >> think) 2. fix the test to be resistant against implementation changes of selectionModel >> >> Thanks for the extensive review, very much appreciated :) > > btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev > > @Test public void test_jdk_8988261_selectNext() { > @Test public void test_jdk_8988261_selectPrevious() { > > the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, > should be 8088261 (spelling error, I think) - is it okay to change them to the right id? > 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I > think) I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel. `seletPrevious()`, `selectNext()` need one more check `value instanceof SeparatorMenuItem`. and similarly `selectFirst()` and `selectLast()` should be overridden correctly. and I can't think of why `select()` was changed so may be rethink about it :). We can discuss it again whenever we start fixing it. > 2. fix the test to be resistant against implementation changes of selectionModel Thanks for link to [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261), As mentioned in this bug description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a separator, but it must not select an arbitrary index instead", So It is not sure to me what should `select()` do in such scenario. So I think the test can also go as is, in case we change the behavior then test can be changed with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From arapte at openjdk.java.net Thu Apr 16 11:25:31 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 11:25:31 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> References: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> Message-ID: On Thu, 16 Apr 2020 11:18:55 GMT, Ambarish Rapte wrote: >> btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev >> >> @Test public void test_jdk_8988261_selectNext() { >> @Test public void test_jdk_8988261_selectPrevious() { >> >> the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, >> should be 8088261 (spelling error, I think) - is it okay to change them to the right id? > >> 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I >> think) > > I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel. > `seletPrevious()`, `selectNext()` need one more check `value instanceof SeparatorMenuItem`. > and similarly `selectFirst()` and `selectLast()` should be overridden correctly. > and I can't think of why `select()` was changed so may be rethink about it :). > We can discuss it again whenever we start fixing it. > > >> 2. fix the test to be resistant against implementation changes of selectionModel > > Thanks for link to [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261), As mentioned in this bug > description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a > separator, but it must not select an arbitrary index instead", So It is not sure to me what should `select()` do in > such scenario. So I think the test can also go as is, in case we change the behavior then test can be changed with it. > should be 8088261 (spelling error, I think) - is it okay to change them to the right id? That will be good to change, but not sure if as part of this bug. It will be unrelated to fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From aghaisas at openjdk.java.net Thu Apr 16 11:38:17 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 16 Apr 2020 11:38:17 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 23:18:46 GMT, Kevin Rushforth wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 >> >> Root Cause : >> Incorrect implementation. >> Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. >> Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. >> >> Fix : >> Added a method for IntegerSpinnerValueFactory with separate implementation. >> >> Testing : >> Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. >> >> Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed >> separately. > > I'm not sure this is quite right, but I need to look at it more closely. It should fix the bug in question for > well-behaved values, but might make it possible to return a value outside the range of [min, max]. > I also want to think about it in light of [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). While a > partial fix seems OK, we need to avoid the situation where some values cause a change from one buggy behavior to a > different buggy behavior on the way to fixing it right. The fix works for well behaved values - and - maintains buggy behavior (to be addressed in JDK-8242553) if (amountToStepBy * no of steps) is greater than the total numbers between min and max. The Spinner.wrapValue() does return value outside min-max range if (amountToStepBy * steps) is greater than total numbers between min and max. It gets clamped to either min or max based on condition in IntegerSpinnerValueFactory valueProperty() listener. I am planning to change Spinner.wrapValue() to use modulo as part of JDK-8242553. This fix is restricted to addressing the issue of stepping through of valid (amountToStepBy * no of steps) which was reported as bug. ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From github.com+2720909+jskov at openjdk.java.net Thu Apr 16 13:48:35 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Thu, 16 Apr 2020 13:48:35 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() Message-ID: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 ------------- Commit messages: - 8198402: Fix ToggleButton leak in ToggleGroup Changes: https://git.openjdk.java.net/jfx/pull/167/files Webrev: https://webrevs.openjdk.java.net/jfx/167/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8198402 Stats: 117 lines in 3 files changed: 102 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/167.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/167/head:pull/167 PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Thu Apr 16 13:48:35 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Thu, 16 Apr 2020 13:48:35 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov wrote: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 /signed ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From fastegal at openjdk.java.net Thu Apr 16 15:04:53 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 15:04:53 GMT Subject: [Rev 02] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: Message-ID: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> > Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the > informally ignored test part for memory leak. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: ChoiceBox/-Skin/-SelectionTest - added code comments to clarify test/implemenation intention ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/177/files - new: https://git.openjdk.java.net/jfx/pull/177/files/0d3ce123..01aa7901 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/177/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/177/webrev.01-02 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177 From fastegal at openjdk.java.net Thu Apr 16 15:05:04 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Apr 2020 15:05:04 GMT Subject: [Rev 01] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: References: <1MBmOY-d5Eec15K1cnJ3-O0waOQXShoBeB5hsTqD_vY=.1122ff80-c9f8-4600-ac4a-cc76d9ec103d@github.com> Message-ID: On Thu, 16 Apr 2020 11:23:24 GMT, Ambarish Rapte wrote: >>> 1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I >>> think) >> >> I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel. >> `seletPrevious()`, `selectNext()` need one more check `value instanceof SeparatorMenuItem`. >> and similarly `selectFirst()` and `selectLast()` should be overridden correctly. >> and I can't think of why `select()` was changed so may be rethink about it :). >> We can discuss it again whenever we start fixing it. >> >> >>> 2. fix the test to be resistant against implementation changes of selectionModel >> >> Thanks for link to [JDK-8088261](https://bugs.openjdk.java.net/browse/JDK-8088261), As mentioned in this bug >> description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a >> separator, but it must not select an arbitrary index instead", So It is not sure to me what should `select()` do in >> such scenario. So I think the test can also go as is, in case we change the behavior then test can be changed with it. > >> should be 8088261 (spelling error, I think) - is it okay to change them to the right id? > > That will be good to change, but not sure if as part of this bug. It will be unrelated to fix. At the end and following your latest comments I did nothing Except adding code comments to the separator test and the else (toggle nulling) branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From arapte at openjdk.java.net Thu Apr 16 16:09:42 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 16:09:42 GMT Subject: [Rev 02] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> References: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> Message-ID: On Thu, 16 Apr 2020 15:04:53 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox/-Skin/-SelectionTest > > - added code comments to clarify test/implemenation intention Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From jhendrikx at openjdk.java.net Thu Apr 16 16:17:43 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 16 Apr 2020 16:17:43 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Thu, 16 Apr 2020 09:45:20 GMT, dannygonzalez wrote: >> @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random >> node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with >> a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw >> about 20000 change listeners registered on this single Scene Window property. However, this custom control is not >> creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going >> on, scrolling was still smooth >30 fps. > > @hjohn I have 12136 change listeners when debugging our application as you suggested. > > Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I > do not see the issue. > It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. > The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with 20.000 nested stack panes resulted in these average times: - Add all 51 ms - Remove all 25 ms Versus the unmodified code: - Add all 34 ms - Remove all 135 ms However, there are some significant functional changes as well that might impact current users: 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window and have Scene provide a new combined status property that Node could use for its purposes. Even better however would be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener lists much shorter, which should scale a lot better. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Thu Apr 16 16:28:38 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 16 Apr 2020 16:28:38 GMT Subject: RFR: 8241582: Infinite animation does not start from the end when started with a negative rate In-Reply-To: References: Message-ID: On Fri, 10 Apr 2020 06:31:39 GMT, Nir Lisker wrote: > ### Cause > > `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly. This causes > `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start the animation not from the end, depending > on the modulo calculation. ### Fix > > For infinite cycles, use the `cycleDuration` as the destination since that is the effective end point. > > ### Tests > > * Added an `testJumpTo_IndefiniteCycles` test that fails without the patch and passes after it. > * Added a `testJumpTo_IndefiniteCycleDuration` that passes both before and after, just to make sure that this type of > infinite duration is correct. > * Removed a test in `SequentialTransition` that fails with this patch, but it passed before it only because the modulo > value happened to land in the right place. Changing the duration of one of the child animation can cause it to fail, so > the test is faulty anyway at this stage. > > ### Future work > > Playing backwards will still not work correctly, but at least now it start from the correct value. This is the first of > a series of fixes under the umbrella issue [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238). looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/169 From github.com+1413266+jgneff at openjdk.java.net Thu Apr 16 19:31:22 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 16 Apr 2020 19:31:22 GMT Subject: [Rev 01] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: > This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements > [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* > repository. Some of the changes were made to support the new device models, while others are minor changes to the > existing support in JavaFX 13. The following changes were made to support the new device models. > * Work around problems on the Kobo Glo HD Model N437. > > Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is > ignored by the driver on the Kobo Glo HD where the error occurs, anyway. > > Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of > the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame > buffer device driver can be an incorrect value. > > * Work around problems on the Kobo Clara HD Model N249. > > The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the > normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The > work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. > > The following changes were made to the existing code that supports e-paper displays in JavaFX 13. > > * Use the correct constant for the number of bytes per pixel. > > Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when > calculating the capacity of the 32-bit off-screen byte buffer. > > * Do not round the luma value to the nearest integer. > > Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of > rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 > percent and doesn't seem worth it for a display with just 16 levels of gray. > > * Change camel case of system property *y8inverted*. > > Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it > is consistent with the other system properties containing Y1, Y4, and Y8 in their names. > > * Improve error handling when mapping the frame buffer. > > Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a > `null` return value from `EPDFrameBuffer.getMappedBuffer`. > > * Replace non-ASCII characters with their ASCII equivalent. > > Replace non-ASCII characters in comments and log messages as follows: > > * "?" with "x" for display resolution and color depth, > * "?" with "*" for multiplication, > * "?" with "to" for transition, and > * "?C" with "degrees Celsius" for temperature. > > * Add descriptions to Monocle EPD system properties. > > Add Javadoc comments to each constant that defines a Monocle EPD system property. > > * Rename `IntStructure.getInteger` to `IntStructure.get`. > > Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method > `Integer.getInteger`, which gets the integer value of a system property. > > Below are some of the more interesting test results. > > * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray > values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. > > * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black > for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that > displays black for values `0x7F` or less and white for values `0x80` or greater. > > * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the > tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame > buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows the animation speed of each model in > milliseconds per frame and frames per second. > > | Product Name | Speed (ms) | Rate (fps) | > | ------------- |:----------:|:----------:| > | Kobo Touch B | 125 | 8.0 | > | Kobo Touch C | 130 | 7.7 | > | Kobo Glo HD | 140 | 7.1 | > | Kobo Clara HD | 145 | 6.9 | John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into monocle-epd-imx6 - 8227425: Add support for e-paper displays on i.MX6 devices ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/60/files - new: https://git.openjdk.java.net/jfx/pull/60/files/aa335246..f7028e89 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/60/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/60/webrev.00-01 Stats: 322794 lines in 6225 files changed: 185606 ins; 92697 del; 44491 mod Patch: https://git.openjdk.java.net/jfx/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60 PR: https://git.openjdk.java.net/jfx/pull/60 From github.com+1413266+jgneff at openjdk.java.net Thu Apr 16 20:47:26 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 16 Apr 2020 20:47:26 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: On Thu, 5 Dec 2019 00:14:34 GMT, John Neffenger wrote: >> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements >> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* >> repository. Some of the changes were made to support the new device models, while others are minor changes to the >> existing support in JavaFX 13. The following changes were made to support the new device models. >> * Work around problems on the Kobo Glo HD Model N437. >> >> Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is >> ignored by the driver on the Kobo Glo HD where the error occurs, anyway. >> >> Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of >> the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame >> buffer device driver can be an incorrect value. >> >> * Work around problems on the Kobo Clara HD Model N249. >> >> The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the >> normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The >> work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. >> >> The following changes were made to the existing code that supports e-paper displays in JavaFX 13. >> >> * Use the correct constant for the number of bytes per pixel. >> >> Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when >> calculating the capacity of the 32-bit off-screen byte buffer. >> >> * Do not round the luma value to the nearest integer. >> >> Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of >> rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 >> percent and doesn't seem worth it for a display with just 16 levels of gray. >> >> * Change camel case of system property *y8inverted*. >> >> Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it >> is consistent with the other system properties containing Y1, Y4, and Y8 in their names. >> >> * Improve error handling when mapping the frame buffer. >> >> Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a >> `null` return value from `EPDFrameBuffer.getMappedBuffer`. >> >> * Replace non-ASCII characters with their ASCII equivalent. >> >> Replace non-ASCII characters in comments and log messages as follows: >> >> * "?" with "x" for display resolution and color depth, >> * "?" with "*" for multiplication, >> * "?" with "to" for transition, and >> * "?C" with "degrees Celsius" for temperature. >> >> * Add descriptions to Monocle EPD system properties. >> >> Add Javadoc comments to each constant that defines a Monocle EPD system property. >> >> * Rename `IntStructure.getInteger` to `IntStructure.get`. >> >> Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method >> `Integer.getInteger`, which gets the integer value of a system property. >> >> Below are some of the more interesting test results. >> >> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray >> values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. >> >> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black >> for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that >> displays black for values `0x7F` or less and white for values `0x80` or greater. >> >> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the >> tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame >> buffer. I plan to investigate the cause of the performance difference. >> >> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold >> increase in the number of pixels in their displays. The table below shows the animation speed of each model in >> milliseconds per frame and frames per second. >> >> | Product Name | Speed (ms) | Rate (fps) | >> | ------------- |:----------:|:----------:| >> | Kobo Touch B | 125 | 8.0 | >> | Kobo Touch C | 130 | 7.7 | >> | Kobo Glo HD | 140 | 7.1 | >> | Kobo Clara HD | 145 | 6.9 | > > /signed @kevinrushforth Did I merge the upstream master branch correctly? The [last time I did this](https://github.com/javafxports/openjdk-jfx/pull/522/commits) on the old *openjdk-jfx* repository, the pull request showed only the single merge commit. This time all 87 commits from the upstream master branch are shown as part of this pull request, even though the code I propose has not changed since the pull request was created on December 4, 2019. Let me know if you would like me to rebase my changes and *force push* a cleaner update. While I have your attention ... would you be able to be my second reviewer? This pull request is a small update that completes the large project begun by [JDK-8217605](https://github.com/javafxports/openjdk-jfx/pull/369) over a year ago. Your comments on that first part were very helpful, so I'm hoping you can bring that experience to this second and final part of the project. ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From jvos at openjdk.java.net Thu Apr 16 21:16:23 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Apr 2020 21:16:23 GMT Subject: RFR: 8242577: Cell selection fails on iOS most of the times In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:31:18 GMT, Jose Pereda wrote: > There are cases when iOS sends one or more NSTouchPhaseMoved for a given touch event, in between NSTouchPhaseBegan and > NSTouchPhaseEnded , even if the initial event location didn't change. > By default, all these events are emulated as mouse enter/down, drag and up/exit events. > > However, when the user taps quickly or even holds steady on a cell, if these touch moved events are generated and sent > as mouse drag events, the cell selection fails, as the flag `latePress` used in > [CellBehaviorBase](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java#L191) > is set to false, preventing the cell selection that should happen upon touch release event. This PR prevents emulating > mouse drag events when the touch event doesn't change its location. looks good. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/181 From aghaisas at openjdk.java.net Fri Apr 17 06:08:54 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 06:08:54 GMT Subject: [Rev 02] RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection In-Reply-To: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> References: <_5eM0Z9l6pzZH6muKs8sFgok4LkVk0kOJ7xkqHP0JMo=.5d9466dc-0a9d-4319-9f45-1200a50d6936@github.com> Message-ID: On Thu, 16 Apr 2020 15:04:53 GMT, Jeanette Winzenburg wrote: >> Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else >> block when updating toggle selection state (see report for details). >> Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the >> incorrect selection state >> - removed listener to selected item >> - removed toggle selection update in showing listener >> >> The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel >> is null initially. >> Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some >> to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the >> informally ignored test part for memory leak. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > ChoiceBox/-Skin/-SelectionTest > > - added code comments to clarify test/implemenation intention Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/177 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 07:10:24 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 07:10:24 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Thu, 16 Apr 2020 16:15:20 GMT, John Hendrikx wrote: >> @hjohn I have 12136 change listeners when debugging our application as you suggested. >> >> Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I >> do not see the issue. >> It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. >> The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. > > I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with > 20.000 nested stack panes resulted in these average times: > - Add all 51 ms > - Remove all 25 ms > > Versus the unmodified code: > > - Add all 34 ms > - Remove all 135 ms > > However, there are some significant functional changes as well that might impact current users: > > 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making > a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This > can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to > check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each > listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per > entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still > well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener > implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes > care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with > respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last > point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs > well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think > this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced > another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window > and have Scene provide a new combined status property that Node could use for its purposes. Even better however would > be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen > to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single > property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener > lists much shorter, which should scale a lot better. @hjon > 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of > times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, > a) the notification order will be (a, a, b). Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as registration which was the case when I used a HashMap. See here: https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 07:24:35 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 07:24:35 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 07:08:01 GMT, dannygonzalez wrote: >> I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with >> 20.000 nested stack panes resulted in these average times: >> - Add all 51 ms >> - Remove all 25 ms >> >> Versus the unmodified code: >> >> - Add all 34 ms >> - Remove all 135 ms >> >> However, there are some significant functional changes as well that might impact current users: >> >> 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making >> a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This >> can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to >> check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each >> listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per >> entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still >> well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener >> implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes >> care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with >> respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last >> point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs >> well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think >> this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced >> another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window >> and have Scene provide a new combined status property that Node could use for its purposes. Even better however would >> be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen >> to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single >> property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener >> lists much shorter, which should scale a lot better. > > @hjon > >> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of >> times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, >> a) the notification order will be (a, a, b). > > Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of > notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as > registration which was the case when I used a HashMap. See here: > https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 @hjohn > 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each > listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more > heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a > further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to the hierarchy as you mentioned). This was mentioned here also: https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Apr 17 07:55:31 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 17 Apr 2020 07:55:31 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 07:22:20 GMT, dannygonzalez wrote: >> @hjon >> >>> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of >>> times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, >>> a) the notification order will be (a, a, b). >> >> Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of >> notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as >> registration which was the case when I used a HashMap. See here: >> https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 > > @hjohn > >> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each >> listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more >> heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a >> further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). > > There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where > we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to > the hierarchy as you mentioned). This was mentioned here also: > https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 I've implemented an alternative solution: Removing the listeners on `Window.showingProperty` and `Scene.windowProperty` completely. They are in fact only used in two places: `PopupWindow` in order to remove itself if the `Window` is no longer showing, and `ProgressIndicatorSkin`. These two can be easily replaced with their own listeners for these properties instead of burdening **all** nodes with these listeners only to support these two classes. I left the `isTreeShowing` method in, and implemented it simply as `isTreeVisible() && isWindowShowing()` as that's really the only difference between "visible" and "showing" apparently. Here is the test result with 20.000 nested StackPanes with only this change in: - Add all 45 ms - Remove all 25 ms I think this might be a good solution as it completely avoids these listeners. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Apr 17 08:09:26 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 17 Apr 2020 08:09:26 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 07:22:20 GMT, dannygonzalez wrote: >> @hjon >> >>> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of >>> times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, >>> a) the notification order will be (a, a, b). >> >> Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of >> notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as >> registration which was the case when I used a HashMap. See here: >> https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 > > @hjohn > >> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each >> listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more >> heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a >> further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). > > There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where > we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to > the hierarchy as you mentioned). This was mentioned here also: > https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 08:50:52 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 08:50:52 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 08:07:08 GMT, John Hendrikx wrote: >> @hjohn >> >>> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each >>> listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more >>> heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a >>> further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). >> >> There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where >> we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to >> the hierarchy as you mentioned). This was mentioned here also: >> https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 > > @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I know my changes may be more fundamental and hence risky. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:33 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Tue, 14 Apr 2020 09:04:40 GMT, Ajit Ghaisas wrote: >> was: https://github.com/openjdk/jfx/pull/136 > > I am taking a look at your changes now. > @ccavanaugh can you make jcheck pass while I review. Please see the details of the failing jcheck. Thank you. I've updated the pull request comments with what I thought was the necessary changes, but jcheck is still failing with "the commits in this PR have inconsistent user names and/or email addresses. Please amend the commits." I'm not sure what to do with this error. Thanks, Craig On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas wrote: > I am taking a look at your changes now. > @ccavanaugh can you make jcheck pass > while I review. Please see the details of the failing jcheck. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From fastegal at openjdk.java.net Fri Apr 17 09:26:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> On Thu, 9 Apr 2020 09:37:30 GMT, Craig Cavanaugh wrote: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! was: https://github.com/openjdk/jfx/pull/136 ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From kcr at openjdk.java.net Fri Apr 17 09:26:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Tue, 14 Apr 2020 10:43:30 GMT, Craig Cavanaugh wrote: >> I am taking a look at your changes now. >> @ccavanaugh can you make jcheck pass while I review. Please see the details of the failing jcheck. > > Thank you. I've updated the pull request comments with what I thought was > the necessary changes, but jcheck is still failing with > > "the commits in this PR have inconsistent user names and/or email > addresses. Please amend the commits." > > I'm not sure what to do with this error. > > Thanks, > Craig > > On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas > wrote: > >> I am taking a look at your changes now. >> @ccavanaugh can you make jcheck pass >> while I review. Please see the details of the failing jcheck. >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> >> . >> I think you will need to rebase and force push your branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From aghaisas at openjdk.java.net Fri Apr 17 09:26:33 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Fri, 10 Apr 2020 10:22:29 GMT, Jeanette Winzenburg wrote: >> https://bugs.openjdk.java.net/browse/JDK-8129123 >> >> This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. >> Also, I believe JDK-8196037 is a duplicate of this issue. >> >> I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. >> >> Thanks! > > was: https://github.com/openjdk/jfx/pull/136 I am taking a look at your changes now. @ccavanaugh can you make jcheck pass while I review. Please see the details of the failing jcheck. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From kcr at openjdk.java.net Fri Apr 17 09:26:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 09:26:34 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> On Thu, 16 Apr 2020 10:01:14 GMT, Craig Cavanaugh wrote: >> I think you will need to rebase and force push your branch. > > Seems I've made a further mess attempting to rebase. I apologize as I know > the list is not intended to be tech support for git usage, but I'm at a > loss and don't want to make it worse. > > Below is the log after an interactive rebase and forced push. > > "" > Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123 > > branches 8129123, origin/8129123 > "" > > Thanks, > Craig > > On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth > wrote: > >> I think you will need to rebase and force push your branch. >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> >> . >> The following should work: $ git rebase -i master If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the following: $ git push --force origin 8129123 ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:34 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:34 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> Message-ID: On Thu, 16 Apr 2020 12:30:20 GMT, Kevin Rushforth wrote: >> Seems I've made a further mess attempting to rebase. I apologize as I know >> the list is not intended to be tech support for git usage, but I'm at a >> loss and don't want to make it worse. >> >> Below is the log after an interactive rebase and forced push. >> >> "" >> Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123 >> >> branches 8129123, origin/8129123 >> "" >> >> Thanks, >> Craig >> >> On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth >> wrote: >> >>> I think you will need to rebase and force push your branch. >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> > > The following should work: > > $ git rebase -i master > > If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is > already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the > following: $ git push --force origin 8129123 That did it! Thanks! On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth wrote: > The following should work: > > $ git rebase -i master > > If the rebase is successful, it will pop you into your EDITOR. You then > select "pick" for the first commit (which is already selected by default) > and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good > to you, do the following: > > $ git push --force origin 8129123 > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:34 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:34 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> Message-ID: On Tue, 14 Apr 2020 11:11:13 GMT, Kevin Rushforth wrote: >> Thank you. I've updated the pull request comments with what I thought was >> the necessary changes, but jcheck is still failing with >> >> "the commits in this PR have inconsistent user names and/or email >> addresses. Please amend the commits." >> >> I'm not sure what to do with this error. >> >> Thanks, >> Craig >> >> On Tue, Apr 14, 2020 at 5:04 AM Ajit Ghaisas >> wrote: >> >>> I am taking a look at your changes now. >>> @ccavanaugh can you make jcheck pass >>> while I review. Please see the details of the failing jcheck. >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> > > I think you will need to rebase and force push your branch. Seems I've made a further mess attempting to rebase. I apologize as I know the list is not intended to be tech support for git usage, but I'm at a loss and don't want to make it worse. Below is the log after an interactive rebase and forced push. "" Merge branch '8129123' of https://github.com/ccavanaugh/jfx into 8129123 branches 8129123, origin/8129123 "" Thanks, Craig On Tue, Apr 14, 2020 at 7:11 AM Kevin Rushforth wrote: > I think you will need to rebase and force push your branch. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Fri Apr 17 09:26:33 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Fri, 17 Apr 2020 09:26:33 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set Message-ID: https://bugs.openjdk.java.net/browse/JDK-8129123 This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. Also, I believe JDK-8196037 is a duplicate of this issue. I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. Thanks! ------------- Commit messages: - Fix for JDK-8129123 Changes: https://git.openjdk.java.net/jfx/pull/166/files Webrev: https://webrevs.openjdk.java.net/jfx/166/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8129123 Stats: 51 lines in 2 files changed: 49 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/166/head:pull/166 PR: https://git.openjdk.java.net/jfx/pull/166 From jhendrikx at openjdk.java.net Fri Apr 17 10:24:37 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 17 Apr 2020 10:24:37 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 08:48:35 GMT, dannygonzalez wrote: >> @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 > > @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being > swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped > off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node > hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck > which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners > to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now > where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I > feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I > know my changes may be more fundamental and hence risky. The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very limited cases, and its addition in the past may have slipped through the cracks. Adding a performance unit test that specifically checks add/remove performance of nodes may prevent such future regressions. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From aghaisas at openjdk.java.net Fri Apr 17 10:37:21 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 10:37:21 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> Message-ID: <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> On Fri, 17 Apr 2020 09:21:25 GMT, Craig Cavanaugh wrote: >> The following should work: >> >> $ git rebase -i master >> >> If the rebase is successful, it will pop you into your EDITOR. You then select "pick" for the first commit (which is >> already selected by default) and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good to you, do the >> following: $ git push --force origin 8129123 > > That did it! > > Thanks! > > On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth > wrote: > >> The following should work: >> >> $ git rebase -i master >> >> If the rebase is successful, it will pop you into your EDITOR. You then >> select "pick" for the first commit (which is already selected by default) >> and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good >> to you, do the following: >> >> $ git push --force origin 8129123 >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , or >> unsubscribe >> >> . >> I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired result for ComboBox. It is nice to have behavior and I am OK with the fix. > Also, I believe JDK-8196037 is a duplicate of this issue. Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. I have a minor comment regarding test. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From aghaisas at openjdk.java.net Fri Apr 17 10:40:58 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 17 Apr 2020 10:40:58 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 09:37:30 GMT, Craig Cavanaugh wrote: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2097: > 2096: first <= index && index <= last); > 2097: > 2098: index = LIST_SIZE - 1; You have tested first and last index selection. It will be nice to have a case where we select index = LIST_SIZE/2 ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From fastegal at openjdk.java.net Fri Apr 17 10:46:45 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 17 Apr 2020 10:46:45 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Fri, 17 Apr 2020 10:34:54 GMT, Ajit Ghaisas wrote: >> That did it! >> >> Thanks! >> >> On Thu, Apr 16, 2020 at 8:30 AM Kevin Rushforth >> wrote: >> >>> The following should work: >>> >>> $ git rebase -i master >>> >>> If the rebase is successful, it will pop you into your EDITOR. You then >>> select "pick" for the first commit (which is already selected by default) >>> and "s"quash or "f"ixup for all subsequent commits. Then, if it looks good >>> to you, do the following: >>> >>> $ git push --force origin 8129123 >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> > > I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired > result for ComboBox. It is nice to have behavior and I am OK with the fix. >> Also, I believe JDK-8196037 is a duplicate of this issue. > > Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. > > I have a minor comment regarding test. repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered :) ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Apr 17 10:49:10 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 17 Apr 2020 10:49:10 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 10:22:15 GMT, John Hendrikx wrote: >> @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being >> swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped >> off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node >> hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck >> which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners >> to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now >> where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I >> feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I >> know my changes may be more fundamental and hence risky. > > The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for > each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change > would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very > limited cases, and its addition in the past may have slipped through the cracks. Adding a performance unit test that > specifically checks add/remove performance of nodes may prevent such future regressions. @hjohn, agreed regards the issues of adding a listener to each node. Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own listeners to make this a pull request that can be reviewed officially? I await any further comments from @kevinrushforth et al. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From arapte at openjdk.java.net Fri Apr 17 13:00:19 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 17 Apr 2020 13:00:19 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> On Tue, 14 Apr 2020 11:15:32 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > Some code cleanups Changes requested by arapte (Reviewer). modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java line 124: > 123: int index = getWindowIndex(window); > 124: if (index != -1 && window.isVisible()) { > 125: focusedWindow = window; This change is sufficient for the test to pass, are there any other scenarios for which the changes in Window.java are needed. If so could you please add the relevant tests. tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 103: > 102: assertCollectable(closedFocusedStageWeak); > 103: } > 104: The current test does not assure that stage is shown when `close()` is called or it is closed when `requestFocus()` is called, I would recommend the test to be as, @Test public void testClosedFocusedStageLeak() throws Exception { CountDownLatch latch = new CountDownLatch(1); Util.runAndWait(() -> { closedFocusedStage = new Stage(); closedFocusedStage.setTitle("Focused Stage"); closedFocusedStageWeak = new WeakReference<>(closedFocusedStage); TextField textField = new TextField(); closedFocusedStage.setScene(new Scene(textField)); closedFocusedStage.setOnShown(l -> { latch.countDown(); }); closedFocusedStage.show(); }); Assert.assertTrue("Timeout waiting for closedFocusedStage to show`", latch.await(15, TimeUnit.MILLISECONDS)); CountDownLatch hideLatch = new CountDownLatch(1); closedFocusedStage.setOnHidden(a -> { hideLatch.countDown(); }); Util.runAndWait(() -> closedFocusedStage.close()); Assert.assertTrue("Timeout waiting for closedFocusedStage to hide`", hideLatch.await(15, TimeUnit.MILLISECONDS)); closedFocusedStage.requestFocus(); closedFocusedStage = null; assertCollectable(closedFocusedStageWeak); } ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From arapte at openjdk.java.net Fri Apr 17 13:00:20 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 17 Apr 2020 13:00:20 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:47:55 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77: >> >>> 76: Platform.runLater(() -> stage.close()); >>> 77: } >>> 78: >> >> Looks like the primary `stage` is not required for actual test, and this block is only used to initialize JavaFX >> runtime. Please check if it can be replaced by below block >> ``` >> @BeforeClass >> public static void initFX() throws Exception { >> startupLatch = new CountDownLatch(1); >> Platform.startup(startupLatch::countDown); >> Assert.assertTrue("Timeout waiting for FX runtime to start", >> startupLatch.await(15, TimeUnit.MILLISECONDS)); >> } > > This version doesn't work for me. > With this change, I get the following error: > test.javafx.stage.FocusedWindowTest > testLeak FAILED > junit.framework.AssertionFailedError: Exceeded timeout limit of 10000 msec > at test.util.Util.runAndWait(Util.java:163) > at test.util.Util.runAndWait(Util.java:134) > at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:82) This is happening because after the last stage is closed JavaFX runtime shuts down implicitly unless specified otherwise using `Platform.setImplicitExit(false);`. So `initFX()` should look as, ``` @BeforeClass public static void initFX() throws Exception { startupLatch = new CountDownLatch(1); Platform.startup(startupLatch::countDown); Platform.setImplicitExit(false); Assert.assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.MILLISECONDS)); } >> tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53: >> >>> 52: System.setProperty("monocle.platform","Headless"); >>> 53: } >>> 54: >> >> The test will always run with Monocle. I see that if this static block is removed then the test fails on Windows 10. >> Can you please verify all the platforms and change the test such that it runs on all platforms/ combinations. > > I wasn't able to reproduce the Problem on Window10 with VirtualBox. > > How should I do it? Add a second test class without the static code? Do you have a good recommendation on how to add it? The previous version of test failed on my Windows 10 machine with below exception, but the updated version does not fail, test.javafx.stage.FocusedWindowTest > testLeak FAILED junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 5fe60662 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNull(Assert.java:233) at junit.framework.Assert.assertNull(Assert.java:226) at test.javafx.stage.FocusedWindowTest.assertCollectable(FocusedWindowTest.java:133) at test.javafx.stage.FocusedWindowTest.testLeakOnce(FocusedWindowTest.java:116) at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:84) ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From arapte at openjdk.java.net Fri Apr 17 13:00:20 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 17 Apr 2020 13:00:20 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 19:19:16 GMT, Ambarish Rapte wrote: >> I wasn't able to reproduce the Problem on Window10 with VirtualBox. >> >> How should I do it? Add a second test class without the static code? Do you have a good recommendation on how to add it? > > The previous version of test failed on my Windows 10 machine with below exception, but the updated version does not > fail, > test.javafx.stage.FocusedWindowTest > testLeak FAILED > junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 5fe60662 > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertNull(Assert.java:233) > at junit.framework.Assert.assertNull(Assert.java:226) > at test.javafx.stage.FocusedWindowTest.assertCollectable(FocusedWindowTest.java:133) > at test.javafx.stage.FocusedWindowTest.testLeakOnce(FocusedWindowTest.java:116) > at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:84) > Do you have a good recommendation on how to add it? May be a test like `MeshManagerCacheLeakTest` should be able to solve the problem. I have not tried it myself, please check if it can help here. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From ghb at openjdk.java.net Fri Apr 17 13:30:30 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 17 Apr 2020 13:30:30 GMT Subject: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:14:49 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java >> side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added SVGTest Looks good to me , verified on mac os x and windows. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/164 From jvos at openjdk.java.net Fri Apr 17 14:43:52 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Apr 2020 14:43:52 GMT Subject: [jfx14] RFR: 8242839: Create release notes for JavaFX 14.0.1 Message-ID: Add release notes for 14.0.1 Fix for JDK-8242839 ------------- Commit messages: - Add release notes for 14.0.1 Changes: https://git.openjdk.java.net/jfx/pull/186/files Webrev: https://webrevs.openjdk.java.net/jfx/186/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242839 Stats: 68 lines in 1 file changed: 68 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/186/head:pull/186 PR: https://git.openjdk.java.net/jfx/pull/186 From kcr at openjdk.java.net Fri Apr 17 14:48:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 14:48:20 GMT Subject: [jfx14] RFR: 8242839: Create release notes for JavaFX 14.0.1 In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 14:34:01 GMT, Johan Vos wrote: > Add release notes for 14.0.1 > Fix for JDK-8242839 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/186 From john at status6.com Fri Apr 17 14:56:51 2020 From: john at status6.com (John Neffenger) Date: Fri, 17 Apr 2020 07:56:51 -0700 Subject: GitHub glitch - merging master into an old pull request Message-ID: I was surprised to see GitHub listing in my pull request all of the changes I merged from the upstream master branch, as I commented here: Did I merge the upstream master branch correctly? https://github.com/openjdk/jfx/pull/60#issuecomment-614885532 Unfortunately, GitHub also pulled into my pull request anyone who participated in those changes to master, which is why I'm posting this to the mailing list instead of commenting there. This is the first time I've seen the problem, but it dates back to at least 2013 according to this Stack Overflow question: GitHub pull request showing commits that are already in target branch https://stackoverflow.com/q/16306012 Should I try the suggested fix of temporarily switching the base branch? In my case, I would edit the pull request to choose the "jfx14" base branch, save the change, and then edit it again to switch it back to the "master" base branch. The Stack Overflow answers state that the extra commits will then be gone, and I'll have a nice clean pull request again. Thanks, John From kcr at openjdk.java.net Fri Apr 17 15:07:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 15:07:36 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> On Thu, 16 Apr 2020 20:45:17 GMT, John Neffenger wrote: > Let me know if you would like me to rebase my changes and force push a cleaner update. Yes, this is what you will need to do. More than just being needed for a cleaner update, the PR lists 6,151 changed files! Either the merge went badly or it has somehow managed to confuse GitHub (my money is on the latter based on what I see in the diffs). Either way, rebasing and force-pushing your branch is the way to go. You might need to export your patch and reset your branch to master if git has trouble rebasing. ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From kevin.rushforth at oracle.com Fri Apr 17 15:08:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Apr 2020 08:08:30 -0700 Subject: GitHub glitch - merging master into an old pull request In-Reply-To: References: Message-ID: <66db2db7-7d63-57f1-41c8-5f761e7206dd@oracle.com> Yeah, something went wrong here. Either the merge went wrong (a quick glance suggests that it didn't) or it has managed to confuse GitHub (that seems likely). I also added a comment to the PR. I do not recommend changing the base branch. Even if that were to fix it, it would be much better for reviewers to rebase and force push. -- Kevin On 4/17/2020 7:56 AM, John Neffenger wrote: > I was surprised to see GitHub listing in my pull request all of the > changes I merged from the upstream master branch, as I commented here: > > Did I merge the upstream master branch correctly? > https://github.com/openjdk/jfx/pull/60#issuecomment-614885532 > > Unfortunately, GitHub also pulled into my pull request anyone who > participated in those changes to master, which is why I'm posting this > to the mailing list instead of commenting there. > > This is the first time I've seen the problem, but it dates back to at > least 2013 according to this Stack Overflow question: > > GitHub pull request showing commits that are already in target branch > https://stackoverflow.com/q/16306012 > > Should I try the suggested fix of temporarily switching the base branch? > > In my case, I would edit the pull request to choose the "jfx14" base > branch, save the change, and then edit it again to switch it back to > the "master" base branch. The Stack Overflow answers state that the > extra commits will then be gone, and I'll have a nice clean pull > request again. > > Thanks, > John > From kcr at openjdk.java.net Fri Apr 17 15:16:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 15:16:30 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> References: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> Message-ID: On Fri, 17 Apr 2020 15:05:22 GMT, Kevin Rushforth wrote: >> @kevinrushforth Did I merge the upstream master branch correctly? The [last time I did >> this](https://github.com/javafxports/openjdk-jfx/pull/522/commits) on the old *openjdk-jfx* repository, the pull >> request showed only the single merge commit. This time all 87 commits from the upstream master branch are shown as part >> of this pull request, even though the code I propose has not changed since the pull request was created on December 4, >> 2019. Let me know if you would like me to rebase my changes and *force push* a cleaner update. While I have your >> attention ... would you be able to be my second reviewer? This pull request is a small update that completes the large >> project begun by [JDK-8217605](https://github.com/javafxports/openjdk-jfx/pull/369) over a year ago. Your comments on >> that first part were very helpful, so I'm hoping you can bring that experience to this second and final part of the >> project. > >> Let me know if you would like me to rebase my changes and force push a cleaner update. > > Yes, this is what you will need to do. > > More than just being needed for a cleaner update, the PR lists 6,151 changed files! Either the merge went badly or it > has somehow managed to confuse GitHub (my money is on the latter based on what I see in the diffs). > Either way, rebasing and force-pushing your branch is the way to go. You might need to export your patch and reset your > branch to master if git has trouble rebasing. I just checked and there is nothing wrong with your merge. But somehow it managed to confuse GitHub. ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From kcr at openjdk.java.net Fri Apr 17 15:19:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Apr 2020 15:19:01 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:25:52 GMT, Bhawesh Choudhary wrote: > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. Can you add a unit test to go along with this fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From github.com+4208131+bhaweshkc at openjdk.java.net Fri Apr 17 15:19:00 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 17 Apr 2020 15:19:00 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX Message-ID: As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare against 600 font weight. ------------- Commit messages: - 8191758: Match WebKit's font weight rendering with JavaFX Changes: https://git.openjdk.java.net/jfx/pull/180/files Webrev: https://webrevs.openjdk.java.net/jfx/180/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8191758 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/180/head:pull/180 PR: https://git.openjdk.java.net/jfx/pull/180 From nlisker at openjdk.java.net Fri Apr 17 16:04:23 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 17 Apr 2020 16:04:23 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> Message-ID: On Wed, 15 Apr 2020 20:59:40 GMT, Kevin Rushforth wrote: >> Here are the results on Phil's machine, which is a Mac Book Pro with a graphics accelerator (Nvidia, I think). >> >> Without the patch: >> 2000 quads average 8.805 fps >> >> With the patch: >> 2000 quads average 4.719 fps >> >> Almost a 2x performance hit. > > Conclusion: The new shaders that support attenuation don't seem to have much of a performance impact on machines with > an Intel HD, but on systems with a graphics accelerator, it is a significant slowdown. > So we are left with the two choices of doubling the number of shaders (that is, a set of shaders with attenuation and a > set without) or living with the performance hit (which will only be a problem on machines with a dedicated graphics > accelerator for highly fill-limited scenes). The only way we can justify a 2x drop in performance is if we are fairly > certain that this is a corner case, and thus unlikely to hit real applications. If we do end up deciding to replicate > the shaders, I don't think it is all that much work. I'm more worried about how well it would scale to subsequent > improvements, although we could easily decide that for, say, spotlights attenuation is so common that you wouldn't > create a version that doesn't do that. In the D3D HLSL shaders, ifdefs are used, so the work would be to restore the > original code and add the new code under an ifdef. Then double the number of lines of gradle (at that point, I'd do it > in a for-each loop), then modify the logic that loads the shaders to pick the right one. For GLSL, the different parts > of the shader are in different files, so it's a matter of creating new versions of each of the three lighting shaders > that handle attenuation and choosing the right one at runtime. I discussed this with a graphics engineer. He said that a couple of branches do not have any real performance impact even on modern mobile devices, and that, e.g., on iOS 7 using half floats instead of floats was improving shader execution dramatically. Desktops with NVIDIA or AMD and even Intel modern cards can process dozens of branches with no significant performance degradation. He suggested actually to have all the light types in a single shader file (looking ahead here). He also suggested not to permute on shaders based on the number of lights and just pass in a uniform for that number and loop over it. The permutations on the bump, specular and self illuminations components are correct (not sure we are not doing that for the diffuse component). If we add later shadows, which is not on my near to-do list, then we should permute there. It also depends on our target hardware. If we take into account hardware from, say, 2005 then maybe branching will cause significant performance loss, but that hinders our ability to increase performance for newer hardware. What is the policy here? I have a Win10 laptop with a GeForce 610M that I will test this weekend to see if the mobile NVidia cards have some issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From Rony.Flatscher at wu.ac.at Fri Apr 17 17:37:01 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Fri, 17 Apr 2020 19:37:01 +0200 Subject: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> Message-ID: <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> There is a new WIP at which adds a compile PI (process instruction) for turning on and off script compilation if the script engine implements the Compilable interface. By default compilation is off (no compilation), such that one needs to add a compile PI ("") at the top to activate this feature. Supplying "true" (default) or "false" as the PI data turns this feature on and off. The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off", alternating using "compile on and off", and alternating using "compile off and on". This will test all variants of applying the compile PI for all categories of scripts. Any feedback appreciated! ---rony P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes. P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a fallback solution in case a compilation is (unexpectedly) not successful, reverting to (interpretative) evaluation/execution of the script. In that version it is planned to have compilation on by default as in the case of a compilation failure there will be a safe backup solution. On 14.04.2020 19:52, Kevin Rushforth wrote: > Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to > create the CSR until the review is far enough along to know which direction we intend to go. > > Unless there is a real concern about possible regressions if scripts are compiled by default, I > think "enabled by default" is the way to go. Your argument that such script engines are broken > seems reasonable, since this only applies to script engines that implement javax.script.Compilable > in the first place. We still might want to add way to turn compilation off for individual scripts. > One other thing to consider is that if compilation fails, it might make sense to log a warning and > fall back to the existing interpreted mode. > > Does anyone else have any concerns with this? > > -- Kevin > > > On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: >> Hi there, >> >> as there was probably enough time that has passed by I would intend to create a CSR in the next days >> with the PR as per Kevin's suggestion. >> >> (For the case that this feature should not be active by default, the CSR will suggest to define a >> new "compile" PI in the form (default, if no PI data given: true), which >> is independent of the existence of a language PI (this way it becomes also possible to allow >> compilation of external scripts denoted with the script-element, which do not need a page language >> to be set as the file's extension allows the appropriate script engine to be loaded and used for >> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI >> or ? to FXML files (and to turn off), which seems to >> be simple and self-documentary. In general employing such compile PIs allows for setting compilation >> of scripts on and off throughout an FXML file.) >> >> ---rony >> >> >> On 04.04.2020 18:03, Rony G. Flatscher wrote: >> >>> Hi Kevin, >>> >>> On 03.04.2020 01:21, Kevin Rushforth wrote: >>>> I see that you updated the PR and sent it for review. >>>> >>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>>> feature, and if so, what form this feature should take. >>>> >>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>>> from it? >>> Script code should be executed faster after compilation, so any FXML page that hosts script code >>> may >>> benefit. >>> >>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >>> significantly. This is because repeated invocation of compiled script event handlers do not cause >>> the reparsing of that script's source and interpreting it on each invocation, which may be >>> expensive >>> depending on the script engine, but rather allows the immediate evaluation/execution of the >>> compiled >>> script by the script engine. >>> >>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >>> In principle there are three possibilities: >>> >>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the >>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and >>> ???? execute the compiled script each time its registered event fires. >>> >>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts >>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >>> ???????? compiling but have been employed successfully in interpreted mode >>> >>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script >>> ???? engine implements the javax.script.Compilable interface. If missing it would default to >>> "false". >>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the >>> ???? "language" PI was not.) >>> >>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the >>> language >>> ???????? PI gets changed >>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts >>> >>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script >>> and >>> ???? node elements and only compile the scripts, if the property is set to true >>> >>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >>> ???????? accordingly >>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that >>> host scripts >>> >>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >>> overruled individually by 3. >>> >>> The question would be whether 2 or/and 3 are really necessary as it can be expected that >>> compilation >>> of scripts by the script engines would find the same errors as while interpreting the very same >>> scripts (if not, the script engine is badly broken and it could be argued that then the >>> interpretation part of the script engine might be expected to be broken as well which would be >>> quite >>> dangerous from an integrity POV; the same consideration applies as well if the execution of the >>> compiled script would behave differently to interpreting the very same script by the same script >>> engine). >>> >>> The current WIP implements 1 above and includes an appropriate test unit. >>> >>>> What do others think? >>> >>>> In either case, we would need to make sure that this doesn't present any security concerns in the >>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>>> but we would need to ensure that. >>> The compilation of scripts needs to be done by the Java script engines (implementing both, >>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >>> scripts ([javax.script.CompiledScript] >>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >>> >>> >>> ---rony >>> >>> >>> >>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>>> After merging master, applying some fixes and changing the title to reflect the change from >>>>> WIP to a >>>>> pull request I would kindly request a review of this pull request! >>>>> >>>>> Here the URL: , title changed to: "8238080: >>>>> FXMLLoader: if >>>>> script engines implement javax.script.Compilable compile scripts". >>>>> >>>>> ---rony >>>>> >>>>> >>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in >>>>>> review, and >>>>>> has an appropriate test unit going with it as well, please review. >>>>>> >>>>>> There should be no compatibility issue with this implementation. >>>>>> >>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>>> information is present with the FXML file which cannot possibly be present in existing FXML >>>>>> files. >>>>>> In this scenario one possible and probably simple solution would be to only compile scripts >>>>>> if the >>>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>>> value >>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML >>>>>> with >>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up >>>>>> with a >>>>>> respective solution as well. >>>>>> >>>>>> ---rony >>>>>> >>>>>> [1] "Implementation and test unit": >>>>>> >>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>>> scripts": >>>>>> >>>>>> >>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>>> >>>>>> >>>>>> >>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>>> >>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to >>>>>>> illustrate >>>>>>> the concept). >>>>>>> >>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>>> Just filed a RFE with the following information: >>>>>>>> >>>>>>>> ???? * Component: >>>>>>>> ???????? o JavaFX >>>>>>>> >>>>>>>> ???? * Subcomponent: >>>>>>>> ???????? o fxml: JavaFX FXML >>>>>>>> >>>>>>>> ???? * Synopsis: >>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>>> >>>>>>>> ???? * Descriptions: >>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>>> (javax.script.ScriptEngine >>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller >>>>>>>> language in >>>>>>>> ?????????? the FXML file. >>>>>>>> >>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such >>>>>>>> scripts >>>>>>>> could >>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>>> using >>>>>>>> ?????????? its eval() methods. >>>>>>>> >>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>>> invocations, >>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>>> onMouseMove) >>>>>>>> ?????????? which may be repetitevly invoked and evaluated." >>>>>>>> >>>>>>>> ???? * System /OS/Java Runtime Information: >>>>>>>> ???????? o "All systems." >>>>>>>> >>>>>>>> Received the internal review ID: "9063426" >>>>>>>> >>>>>>>> ---rony From prr at openjdk.java.net Fri Apr 17 18:08:16 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 17 Apr 2020 18:08:16 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 12:40:24 GMT, Kevin Rushforth wrote: >> As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to >> fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare >> against 600 font weight. > > Can you add a unit test to go along with this fix? Per the opentype spec, 700 is bold. 600 is semi-bold https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass CSS agrees : https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight So are you saying webkit has been using bold at a lower weight than these specs suggest ? I see the logic all comes from Source/WebCore/platform/graphics/FontSelectionAlgorithm.h I suppose the existing code thinks that if we have reached what that file calls the bold threshold of 600 then we should use bold. It isn't necessarily "wrong" but I think I agree that it is more important to be consistent with the rest of Java FX ... which I believe is the point of this change ? ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From twitch at nervestaple.com Fri Apr 17 18:55:48 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Fri, 17 Apr 2020 14:55:48 -0400 Subject: Windows Installation Instructions, All DLL Files Missing Message-ID: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> I manage a project[0]? that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: https://openjfx.io/openjfx-docs/#install-javafx I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: C:\Program Files\Java\javafx-sdk-14\bin Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? Also, what impact does this have on distribution of applications? Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. -- Miles [0]: https://github.com/cmiles74/xmltool [1]: https://openjfx.io/openjfx-docs/#install-javafx From github.com+1413266+jgneff at openjdk.java.net Fri Apr 17 19:11:19 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 17 Apr 2020 19:11:19 GMT Subject: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: > This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements > [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* > repository. Some of the changes were made to support the new device models, while others are minor changes to the > existing support in JavaFX 13. The following changes were made to support the new device models. > * Work around problems on the Kobo Glo HD Model N437. > > Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is > ignored by the driver on the Kobo Glo HD where the error occurs, anyway. > > Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of > the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame > buffer device driver can be an incorrect value. > > * Work around problems on the Kobo Clara HD Model N249. > > The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the > normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The > work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. > > The following changes were made to the existing code that supports e-paper displays in JavaFX 13. > > * Use the correct constant for the number of bytes per pixel. > > Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when > calculating the capacity of the 32-bit off-screen byte buffer. > > * Do not round the luma value to the nearest integer. > > Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of > rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 > percent and doesn't seem worth it for a display with just 16 levels of gray. > > * Change camel case of system property *y8inverted*. > > Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it > is consistent with the other system properties containing Y1, Y4, and Y8 in their names. > > * Improve error handling when mapping the frame buffer. > > Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a > `null` return value from `EPDFrameBuffer.getMappedBuffer`. > > * Replace non-ASCII characters with their ASCII equivalent. > > Replace non-ASCII characters in comments and log messages as follows: > > * "?" with "x" for display resolution and color depth, > * "?" with "*" for multiplication, > * "?" with "to" for transition, and > * "?C" with "degrees Celsius" for temperature. > > * Add descriptions to Monocle EPD system properties. > > Add Javadoc comments to each constant that defines a Monocle EPD system property. > > * Rename `IntStructure.getInteger` to `IntStructure.get`. > > Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method > `Integer.getInteger`, which gets the integer value of a system property. > > Below are some of the more interesting test results. > > * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray > values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. > > * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black > for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that > displays black for values `0x7F` or less and white for values `0x80` or greater. > > * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the > tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame > buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows the animation speed of each model in > milliseconds per frame and frames per second. > > | Product Name | Speed (ms) | Rate (fps) | > | ------------- |:----------:|:----------:| > | Kobo Touch B | 125 | 8.0 | > | Kobo Touch C | 130 | 7.7 | > | Kobo Glo HD | 140 | 7.1 | > | Kobo Clara HD | 145 | 6.9 | John Neffenger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8227425: Add support for e-paper displays on i.MX6 devices ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/60/files - new: https://git.openjdk.java.net/jfx/pull/60/files/f7028e89..ba668b51 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/60/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/60/webrev.01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60 PR: https://git.openjdk.java.net/jfx/pull/60 From swpalmer at gmail.com Fri Apr 17 19:23:12 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 17 Apr 2020 15:23:12 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> Message-ID: I use jlink and jpackage to distribute JavaFX applications. You suggest there will be a problem if you use jlink, but it will work if you include the needed javafx modules. The .jmod files contain the necessary native libraries and jlink will build a JRE that has the DLLs in the right place for the runtime to find them. Modifying your PATH is not the right way to do this. Distributing a runtime with your application is the right way to solve this. The jlink and jpackage tools make this fairly easy. I use a custom Gradle script to bundle my application, it works well. Scott > On Apr 17, 2020, at 2:55 PM, Christopher Miles wrote: > > I manage a project[0] that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. > > It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: > > https://openjfx.io/openjfx-docs/#install-javafx > > I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: > > Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) > > I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: > > C:\Program Files\Java\javafx-sdk-14\bin > > Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? > > Also, what impact does this have on distribution of applications? > > Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! > > Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. > > -- > Miles > > [0]: https://github.com/cmiles74/xmltool > [1]: https://openjfx.io/openjfx-docs/#install-javafx From hohonuuli at icloud.com Fri Apr 17 20:17:09 2020 From: hohonuuli at icloud.com (hohonuuli at icloud.com) Date: Fri, 17 Apr 2020 13:17:09 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> Message-ID: <05055964-8e47-4e92-892f-7c506543da2c@Spark> I build several JavaFX projects with cross-builds for Windows, Mac, Linux. Note that I build the projects with Java 11, then use Java 14 packager to build the final installer. So my examples require that you set a JPACKAGE_HOME env variable that points at the Java 14 home. Anyway, here?s an example project:?https://github.com/mbari-media-management/vars-query Cheers Brian Schlining Software Engineer P (831) 775-1855 ? F (831) 775-1620 Monterey Bay Aquarium Research Institute 7700 Sandholdt Road, Moss Landing CA 95039 www.mbari.org Advancing marine science and engineering to understand our changing ocean. On Apr 17, 2020, 11:59 AM -0700, Christopher Miles , wrote: > I manage a project[0]? that leverages JavaFX. It's been a while since > I've worked on this project, almost two years. At that time JavaFX was > bundled with the Java runtime from Oracle. The few customers I had would > simply run the application from the bundled launcher and as long as they > had Java installed, it would work. > > It's time for me to add some features to the project, I am now using > OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the > instructions[1] from the following URL: > > https://openjfx.io/openjfx-docs/#install-javafx > > I am on Windows and followed the instructions for that platform. > Unfortunately, things didn't really work. The error was as follows: > > Graphics Device initialization failed for : d3d, sw Error initializing > QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: > java.lang.RuntimeException: Error initializing QuantumRend erer: no > suitable pipeline found at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno > wn Source) > > I fussed with this and that but nothing made a difference. Eventually I > tried adding the "bin" directory from the JavaFX distribution to my > path. This is the entry I added to my global PATH variable: > > C:\Program Files\Java\javafx-sdk-14\bin > > Is this the right way to do this and, if so, why isn't this included in > the directions? Is this a Windows specific issue? > > Also, what impact does this have on distribution of applications? > > Looking at the "Runtime Images" instructions, it looks like the same > issues will be present. Those instructions use `jlink` to point to the > JavaFX libraries and the JAVAFX modules (distributed in another package) > but also leave off references to the DLL files in the "bin" directory. I > am worried that I will need to have people manually install the > OpenJavaFX distribution and add the "bin" directory to their path in > order to run my application. Please say it's not so! > > Any help or pointers to additional documentation would be very much > appreciated! I have made it over the bumps and can now continue > development of my application, my next concern is distributing it to > customers. > > -- > Miles > > [0]: https://github.com/cmiles74/xmltool > [1]: https://openjfx.io/openjfx-docs/#install-javafx From twitch at nervestaple.com Fri Apr 17 20:18:48 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Fri, 17 Apr 2020 16:18:48 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> Message-ID: <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> I have downloaded both the "mods" and the SDK. I put them alongside the JDK on my workstation. C:\Program Files\Java\jdk-14.0.1 C:\Program Files\Java\javafx-sdk-14 C:\Program Files\Java\javafx-jmods-14.0.1 If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... jlink --module-path "C:\Program Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" --add-modules javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base --output C:\Users\cmiles\source\repos\xmltool\target/jlink --strip-debug --no-man-pages --no-header-files --compress=2 ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my global path, the application builds. When I try to run the application I see the following error. Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found Swapping out the mods path for the SDK "lib" directory has, as far as I can tell, the exact same effect. :-( If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my global PATH then it does run successfully. I hear what you're saying but this doesn't seem to be the case... What version of Windows are you using? I don't think this is a Windows 10 specific issue but perhaps there is something platform specific involved. Thank you! Scott Palmer wrote on 4/17/2020 15:23: > I use jlink and jpackage to distribute JavaFX applications. > You suggest there will be a problem if you use jlink, but it will work if you include the needed javafx modules. The .jmod files contain the necessary native libraries and jlink will build a JRE that has the DLLs in the right place for the runtime to find them. > > Modifying your PATH is not the right way to do this. Distributing a runtime with your application is the right way to solve this. The jlink and jpackage tools make this fairly easy. I use a custom Gradle script to bundle my application, it works well. > > Scott > >> On Apr 17, 2020, at 2:55 PM, Christopher Miles wrote: >> >> I manage a project[0] that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. >> >> It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: >> >> https://openjfx.io/openjfx-docs/#install-javafx >> >> I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: >> >> Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) >> >> I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: >> >> C:\Program Files\Java\javafx-sdk-14\bin >> >> Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? >> >> Also, what impact does this have on distribution of applications? >> >> Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! >> >> Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. >> >> -- >> Miles >> >> [0]: https://github.com/cmiles74/xmltool >> [1]: https://openjfx.io/openjfx-docs/#install-javafx > -- Miles From kevin.rushforth at oracle.com Fri Apr 17 20:51:12 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Apr 2020 13:51:12 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: Where are you getting JDK 14.0.1 from? Does it include the Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 sdk includes them, but the jmods do not. See JDK-8207015 [1] for why not. If the JDK has them, then there should be no problem running a jlinked app. One possible problem is that your jlink line is wrong. You should not point to the SDK at all when running jlink. Use the jmods with jlink (don't use the sdk). Use the sdk with javac and java --module-path (don't use the jmods at all). Btw, even if you are running a JDK that for some reason doesn't have the Microsoft DLLs, you should still be able to run using the SDK (directly, not via jlink, which requires the jmods) as follows: java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" --add-modules javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web MyApplication If this doesn't work without you putting javafx-sdk-14/bin in your PATH then something else is wrong. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8207015 On 4/17/2020 1:18 PM, Christopher Miles wrote: > I have downloaded both the "mods" and the SDK. I put them alongside > the JDK on my workstation. > > ? C:\Program Files\Java\jdk-14.0.1 > ? C:\Program Files\Java\javafx-sdk-14 > ? C:\Program Files\Java\javafx-jmods-14.0.1 > > If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and > point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... > > jlink --module-path "C:\Program > Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" > --add-modules > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base > --output C:\Users\cmiles\source\repos\xmltool\target/jlink > --strip-debug --no-man-pages --no-header-files --compress=2 > > ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my global > path, the application builds. When I try to run the application I see > the following error. > > ? Graphics Device initialization failed for :? d3d, sw > ? Error initializing QuantumRenderer: no suitable pipeline found > > Swapping out the mods path for the SDK "lib" directory has, as far as > I can tell, the exact same effect. :-( > > If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my > global PATH then it does run successfully. > > I hear what you're saying but this doesn't seem to be the case... > > What version of Windows are you using? I don't think this is a Windows > 10 specific issue but perhaps there is something platform specific > involved. > > Thank you! > > > Scott Palmer wrote on 4/17/2020 15:23: >> I use jlink and jpackage to distribute JavaFX applications. >> You suggest there will be a problem if you use jlink, but it will >> work if you include the needed javafx modules. The .jmod files >> contain the necessary native libraries and jlink will build a JRE >> that has the DLLs in the right place for the runtime to find them. >> >> Modifying your PATH is not the right way to do this. Distributing a >> runtime with your application is the right way to solve this. The >> jlink and jpackage tools make this fairly easy. I use a custom Gradle >> script to bundle my application, it works well. >> >> Scott >> >>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>> wrote: >>> >>> I manage a project[0]? that leverages JavaFX. It's been a while >>> since I've worked on this project, almost two years. At that time >>> JavaFX was bundled with the Java runtime from Oracle. The few >>> customers I had would simply run the application from the bundled >>> launcher and as long as they had Java installed, it would work. >>> >>> It's time for me to add some features to the project, I am now using >>> OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed >>> the instructions[1] from the following URL: >>> >>> https://openjfx.io/openjfx-docs/#install-javafx >>> >>> I am on Windows and followed the instructions for that platform. >>> Unfortunately, things didn't really work. The error was as follows: >>> >>> Graphics Device initialization failed for : d3d, sw Error >>> initializing QuantumRenderer: no suitable pipeline found >>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>> initializing QuantumRend erer: no suitable pipeline found at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>> wn Source) >>> >>> I fussed with this and that but nothing made a difference. >>> Eventually I tried adding the "bin" directory from the JavaFX >>> distribution to my path. This is the entry I added to my global PATH >>> variable: >>> >>> C:\Program Files\Java\javafx-sdk-14\bin >>> >>> Is this the right way to do this and, if so, why isn't this included >>> in the directions? Is this a Windows specific issue? >>> >>> Also, what impact does this have on distribution of applications? >>> >>> Looking at the "Runtime Images" instructions, it looks like the same >>> issues will be present. Those instructions use `jlink` to point to >>> the JavaFX libraries and the JAVAFX modules (distributed in another >>> package) but also leave off references to the DLL files in the "bin" >>> directory. I am worried that I will need to have people manually >>> install the OpenJavaFX distribution and add the "bin" directory to >>> their path in order to run my application. Please say it's not so! >>> >>> Any help or pointers to additional documentation would be very much >>> appreciated! I have made it over the bumps and can now continue >>> development of my application, my next concern is distributing it to >>> customers. >>> >>> -- >>> Miles >>> >>> [0]: https://github.com/cmiles74/xmltool >>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >> > > From twitch at nervestaple.com Fri Apr 17 21:16:11 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Fri, 17 Apr 2020 17:16:11 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: Yeah, I've tried it with both. The instructions on the JavaFX page tell you to add the "lib" directory to the `javac` path and the "mods" to the `jlink` path. I figured, since nothing is working, why not try them the other way around? In all cases the results are the same. I'm using OpenJDK, wouldn't that project have the same issue distributing these DLL files? I would bet they would, since they are also an open source project. I can run Swing projects, however, without these DLL files. I can give the Oracle JDK a try. I had been shying away from it since OpenJDK is getting to be so popular. If that works, I will let the list know. As an aside, the JavaFX home page recommends using OpenJDK right now: https://openjfx.io/openjfx-docs/#install-java Thank you! Kevin Rushforth wrote on 4/17/2020 16:51: > Where are you getting JDK 14.0.1 from? Does it include the Microsoft > VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of them > (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 sdk > includes them, but the jmods do not. See JDK-8207015 [1] for why not. If > the JDK has them, then there should be no problem running a jlinked app. > > One possible problem is that your jlink line is wrong. You should not > point to the SDK at all when running jlink. Use the jmods with jlink > (don't use the sdk). Use the sdk with javac and java --module-path > (don't use the jmods at all). > > Btw, even if you are running a JDK that for some reason doesn't have the > Microsoft DLLs, you should still be able to run using the SDK (directly, > not via jlink, which requires the jmods) as follows: > > java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" > --add-modules > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web > MyApplication > > If this doesn't work without you putting javafx-sdk-14/bin in your PATH > then something else is wrong. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8207015 > > On 4/17/2020 1:18 PM, Christopher Miles wrote: >> I have downloaded both the "mods" and the SDK. I put them alongside >> the JDK on my workstation. >> >> ? C:\Program Files\Java\jdk-14.0.1 >> ? C:\Program Files\Java\javafx-sdk-14 >> ? C:\Program Files\Java\javafx-jmods-14.0.1 >> >> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... >> >> jlink --module-path "C:\Program >> Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" >> --add-modules >> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >> --strip-debug --no-man-pages --no-header-files --compress=2 >> >> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my global >> path, the application builds. When I try to run the application I see >> the following error. >> >> ? Graphics Device initialization failed for :? d3d, sw >> ? Error initializing QuantumRenderer: no suitable pipeline found >> >> Swapping out the mods path for the SDK "lib" directory has, as far as >> I can tell, the exact same effect. :-( >> >> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >> global PATH then it does run successfully. >> >> I hear what you're saying but this doesn't seem to be the case... >> >> What version of Windows are you using? I don't think this is a Windows >> 10 specific issue but perhaps there is something platform specific >> involved. >> >> Thank you! >> >> >> Scott Palmer wrote on 4/17/2020 15:23: >>> I use jlink and jpackage to distribute JavaFX applications. >>> You suggest there will be a problem if you use jlink, but it will >>> work if you include the needed javafx modules. The .jmod files >>> contain the necessary native libraries and jlink will build a JRE >>> that has the DLLs in the right place for the runtime to find them. >>> >>> Modifying your PATH is not the right way to do this. Distributing a >>> runtime with your application is the right way to solve this. The >>> jlink and jpackage tools make this fairly easy. I use a custom Gradle >>> script to bundle my application, it works well. >>> >>> Scott >>> >>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>> wrote: >>>> >>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>> since I've worked on this project, almost two years. At that time >>>> JavaFX was bundled with the Java runtime from Oracle. The few >>>> customers I had would simply run the application from the bundled >>>> launcher and as long as they had Java installed, it would work. >>>> >>>> It's time for me to add some features to the project, I am now using >>>> OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed >>>> the instructions[1] from the following URL: >>>> >>>> https://openjfx.io/openjfx-docs/#install-javafx >>>> >>>> I am on Windows and followed the instructions for that platform. >>>> Unfortunately, things didn't really work. The error was as follows: >>>> >>>> Graphics Device initialization failed for : d3d, sw Error >>>> initializing QuantumRenderer: no suitable pipeline found >>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>> initializing QuantumRend erer: no suitable pipeline found at >>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>> wn Source) >>>> >>>> I fussed with this and that but nothing made a difference. >>>> Eventually I tried adding the "bin" directory from the JavaFX >>>> distribution to my path. This is the entry I added to my global PATH >>>> variable: >>>> >>>> C:\Program Files\Java\javafx-sdk-14\bin >>>> >>>> Is this the right way to do this and, if so, why isn't this included >>>> in the directions? Is this a Windows specific issue? >>>> >>>> Also, what impact does this have on distribution of applications? >>>> >>>> Looking at the "Runtime Images" instructions, it looks like the same >>>> issues will be present. Those instructions use `jlink` to point to >>>> the JavaFX libraries and the JAVAFX modules (distributed in another >>>> package) but also leave off references to the DLL files in the "bin" >>>> directory. I am worried that I will need to have people manually >>>> install the OpenJavaFX distribution and add the "bin" directory to >>>> their path in order to run my application. Please say it's not so! >>>> >>>> Any help or pointers to additional documentation would be very much >>>> appreciated! I have made it over the bumps and can now continue >>>> development of my application, my next concern is distributing it to >>>> customers. >>>> >>>> -- >>>> Miles >>>> >>>> [0]: https://github.com/cmiles74/xmltool >>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>> >> >> > -- Miles From kevin.rushforth at oracle.com Fri Apr 17 21:34:31 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Apr 2020 14:34:31 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: From where are you getting your OpenJDK build? https://jdk.java.net/14 ? Somewhere else? -- Kevin On 4/17/2020 2:16 PM, Christopher Miles wrote: > Yeah, I've tried it with both. The instructions on the JavaFX page > tell you to add the "lib" directory to the `javac` path and the "mods" > to the `jlink` path. I figured, since nothing is working, why not try > them the other way around? In all cases the results are the same. > > I'm using OpenJDK, wouldn't that project have the same issue > distributing these DLL files? I would bet they would, since they are > also an open source project. I can run Swing projects, however, > without these DLL files. > > I can give the Oracle JDK a try. I had been shying away from it since > OpenJDK is getting to be so popular. If that works, I will let the > list know. > > As an aside, the JavaFX home page recommends using OpenJDK right now: > > ? https://openjfx.io/openjfx-docs/#install-java > > Thank you! > > Kevin Rushforth wrote on 4/17/2020 16:51: >> Where are you getting JDK 14.0.1 from? Does it include the Microsoft >> VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of >> them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 >> sdk includes them, but the jmods do not. See JDK-8207015 [1] for why >> not. If the JDK has them, then there should be no problem running a >> jlinked app. >> >> One possible problem is that your jlink line is wrong. You should not >> point to the SDK at all when running jlink. Use the jmods with jlink >> (don't use the sdk). Use the sdk with javac and java --module-path >> (don't use the jmods at all). >> >> Btw, even if you are running a JDK that for some reason doesn't have >> the Microsoft DLLs, you should still be able to run using the SDK >> (directly, not via jlink, which requires the jmods) as follows: >> >> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >> --add-modules >> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >> MyApplication >> >> If this doesn't work without you putting javafx-sdk-14/bin in your >> PATH then something else is wrong. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >> >> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>> I have downloaded both the "mods" and the SDK. I put them alongside >>> the JDK on my workstation. >>> >>> ? C:\Program Files\Java\jdk-14.0.1 >>> ? C:\Program Files\Java\javafx-sdk-14 >>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>> >>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... >>> >>> jlink --module-path "C:\Program >>> Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" >>> --add-modules >>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>> --strip-debug --no-man-pages --no-header-files --compress=2 >>> >>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>> global path, the application builds. When I try to run the >>> application I see the following error. >>> >>> ? Graphics Device initialization failed for :? d3d, sw >>> ? Error initializing QuantumRenderer: no suitable pipeline found >>> >>> Swapping out the mods path for the SDK "lib" directory has, as far >>> as I can tell, the exact same effect. :-( >>> >>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>> global PATH then it does run successfully. >>> >>> I hear what you're saying but this doesn't seem to be the case... >>> >>> What version of Windows are you using? I don't think this is a >>> Windows 10 specific issue but perhaps there is something platform >>> specific involved. >>> >>> Thank you! >>> >>> >>> Scott Palmer wrote on 4/17/2020 15:23: >>>> I use jlink and jpackage to distribute JavaFX applications. >>>> You suggest there will be a problem if you use jlink, but it will >>>> work if you include the needed javafx modules. The .jmod files >>>> contain the necessary native libraries and jlink will build a JRE >>>> that has the DLLs in the right place for the runtime to find them. >>>> >>>> Modifying your PATH is not the right way to do this. Distributing a >>>> runtime with your application is the right way to solve this. The >>>> jlink and jpackage tools make this fairly easy. I use a custom >>>> Gradle script to bundle my application, it works well. >>>> >>>> Scott >>>> >>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>> wrote: >>>>> >>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>> since I've worked on this project, almost two years. At that time >>>>> JavaFX was bundled with the Java runtime from Oracle. The few >>>>> customers I had would simply run the application from the bundled >>>>> launcher and as long as they had Java installed, it would work. >>>>> >>>>> It's time for me to add some features to the project, I am now >>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>> followed the instructions[1] from the following URL: >>>>> >>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>> >>>>> I am on Windows and followed the instructions for that platform. >>>>> Unfortunately, things didn't really work. The error was as follows: >>>>> >>>>> Graphics Device initialization failed for : d3d, sw Error >>>>> initializing QuantumRenderer: no suitable pipeline found >>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>> wn Source) >>>>> >>>>> I fussed with this and that but nothing made a difference. >>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>> distribution to my path. This is the entry I added to my global >>>>> PATH variable: >>>>> >>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>> >>>>> Is this the right way to do this and, if so, why isn't this >>>>> included in the directions? Is this a Windows specific issue? >>>>> >>>>> Also, what impact does this have on distribution of applications? >>>>> >>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>> same issues will be present. Those instructions use `jlink` to >>>>> point to the JavaFX libraries and the JAVAFX modules (distributed >>>>> in another package) but also leave off references to the DLL files >>>>> in the "bin" directory. I am worried that I will need to have >>>>> people manually install the OpenJavaFX distribution and add the >>>>> "bin" directory to their path in order to run my application. >>>>> Please say it's not so! >>>>> >>>>> Any help or pointers to additional documentation would be very >>>>> much appreciated! I have made it over the bumps and can now >>>>> continue development of my application, my next concern is >>>>> distributing it to customers. >>>>> >>>>> -- >>>>> Miles >>>>> >>>>> [0]: https://github.com/cmiles74/xmltool >>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>> >>> >>> >> > > From github.com+636962+ccavanaugh at openjdk.java.net Sat Apr 18 09:43:54 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sat, 18 Apr 2020 09:43:54 GMT Subject: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! Craig Cavanaugh has updated the pull request incrementally with one additional commit since the last revision: Update unit test for JDK_8129123 to check midpoint of the list ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/166/files - new: https://git.openjdk.java.net/jfx/pull/166/files/28b25370..0b6683dd Webrevs: - full: https://webrevs.openjdk.java.net/jfx/166/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/166/webrev.00-01 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/166/head:pull/166 PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Sat Apr 18 09:43:55 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sat, 18 Apr 2020 09:43:55 GMT Subject: [Rev 01] RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 10:38:06 GMT, Ajit Ghaisas wrote: >> Craig Cavanaugh has updated the pull request incrementally with one additional commit since the last revision: >> >> Update unit test for JDK_8129123 to check midpoint of the list > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2097: > >> 2096: first <= index && index <= last); >> 2097: >> 2098: index = LIST_SIZE - 1; > > You have tested first and last index selection. > It will be nice to have a case where we select index = LIST_SIZE/2 Agreed, mid point test added ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From mp at jugs.org Sat Apr 18 10:01:07 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Apr 2020 12:01:07 +0200 Subject: Remove JavaFX JPMS enforcement Message-ID: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Getting started with JavaFX is made overly complicated by the fact that the use of the module system is enforced by some code in the JDK. Especially for beginners, who just want to get some small program running, this is almost always a big source of frustration. It is not very good marketing for JavaFX to make these initial steps such a pain. If you need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar sites (and also this mailing list). Almost every day you can read frustrated posts from helpless people who would just like to get some JavaFX project running but are failing because they get lost in the module system jungle. In order to make JavaFX more easily accessible, especially for beginners, I'd like to start a discussion here about the possibility to unconditionally remove the JavaFX JPMS enforcement. IMHO this enforcement is simply not necessary and is just the root for a lot of frustration with JavaFX. It should just be possible to put all the JavaFX jars on the classpath (instead of the module path) like you would do with any other external dependency in a non-modular setup. With a not very intuitive hack you can circumvent this problem already now. Just add a line like this to the file which contains your main class extending Application (MyApp). class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}} Because of this launcher it is now possible to put all dependencies and all JavaFX jars on the classpath and to completely forget the module system with all its intricacies and pitfalls. But why should people be forced to use such dirty tricks? The better alternative would be to just lift the current constraint. I am using this trick for a long time now, even on bigger projects, and I have never ever experienced any problem resulting from this. Even in theory I don't know anything that could prevent a formally correct module jar to also work on the classpath (which is of course not true the other way round). Therefore I say that this constraint is just not necessary and only does a lot of damage to JavaFXs reputation. I'd now like to have some feedback of the community about this. Michael From youngty1997 at gmail.com Sat Apr 18 10:58:01 2020 From: youngty1997 at gmail.com (Ty Young) Date: Sat, 18 Apr 2020 05:58:01 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> On 4/18/20 5:01 AM, Michael Paus wrote: > Getting started with JavaFX is made overly complicated by the fact > that the use of the > module system is enforced by some code in the JDK. Especially for > beginners, who just > want to get some small program running, this is almost always a big > source of frustration. > It is not very good marketing for JavaFX to make these initial steps > such a pain. If you > need some evidence for this statement, then just follow JavaFX on > Stackoverflow or similar > sites (and also this mailing list). Almost every day you can read > frustrated posts from > helpless people who would just like to get some JavaFX project running > but are failing > because they get lost in the module system jungle. Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and? poor/buggy IDE support. Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: https://openjfx.io/openjfx-docs/#IDE-NetBeans Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way. From mp at jugs.org Sat Apr 18 12:40:34 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Apr 2020 14:40:34 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> Message-ID: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Hi, I would just like to add that many of the problems you have cited would just vanish if the JPMS enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd runtime module VM arguments" anymore and the IDE integration would just be straight forward. JavaFX would become just one more dependency whithout the need for any special treatment. I did, however, not say that JavaFX should be de-modularized. For an expert user who wants to use the JPMS nothing would change at all. Michael Am 18.04.20 um 12:58 schrieb Ty Young: > > On 4/18/20 5:01 AM, Michael Paus wrote: >> Getting started with JavaFX is made overly complicated by the fact >> that the use of the >> module system is enforced by some code in the JDK. Especially for >> beginners, who just >> want to get some small program running, this is almost always a big >> source of frustration. >> It is not very good marketing for JavaFX to make these initial steps >> such a pain. If you >> need some evidence for this statement, then just follow JavaFX on >> Stackoverflow or similar >> sites (and also this mailing list). Almost every day you can read >> frustrated posts from >> helpless people who would just like to get some JavaFX project >> running but are failing >> because they get lost in the module system jungle. > > > Speaking as a long time JavaFX user(literally since Java 8), I have > mostly disagree that the JPMS is hurting JavaFX. > > > That said, I don't think the frustration is misplaced. What you say is > true(Netbeans mailing list is fill of JavaFX issues) and the end user > is *NOT* to be blamed here. > > > Rather, I think what's to blame is poor documentation, JavaFX > requiring absurd runtime module VM arguments, and? poor/buggy IDE > support. > > > Starting with documentation, JavaFX uses reflection for things like > TableView(everyone's favorite) and CSS style sheets. While this may be > obvious for people who are more experienced, those who are not may be > very confused when they get an onslaught of error messages regarding > reflection. Better documentation on what requires reflection, why, and > how to enable it would be useful. > > > Likewise, the notice about having to include javafx.graphics to the > runtime module arguments here: > > > https://openjfx.io/openjfx-docs/#IDE-NetBeans > > > Apply to Maven as well, but it's under Ant for some reason. I don't > know what was changed in JavaFX 14 that now suddenly requires a > runtime VM argument, but it's a PITA and BS. End users are going to > struggle with this, and it prevents JavaFX runtime from being purely > managed by Maven. No other JavaFX version requires this, so it's mind > boggling that all of a sudden JavaFX needs this. > > > Poor/buggy IDE support is really the big one here. I don't know about > other IDEs but Netbeans DOES NOT provide a project template for > creating a JavaFX application with setup dependencies. Netbeans, when > setup with a Maven project, allows you to select an entire > project(pom) rather than the individual dependencies(jar) which > doesn't work. What you search for also matters: if you search for > "JavaFX" you will get the wrong search results. You need to search for > "openjfx" which can be confusing. > > > Anyway, yeah, it's a PITA. There is also an issue with Ant based > projects and Netbeans because JavaFX puts its src.zip in a folder that > is supposed to only include the runtime library that has existed for > years(literally a 1 line fix too). No one really uses Ant anymore so > it's probably not a big deal now but yeah, getting JavaFX working > hasn't been "include and done" when it could potentially be that way. > From weiqigao at gmail.com Sat Apr 18 14:56:46 2020 From: weiqigao at gmail.com (Weiqi Gao) Date: Sat, 18 Apr 2020 09:56:46 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> References: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Message-ID: <86972CED-9549-405D-B963-5065B747D041@gmail.com> I have built both non-modular and modular JavaFX apps in the past five years, and I agree that bootstrapping a modular Hello World JavaFX application is not as trivial as bootstrapping a non-modular one. The big challenges are related to the JPMS. These challenges are not unique to JavaFX. They are present in almost all libraries that are going through the modularization process. (JAXB for example.) The good news in this regard is that with a combination of tools like Gradle and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular JavaFX application has become a non-event that can be done in minutes. And after that initial setup, further development of the application is almost the same as for non-modular JavaFX applications, with the occasional need to add an exports or an opens line to the module-info.java file to allow FXML (or the dependency injector of your choice, I used Juice and Micronaut in two different projects to good effect) reflective access to your controller classes. My IDE of choice, IntelliJ IDEA, works happily with JavaFX. ? Weiqi Gao Sent from my iPhone > On Apr 18, 2020, at 7:43 AM, Michael Paus wrote: > > ?Hi, > I would just like to add that many of the problems you have cited would just vanish if the JPMS > enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd > runtime module VM arguments" anymore and the IDE integration would just be straight forward. > JavaFX would become just one more dependency whithout the need for any special treatment. > > I did, however, not say that JavaFX should be de-modularized. For an expert user who wants > to use the JPMS nothing would change at all. > > Michael > >> Am 18.04.20 um 12:58 schrieb Ty Young: >> >>> On 4/18/20 5:01 AM, Michael Paus wrote: >>> Getting started with JavaFX is made overly complicated by the fact that the use of the >>> module system is enforced by some code in the JDK. Especially for beginners, who just >>> want to get some small program running, this is almost always a big source of frustration. >>> It is not very good marketing for JavaFX to make these initial steps such a pain. If you >>> need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar >>> sites (and also this mailing list). Almost every day you can read frustrated posts from >>> helpless people who would just like to get some JavaFX project running but are failing >>> because they get lost in the module system jungle. >> >> >> Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. >> >> >> That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. >> >> >> Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and poor/buggy IDE support. >> >> >> Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. >> >> >> Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: >> >> >> https://openjfx.io/openjfx-docs/#IDE-NetBeans >> >> >> Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. >> >> >> Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. >> >> >> Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way. >> > From kcr at openjdk.java.net Sat Apr 18 15:32:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 15:32:15 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Fri, 17 Apr 2020 10:42:30 GMT, Jeanette Winzenburg wrote: >> I think, selection and scrolling are two separate operations. Here we use these two operations to achieve the desired >> result for ComboBox. It is nice to have behavior and I am OK with the fix. >>> Also, I believe JDK-8196037 is a duplicate of this issue. >> >> Please Note that - JDK-8196037 is not a duplicate of this issue as described in PR description. >> >> I have a minor comment regarding test. > > repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): > I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered > :) This will need two reviewers. As part of this review, the questions raised by @kleopatra in [this message from the original PR](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086) need to be answered. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From kcr at openjdk.java.net Sat Apr 18 15:47:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 15:47:46 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> Message-ID: <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> On Fri, 17 Apr 2020 16:02:12 GMT, Nir Lisker wrote: >> Conclusion: The new shaders that support attenuation don't seem to have much of a performance impact on machines with >> an Intel HD, but on systems with a graphics accelerator, it is a significant slowdown. >> So we are left with the two choices of doubling the number of shaders (that is, a set of shaders with attenuation and a >> set without) or living with the performance hit (which will only be a problem on machines with a dedicated graphics >> accelerator for highly fill-limited scenes). The only way we can justify a 2x drop in performance is if we are fairly >> certain that this is a corner case, and thus unlikely to hit real applications. If we do end up deciding to replicate >> the shaders, I don't think it is all that much work. I'm more worried about how well it would scale to subsequent >> improvements, although we could easily decide that for, say, spotlights attenuation is so common that you wouldn't >> create a version that doesn't do that. In the D3D HLSL shaders, ifdefs are used, so the work would be to restore the >> original code and add the new code under an ifdef. Then double the number of lines of gradle (at that point, I'd do it >> in a for-each loop), then modify the logic that loads the shaders to pick the right one. For GLSL, the different parts >> of the shader are in different files, so it's a matter of creating new versions of each of the three lighting shaders >> that handle attenuation and choosing the right one at runtime. > > I discussed this with a graphics engineer. He said that a couple of branches do not have any real performance impact > even on modern mobile devices, and that, e.g., on iOS 7 using half floats instead of floats was improving shader > execution dramatically. Desktops with NVIDIA or AMD and even Intel modern cards can process dozens of branches with no > significant performance degradation. He suggested actually to have all the light types in a single shader file > (looking ahead here). He also suggested not to permute on shaders based on the number of lights and just pass in a > uniform for that number and loop over it. The permutations on the bump, specular and self illuminations components are > correct (not sure we are not doing that for the diffuse component). If we add later shadows, which is not on my near > to-do list, then we should permute there. It also depends on our target hardware. If we take into account hardware > from, say, 2005 then maybe branching will cause significant performance loss, but that hinders our ability to increase > performance for newer hardware. What is the policy here? I have a Win10 laptop with a GeForce 610M that I will test > this weekend to see if the mobile NVidia cards have some issue. I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so far is on graphics accelerators that are a few years old by now. Integrated graphics chipsets (such as Intel HD) either old or new seem largely unaffected by the shader changes. What we are missing is performance metrics from newer graphics accelerators on Mac and Windows. Even with the performance drop on older graphics devices, I'm leaning towards not having the shaders to be shaders to be doubled, since this is an artificial stress test with huge quads. If we could get performance data from a couple more recent graphics accelerators that would be best. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From jvos at openjdk.java.net Sat Apr 18 15:54:47 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 18 Apr 2020 15:54:47 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done > for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. > I have run a full build and test using this new compiler. Works on my development system (didn't test on our build system yet) ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/178 From kcr at openjdk.java.net Sat Apr 18 16:03:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 16:03:58 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: <9LaXcxJ-7WaC0Rhc-H6fYp0zXJah6SatCRw4ymCKaO4=.7a0e9579-da3a-4ef8-b343-52fa578bcf1e@github.com> On Thu, 9 Apr 2020 10:00:49 GMT, Jesper Skov wrote: >> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. >> >> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 > > /signed @arapte can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Sat Apr 18 16:06:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 16:06:49 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov wrote: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 The fix looks correct to me. Have you run all tests to ensure no regressions? I left a couple inline comments. modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java line 196: > 195: private ObjectProperty toggleGroup; > 196: @Override > 197: public final void setToggleGroup(ToggleGroup value) { This is unrelated to the fix. The changes in this file should be reverted. modules/javafx.controls/src/test/java/test/javafx/scene/control/ToggleButtonTest.java line 270: > 269: } catch (InterruptedException e) { > 270: System.err.println("InterruptedException occurred during Thread.sleep()"); > 271: } An exception here should cause the test to fail. You can use `Assert.fail` or else re-throw the exception as an `AssertionFailedError`. modules/javafx.controls/src/main/java/javafx/scene/control/ToggleGroup.java line 74: > 73: while (c.next()) { > 74: List addedToggles = c.getAddedSubList(); > 75: This can be declared as final. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Sat Apr 18 16:16:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 16:16:02 GMT Subject: RFR: 8242490: Upgrade to gcc 9.2 on Linux In-Reply-To: References: Message-ID: On Sat, 18 Apr 2020 15:52:36 GMT, Johan Vos wrote: >> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done >> for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). >> On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by >> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. >> I have run a full build and test using this new compiler. > > Works on my development system (didn't test on our build system yet) I won't integrate this until Monday anyway. If you run into a problem with the actual builds using this compiler, let me know and I'll hold off further (it's been well-tested on my end). ------------- PR: https://git.openjdk.java.net/jfx/pull/178 From tbee at tbee.org Sat Apr 18 16:21:29 2020 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 18 Apr 2020 18:21:29 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <86972CED-9549-405D-B963-5065B747D041@gmail.com> References: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <86972CED-9549-405D-B963-5065B747D041@gmail.com> Message-ID: <3886dff7-67aa-8c5c-97f8-b984bf0f90bb@tbee.org> I'm in the process of porting an app from Java 8 to Java 11. Just getting it to run in classpath mode is not that hard anymore; upgrade a bunch of libraries and you're set. As an experiment I'm now activating JPMS. Right! What a lot of work! Do you have any idea how many fairly common libraries not even include an automatic module name in the manifest? Let alone being full fledged modules. It seems modules is a threshold a lot of projects see no need to cross. So I figure most JavaFX projects also run in classic classpath mode, hence that would be the main usage of the library. Just sayin' Tom On 18-4-2020 16:56, Weiqi Gao wrote: > I have built both non-modular and modular JavaFX apps in the past five years, and I agree that bootstrapping a modular Hello World JavaFX application is not as trivial as bootstrapping a non-modular one. > > The big challenges are related to the JPMS. These challenges are not unique to JavaFX. They are present in almost all libraries that are going through the modularization process. (JAXB for example.) > > The good news in this regard is that with a combination of tools like Gradle and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular JavaFX application has become a non-event that can be done in minutes. > > And after that initial setup, further development of the application is almost the same as for non-modular JavaFX applications, with the occasional need to add an exports or an opens line to the module-info.java file to allow FXML (or the dependency injector of your choice, I used Juice and Micronaut in two different projects to good effect) reflective access to your controller classes. > > My IDE of choice, IntelliJ IDEA, works happily with JavaFX. > > ? > Weiqi Gao > > Sent from my iPhone > >> On Apr 18, 2020, at 7:43 AM, Michael Paus wrote: >> >> ?Hi, >> I would just like to add that many of the problems you have cited would just vanish if the JPMS >> enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd >> runtime module VM arguments" anymore and the IDE integration would just be straight forward. >> JavaFX would become just one more dependency whithout the need for any special treatment. >> >> I did, however, not say that JavaFX should be de-modularized. For an expert user who wants >> to use the JPMS nothing would change at all. >> >> Michael >> >>> Am 18.04.20 um 12:58 schrieb Ty Young: >>> >>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>> Getting started with JavaFX is made overly complicated by the fact that the use of the >>>> module system is enforced by some code in the JDK. Especially for beginners, who just >>>> want to get some small program running, this is almost always a big source of frustration. >>>> It is not very good marketing for JavaFX to make these initial steps such a pain. If you >>>> need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar >>>> sites (and also this mailing list). Almost every day you can read frustrated posts from >>>> helpless people who would just like to get some JavaFX project running but are failing >>>> because they get lost in the module system jungle. >>> >>> Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. >>> >>> >>> That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. >>> >>> >>> Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and poor/buggy IDE support. >>> >>> >>> Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. >>> >>> >>> Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: >>> >>> >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>> >>> >>> Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. >>> >>> >>> Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. >>> >>> >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way. >>> From saleem_yusuf at hotmail.com Sat Apr 18 16:32:20 2020 From: saleem_yusuf at hotmail.com (Mohammad Saleem Yusuf) Date: Sat, 18 Apr 2020 16:32:20 +0000 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: Michael, I completely agree with you. I am Professor at a community college (NHTI) and teach entry level courses to students who have just graduated from high school. About a year ago (JDK 8 to 11), I started including Java FX in my Java course, but after that I had to remove it (JDK > 11.03) as the Oracle examples on web stopped working. I noticed that the textbook I use (Java, The Complete Reference 11 ed, Oracle Press) also took Java FX out. I really like JavaFX and I also teach Microsoft and Google (Android) courses. For GUI, they also use similar technologies in WPF, UWP and Android Development. It would be very helpful to make Java FX use easy again, so students start using Java FX again. I tried for a while but gave as I don't have to time to do all the research and install additional software. M. Saleem Yusuf -----Original Message----- From: openjfx-dev On Behalf Of Michael Paus Sent: Saturday, April 18, 2020 6:01 AM To: OpenJFX Subject: Remove JavaFX JPMS enforcement Getting started with JavaFX is made overly complicated by the fact that the use of the module system is enforced by some code in the JDK. Especially for beginners, who just want to get some small program running, this is almost always a big source of frustration. It is not very good marketing for JavaFX to make these initial steps such a pain. If you need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar sites (and also this mailing list). Almost every day you can read frustrated posts from helpless people who would just like to get some JavaFX project running but are failing because they get lost in the module system jungle. In order to make JavaFX more easily accessible, especially for beginners, I'd like to start a discussion here about the possibility to unconditionally remove the JavaFX JPMS enforcement. IMHO this enforcement is simply not necessary and is just the root for a lot of frustration with JavaFX. It should just be possible to put all the JavaFX jars on the classpath (instead of the module path) like you would do with any other external dependency in a non-modular setup. With a not very intuitive hack you can circumvent this problem already now. Just add a line like this to the file which contains your main class extending Application (MyApp). class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}} Because of this launcher it is now possible to put all dependencies and all JavaFX jars on the classpath and to completely forget the module system with all its intricacies and pitfalls. But why should people be forced to use such dirty tricks? The better alternative would be to just lift the current constraint. I am using this trick for a long time now, even on bigger projects, and I have never ever experienced any problem resulting from this. Even in theory I don't know anything that could prevent a formally correct module jar to also work on the classpath (which is of course not true the other way round). Therefore I say that this constraint is just not necessary and only does a lot of damage to JavaFXs reputation. I'd now like to have some feedback of the community about this. Michael From github.com+7517141+yososs at openjdk.java.net Sat Apr 18 16:49:28 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sat, 18 Apr 2020 16:49:28 GMT Subject: [Rev 01] RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > > private static final boolean USE_WIDTH_FIXED_SIZE = true; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=300; > private static final int COL_COUNT=600; > // private static final int COL_COUNT=1000; > private static final int ROW_COUNT=1000; > > @Override > public void start(Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if(USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > if(USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > prepareTimeline(scene); > > } > > public static void main(String[] args) { > Application.launch(args); > } > > private void prepareTimeline(Scene scene) { > new AnimationTimer() { > @Override public void handle(long now) { > double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage)scene.getWindow()).setTitle("FPS:"+(int)fps); > } > }.start(); > } > > } yosbits has updated the pull request incrementally with one additional commit since the last revision: 8185886: Fix scroll performance of TableView with many columns ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/125/files - new: https://git.openjdk.java.net/jfx/pull/125/files/04951abf..19fabf2e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/125/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/125/webrev.00-01 Stats: 48 lines in 1 file changed: 24 ins; 19 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/125/head:pull/125 PR: https://git.openjdk.java.net/jfx/pull/125 From cenbe at kolabnow.com Sat Apr 18 17:15:52 2020 From: cenbe at kolabnow.com (Glenn Holmer) Date: Sat, 18 Apr 2020 12:15:52 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: On 4/18/20 5:01 AM, Michael Paus wrote: > Getting started with JavaFX is made overly complicated by the fact > that the use of the module system is enforced by some code in the > JDK. Especially for beginners, who just want to get some small > program running, this is almost always a big source of frustration. > I'd now like to have some feedback of the community about this. Making it easy for beginners is the job of an IDE. NetBeans 12.0 beta3 can already create modular JavaFX projects using Maven in which "run project" and "debug project" work out of the box. Look for the addition of out-of-box profiling support in beta 4 (hopefully the last before 12.0 releases). -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." From github.com+7517141+yososs at openjdk.java.net Sat Apr 18 17:42:48 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Sat, 18 Apr 2020 17:42:48 GMT Subject: [Rev 01] RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Fri, 3 Apr 2020 03:55:37 GMT, yosbits wrote: >> Hi, >> I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail >> at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. > > My name is "Naohiro Yoshimoto" > I have received an approved email on 2019-8-3. 19fabf2eafcb02b519d39a1b0a9dad5b9209db64 * The constructor creates a cell, but the If the fixedCellSize is not initialized, the Fixed a wasteful process of creating all cells and deleting cells out of the display range. * Reduce the load on ExpressionHelper.removeListener by removing cells outside of the display range from the back of the scrolling operation. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From ajoseph at openjdk.java.net Sat Apr 18 17:49:49 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Sat, 18 Apr 2020 17:49:49 GMT Subject: FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern Message-ID: SVGTest.testSVGRenderingWithPattern is failing frequently due to [JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should skip this test until it is fixed. ------------- Commit messages: - 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern Changes: https://git.openjdk.java.net/jfx/pull/188/files Webrev: https://webrevs.openjdk.java.net/jfx/188/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243112 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/188.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/188/head:pull/188 PR: https://git.openjdk.java.net/jfx/pull/188 From kcr at openjdk.java.net Sat Apr 18 17:49:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Apr 2020 17:49:49 GMT Subject: FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern In-Reply-To: References: Message-ID: On Sat, 18 Apr 2020 17:38:17 GMT, Arun Joseph wrote: > SVGTest.testSVGRenderingWithPattern is failing frequently due to > [JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should skip this test until it is fixed. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/188 From twitch at nervestaple.com Sat Apr 18 18:18:44 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Sat, 18 Apr 2020 14:18:44 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> Message-ID: <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> Yep, that's where I downloaded it from. > PS C:\Users\cmiles\source\repos\xmltool> java --version > openjdk 14.0.1 2020-04-14 > OpenJDK Runtime Environment (build 14.0.1+7) > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) When I look at the "bin" directory that came with the JavaFX SDK and compare it to the "bin" directory that comes with OpenJDK there are things in the JavaFX distribution that aren't present in the OpenJDK distribution. These three caught my attention: + prism_common.dll + prism_d3d.dll + prism_sw.dll I suspect missing these DLL's is what is causing the exception when I try to launch my application. I took a look at "JDK-8207015" and I don't think that is my problem, yet. It could be that if the "prism_xxx.dll" files were present, I might run into this issue. I changed my `jlink` command to point at the "mods" as this seems like the correct way to do this. Still, the app refuses to launch with the same error message. > Graphics Device initialization failed for : d3d, sw > Error initializing QuantumRenderer: no suitable pipeline found > java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found I would very much like to avoid adding switches to a `java` invocation in order to run the application. In your example, I would need to have customer installed the JavaFX JDK to a specific location in order for that to work. I'd also need to have some kind of wrapper to handle other operating systems, like Linux or OS X. My goal is to distribute one package with custom launching scripts (i.e. one for batch, Powershell, and Linux/OS X shell) as I did under Java 8. This makes me think that using `jlink` with the mods is the way to go, as long as I can figure out why that is not working. Thank you for your help with this. :-) Kevin Rushforth wrote on 4/17/2020 17:34: > From where are you getting your OpenJDK build? https://jdk.java.net/14 > ? Somewhere else? > > -- Kevin > > > On 4/17/2020 2:16 PM, Christopher Miles wrote: >> Yeah, I've tried it with both. The instructions on the JavaFX page >> tell you to add the "lib" directory to the `javac` path and the "mods" >> to the `jlink` path. I figured, since nothing is working, why not try >> them the other way around? In all cases the results are the same. >> >> I'm using OpenJDK, wouldn't that project have the same issue >> distributing these DLL files? I would bet they would, since they are >> also an open source project. I can run Swing projects, however, >> without these DLL files. >> >> I can give the Oracle JDK a try. I had been shying away from it since >> OpenJDK is getting to be so popular. If that works, I will let the >> list know. >> >> As an aside, the JavaFX home page recommends using OpenJDK right now: >> >> ? https://openjfx.io/openjfx-docs/#install-java >> >> Thank you! >> >> Kevin Rushforth wrote on 4/17/2020 16:51: >>> Where are you getting JDK 14.0.1 from? Does it include the Microsoft >>> VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There are 45 of >>> them (40 of them are of the form api-ms-win-*.dll). The JavaFX 14.0.1 >>> sdk includes them, but the jmods do not. See JDK-8207015 [1] for why >>> not. If the JDK has them, then there should be no problem running a >>> jlinked app. >>> >>> One possible problem is that your jlink line is wrong. You should not >>> point to the SDK at all when running jlink. Use the jmods with jlink >>> (don't use the sdk). Use the sdk with javac and java --module-path >>> (don't use the jmods at all). >>> >>> Btw, even if you are running a JDK that for some reason doesn't have >>> the Microsoft DLLs, you should still be able to run using the SDK >>> (directly, not via jlink, which requires the jmods) as follows: >>> >>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>> --add-modules >>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>> MyApplication >>> >>> If this doesn't work without you putting javafx-sdk-14/bin in your >>> PATH then something else is wrong. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>> >>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>> I have downloaded both the "mods" and the SDK. I put them alongside >>>> the JDK on my workstation. >>>> >>>> ? C:\Program Files\Java\jdk-14.0.1 >>>> ? C:\Program Files\Java\javafx-sdk-14 >>>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>>> >>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` path... >>>> >>>> jlink --module-path "C:\Program >>>> Files\Java\javafx-sdk-14\lib;C:\Program Files\Java\jdk-14.0.1/jmods" >>>> --add-modules >>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>> >>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>> global path, the application builds. When I try to run the >>>> application I see the following error. >>>> >>>> ? Graphics Device initialization failed for :? d3d, sw >>>> ? Error initializing QuantumRenderer: no suitable pipeline found >>>> >>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>> as I can tell, the exact same effect. :-( >>>> >>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>> global PATH then it does run successfully. >>>> >>>> I hear what you're saying but this doesn't seem to be the case... >>>> >>>> What version of Windows are you using? I don't think this is a >>>> Windows 10 specific issue but perhaps there is something platform >>>> specific involved. >>>> >>>> Thank you! >>>> >>>> >>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>> You suggest there will be a problem if you use jlink, but it will >>>>> work if you include the needed javafx modules. The .jmod files >>>>> contain the necessary native libraries and jlink will build a JRE >>>>> that has the DLLs in the right place for the runtime to find them. >>>>> >>>>> Modifying your PATH is not the right way to do this. Distributing a >>>>> runtime with your application is the right way to solve this. The >>>>> jlink and jpackage tools make this fairly easy. I use a custom >>>>> Gradle script to bundle my application, it works well. >>>>> >>>>> Scott >>>>> >>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>> wrote: >>>>>> >>>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>>> since I've worked on this project, almost two years. At that time >>>>>> JavaFX was bundled with the Java runtime from Oracle. The few >>>>>> customers I had would simply run the application from the bundled >>>>>> launcher and as long as they had Java installed, it would work. >>>>>> >>>>>> It's time for me to add some features to the project, I am now >>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>> followed the instructions[1] from the following URL: >>>>>> >>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>> >>>>>> I am on Windows and followed the instructions for that platform. >>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>> >>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>> wn Source) >>>>>> >>>>>> I fussed with this and that but nothing made a difference. >>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>> distribution to my path. This is the entry I added to my global >>>>>> PATH variable: >>>>>> >>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>> >>>>>> Is this the right way to do this and, if so, why isn't this >>>>>> included in the directions? Is this a Windows specific issue? >>>>>> >>>>>> Also, what impact does this have on distribution of applications? >>>>>> >>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>> same issues will be present. Those instructions use `jlink` to >>>>>> point to the JavaFX libraries and the JAVAFX modules (distributed >>>>>> in another package) but also leave off references to the DLL files >>>>>> in the "bin" directory. I am worried that I will need to have >>>>>> people manually install the OpenJavaFX distribution and add the >>>>>> "bin" directory to their path in order to run my application. >>>>>> Please say it's not so! >>>>>> >>>>>> Any help or pointers to additional documentation would be very >>>>>> much appreciated! I have made it over the bumps and can now >>>>>> continue development of my application, my next concern is >>>>>> distributing it to customers. >>>>>> >>>>>> -- >>>>>> Miles >>>>>> >>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>> >>>> >>>> >>> >> >> > -- Miles From mp at jugs.org Sat Apr 18 18:44:43 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Apr 2020 20:44:43 +0200 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> Message-ID: <3525e2d5-b813-6895-0bba-a933f0fbc101@jugs.org> Hi Christopher, I do not know what your specific problem is but maybe you just have to shift your goals a little bit. Continuing like you did in the Java 8 days is not a good idea for various reasons. The current trend for distributing desktop software with Java is to build a platform specific installer. The tools for that are all there. Just give it a try. Together with Dirk Lemmermann I have set up a working example and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac and Windows (should also work on Linux but I haven't tested it.) The nice thing about this approach is that your customer does not have to have anything installed on his own machine. He can just install your software like he would install any other piece of software. Michael Am 18.04.20 um 20:18 schrieb Christopher Miles: > Yep, that's where I downloaded it from. > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > openjdk 14.0.1 2020-04-14 > > OpenJDK Runtime Environment (build 14.0.1+7) > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > When I look at the "bin" directory that came with the JavaFX SDK and > compare it to the "bin" directory that comes with OpenJDK there are > things in the JavaFX distribution that aren't present in the OpenJDK > distribution. These three caught my attention: > > ? + prism_common.dll > ? + prism_d3d.dll > ? + prism_sw.dll > > I suspect missing these DLL's is what is causing the exception when I > try to launch my application. > > I took a look at "JDK-8207015" and I don't think that is my problem, > yet. It could be that if the "prism_xxx.dll" files were present, I > might run into this issue. > > I changed my `jlink` command to point at the "mods" as this seems like > the correct way to do this. Still, the app refuses to launch with the > same error message. > > > Graphics Device initialization failed for :? d3d, sw > > Error initializing QuantumRenderer: no suitable pipeline found > > java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing QuantumRenderer: no suitable pipeline found > > I would very much like to avoid adding switches to a `java` invocation > in order to run the application. In your example, I would need to have > customer installed the JavaFX JDK to a specific location in order for > that to work. I'd also need to have some kind of wrapper to handle > other operating systems, like Linux or OS X. My goal is to distribute > one package with custom launching scripts (i.e. one for batch, > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > think that using `jlink` with the mods is the way to go, as long as I > can figure out why that is not working. > > Thank you for your help with this. :-) > > Kevin Rushforth wrote on 4/17/2020 17:34: >> ?From where are you getting your OpenJDK build? >> https://jdk.java.net/14 ? Somewhere else? >> >> -- Kevin >> >> >> On 4/17/2020 2:16 PM, Christopher Miles wrote: >>> Yeah, I've tried it with both. The instructions on the JavaFX page >>> tell you to add the "lib" directory to the `javac` path and the >>> "mods" to the `jlink` path. I figured, since nothing is working, why >>> not try them the other way around? In all cases the results are the >>> same. >>> >>> I'm using OpenJDK, wouldn't that project have the same issue >>> distributing these DLL files? I would bet they would, since they are >>> also an open source project. I can run Swing projects, however, >>> without these DLL files. >>> >>> I can give the Oracle JDK a try. I had been shying away from it >>> since OpenJDK is getting to be so popular. If that works, I will let >>> the list know. >>> >>> As an aside, the JavaFX home page recommends using OpenJDK right now: >>> >>> ? https://openjfx.io/openjfx-docs/#install-java >>> >>> Thank you! >>> >>> Kevin Rushforth wrote on 4/17/2020 16:51: >>>> Where are you getting JDK 14.0.1 from? Does it include the >>>> Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There >>>> are 45 of them (40 of them are of the form api-ms-win-*.dll). The >>>> JavaFX 14.0.1 sdk includes them, but the jmods do not. See >>>> JDK-8207015 [1] for why not. If the JDK has them, then there should >>>> be no problem running a jlinked app. >>>> >>>> One possible problem is that your jlink line is wrong. You should >>>> not point to the SDK at all when running jlink. Use the jmods with >>>> jlink (don't use the sdk). Use the sdk with javac and java >>>> --module-path (don't use the jmods at all). >>>> >>>> Btw, even if you are running a JDK that for some reason doesn't >>>> have the Microsoft DLLs, you should still be able to run using the >>>> SDK (directly, not via jlink, which requires the jmods) as follows: >>>> >>>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>>> --add-modules >>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>>> MyApplication >>>> >>>> If this doesn't work without you putting javafx-sdk-14/bin in your >>>> PATH then something else is wrong. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>>> >>>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>>> I have downloaded both the "mods" and the SDK. I put them >>>>> alongside the JDK on my workstation. >>>>> >>>>> ? C:\Program Files\Java\jdk-14.0.1 >>>>> ? C:\Program Files\Java\javafx-sdk-14 >>>>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>>>> >>>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` >>>>> path... >>>>> >>>>> jlink --module-path "C:\Program >>>>> Files\Java\javafx-sdk-14\lib;C:\Program >>>>> Files\Java\jdk-14.0.1/jmods" --add-modules >>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>>> >>>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>>> global path, the application builds. When I try to run the >>>>> application I see the following error. >>>>> >>>>> ? Graphics Device initialization failed for :? d3d, sw >>>>> ? Error initializing QuantumRenderer: no suitable pipeline found >>>>> >>>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>>> as I can tell, the exact same effect. :-( >>>>> >>>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>>> global PATH then it does run successfully. >>>>> >>>>> I hear what you're saying but this doesn't seem to be the case... >>>>> >>>>> What version of Windows are you using? I don't think this is a >>>>> Windows 10 specific issue but perhaps there is something platform >>>>> specific involved. >>>>> >>>>> Thank you! >>>>> >>>>> >>>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>>> You suggest there will be a problem if you use jlink, but it will >>>>>> work if you include the needed javafx modules. The .jmod files >>>>>> contain the necessary native libraries and jlink will build a JRE >>>>>> that has the DLLs in the right place for the runtime to find them. >>>>>> >>>>>> Modifying your PATH is not the right way to do this. Distributing >>>>>> a runtime with your application is the right way to solve this. >>>>>> The jlink and jpackage tools make this fairly easy. I use a >>>>>> custom Gradle script to bundle my application, it works well. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>>> wrote: >>>>>>> >>>>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>>>> since I've worked on this project, almost two years. At that >>>>>>> time JavaFX was bundled with the Java runtime from Oracle. The >>>>>>> few customers I had would simply run the application from the >>>>>>> bundled launcher and as long as they had Java installed, it >>>>>>> would work. >>>>>>> >>>>>>> It's time for me to add some features to the project, I am now >>>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>>> followed the instructions[1] from the following URL: >>>>>>> >>>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>>> >>>>>>> I am on Windows and followed the instructions for that platform. >>>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>>> >>>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>>> wn Source) >>>>>>> >>>>>>> I fussed with this and that but nothing made a difference. >>>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>>> distribution to my path. This is the entry I added to my global >>>>>>> PATH variable: >>>>>>> >>>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>>> >>>>>>> Is this the right way to do this and, if so, why isn't this >>>>>>> included in the directions? Is this a Windows specific issue? >>>>>>> >>>>>>> Also, what impact does this have on distribution of applications? >>>>>>> >>>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>>> same issues will be present. Those instructions use `jlink` to >>>>>>> point to the JavaFX libraries and the JAVAFX modules >>>>>>> (distributed in another package) but also leave off references >>>>>>> to the DLL files in the "bin" directory. I am worried that I >>>>>>> will need to have people manually install the OpenJavaFX >>>>>>> distribution and add the "bin" directory to their path in order >>>>>>> to run my application. Please say it's not so! >>>>>>> >>>>>>> Any help or pointers to additional documentation would be very >>>>>>> much appreciated! I have made it over the bumps and can now >>>>>>> continue development of my application, my next concern is >>>>>>> distributing it to customers. >>>>>>> >>>>>>> -- >>>>>>> Miles >>>>>>> >>>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From github.com+3197675+abhinayagarwal at openjdk.java.net Sun Apr 19 08:22:45 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Sun, 19 Apr 2020 08:22:45 GMT Subject: RFR: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine Message-ID: Update WebEngine's Javadoc to add information on how it switches to HttpClient instead of URLConnection in JavaFX 14 when used with JDK 12 or later. Identification the correct client is important as both these clients may offer different ways to achieve a task. One such task can be bypassing insecure HTTPS connection. ------------- Commit messages: - Remove trailing whitespace - 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine Changes: https://git.openjdk.java.net/jfx/pull/189/files Webrev: https://webrevs.openjdk.java.net/jfx/189/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242077 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/189/head:pull/189 PR: https://git.openjdk.java.net/jfx/pull/189 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 09:36:12 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 09:36:12 GMT Subject: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sat, 18 Apr 2020 15:50:55 GMT, Kevin Rushforth wrote: >> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. >> >> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 > > modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java line 196: > >> 195: private ObjectProperty toggleGroup; >> 196: @Override >> 197: public final void setToggleGroup(ToggleGroup value) { > > This is unrelated to the fix. The changes in this file should be reverted. OK. They are gone. Would this (keeping the changes very specific to the bug?) be worth mentioning in CONTRIBUTING.md? That is, like the note about imports: do not fix warnings that are not directly related to the issue? ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 09:51:07 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 09:51:07 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 Jesper Skov has updated the pull request incrementally with three additional commits since the last revision: - Fail instead of print message - addedToggles list is final - Leave unrelated file alone ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/167/files - new: https://git.openjdk.java.net/jfx/pull/167/files/1386ad74..10eef05b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/167/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/167/webrev.00-01 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/167.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/167/head:pull/167 PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 09:58:42 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 09:58:42 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sat, 18 Apr 2020 16:04:34 GMT, Kevin Rushforth wrote: >> Jesper Skov has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fail instead of print message >> - addedToggles list is final >> - Leave unrelated file alone > > The fix looks correct to me. Have you run all tests to ensure no regressions? > > I left a couple inline comments. @kevinrushforth I tested by: ` bash ./gradlew clean all test -x :web:test ` I assumed that would do it. But I see use of ToggleButton in javafx.web, so that was clearly a faulty assumption. I will try to get webkit working. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+636962+ccavanaugh at openjdk.java.net Sun Apr 19 10:40:14 2020 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Sun, 19 Apr 2020 10:40:14 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Fri, 17 Apr 2020 10:42:30 GMT, Jeanette Winzenburg wrote: > repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): > I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered > :) > - is it really a bug or a nice-to-have enhancement? couldn't find an example in win, didn't try too hard and nowadays, > such plain combos are not a really frequent > - while none of the virtualized controls (nor ChoiceBox) combines selection with scrolling to the selected item. For > combo and choice, I see no reason not make it the default behavior. We need to make certain it behaves "naturally" when > navigating in the open popup. > - instead of catching every list.select (and not forget the unselect) we might consider doing it in a showing handler > - alternatively, we might consider to go deeper and support it directly in the listView - For me / my users / and the open bug, it is a bug due to the current behavior being unexpected. It creates the illusion of a preselected value not actually being selected because it's not visible if the list is large and has been shown. It creates doubt and the user has to scroll to reconfirm their selection which takes extra unnecessary effort and time. - With my testing, for the ComboBox, behavior was smooth and natural. I've not made any attempt to change selection with it shown and I'm not certain it can happen unless done programmatically. User selection within the list requires scrolling, so the selected value is already visible. - I'm not opposed to taking this approach. My current work around by extending ComboBox is based on scrolling when the value is set (restored) programmatically. I could see how it may be more efficient if multiple selections were being performed programmatically, but not sure why someone would write code this way. I would think it's a one shot process to select the final value. - Implementing the change in ListView would not change/improve ChoiceBox simply because it does not use an underlying ListView. My search on uses of ListView only reviled ComboBox other than itself. Since ListView by itself is not collapsed/hidden for typical uses, would automatic scrolling within ListView create a confusing experience? ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 12:44:23 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 12:44:23 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 09:56:27 GMT, Jesper Skov wrote: >> The fix looks correct to me. Have you run all tests to ensure no regressions? >> >> I left a couple inline comments. > > @kevinrushforth I tested by: > ` > bash ./gradlew clean all test -x :web:test > ` > I assumed that would do it. > But I see use of ToggleButton in javafx.web, so that was clearly a faulty assumption. > > I will try to get webkit working. I have failed getting web:tests to work. Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the error below. And that is with both a locally built webkit, and the one from javafx-web-15-ea+3-linux.jar So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW). Any suggestions for how to resolve this? ` > Task :web:test ***************************************************** WARNING: running web tests without building webkit. The webkit native library will be copied from the JDK, which might lead to failures in some web tests. To avoid these failures, you should either build webkit locally, copy the native webkit library from a recent build, or skip execution of web test cases with '-x :web:test' ***************************************************** Exception in thread "JavaFX Application Thread" # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f4e01ae8a61, pid=78774, tid=78815 # # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10) # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x579a61] AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /opt/sources/github/jfx/modules/javafx.web/core.78774) # # An error report file with more information is saved as: # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log # # If you would like to submit a bug report, please visit: # https://github.com/AdoptOpenJDK/openjdk-support/issues # ` ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 12:46:31 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 12:46:31 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 12:42:09 GMT, Jesper Skov wrote: >> @kevinrushforth I tested by: >> ` >> bash ./gradlew clean all test -x :web:test >> ` >> I assumed that would do it. >> But I see use of ToggleButton in javafx.web, so that was clearly a faulty assumption. >> >> I will try to get webkit working. > > I have failed getting web:tests to work. > Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the error below. > > And that is with both a locally built webkit, and the one from javafx-web-15-ea+3-linux.jar > > So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW). > > Any suggestions for how to resolve this? > > ` >> Task :web:test > ***************************************************** > WARNING: running web tests without building webkit. > The webkit native library will be copied from the JDK, > which might lead to failures in some web tests. > To avoid these failures, you should either build > webkit locally, copy the native webkit library from a > recent build, or skip execution of web test cases with > '-x :web:test' > ***************************************************** > Exception in thread "JavaFX Application Thread" > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f4e01ae8a61, pid=78774, tid=78815 > # > # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10) > # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x579a61] AccessInternal::PostRuntimeDispatch, > (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P > %u %g %s %t %c %h" (or dumping to /opt/sources/github/jfx/modules/javafx.web/core.78774) # > # An error report file with more information is saved as: > # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log > # > # If you would like to submit a bug report, please visit: > # https://github.com/AdoptOpenJDK/openjdk-support/issues > # > ` Uh, the exception is (as the comment note suggests) from using a prebuilt webkit. I will try a locally built one now. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From github.com+2720909+jskov at openjdk.java.net Sun Apr 19 13:52:36 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Sun, 19 Apr 2020 13:52:36 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 12:44:23 GMT, Jesper Skov wrote: >> I have failed getting web:tests to work. >> Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the error below. >> >> And that is with both a locally built webkit, and the one from javafx-web-15-ea+3-linux.jar >> >> So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW). >> >> Any suggestions for how to resolve this? >> >> ` >>> Task :web:test >> ***************************************************** >> WARNING: running web tests without building webkit. >> The webkit native library will be copied from the JDK, >> which might lead to failures in some web tests. >> To avoid these failures, you should either build >> webkit locally, copy the native webkit library from a >> recent build, or skip execution of web test cases with >> '-x :web:test' >> ***************************************************** >> Exception in thread "JavaFX Application Thread" >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007f4e01ae8a61, pid=78774, tid=78815 >> # >> # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10) >> # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x579a61] AccessInternal::PostRuntimeDispatch, >> (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P >> %u %g %s %t %c %h" (or dumping to /opt/sources/github/jfx/modules/javafx.web/core.78774) # >> # An error report file with more information is saved as: >> # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log >> # >> # If you would like to submit a bug report, please visit: >> # https://github.com/AdoptOpenJDK/openjdk-support/issues >> # >> ` > > Uh, the exception is (as the comment note suggests) from using a prebuilt webkit. > I will try a locally built one now. Ah, well. Ended with the same VM crash when building webkit myself. So I am kinda stuck. Suggestions? ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From apurwaagr at gmail.com Sun Apr 19 21:34:00 2020 From: apurwaagr at gmail.com (Apurwa Agrawal) Date: Mon, 20 Apr 2020 03:04:00 +0530 Subject: mailing list invite Message-ID: Hello Please add me to mailing list: apurwagr at gmail.com Thanks and Regards Apurwa Agrawal From ebresie at gmail.com Mon Apr 20 01:55:17 2020 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 19 Apr 2020 20:55:17 -0500 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: 3525e2d5-b813-6895-0bba-a933f0fbc101@jugs.org References: 68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com BDCD737D-A161-40D0-9CAE-1828BFC03CAF@gmail.com 9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com a9ec3335-3e5c-4988-68f5-1f4318e61d5f@oracle.com e8105ea9-62b9-49b3-e1a5-cfb2e4677e1a@nervestaple.com acc3cc78-ef1c-96a3-20be-4a6f45ccd867@oracle.com 8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com 8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com Message-ID: <83c6e199-d7cd-4a44-b0bf-9c5ab01e65c5@Erics-iPhone-X> Would jdeps help to see what dependencies are needed? Eric Bresie Ebresie at gmail.com > On April 18, 2020 at 1:44:43 PM CDT, Michael Paus wrote: > Hi Christopher, > I do not know what your specific problem is but maybe you just have to > shift your goals a little bit. > Continuing like you did in the Java 8 days is not a good idea for > various reasons. The current trend > for distributing desktop software with Java is to build a platform > specific installer. The tools for that > are all there. Just give it a try. Together with Dirk Lemmermann I have > set up a working example > and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac > and Windows (should also work > on Linux but I haven't tested it.) > > The nice thing about this approach is that your customer does not have > to have anything installed on his > own machine. He can just install your software like he would install any > other piece of software. > Michael > > Am 18.04.20 um 20:18 schrieb Christopher Miles: > > Yep, that's where I downloaded it from. > > > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > > openjdk 14.0.1 2020-04-14 > > > OpenJDK Runtime Environment (build 14.0.1+7) > > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > > > When I look at the "bin" directory that came with the JavaFX SDK and > > compare it to the "bin" directory that comes with OpenJDK there are > > things in the JavaFX distribution that aren't present in the OpenJDK > > distribution. These three caught my attention: > > > > + prism_common.dll > > + prism_d3d.dll > > + prism_sw.dll > > > > I suspect missing these DLL's is what is causing the exception when I > > try to launch my application. > > > > I took a look at "JDK-8207015" and I don't think that is my problem, > > yet. It could be that if the "prism_xxx.dll" files were present, I > > might run into this issue. > > > > I changed my `jlink` command to point at the "mods" as this seems like > > the correct way to do this. Still, the app refuses to launch with the > > same error message. > > > > > Graphics Device initialization failed for : d3d, sw > > > Error initializing QuantumRenderer: no suitable pipeline found > > > java.lang.RuntimeException: java.lang.RuntimeException: Error > > initializing QuantumRenderer: no suitable pipeline found > > > > I would very much like to avoid adding switches to a `java` invocation > > in order to run the application. In your example, I would need to have > > customer installed the JavaFX JDK to a specific location in order for > > that to work. I'd also need to have some kind of wrapper to handle > > other operating systems, like Linux or OS X. My goal is to distribute > > one package with custom launching scripts (i.e. one for batch, > > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > > think that using `jlink` with the mods is the way to go, as long as I > > can figure out why that is not working. > > > > Thank you for your help with this. :-) > > > > Kevin Rushforth wrote on 4/17/2020 17:34: > > > From where are you getting your OpenJDK build? > > > https://jdk.java.net/14 ? Somewhere else? > > > > > > -- Kevin > > > > > > > > > On 4/17/2020 2:16 PM, Christopher Miles wrote: > > > > Yeah, I've tried it with both. The instructions on the JavaFX page > > > > tell you to add the "lib" directory to the `javac` path and the > > > > "mods" to the `jlink` path. I figured, since nothing is working, why > > > > not try them the other way around? In all cases the results are the > > > > same. > > > > > > > > I'm using OpenJDK, wouldn't that project have the same issue > > > > distributing these DLL files? I would bet they would, since they are > > > > also an open source project. I can run Swing projects, however, > > > > without these DLL files. > > > > > > > > I can give the Oracle JDK a try. I had been shying away from it > > > > since OpenJDK is getting to be so popular. If that works, I will let > > > > the list know. > > > > > > > > As an aside, the JavaFX home page recommends using OpenJDK right now: > > > > > > > > https://openjfx.io/openjfx-docs/#install-java > > > > > > > > Thank you! > > > > > > > > Kevin Rushforth wrote on 4/17/2020 16:51: > > > > > Where are you getting JDK 14.0.1 from? Does it include the > > > > > Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There > > > > > are 45 of them (40 of them are of the form api-ms-win-*.dll). The > > > > > JavaFX 14.0.1 sdk includes them, but the jmods do not. See > > > > > JDK-8207015 [1] for why not. If the JDK has them, then there should > > > > > be no problem running a jlinked app. > > > > > > > > > > One possible problem is that your jlink line is wrong. You should > > > > > not point to the SDK at all when running jlink. Use the jmods with > > > > > jlink (don't use the sdk). Use the sdk with javac and java > > > > > --module-path (don't use the jmods at all). > > > > > > > > > > Btw, even if you are running a JDK that for some reason doesn't > > > > > have the Microsoft DLLs, you should still be able to run using the > > > > > SDK (directly, not via jlink, which requires the jmods) as follows: > > > > > > > > > > java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" > > > > > --add-modules > > > > > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web > > > > > MyApplication > > > > > > > > > > If this doesn't work without you putting javafx-sdk-14/bin in your > > > > > PATH then something else is wrong. > > > > > > > > > > -- Kevin > > > > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8207015 > > > > > > > > > > On 4/17/2020 1:18 PM, Christopher Miles wrote: > > > > > > I have downloaded both the "mods" and the SDK. I put them > > > > > > alongside the JDK on my workstation. > > > > > > > > > > > > C:\Program Files\Java\jdk-14.0.1 > > > > > > C:\Program Files\Java\javafx-sdk-14 > > > > > > C:\Program Files\Java\javafx-jmods-14.0.1 > > > > > > > > > > > > If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and > > > > > > point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` > > > > > > path... > > > > > > > > > > > > jlink --module-path "C:\Program > > > > > > Files\Java\javafx-sdk-14\lib;C:\Program > > > > > > Files\Java\jdk-14.0.1/jmods" --add-modules > > > > > > javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base > > > > > > --output C:\Users\cmiles\source\repos\xmltool\target/jlink > > > > > > --strip-debug --no-man-pages --no-header-files --compress=2 > > > > > > > > > > > > ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my > > > > > > global path, the application builds. When I try to run the > > > > > > application I see the following error. > > > > > > > > > > > > Graphics Device initialization failed for : d3d, sw > > > > > > Error initializing QuantumRenderer: no suitable pipeline found > > > > > > > > > > > > Swapping out the mods path for the SDK "lib" directory has, as far > > > > > > as I can tell, the exact same effect. :-( > > > > > > > > > > > > If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my > > > > > > global PATH then it does run successfully. > > > > > > > > > > > > I hear what you're saying but this doesn't seem to be the case... > > > > > > > > > > > > What version of Windows are you using? I don't think this is a > > > > > > Windows 10 specific issue but perhaps there is something platform > > > > > > specific involved. > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > > > > > > Scott Palmer wrote on 4/17/2020 15:23: > > > > > > > I use jlink and jpackage to distribute JavaFX applications. > > > > > > > You suggest there will be a problem if you use jlink, but it will > > > > > > > work if you include the needed javafx modules. The .jmod files > > > > > > > contain the necessary native libraries and jlink will build a JRE > > > > > > > that has the DLLs in the right place for the runtime to find them. > > > > > > > > > > > > > > Modifying your PATH is not the right way to do this. Distributing > > > > > > > a runtime with your application is the right way to solve this. > > > > > > > The jlink and jpackage tools make this fairly easy. I use a > > > > > > > custom Gradle script to bundle my application, it works well. > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > On Apr 17, 2020, at 2:55 PM, Christopher Miles > > > > > > > > wrote: > > > > > > > > > > > > > > > > I manage a project[0] that leverages JavaFX. It's been a while > > > > > > > > since I've worked on this project, almost two years. At that > > > > > > > > time JavaFX was bundled with the Java runtime from Oracle. The > > > > > > > > few customers I had would simply run the application from the > > > > > > > > bundled launcher and as long as they had Java installed, it > > > > > > > > would work. > > > > > > > > > > > > > > > > It's time for me to add some features to the project, I am now > > > > > > > > using OpenJDK 14.0.1 and I installed the OpenJavaFX package and > > > > > > > > followed the instructions[1] from the following URL: > > > > > > > > > > > > > > > > https://openjfx.io/openjfx-docs/#install-javafx > > > > > > > > > > > > > > > > I am on Windows and followed the instructions for that platform. > > > > > > > > Unfortunately, things didn't really work. The error was as follows: > > > > > > > > > > > > > > > > Graphics Device initialization failed for : d3d, sw Error > > > > > > > > initializing QuantumRenderer: no suitable pipeline found > > > > > > > > java.lang.RuntimeException: java.lang.RuntimeException: Error > > > > > > > > initializing QuantumRend erer: no suitable pipeline found at > > > > > > > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno > > > > > > > > wn Source) > > > > > > > > > > > > > > > > I fussed with this and that but nothing made a difference. > > > > > > > > Eventually I tried adding the "bin" directory from the JavaFX > > > > > > > > distribution to my path. This is the entry I added to my global > > > > > > > > PATH variable: > > > > > > > > > > > > > > > > C:\Program Files\Java\javafx-sdk-14\bin > > > > > > > > > > > > > > > > Is this the right way to do this and, if so, why isn't this > > > > > > > > included in the directions? Is this a Windows specific issue? > > > > > > > > > > > > > > > > Also, what impact does this have on distribution of applications? > > > > > > > > > > > > > > > > Looking at the "Runtime Images" instructions, it looks like the > > > > > > > > same issues will be present. Those instructions use `jlink` to > > > > > > > > point to the JavaFX libraries and the JAVAFX modules > > > > > > > > (distributed in another package) but also leave off references > > > > > > > > to the DLL files in the "bin" directory. I am worried that I > > > > > > > > will need to have people manually install the OpenJavaFX > > > > > > > > distribution and add the "bin" directory to their path in order > > > > > > > > to run my application. Please say it's not so! > > > > > > > > > > > > > > > > Any help or pointers to additional documentation would be very > > > > > > > > much appreciated! I have made it over the bumps and can now > > > > > > > > continue development of my application, my next concern is > > > > > > > > distributing it to customers. > > > > > > > > > > > > > > > > -- > > > > > > > > Miles > > > > > > > > > > > > > > > > [0]: https://github.com/cmiles74/xmltool > > > > > > > > [1]: https://openjfx.io/openjfx-docs/#install-javafx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nlisker at gmail.com Mon Apr 20 04:43:08 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 20 Apr 2020 07:43:08 +0300 Subject: Testing JavaFX with Java14 preview features In-Reply-To: References: <42320579-29a5-8aab-7988-18236aff2ad5@oracle.com> Message-ID: I managed to get it working by adding "--enable-preview" in several places, I'm not sure if they are all needed. There will be a test branch in my fork with the working build.grade. On Tue, Apr 14, 2020 at 4:35 AM Nir Lisker wrote: > It contains: > -source > 14 > -target > 14 > > Looks like I'll have to do some digging. > > Thanks > > On Tue, Apr 14, 2020 at 2:38 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Not sure, but you might check here: >> >> modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt >> >> That's the list of args that gradle generates to pass to javac (using >> @.../java-compiler-args.txt) >> >> -- Kevin >> >> On 4/13/2020 4:10 PM, Nir Lisker wrote: >> >> Thanks, yes, testing on JavaFX itself. >> I made these changes. I'm getting "error: invalid source release: 14" >> when trying to build. These are the settings that are output during the >> task: >> >> Gradle Distribution: Gradle wrapper from target build >> Gradle Version: 6.3 >> Java Home: C:\Program Files\Java\jdk-14 >> JVM Arguments: None >> Program Arguments: None >> Build Scans Enabled: false >> Offline Mode Enabled: false >> Gradle Tasks: build >> >> This is the full error message: >> >> error: invalid source release: 14 >> Usage: javac >> use --help for a list of possible options >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':base:compileJava'. >> > Compilation failed with exit code 2; see the compiler error output for >> details. >> >> On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> I guess you mean modifying the FX build in your local repo so that you >>> can test the use of JDK 14 preview features in FX itself? (if you were >>> just trying to use it from your app you wouldn't need any build changes >>> in FX). At a minimum you would need to add the "--enable-preview" flag >>> to compile.options.compilerArgs, and change "sourceCompatibility" from >>> "11" to "14". Not sure if anything more is needed. I've never tried it. >>> >>> -- Kevin >>> >>> >>> On 4/13/2020 1:49 PM, Nir Lisker wrote: >>> > Hi, >>> > >>> > I would like to test the preview features in Java 14 on JavaFX. What >>> > changes should I make in the build files to get it working? >>> > >>> > - Nir >>> >>> >> From mp at jugs.org Mon Apr 20 06:51:44 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 08:51:44 +0200 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <83c6e199-d7cd-4a44-b0bf-9c5ab01e65c5@Erics-iPhone-X> References: <83c6e199-d7cd-4a44-b0bf-9c5ab01e65c5@Erics-iPhone-X> Message-ID: <71071db3-acf8-6c83-94a5-b165d08961d1@jugs.org> Yes, that's what I use in my example together with jlink and jpackage. Am 20.04.20 um 03:55 schrieb Eric Bresie: > Would jdeps help to see what dependencies are needed? > > Eric Bresie > Ebresie at gmail.com >> On April 18, 2020 at 1:44:43 PM CDT, Michael Paus wrote: >> Hi Christopher, >> I do not know what your specific problem is but maybe you just have to >> shift your goals a little bit. >> Continuing like you did in the Java 8 days is not a good idea for >> various reasons. The current trend >> for distributing desktop software with Java is to build a platform >> specific installer. The tools for that >> are all there. Just give it a try. Together with Dirk Lemmermann I have >> set up a working example >> and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac >> and Windows (should also work >> on Linux but I haven't tested it.) >> >> The nice thing about this approach is that your customer does not have >> to have anything installed on his >> own machine. He can just install your software like he would install any >> other piece of software. >> Michael >> >> Am 18.04.20 um 20:18 schrieb Christopher Miles: >>> Yep, that's where I downloaded it from. >>> >>>> PS C:\Users\cmiles\source\repos\xmltool> java --version >>>> openjdk 14.0.1 2020-04-14 >>>> OpenJDK Runtime Environment (build 14.0.1+7) >>>> OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) >>> When I look at the "bin" directory that came with the JavaFX SDK and >>> compare it to the "bin" directory that comes with OpenJDK there are >>> things in the JavaFX distribution that aren't present in the OpenJDK >>> distribution. These three caught my attention: >>> >>> + prism_common.dll >>> + prism_d3d.dll >>> + prism_sw.dll >>> >>> I suspect missing these DLL's is what is causing the exception when I >>> try to launch my application. >>> >>> I took a look at "JDK-8207015" and I don't think that is my problem, >>> yet. It could be that if the "prism_xxx.dll" files were present, I >>> might run into this issue. >>> >>> I changed my `jlink` command to point at the "mods" as this seems like >>> the correct way to do this. Still, the app refuses to launch with the >>> same error message. >>> >>>> Graphics Device initialization failed for : d3d, sw >>>> Error initializing QuantumRenderer: no suitable pipeline found >>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>> initializing QuantumRenderer: no suitable pipeline found >>> >>> I would very much like to avoid adding switches to a `java` invocation >>> in order to run the application. In your example, I would need to have >>> customer installed the JavaFX JDK to a specific location in order for >>> that to work. I'd also need to have some kind of wrapper to handle >>> other operating systems, like Linux or OS X. My goal is to distribute >>> one package with custom launching scripts (i.e. one for batch, >>> Powershell, and Linux/OS X shell) as I did under Java 8. This makes me >>> think that using `jlink` with the mods is the way to go, as long as I >>> can figure out why that is not working. >>> >>> Thank you for your help with this. :-) >>> >>> Kevin Rushforth wrote on 4/17/2020 17:34: >>>> From where are you getting your OpenJDK build? >>>> https://jdk.java.net/14 ? Somewhere else? >>>> >>>> -- Kevin >>>> >>>> >>>> On 4/17/2020 2:16 PM, Christopher Miles wrote: >>>>> Yeah, I've tried it with both. The instructions on the JavaFX page >>>>> tell you to add the "lib" directory to the `javac` path and the >>>>> "mods" to the `jlink` path. I figured, since nothing is working, why >>>>> not try them the other way around? In all cases the results are the >>>>> same. >>>>> >>>>> I'm using OpenJDK, wouldn't that project have the same issue >>>>> distributing these DLL files? I would bet they would, since they are >>>>> also an open source project. I can run Swing projects, however, >>>>> without these DLL files. >>>>> >>>>> I can give the Oracle JDK a try. I had been shying away from it >>>>> since OpenJDK is getting to be so popular. If that works, I will let >>>>> the list know. >>>>> >>>>> As an aside, the JavaFX home page recommends using OpenJDK right now: >>>>> >>>>> https://openjfx.io/openjfx-docs/#install-java >>>>> >>>>> Thank you! >>>>> >>>>> Kevin Rushforth wrote on 4/17/2020 16:51: >>>>>> Where are you getting JDK 14.0.1 from? Does it include the >>>>>> Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There >>>>>> are 45 of them (40 of them are of the form api-ms-win-*.dll). The >>>>>> JavaFX 14.0.1 sdk includes them, but the jmods do not. See >>>>>> JDK-8207015 [1] for why not. If the JDK has them, then there should >>>>>> be no problem running a jlinked app. >>>>>> >>>>>> One possible problem is that your jlink line is wrong. You should >>>>>> not point to the SDK at all when running jlink. Use the jmods with >>>>>> jlink (don't use the sdk). Use the sdk with javac and java >>>>>> --module-path (don't use the jmods at all). >>>>>> >>>>>> Btw, even if you are running a JDK that for some reason doesn't >>>>>> have the Microsoft DLLs, you should still be able to run using the >>>>>> SDK (directly, not via jlink, which requires the jmods) as follows: >>>>>> >>>>>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>>>>> --add-modules >>>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>>>>> MyApplication >>>>>> >>>>>> If this doesn't work without you putting javafx-sdk-14/bin in your >>>>>> PATH then something else is wrong. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>>>>> >>>>>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>>>>> I have downloaded both the "mods" and the SDK. I put them >>>>>>> alongside the JDK on my workstation. >>>>>>> >>>>>>> C:\Program Files\Java\jdk-14.0.1 >>>>>>> C:\Program Files\Java\javafx-sdk-14 >>>>>>> C:\Program Files\Java\javafx-jmods-14.0.1 >>>>>>> >>>>>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>>>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` >>>>>>> path... >>>>>>> >>>>>>> jlink --module-path "C:\Program >>>>>>> Files\Java\javafx-sdk-14\lib;C:\Program >>>>>>> Files\Java\jdk-14.0.1/jmods" --add-modules >>>>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>>>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>>>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>>>>> >>>>>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>>>>> global path, the application builds. When I try to run the >>>>>>> application I see the following error. >>>>>>> >>>>>>> Graphics Device initialization failed for : d3d, sw >>>>>>> Error initializing QuantumRenderer: no suitable pipeline found >>>>>>> >>>>>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>>>>> as I can tell, the exact same effect. :-( >>>>>>> >>>>>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>>>>> global PATH then it does run successfully. >>>>>>> >>>>>>> I hear what you're saying but this doesn't seem to be the case... >>>>>>> >>>>>>> What version of Windows are you using? I don't think this is a >>>>>>> Windows 10 specific issue but perhaps there is something platform >>>>>>> specific involved. >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> >>>>>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>>>>> You suggest there will be a problem if you use jlink, but it will >>>>>>>> work if you include the needed javafx modules. The .jmod files >>>>>>>> contain the necessary native libraries and jlink will build a JRE >>>>>>>> that has the DLLs in the right place for the runtime to find them. >>>>>>>> >>>>>>>> Modifying your PATH is not the right way to do this. Distributing >>>>>>>> a runtime with your application is the right way to solve this. >>>>>>>> The jlink and jpackage tools make this fairly easy. I use a >>>>>>>> custom Gradle script to bundle my application, it works well. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I manage a project[0] that leverages JavaFX. It's been a while >>>>>>>>> since I've worked on this project, almost two years. At that >>>>>>>>> time JavaFX was bundled with the Java runtime from Oracle. The >>>>>>>>> few customers I had would simply run the application from the >>>>>>>>> bundled launcher and as long as they had Java installed, it >>>>>>>>> would work. >>>>>>>>> >>>>>>>>> It's time for me to add some features to the project, I am now >>>>>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>>>>> followed the instructions[1] from the following URL: >>>>>>>>> >>>>>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>>>>> >>>>>>>>> I am on Windows and followed the instructions for that platform. >>>>>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>>>>> >>>>>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>>>>> wn Source) >>>>>>>>> >>>>>>>>> I fussed with this and that but nothing made a difference. >>>>>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>>>>> distribution to my path. This is the entry I added to my global >>>>>>>>> PATH variable: >>>>>>>>> >>>>>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>>>>> >>>>>>>>> Is this the right way to do this and, if so, why isn't this >>>>>>>>> included in the directions? Is this a Windows specific issue? >>>>>>>>> >>>>>>>>> Also, what impact does this have on distribution of applications? >>>>>>>>> >>>>>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>>>>> same issues will be present. Those instructions use `jlink` to >>>>>>>>> point to the JavaFX libraries and the JAVAFX modules >>>>>>>>> (distributed in another package) but also leave off references >>>>>>>>> to the DLL files in the "bin" directory. I am worried that I >>>>>>>>> will need to have people manually install the OpenJavaFX >>>>>>>>> distribution and add the "bin" directory to their path in order >>>>>>>>> to run my application. Please say it's not so! >>>>>>>>> >>>>>>>>> Any help or pointers to additional documentation would be very >>>>>>>>> much appreciated! I have made it over the bumps and can now >>>>>>>>> continue development of my application, my next concern is >>>>>>>>> distributing it to customers. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Miles >>>>>>>>> >>>>>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>>>> >>>>> >>> From mike at plan99.net Mon Apr 20 09:28:14 2020 From: mike at plan99.net (Mike Hearn) Date: Mon, 20 Apr 2020 02:28:14 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: With respect to reflection, it seems like the module system really wants you to use Lookup capabilities rather than "open" modules to reflection. That is, JFX could be changed to use var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("....")); The semantics of a Lookup are that it grants whoever holds the object the same access rights as whoever created it. Thus if an object creates a Lookup and gives it to a framework, that framework can access anything the object could itself access. The lookup object would then be used to do reflection rather than the classical reflection API. With this change the API would guide you to a form that always works, regardless of module configuration. Due to its nature as a GUI toolkit JFX often needs to reflect over user code. It may be worth considering a deeper upgrade in which a Lookup object is provided during application startup, and passed in to the framework e.g. the Application class. Lookup objects can be 'teleported' so JFX components that wish to work with user GUI code generically can then fetch a Lookup from a central place. However, this wouldn't allow overriding of access control (i.e. FXMLLoader that takes such a lookup and teleports it to the right class for access, wouldn't be able to access private fields, because the original place where the lookup was created also couldn't). From nlisker at gmail.com Mon Apr 20 10:46:11 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 20 Apr 2020 13:46:11 +0300 Subject: Gradle task for running tests without Webkit Message-ID: Hi, For those who didn't build Webkit, running tests is done with `-x :web:test`. I think it makes sense to just add a test task that does exactly that, for convenience. What do you think? - Nir From fastegal at openjdk.java.net Mon Apr 20 12:31:18 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 20 Apr 2020 12:31:18 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown Message-ID: The issue is that ChoiceBoxSkin a) doesn't update the text of the label if the value is not contained in the items b) doesn't respect converter for label text Fixed by - listening to value changes to update the label - removing ad-hoc updates (not needed), added update on converter change - passing all label updates through converter Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, so for coveragy, contains also tests that passed before as well as after) ------------- Commit messages: - 8087555: [ChoiceBox] uncontained value not shown Changes: https://git.openjdk.java.net/jfx/pull/191/files Webrev: https://webrevs.openjdk.java.net/jfx/191/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8087555 Stats: 464 lines in 2 files changed: 451 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/191.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/191/head:pull/191 PR: https://git.openjdk.java.net/jfx/pull/191 From kevin.rushforth at oracle.com Mon Apr 20 12:57:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 05:57:51 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> References: <68f12a28-16d1-d5bd-cf58-ecf03f01fcc3@nervestaple.com> <9cfbc187-3aea-bc79-3742-b416ea393216@nervestaple.com> <8d7fe3c4-de2c-5ff9-59c9-588fd8bfc77e@nervestaple.com> Message-ID: <46f0e60c-4629-e81a-ecd8-5b4c32b47703@oracle.com> Can you try running your app with the following two flags? java -Djavafx.verbose=true -Dprism.verbose=true That might help diagnose the problem. -- Kevin On 4/18/2020 11:18 AM, Christopher Miles wrote: > Yep, that's where I downloaded it from. > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > openjdk 14.0.1 2020-04-14 > > OpenJDK Runtime Environment (build 14.0.1+7) > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > When I look at the "bin" directory that came with the JavaFX SDK and > compare it to the "bin" directory that comes with OpenJDK there are > things in the JavaFX distribution that aren't present in the OpenJDK > distribution. These three caught my attention: > > ? + prism_common.dll > ? + prism_d3d.dll > ? + prism_sw.dll > > I suspect missing these DLL's is what is causing the exception when I > try to launch my application. > > I took a look at "JDK-8207015" and I don't think that is my problem, > yet. It could be that if the "prism_xxx.dll" files were present, I > might run into this issue. > > I changed my `jlink` command to point at the "mods" as this seems like > the correct way to do this. Still, the app refuses to launch with the > same error message. > > > Graphics Device initialization failed for :? d3d, sw > > Error initializing QuantumRenderer: no suitable pipeline found > > java.lang.RuntimeException: java.lang.RuntimeException: Error > initializing QuantumRenderer: no suitable pipeline found > > I would very much like to avoid adding switches to a `java` invocation > in order to run the application. In your example, I would need to have > customer installed the JavaFX JDK to a specific location in order for > that to work. I'd also need to have some kind of wrapper to handle > other operating systems, like Linux or OS X. My goal is to distribute > one package with custom launching scripts (i.e. one for batch, > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > think that using `jlink` with the mods is the way to go, as long as I > can figure out why that is not working. > > Thank you for your help with this. :-) > > Kevin Rushforth wrote on 4/17/2020 17:34: >> ?From where are you getting your OpenJDK build? >> https://jdk.java.net/14 ? Somewhere else? >> >> -- Kevin >> >> >> On 4/17/2020 2:16 PM, Christopher Miles wrote: >>> Yeah, I've tried it with both. The instructions on the JavaFX page >>> tell you to add the "lib" directory to the `javac` path and the >>> "mods" to the `jlink` path. I figured, since nothing is working, why >>> not try them the other way around? In all cases the results are the >>> same. >>> >>> I'm using OpenJDK, wouldn't that project have the same issue >>> distributing these DLL files? I would bet they would, since they are >>> also an open source project. I can run Swing projects, however, >>> without these DLL files. >>> >>> I can give the Oracle JDK a try. I had been shying away from it >>> since OpenJDK is getting to be so popular. If that works, I will let >>> the list know. >>> >>> As an aside, the JavaFX home page recommends using OpenJDK right now: >>> >>> ? https://openjfx.io/openjfx-docs/#install-java >>> >>> Thank you! >>> >>> Kevin Rushforth wrote on 4/17/2020 16:51: >>>> Where are you getting JDK 14.0.1 from? Does it include the >>>> Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There >>>> are 45 of them (40 of them are of the form api-ms-win-*.dll). The >>>> JavaFX 14.0.1 sdk includes them, but the jmods do not. See >>>> JDK-8207015 [1] for why not. If the JDK has them, then there should >>>> be no problem running a jlinked app. >>>> >>>> One possible problem is that your jlink line is wrong. You should >>>> not point to the SDK at all when running jlink. Use the jmods with >>>> jlink (don't use the sdk). Use the sdk with javac and java >>>> --module-path (don't use the jmods at all). >>>> >>>> Btw, even if you are running a JDK that for some reason doesn't >>>> have the Microsoft DLLs, you should still be able to run using the >>>> SDK (directly, not via jlink, which requires the jmods) as follows: >>>> >>>> java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" >>>> --add-modules >>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web >>>> MyApplication >>>> >>>> If this doesn't work without you putting javafx-sdk-14/bin in your >>>> PATH then something else is wrong. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207015 >>>> >>>> On 4/17/2020 1:18 PM, Christopher Miles wrote: >>>>> I have downloaded both the "mods" and the SDK. I put them >>>>> alongside the JDK on my workstation. >>>>> >>>>> ? C:\Program Files\Java\jdk-14.0.1 >>>>> ? C:\Program Files\Java\javafx-sdk-14 >>>>> ? C:\Program Files\Java\javafx-jmods-14.0.1 >>>>> >>>>> If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and >>>>> point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` >>>>> path... >>>>> >>>>> jlink --module-path "C:\Program >>>>> Files\Java\javafx-sdk-14\lib;C:\Program >>>>> Files\Java\jdk-14.0.1/jmods" --add-modules >>>>> javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base >>>>> --output C:\Users\cmiles\source\repos\xmltool\target/jlink >>>>> --strip-debug --no-man-pages --no-header-files --compress=2 >>>>> >>>>> ...and remove `C:\Program Files\Java\javafx-sdk-14\bin` from my >>>>> global path, the application builds. When I try to run the >>>>> application I see the following error. >>>>> >>>>> ? Graphics Device initialization failed for :? d3d, sw >>>>> ? Error initializing QuantumRenderer: no suitable pipeline found >>>>> >>>>> Swapping out the mods path for the SDK "lib" directory has, as far >>>>> as I can tell, the exact same effect. :-( >>>>> >>>>> If I add the path `C:\Program Files\Java\javafx-sdk-14\bin` to my >>>>> global PATH then it does run successfully. >>>>> >>>>> I hear what you're saying but this doesn't seem to be the case... >>>>> >>>>> What version of Windows are you using? I don't think this is a >>>>> Windows 10 specific issue but perhaps there is something platform >>>>> specific involved. >>>>> >>>>> Thank you! >>>>> >>>>> >>>>> Scott Palmer wrote on 4/17/2020 15:23: >>>>>> I use jlink and jpackage to distribute JavaFX applications. >>>>>> You suggest there will be a problem if you use jlink, but it will >>>>>> work if you include the needed javafx modules. The .jmod files >>>>>> contain the necessary native libraries and jlink will build a JRE >>>>>> that has the DLLs in the right place for the runtime to find them. >>>>>> >>>>>> Modifying your PATH is not the right way to do this. Distributing >>>>>> a runtime with your application is the right way to solve this. >>>>>> The jlink and jpackage tools make this fairly easy. I use a >>>>>> custom Gradle script to bundle my application, it works well. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Apr 17, 2020, at 2:55 PM, Christopher Miles >>>>>>> wrote: >>>>>>> >>>>>>> I manage a project[0]? that leverages JavaFX. It's been a while >>>>>>> since I've worked on this project, almost two years. At that >>>>>>> time JavaFX was bundled with the Java runtime from Oracle. The >>>>>>> few customers I had would simply run the application from the >>>>>>> bundled launcher and as long as they had Java installed, it >>>>>>> would work. >>>>>>> >>>>>>> It's time for me to add some features to the project, I am now >>>>>>> using OpenJDK 14.0.1 and I installed the OpenJavaFX package and >>>>>>> followed the instructions[1] from the following URL: >>>>>>> >>>>>>> https://openjfx.io/openjfx-docs/#install-javafx >>>>>>> >>>>>>> I am on Windows and followed the instructions for that platform. >>>>>>> Unfortunately, things didn't really work. The error was as follows: >>>>>>> >>>>>>> Graphics Device initialization failed for : d3d, sw Error >>>>>>> initializing QuantumRenderer: no suitable pipeline found >>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: Error >>>>>>> initializing QuantumRend erer: no suitable pipeline found at >>>>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >>>>>>> wn Source) >>>>>>> >>>>>>> I fussed with this and that but nothing made a difference. >>>>>>> Eventually I tried adding the "bin" directory from the JavaFX >>>>>>> distribution to my path. This is the entry I added to my global >>>>>>> PATH variable: >>>>>>> >>>>>>> C:\Program Files\Java\javafx-sdk-14\bin >>>>>>> >>>>>>> Is this the right way to do this and, if so, why isn't this >>>>>>> included in the directions? Is this a Windows specific issue? >>>>>>> >>>>>>> Also, what impact does this have on distribution of applications? >>>>>>> >>>>>>> Looking at the "Runtime Images" instructions, it looks like the >>>>>>> same issues will be present. Those instructions use `jlink` to >>>>>>> point to the JavaFX libraries and the JAVAFX modules >>>>>>> (distributed in another package) but also leave off references >>>>>>> to the DLL files in the "bin" directory. I am worried that I >>>>>>> will need to have people manually install the OpenJavaFX >>>>>>> distribution and add the "bin" directory to their path in order >>>>>>> to run my application. Please say it's not so! >>>>>>> >>>>>>> Any help or pointers to additional documentation would be very >>>>>>> much appreciated! I have made it over the bumps and can now >>>>>>> continue development of my application, my next concern is >>>>>>> distributing it to customers. >>>>>>> >>>>>>> -- >>>>>>> Miles >>>>>>> >>>>>>> [0]: https://github.com/cmiles74/xmltool >>>>>>> [1]: https://openjfx.io/openjfx-docs/#install-javafx >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Rony.Flatscher at wu.ac.at Mon Apr 20 12:58:35 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 20 Apr 2020 14:58:35 +0200 Subject: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> Message-ID: <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at> There is a new WIP at : This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be done without compilation. Because of the fallback scripts get compiled with this version by default. It extends PR 187 #187. To further ease spotting scripts that cause a ScriptException a message in the form of "filename: caused ScriptException" gets added to the exception handling in either of the three locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three different kinds of reporting ScriptExceptions may be questioned, however none of these tear down the FXML GUI). This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged whenever a script cannot be compiled and the fallback gets used. It is suggested to use this WIP as it includes the compilation by default with a safe fallback to evaluate the uncompiled script, if compilation (unexpectedly) fails. Again, any feedback, discussion welcome! ---rony P.S.: In the log history there is a commit message "Make message more pregnant.", it should have read "Make messages more terse." instead|.|| | On 17.04.2020 19:37, Rony G. Flatscher wrote: > There is a new WIP at which adds a compile PI (process > instruction) for turning on and off script compilation if the script engine implements the > Compilable interface. > > By default compilation is off (no compilation), such that one needs to add a compile PI > ("") at the top to activate this feature. Supplying "true" (default) or "false" as the PI > data turns this feature on and off. > > The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off", > alternating using "compile on and off", and alternating using "compile off and on". This will test > all variants of applying the compile PI for all categories of scripts. > > Any feedback appreciated! > > ---rony > > P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get > ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes. > > P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a > fallback solution in case a compilation is (unexpectedly) not successful, reverting to > (interpretative) evaluation/execution of the script. In that version it is planned to have > compilation on by default as in the case of a compilation failure there will be a safe backup solution. > > > On 14.04.2020 19:52, Kevin Rushforth wrote: >> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to >> create the CSR until the review is far enough along to know which direction we intend to go. >> >> Unless there is a real concern about possible regressions if scripts are compiled by default, I >> think "enabled by default" is the way to go. Your argument that such script engines are broken >> seems reasonable, since this only applies to script engines that implement javax.script.Compilable >> in the first place. We still might want to add way to turn compilation off for individual scripts. >> One other thing to consider is that if compilation fails, it might make sense to log a warning and >> fall back to the existing interpreted mode. >> >> Does anyone else have any concerns with this? >> >> -- Kevin >> >> >> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: >>> Hi there, >>> >>> as there was probably enough time that has passed by I would intend to create a CSR in the next days >>> with the PR as per Kevin's suggestion. >>> >>> (For the case that this feature should not be active by default, the CSR will suggest to define a >>> new "compile" PI in the form (default, if no PI data given: true), which >>> is independent of the existence of a language PI (this way it becomes also possible to allow >>> compilation of external scripts denoted with the script-element, which do not need a page language >>> to be set as the file's extension allows the appropriate script engine to be loaded and used for >>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI >>> or ? to FXML files (and to turn off), which seems to >>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation >>> of scripts on and off throughout an FXML file.) >>> >>> ---rony >>> >>> >>> On 04.04.2020 18:03, Rony G. Flatscher wrote: >>> >>>> Hi Kevin, >>>> >>>> On 03.04.2020 01:21, Kevin Rushforth wrote: >>>>> I see that you updated the PR and sent it for review. >>>>> >>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>>>> feature, and if so, what form this feature should take. >>>>> >>>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>>>> from it? >>>> Script code should be executed faster after compilation, so any FXML page that hosts script code >>>> may >>>> benefit. >>>> >>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >>>> significantly. This is because repeated invocation of compiled script event handlers do not cause >>>> the reparsing of that script's source and interpreting it on each invocation, which may be >>>> expensive >>>> depending on the script engine, but rather allows the immediate evaluation/execution of the >>>> compiled >>>> script by the script engine. >>>> >>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >>>> In principle there are three possibilities: >>>> >>>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the >>>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and >>>> ???? execute the compiled script each time its registered event fires. >>>> >>>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts >>>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >>>> ???????? compiling but have been employed successfully in interpreted mode >>>> >>>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >>>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script >>>> ???? engine implements the javax.script.Compilable interface. If missing it would default to >>>> "false". >>>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >>>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the >>>> ???? "language" PI was not.) >>>> >>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the >>>> language >>>> ???????? PI gets changed >>>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts >>>> >>>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script >>>> and >>>> ???? node elements and only compile the scripts, if the property is set to true >>>> >>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >>>> ???????? accordingly >>>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that >>>> host scripts >>>> >>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >>>> overruled individually by 3. >>>> >>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that >>>> compilation >>>> of scripts by the script engines would find the same errors as while interpreting the very same >>>> scripts (if not, the script engine is badly broken and it could be argued that then the >>>> interpretation part of the script engine might be expected to be broken as well which would be >>>> quite >>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the >>>> compiled script would behave differently to interpreting the very same script by the same script >>>> engine). >>>> >>>> The current WIP implements 1 above and includes an appropriate test unit. >>>> >>>>> What do others think? >>>>> In either case, we would need to make sure that this doesn't present any security concerns in the >>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>>>> but we would need to ensure that. >>>> The compilation of scripts needs to be done by the Java script engines (implementing both, >>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >>>> scripts ([javax.script.CompiledScript] >>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >>>> >>>> >>>> ---rony >>>> >>>> >>>> >>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>>>> After merging master, applying some fixes and changing the title to reflect the change from >>>>>> WIP to a >>>>>> pull request I would kindly request a review of this pull request! >>>>>> >>>>>> Here the URL: , title changed to: "8238080: >>>>>> FXMLLoader: if >>>>>> script engines implement javax.script.Compilable compile scripts". >>>>>> >>>>>> ---rony >>>>>> >>>>>> >>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in >>>>>>> review, and >>>>>>> has an appropriate test unit going with it as well, please review. >>>>>>> >>>>>>> There should be no compatibility issue with this implementation. >>>>>>> >>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML >>>>>>> files. >>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts >>>>>>> if the >>>>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>>>> value >>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML >>>>>>> with >>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up >>>>>>> with a >>>>>>> respective solution as well. >>>>>>> >>>>>>> ---rony >>>>>>> >>>>>>> [1] "Implementation and test unit": >>>>>>> >>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>>>> scripts": >>>>>>> >>>>>>> >>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>>>> >>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to >>>>>>>> illustrate >>>>>>>> the concept). >>>>>>>> >>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>>>> Just filed a RFE with the following information: >>>>>>>>> >>>>>>>>> ???? * Component: >>>>>>>>> ???????? o JavaFX >>>>>>>>> >>>>>>>>> ???? * Subcomponent: >>>>>>>>> ???????? o fxml: JavaFX FXML >>>>>>>>> >>>>>>>>> ???? * Synopsis: >>>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>>>> >>>>>>>>> ???? * Descriptions: >>>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>>>> (javax.script.ScriptEngine >>>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller >>>>>>>>> language in >>>>>>>>> ?????????? the FXML file. >>>>>>>>> >>>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such >>>>>>>>> scripts >>>>>>>>> could >>>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>>>> using >>>>>>>>> ?????????? its eval() methods. >>>>>>>>> >>>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>>>> invocations, >>>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>>>> onMouseMove) >>>>>>>>> ?????????? which may be repetitevly invoked and evaluated." >>>>>>>>> >>>>>>>>> ???? * System /OS/Java Runtime Information: >>>>>>>>> ???????? o "All systems." >>>>>>>>> >>>>>>>>> Received the internal review ID: "9063426" >>>>>>>>> >>>>>>>>> ---rony From mp at jugs.org Mon Apr 20 13:06:16 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 15:06:16 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: This is deviating quite a bit from the original issue of this thread, isn't it? As a side note: MethodHandles are not supported by GraalVM native image and so this would probably collide with the attempts to get JavaFX running on Android/iOS. Am 20.04.20 um 11:28 schrieb Mike Hearn: > With respect to reflection, it seems like the module system really wants > you to use Lookup capabilities rather than "open" modules to reflection. > That is, JFX could be changed to use > > var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("....")); > > The semantics of a Lookup are that it grants whoever holds the object the > same access rights as whoever created it. Thus if an object creates a > Lookup and gives it to a framework, that framework can access anything the > object could itself access. > > The lookup object would then be used to do reflection rather than the > classical reflection API. With this change the API would guide you to a > form that always works, regardless of module configuration. > > Due to its nature as a GUI toolkit JFX often needs to reflect over user > code. It may be worth considering a deeper upgrade in which a Lookup object > is provided during application startup, and passed in to the framework e.g. > the Application class. Lookup objects can be 'teleported' so JFX components > that wish to work with user GUI code generically can then fetch a Lookup > from a central place. However, this wouldn't allow overriding of access > control (i.e. FXMLLoader that takes such a lookup and teleports it to the > right class for access, wouldn't be able to access private fields, because > the original place where the lookup was created also couldn't). From Rony.Flatscher at wu.ac.at Mon Apr 20 13:26:19 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 20 Apr 2020 15:26:19 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> On 20.04.2020 15:06, Michael Paus wrote: > This is deviating quite a bit from the original issue of this thread, isn't it? > > As a side note: MethodHandles are not supported by GraalVM native image > and so this would probably collide with the attempts to get JavaFX running > on Android/iOS. Would you have some link where there would be a technical overview about how Java and JavaFX support gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on that platform, ie. is java.lang.reflect available? ---rony From johan.vos at gluonhq.com Mon Apr 20 13:54:34 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 20 Apr 2020 15:54:34 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: Hi, The JavaFX implementation used in Android and iOS is using 100% the same code as the one on desktop. JavaFX internally uses reflection, and that is supported indeed (can be used in app-specific code as well). The best place to get started is at https://github.com/gluonhq/client-samples - Johan On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher wrote: > On 20.04.2020 15:06, Michael Paus wrote: > > This is deviating quite a bit from the original issue of this thread, > isn't it? > > > > As a side note: MethodHandles are not supported by GraalVM native image > > and so this would probably collide with the attempts to get JavaFX > running > > on Android/iOS. > Would you have some link where there would be a technical overview about > how Java and JavaFX support > gets currently realized under Android/iOS? Also, how is reflection > supposed to be carried out on > that platform, ie. is java.lang.reflect available? > > ---rony > > > From Rony.Flatscher at wu.ac.at Mon Apr 20 13:59:23 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 20 Apr 2020 15:59:23 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: Hi Johan, On 20.04.2020 15:54, Johan Vos wrote: > The JavaFX implementation used in Android and iOS is using 100% the same code as the one on desktop. > JavaFX internally uses reflection, and that is supported indeed (can be used in app-specific code > as well). > The best place to get started is at?https://github.com/gluonhq/client-samples thank you very much for both, the link and assuring that reflection is still available to apps as well! ---rony > > On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher > wrote: > > On 20.04.2020 15:06, Michael Paus wrote: > > This is deviating quite a bit from the original issue of this thread, isn't it? > > > > As a side note: MethodHandles are not supported by GraalVM native image > > and so this would probably collide with the attempts to get JavaFX running > > on Android/iOS. > Would you have some link where there would be a technical overview about how Java and JavaFX > support > gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on > that platform, ie. is java.lang.reflect available? > > ---rony > From mike at plan99.net Mon Apr 20 14:44:23 2020 From: mike at plan99.net (Mike Hearn) Date: Mon, 20 Apr 2020 07:44:23 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: Possibly - I posted this because, being ultimately still a product of the Java group at Oracle, I'm sceptical JavaFX will become *less* dependent on the module system when the trend has been to use it more. So there are at least two usability problems: 1 - needing additional downloads and new JVM flags to use JavaFX as modules rather than ordinary JARs 2 - needing to open packages to JavaFX so it can reflect over them (not a problem if your app runs on the classpath, but can hit you the moment you use a component that's been modularised) The first one has a few workarounds/solutions but what I do is go with the flow and prepare my own JDK using jlink, which has JavaFX baked in like it did before. I use a variant on this script: https://gist.github.com/mikehearn/b18842d45181ac150ec9e6d0b2bb1e24 The output is a JDK directory I can point my IDE at. It's seen as a normal JDK, but like in Java 8 JavaFX is now fully baked in and available by default. Because it's already on the module path no special JVM flags are required. Probably someone (me?) should upload JDKs for each platform that are "fully baked" like this. That leaves the second problem, for which there's no good solution with the current JFX API. Dependency injectors fundamentally don't mix well with JPMS. Using Lookup objects is a backwards compatible addition that would remove part of the pain of using modules with JavaFX because you'd no longer need to remember to add special incantations to a module-info.java to enable reflection - incantations which might change between JFX versions as reflection uses are added or changed. On Mon, Apr 20, 2020 at 15:06:16, Michael Paus wrote: > This is deviating quite a bit from the original issue of this thread, > isn't it? > > As a side note: MethodHandles are not supported by GraalVM native image > and so this would probably collide with the attempts to get JavaFX running > on Android/iOS. > > Am 20.04.20 um 11:28 schrieb Mike Hearn: > > With respect to reflection, it seems like the module system really wants > you to use Lookup capabilities rather than "open" modules to reflection. > That is, JFX could be changed to use > > var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("....")); > > The semantics of a Lookup are that it grants whoever holds the object the > same access rights as whoever created it. Thus if an object creates a > Lookup and gives it to a framework, that framework can access anything the > object could itself access. > > The lookup object would then be used to do reflection rather than the > classical reflection API. With this change the API would guide you to a > form that always works, regardless of module configuration. > > Due to its nature as a GUI toolkit JFX often needs to reflect over user > code. It may be worth considering a deeper upgrade in which a Lookup object > is provided during application startup, and passed in to the framework e.g. > the Application class. Lookup objects can be 'teleported' so JFX components > that wish to work with user GUI code generically can then fetch a Lookup > from a central place. However, this wouldn't allow overriding of access > control (i.e. FXMLLoader that takes such a lookup and teleports it to the > right class for access, wouldn't be able to access private fields, because > the original place where the lookup was created also couldn't). > > From David.Grieve at microsoft.com Mon Apr 20 15:13:27 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 20 Apr 2020 15:13:27 +0000 Subject: Windows Installation Instructions, All DLL Files Missing Message-ID: Set -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin For the jlink question, look at jmod. You'll use jmod to bundle up the dll's and whatever else you need, then jlink to create the custom runtime. -----Original Message----- From: openjfx-dev On Behalf Of Christopher Miles Sent: Friday, April 17, 2020 2:56 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing I manage a project[0]? that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: https://openjfx.io/openjfx-docs/#install-javafx I am on Windows and followed the instructions for that platform. Unfortunately, things didn't really work. The error was as follows: Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno wn Source) I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: C:\Program Files\Java\javafx-sdk-14\bin Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? Also, what impact does this have on distribution of applications? Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. -- Miles [0]: https://github.com/cmiles74/xmltool [1]: https://openjfx.io/openjfx-docs/#install-javafx From kevin.rushforth at oracle.com Mon Apr 20 15:19:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 08:19:49 -0700 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: References: Message-ID: <035b1f84-9f13-38b1-bca4-c1e09f95bf4a@oracle.com> That shouldn't be necessary. It's a better workaround than setting the PATH env variable to be sure, but there is some underlying problem that isn't yet understood. -- Kevin On 4/20/2020 8:13 AM, David Grieve wrote: > Set -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin > > For the jlink question, look at jmod. You'll use jmod to bundle up the dll's and whatever else you need, then jlink to create the custom runtime. > > -----Original Message----- > From: openjfx-dev On Behalf Of Christopher Miles > Sent: Friday, April 17, 2020 2:56 PM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing > > I manage a project[0]? that leverages JavaFX. It's been a while since I've worked on this project, almost two years. At that time JavaFX was bundled with the Java runtime from Oracle. The few customers I had would simply run the application from the bundled launcher and as long as they had Java installed, it would work. > > It's time for me to add some features to the project, I am now using OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] from the following URL: > > https://openjfx.io/openjfx-docs/#install-javafx > > I am on Windows and followed the instructions for that platform. > Unfortunately, things didn't really work. The error was as follows: > > Graphics Device initialization failed for : d3d, sw Error initializing > QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: > java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable pipeline found at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno > wn Source) > > I fussed with this and that but nothing made a difference. Eventually I tried adding the "bin" directory from the JavaFX distribution to my path. This is the entry I added to my global PATH variable: > > C:\Program Files\Java\javafx-sdk-14\bin > > Is this the right way to do this and, if so, why isn't this included in the directions? Is this a Windows specific issue? > > Also, what impact does this have on distribution of applications? > > Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another package) but also leave off references to the DLL files in the "bin" directory. I am worried that I will need to have people manually install the OpenJavaFX distribution and add the "bin" directory to their path in order to run my application. Please say it's not so! > > Any help or pointers to additional documentation would be very much appreciated! I have made it over the bumps and can now continue development of my application, my next concern is distributing it to customers. > > -- > Miles > > [0]: https://github.com/cmiles74/xmltool > [1]: https://openjfx.io/openjfx-docs/#install-javafx From youngty1997 at gmail.com Mon Apr 20 15:25:58 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Apr 2020 10:25:58 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Message-ID: On 4/18/20 7:40 AM, Michael Paus wrote: > Hi, > I would just like to add that many of the problems you have cited > would just vanish if the JPMS > enforcement would be removed from the JDK. There would be no "JavaFX > requiring absurd > runtime module VM arguments" anymore and the IDE integration would > just be straight forward. > JavaFX would become just one more dependency whithout the need for any > special treatment. The custom Maven runtime arguments shouldn't exist, period. They didn't exist before 14 and there was zero discussion here as to why they are suddenly required on this mailing list. It just kinda came out of no where. Also, correction, the wiki is wrong: that JVM argument is ONLY for Maven projects, not Ant. I still stand that the fault isn't JPMS but rather people not willing to add documentation or support for it. When JavaFX fails to reflect on a class file or a CSS file it could suggest that it needs to be "open"ed. > > I did, however, not say that JavaFX should be de-modularized. For an > expert user who wants > to use the JPMS nothing would change at all. I'm a bit confused here. if you don't want JPMS then you should be able to run everything on the classpath like normal. Netbeans at least doesn't force modules wtih Maven. Or is reflection disabled on classpath as of Java 9 too unless you have a module-info? > > Michael > > Am 18.04.20 um 12:58 schrieb Ty Young: >> >> On 4/18/20 5:01 AM, Michael Paus wrote: >>> Getting started with JavaFX is made overly complicated by the fact >>> that the use of the >>> module system is enforced by some code in the JDK. Especially for >>> beginners, who just >>> want to get some small program running, this is almost always a big >>> source of frustration. >>> It is not very good marketing for JavaFX to make these initial steps >>> such a pain. If you >>> need some evidence for this statement, then just follow JavaFX on >>> Stackoverflow or similar >>> sites (and also this mailing list). Almost every day you can read >>> frustrated posts from >>> helpless people who would just like to get some JavaFX project >>> running but are failing >>> because they get lost in the module system jungle. >> >> >> Speaking as a long time JavaFX user(literally since Java 8), I have >> mostly disagree that the JPMS is hurting JavaFX. >> >> >> That said, I don't think the frustration is misplaced. What you say >> is true(Netbeans mailing list is fill of JavaFX issues) and the end >> user is *NOT* to be blamed here. >> >> >> Rather, I think what's to blame is poor documentation, JavaFX >> requiring absurd runtime module VM arguments, and? poor/buggy IDE >> support. >> >> >> Starting with documentation, JavaFX uses reflection for things like >> TableView(everyone's favorite) and CSS style sheets. While this may >> be obvious for people who are more experienced, those who are not may >> be very confused when they get an onslaught of error messages >> regarding reflection. Better documentation on what requires >> reflection, why, and how to enable it would be useful. >> >> >> Likewise, the notice about having to include javafx.graphics to the >> runtime module arguments here: >> >> >> https://openjfx.io/openjfx-docs/#IDE-NetBeans >> >> >> Apply to Maven as well, but it's under Ant for some reason. I don't >> know what was changed in JavaFX 14 that now suddenly requires a >> runtime VM argument, but it's a PITA and BS. End users are going to >> struggle with this, and it prevents JavaFX runtime from being purely >> managed by Maven. No other JavaFX version requires this, so it's mind >> boggling that all of a sudden JavaFX needs this. >> >> >> Poor/buggy IDE support is really the big one here. I don't know about >> other IDEs but Netbeans DOES NOT provide a project template for >> creating a JavaFX application with setup dependencies. Netbeans, when >> setup with a Maven project, allows you to select an entire >> project(pom) rather than the individual dependencies(jar) which >> doesn't work. What you search for also matters: if you search for >> "JavaFX" you will get the wrong search results. You need to search >> for "openjfx" which can be confusing. >> >> >> Anyway, yeah, it's a PITA. There is also an issue with Ant based >> projects and Netbeans because JavaFX puts its src.zip in a folder >> that is supposed to only include the runtime library that has existed >> for years(literally a 1 line fix too). No one really uses Ant anymore >> so it's probably not a big deal now but yeah, getting JavaFX working >> hasn't been "include and done" when it could potentially be that way. >> > From github.com+1413266+jgneff at openjdk.java.net Mon Apr 20 15:31:44 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 20 Apr 2020 15:31:44 GMT Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: <-X6nzL9xZpk0TLADoHQMD0cf904u6OPqmGZUdyiZszA=.b4271006-a560-44fa-89e4-9f4a9880ca7f@github.com> Message-ID: On Fri, 17 Apr 2020 15:14:19 GMT, Kevin Rushforth wrote: > I just checked and there is nothing wrong with your merge. But somehow it managed to confuse GitHub. Thanks, Kevin. A simple `git rebase master` and `git push --force` did the trick! I hope it's okay for me to add some advocacy to the conversation here. My initial comment makes it easy to miss the general context of this update. This pull request completes the project of adding support for e-paper displays that we started back in JavaFX 13. I would love to see these last few changes merged in time for JavaFX 15. Below are five reasons to merge this pull request into the next release: 1. It's small. It's only 50 lines of code ? the last 3 percent of the entire project. 2. It's done. It completes the work already included in JavaFX 13, which was 1,812 lines of code and 97 percent of the project. 3. It's safe. The code runs only when the system properties include `glass.platform=Monocle` and `monocle.platform=EPD`, and even then, only when the system has an e-paper display with the EPD Controller frame buffer driver. There are no changes to any JavaFX code outside of the Monocle EPD platform. 4. It's tested. I tested the code in November with JDK 13 and JavaFX 14. I tested the code again this week with JDK 14 and JavaFX 15. I ran tests with Ubuntu OpenJDK 11 and 13 as well as AdoptOpenJDK 11 and 14. I tested older devices under Ubuntu 14.04 and newer devices under Ubuntu 20.04 Beta. All tests passed. 5. It's unique. This pull request makes JavaFX the only cross-platform application framework with built-in support for e-paper displays. It demonstrates that the Java slogan "write once, run anywhere" is as true today as it was in 1995, not just for different operating systems and processor architectures, but even for radically different display technologies like electronic ink. To my potential reviewers, @johanvos and @kevinrushforth, is there anything I can do to make your code review easier? ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From hjohn at xs4all.nl Mon Apr 20 15:34:25 2020 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 20 Apr 2020 17:34:25 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: > With a not very intuitive hack you can circumvent this problem already now. > Just add a line like this to the file which contains your main class > extending > Application (MyApp). > > class MyAppLauncher {public static void main(String[] args) > {MyApp.main(args);}} I do exactly the same, I construct a fat jar with all of JavaFX included and run it as above. I was looking forward to the module system allowing a clean and easy way to have a visibility scope inbetween public and package (by making packages hierarchical for example), but it turned into a monster that just seems to make projects fragile and hard to build/run. I suppose it may be possible to just generate and publish JavaFX jars without all the module-info files included, but I'm not sure it is as simple as that. --John From yousef.alhashemi at gmail.com Mon Apr 20 16:12:36 2020 From: yousef.alhashemi at gmail.com (Yousef Alhashemi) Date: Mon, 20 Apr 2020 19:12:36 +0300 Subject: Porting OpenJFX to BSD Message-ID: Hello, How difficult would it be to port/compile the latest version of openjfx (14?) on BSD? On FreeBSD, only version 8 is available as a port/package and it's deprecated and will be removed later this year. I haven't done any large scale porting of code, but I do understand the basic concepts (using typedefs, not using compiler-specific optimizations so say gcc code can also be compiled on clang, etc). If porting to BSD is well-documented somewhere and is fairly systematic, I'd be happy to give it a shot. Any pointers are appreciated. Thanks, Yousef From org.openjdk at io7m.com Mon Apr 20 15:47:50 2020 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 20 Apr 2020 15:47:50 +0000 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> Message-ID: <20200420154750.7a38ec8b@sunflower.int.arc7.info> Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the module path), using plain Maven builds with no special arguments, and IDEA as the IDE. This is on JDK 13, with the 13.0.2 JavaFX release from Central. -- Mark Raynsford | https://www.io7m.com From youngty1997 at gmail.com Mon Apr 20 16:37:16 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Apr 2020 11:37:16 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> Message-ID: On 4/20/20 11:36 AM, Ty Young wrote: > > On 4/20/20 10:47 AM, Mark Raynsford wrote: >> Am I missing something here? What absurd arguments are required for >> Maven projects? >> >> I have multiple applications here running in full module-path mode (the >> applications are modularized, and JavaFX is on the module path), using >> plain Maven builds with no special arguments, and IDEA as the IDE. >> This is on JDK 13, with the 13.0.2 JavaFX release from Central. >> > > From the second warning on this page: > > > https://openjfx.io/openjfx-docs/ > > > That's the absurd part. JavaFX 14 now requires this as a JVM runtime > argument: > > > --module-path /path/to/javafx-sdk-12/lib --add-modules > javafx.controls,javafx.fxml > > > Which wasn't required before. Not only is this a PITA and confusing > but it also prevents Maven from just handling everything. Netbeans > uses a custom file for runtime arguments, which the above is added to. > Also, it gives JavaFX 12 as an example, which is wrong. It should be 14. From youngty1997 at gmail.com Mon Apr 20 16:36:05 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Apr 2020 11:36:05 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <20200420154750.7a38ec8b@sunflower.int.arc7.info> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> Message-ID: <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> On 4/20/20 10:47 AM, Mark Raynsford wrote: > Am I missing something here? What absurd arguments are required for > Maven projects? > > I have multiple applications here running in full module-path mode (the > applications are modularized, and JavaFX is on the module path), using > plain Maven builds with no special arguments, and IDEA as the IDE. > This is on JDK 13, with the 13.0.2 JavaFX release from Central. > From the second warning on this page: https://openjfx.io/openjfx-docs/ That's the absurd part. JavaFX 14 now requires this as a JVM runtime argument: --module-path /path/to/javafx-sdk-12/lib --add-modules javafx.controls,javafx.fxml Which wasn't required before. Not only is this a PITA and confusing but it also prevents Maven from just handling everything. Netbeans uses a custom file for runtime arguments, which the above is added to. From twitch at nervestaple.com Mon Apr 20 17:26:54 2020 From: twitch at nervestaple.com (Christopher Miles) Date: Mon, 20 Apr 2020 13:26:54 -0400 Subject: Windows Installation Instructions, All DLL Files Missing In-Reply-To: <035b1f84-9f13-38b1-bca4-c1e09f95bf4a@oracle.com> References: <035b1f84-9f13-38b1-bca4-c1e09f95bf4a@oracle.com> Message-ID: <325af10f-295c-58ef-bd96-28acf7a05516@nervestaple.com> I really appreciate all of the helpful comments in this thread! I have made a lot of progress on this issue, I can compile and run my application and am working on packaging. In my opinion, my big problem was that when I was compiling I wasn't setting the correct flags with `javac` and, at the same time, probably didn't have the correct flags for `java` either. To be honest I was mostly button mashing at that point in the hopes that I'd stumble across the correct combination. To get everything working I have moved to using the "mods" with `javac` and to compile and then using `jlink` build an image. After `jlink` runs I am using the `java` that is in the image directory to run the compiled "JAR" file and that is working well. I think one big hurdle here was my lack of familiarity with Java modules and how they work. While I knew that Java modules had been a thing for a while I've been working on non-Java projects and it was not at the front of my mind. While the examples on the JavaFX "Getting Started" page worked for me, I don't think I came away with a clear understanding of what the flags where actually doing and that made it a little harder to migrate that information over to my own project. My thinking is that using the "mods" will make it easier to eventually get my application packaged but I'm not entirely clear on the bit about the JavaFX runtime and if I need it at all. I don't think a discussion of the Java modules system would be appropriate on the "Getting Started" page, but maybe getting a little more into the details of which approach makes the most sense (mods vs. the SDK) in which situations would clarify some things. Thank you all for your help on this! :-) -- Miles Kevin Rushforth wrote on 4/20/2020 11:19: > That shouldn't be necessary. It's a better workaround than setting the > PATH env variable to be sure, but there is some underlying problem that > isn't yet understood. > > -- Kevin > > On 4/20/2020 8:13 AM, David Grieve wrote: >> Set? -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin >> >> For the jlink question, look at jmod. You'll use jmod to bundle up the >> dll's and whatever else you need, then jlink to create the custom >> runtime. >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Christopher Miles >> Sent: Friday, April 17, 2020 2:56 PM >> To: openjfx-dev at openjdk.java.net >> Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files >> Missing >> >> I manage a project[0]? that leverages JavaFX. It's been a while since >> I've worked on this project, almost two years. At that time JavaFX was >> bundled with the Java runtime from Oracle. The few customers I had >> would simply run the application from the bundled launcher and as long >> as they had Java installed, it would work. >> >> It's time for me to add some features to the project, I am now using >> OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the >> instructions[1] from the following URL: >> >> https://openjfx.io/openjfx-docs/#install-javafx >> >> I am on Windows and followed the instructions for that platform. >> Unfortunately, things didn't really work. The error was as follows: >> >> Graphics Device initialization failed for : d3d, sw Error initializing >> QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: >> java.lang.RuntimeException: Error initializing QuantumRend erer: no >> suitable pipeline found at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno >> >> wn Source) >> >> I fussed with this and that but nothing made a difference. Eventually >> I tried adding the "bin" directory from the JavaFX distribution to my >> path. This is the entry I added to my global PATH variable: >> >> C:\Program Files\Java\javafx-sdk-14\bin >> >> Is this the right way to do this and, if so, why isn't this included >> in the directions? Is this a Windows specific issue? >> >> Also, what impact does this have on distribution of applications? >> >> Looking at the "Runtime Images" instructions, it looks like the same >> issues will be present. Those instructions use `jlink` to point to the >> JavaFX libraries and the JAVAFX modules (distributed in another >> package) but also leave off references to the DLL files in the "bin" >> directory. I am worried that I will need to have people manually >> install the OpenJavaFX distribution and add the "bin" directory to >> their path in order to run my application. Please say it's not so! >> >> Any help or pointers to additional documentation would be very much >> appreciated! I have made it over the bumps and can now continue >> development of my application, my next concern is distributing it to >> customers. >> >> -- >> Miles >> >> [0]: https://github.com/cmiles74/xmltool >> [1]: https://openjfx.io/openjfx-docs/#install-javafx > From mp at jugs.org Mon Apr 20 17:29:26 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 19:29:26 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: The Android/iOS work is based on GraalVMs Native Image which has some limitations. These can be found here: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md I stumbled over the problem with Method Handles when I tried to integrate some third-party software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and fixed the problems in NSMenuFX.) Am 20.04.20 um 15:26 schrieb Rony G. Flatscher: > On 20.04.2020 15:06, Michael Paus wrote: >> This is deviating quite a bit from the original issue of this thread, isn't it? >> >> As a side note: MethodHandles are not supported by GraalVM native image >> and so this would probably collide with the attempts to get JavaFX running >> on Android/iOS. > Would you have some link where there would be a technical overview about how Java and JavaFX support > gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on > that platform, ie. is java.lang.reflect available? > > ---rony > > From mp at jugs.org Mon Apr 20 17:31:19 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 19:31:19 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> Message-ID: <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Oh I see. You? are obviously not familiar with the fact that the JDK has a built-in test which checks whether the JavaFX graphics module is on the module path when you try to launch an application main class which is derived from the JavaFX Application class. If you try this and the graphics module is not on the module path the launch will fail with an error message. That's the only reason why JavaFX programs cannot be launched completely on the classpath and that's where all the trouble starts. If you circumvent this test with the trick, I have mentioned before, everything becomes nice and easy. So for me there are only two questions. 1. Is there any proof of a technical reason why JavaFX could not run correctly on the classpath? 2. If there is no such reason, then why do we torture all the newbies with the "intricacies" of the module system instead of just removing this barrier? As I said before, I have not found any such problem in all the time since JavaFX was separated from the JDK, so this test seems to be quite artificial to me but of course I may be wrong. That's why I asked here. Am 20.04.20 um 17:25 schrieb Ty Young: > > I'm a bit confused here. if you don't want JPMS then you should be > able to run everything on the classpath like normal. Netbeans at least > doesn't force modules wtih Maven. Or is reflection disabled on > classpath as of Java 9 too unless you have a module-info? > > >> >> Michael >> >> Am 18.04.20 um 12:58 schrieb Ty Young: >>> >>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>> Getting started with JavaFX is made overly complicated by the fact >>>> that the use of the >>>> module system is enforced by some code in the JDK. Especially for >>>> beginners, who just >>>> want to get some small program running, this is almost always a big >>>> source of frustration. >>>> It is not very good marketing for JavaFX to make these initial >>>> steps such a pain. If you >>>> need some evidence for this statement, then just follow JavaFX on >>>> Stackoverflow or similar >>>> sites (and also this mailing list). Almost every day you can read >>>> frustrated posts from >>>> helpless people who would just like to get some JavaFX project >>>> running but are failing >>>> because they get lost in the module system jungle. >>> >>> >>> Speaking as a long time JavaFX user(literally since Java 8), I have >>> mostly disagree that the JPMS is hurting JavaFX. >>> >>> >>> That said, I don't think the frustration is misplaced. What you say >>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>> user is *NOT* to be blamed here. >>> >>> >>> Rather, I think what's to blame is poor documentation, JavaFX >>> requiring absurd runtime module VM arguments, and? poor/buggy IDE >>> support. >>> >>> >>> Starting with documentation, JavaFX uses reflection for things like >>> TableView(everyone's favorite) and CSS style sheets. While this may >>> be obvious for people who are more experienced, those who are not >>> may be very confused when they get an onslaught of error messages >>> regarding reflection. Better documentation on what requires >>> reflection, why, and how to enable it would be useful. >>> >>> >>> Likewise, the notice about having to include javafx.graphics to the >>> runtime module arguments here: >>> >>> >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>> >>> >>> Apply to Maven as well, but it's under Ant for some reason. I don't >>> know what was changed in JavaFX 14 that now suddenly requires a >>> runtime VM argument, but it's a PITA and BS. End users are going to >>> struggle with this, and it prevents JavaFX runtime from being purely >>> managed by Maven. No other JavaFX version requires this, so it's >>> mind boggling that all of a sudden JavaFX needs this. >>> >>> >>> Poor/buggy IDE support is really the big one here. I don't know >>> about other IDEs but Netbeans DOES NOT provide a project template >>> for creating a JavaFX application with setup dependencies. Netbeans, >>> when setup with a Maven project, allows you to select an entire >>> project(pom) rather than the individual dependencies(jar) which >>> doesn't work. What you search for also matters: if you search for >>> "JavaFX" you will get the wrong search results. You need to search >>> for "openjfx" which can be confusing. >>> >>> >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>> projects and Netbeans because JavaFX puts its src.zip in a folder >>> that is supposed to only include the runtime library that has >>> existed for years(literally a 1 line fix too). No one really uses >>> Ant anymore so it's probably not a big deal now but yeah, getting >>> JavaFX working hasn't been "include and done" when it could >>> potentially be that way. >>> >> From alexander.scherbatiy at bell-sw.com Mon Apr 20 18:15:48 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Mon, 20 Apr 2020 21:15:48 +0300 Subject: JavaFX controls have large size on Raspberry Pi Message-ID: <82483b58-595a-b407-28af-ea6b344eae38@bell-sw.com> Hello, I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. This is because of the algorithm which is used by PrismFontFactory.getSystemFontSize() method [1] to select a system font size. If a system is embedded then the font size is calculated as ??? int screenDPI = Screen.getMainScreen().getResolutionY(); ??? systemFontSize = ((float) screenDPI) / 6f; // 12 points and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. I would like to contribute a fix for this but I do not know how the right fix could look like. Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? Is there a way to check that used screen is from embedded device? May be it should be solved in different way? [1] https://github.com/openjdk/jfx/blob/ec8608f39576035d41e8e532e9334b979b859543/modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java#L1944 [2] https://github.com/openjdk/jfx/blob/ec8608f39576035d41e8e532e9334b979b859543/buildSrc/armv6hf.gradle#L182 JavaFX application: ---------------------------- import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class ButtonFX extends Application { ??? public static void main(String[] args) { ??????? launch(args); ??? } ??? @Override ??? public void start(Stage primaryStage) { ??????? primaryStage.setTitle("Hello World!"); ??? Button button = new Button("Hello, World!"); ??????? StackPane root = new StackPane(); ??????? root.getChildren().add(button); ??????? primaryStage.setScene(new Scene(root, 300, 250)); ??????? primaryStage.show(); ??? } } ---------------------------- Thanks, Alexander. From bruno.borges at gmail.com Mon Apr 20 18:18:40 2020 From: bruno.borges at gmail.com (Bruno Borges) Date: Mon, 20 Apr 2020 11:18:40 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: I do wonder why isn't JavaFX in a single module, like Swing? For Java developers to build Swing apps, all they need is a "requires java.desktop". But for JavaFX, there are multiple modules. --- *Bruno Borges* brunoborges.io On Mon, Apr 20, 2020 at 10:36 AM Michael Paus wrote: > Oh I see. You are obviously not familiar with the fact that the JDK has > a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs cannot > be launched > completely on the classpath and that's where all the trouble starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be > > able to run everything on the classpath like normal. Netbeans at least > > doesn't force modules wtih Maven. Or is reflection disabled on > > classpath as of Java 9 too unless you have a module-info? > > > > > >> > >> Michael > >> > >> Am 18.04.20 um 12:58 schrieb Ty Young: > >>> > >>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>> Getting started with JavaFX is made overly complicated by the fact > >>>> that the use of the > >>>> module system is enforced by some code in the JDK. Especially for > >>>> beginners, who just > >>>> want to get some small program running, this is almost always a big > >>>> source of frustration. > >>>> It is not very good marketing for JavaFX to make these initial > >>>> steps such a pain. If you > >>>> need some evidence for this statement, then just follow JavaFX on > >>>> Stackoverflow or similar > >>>> sites (and also this mailing list). Almost every day you can read > >>>> frustrated posts from > >>>> helpless people who would just like to get some JavaFX project > >>>> running but are failing > >>>> because they get lost in the module system jungle. > >>> > >>> > >>> Speaking as a long time JavaFX user(literally since Java 8), I have > >>> mostly disagree that the JPMS is hurting JavaFX. > >>> > >>> > >>> That said, I don't think the frustration is misplaced. What you say > >>> is true(Netbeans mailing list is fill of JavaFX issues) and the end > >>> user is *NOT* to be blamed here. > >>> > >>> > >>> Rather, I think what's to blame is poor documentation, JavaFX > >>> requiring absurd runtime module VM arguments, and poor/buggy IDE > >>> support. > >>> > >>> > >>> Starting with documentation, JavaFX uses reflection for things like > >>> TableView(everyone's favorite) and CSS style sheets. While this may > >>> be obvious for people who are more experienced, those who are not > >>> may be very confused when they get an onslaught of error messages > >>> regarding reflection. Better documentation on what requires > >>> reflection, why, and how to enable it would be useful. > >>> > >>> > >>> Likewise, the notice about having to include javafx.graphics to the > >>> runtime module arguments here: > >>> > >>> > >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>> > >>> > >>> Apply to Maven as well, but it's under Ant for some reason. I don't > >>> know what was changed in JavaFX 14 that now suddenly requires a > >>> runtime VM argument, but it's a PITA and BS. End users are going to > >>> struggle with this, and it prevents JavaFX runtime from being purely > >>> managed by Maven. No other JavaFX version requires this, so it's > >>> mind boggling that all of a sudden JavaFX needs this. > >>> > >>> > >>> Poor/buggy IDE support is really the big one here. I don't know > >>> about other IDEs but Netbeans DOES NOT provide a project template > >>> for creating a JavaFX application with setup dependencies. Netbeans, > >>> when setup with a Maven project, allows you to select an entire > >>> project(pom) rather than the individual dependencies(jar) which > >>> doesn't work. What you search for also matters: if you search for > >>> "JavaFX" you will get the wrong search results. You need to search > >>> for "openjfx" which can be confusing. > >>> > >>> > >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>> that is supposed to only include the runtime library that has > >>> existed for years(literally a 1 line fix too). No one really uses > >>> Ant anymore so it's probably not a big deal now but yeah, getting > >>> JavaFX working hasn't been "include and done" when it could > >>> potentially be that way. > >>> > >> > > > From mp at jugs.org Mon Apr 20 18:36:44 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Apr 2020 20:36:44 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <3d3de6ba-27cd-254a-dd7a-583e161cc780@jugs.org> Hi Bruno I actually like the fact that JavaFX has been split up into some smaller parts. E.g., javafx.web is the biggest moster in this context and if you do not really need it, it is nice that you leave it out. Also media, swing and fxml are not always needed and so you can leave them out. I even have cases where I only allow javafx.base because that is all you need to write your view-models and it is good that you can explicitly separate that from all the graphics and control stuff. So I have absolutely no problem with that kind of modularization. Michael Am 20.04.20 um 20:18 schrieb Bruno Borges: > I do wonder why isn't JavaFX in a single module, like Swing? > > For Java developers to build Swing apps, all they need is a "requires > java.desktop". > > But for JavaFX, there are multiple modules. > > --- > *Bruno Borges* > brunoborges.io > > > On Mon, Apr 20, 2020 at 10:36 AM Michael Paus > wrote: > > Oh I see. You? are obviously not familiar with the fact that the > JDK has > a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the > JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs > cannot > be launched > completely on the classpath and that's where all the trouble > starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be > > able to run everything on the classpath like normal. Netbeans at > least > > doesn't force modules wtih Maven. Or is reflection disabled on > > classpath as of Java 9 too unless you have a module-info? > > > > > >> > >> Michael > >> > >> Am 18.04.20 um 12:58 schrieb Ty Young: > >>> > >>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>> Getting started with JavaFX is made overly complicated by the > fact > >>>> that the use of the > >>>> module system is enforced by some code in the JDK. Especially > for > >>>> beginners, who just > >>>> want to get some small program running, this is almost always > a big > >>>> source of frustration. > >>>> It is not very good marketing for JavaFX to make these initial > >>>> steps such a pain. If you > >>>> need some evidence for this statement, then just follow > JavaFX on > >>>> Stackoverflow or similar > >>>> sites (and also this mailing list). Almost every day you can > read > >>>> frustrated posts from > >>>> helpless people who would just like to get some JavaFX project > >>>> running but are failing > >>>> because they get lost in the module system jungle. > >>> > >>> > >>> Speaking as a long time JavaFX user(literally since Java 8), I > have > >>> mostly disagree that the JPMS is hurting JavaFX. > >>> > >>> > >>> That said, I don't think the frustration is misplaced. What > you say > >>> is true(Netbeans mailing list is fill of JavaFX issues) and > the end > >>> user is *NOT* to be blamed here. > >>> > >>> > >>> Rather, I think what's to blame is poor documentation, JavaFX > >>> requiring absurd runtime module VM arguments, and? poor/buggy IDE > >>> support. > >>> > >>> > >>> Starting with documentation, JavaFX uses reflection for things > like > >>> TableView(everyone's favorite) and CSS style sheets. While > this may > >>> be obvious for people who are more experienced, those who are not > >>> may be very confused when they get an onslaught of error messages > >>> regarding reflection. Better documentation on what requires > >>> reflection, why, and how to enable it would be useful. > >>> > >>> > >>> Likewise, the notice about having to include javafx.graphics > to the > >>> runtime module arguments here: > >>> > >>> > >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>> > >>> > >>> Apply to Maven as well, but it's under Ant for some reason. I > don't > >>> know what was changed in JavaFX 14 that now suddenly requires a > >>> runtime VM argument, but it's a PITA and BS. End users are > going to > >>> struggle with this, and it prevents JavaFX runtime from being > purely > >>> managed by Maven. No other JavaFX version requires this, so it's > >>> mind boggling that all of a sudden JavaFX needs this. > >>> > >>> > >>> Poor/buggy IDE support is really the big one here. I don't know > >>> about other IDEs but Netbeans DOES NOT provide a project template > >>> for creating a JavaFX application with setup dependencies. > Netbeans, > >>> when setup with a Maven project, allows you to select an entire > >>> project(pom) rather than the individual dependencies(jar) which > >>> doesn't work. What you search for also matters: if you search for > >>> "JavaFX" you will get the wrong search results. You need to > search > >>> for "openjfx" which can be confusing. > >>> > >>> > >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>> that is supposed to only include the runtime library that has > >>> existed for years(literally a 1 line fix too). No one really uses > >>> Ant anymore so it's probably not a big deal now but yeah, getting > >>> JavaFX working hasn't been "include and done" when it could > >>> potentially be that way. > >>> > >> > > From philip.race at oracle.com Mon Apr 20 18:52:49 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 Apr 2020 11:52:49 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <5E9DEF81.6000401@oracle.com> On 4/20/20, 11:18 AM, Bruno Borges wrote: > I do wonder why isn't JavaFX in a single module, like Swing? > > > For Java developers to build Swing apps, all they need is a "requires > java.desktop". Well it isn't because we wanted to do that for Swing. It is because it was too hard to decompose it because of interdependencies between AWT and Swing and 2D. For example AWT + 2D APIs are in the same java.awt package. And Swing is the 99% use case so it would have amounted to using all of the same anyway. But even if it could have been done likely we would still have had an aggregator module to make it easy. Note that java.datatransfer is required by java.desktop. -phil. > But for JavaFX, there are multiple modules. > > --- > *Bruno Borges* > brunoborges.io > > > On Mon, Apr 20, 2020 at 10:36 AM Michael Paus wrote: > >> Oh I see. You are obviously not familiar with the fact that the JDK has >> a built-in test >> which checks whether the JavaFX graphics module is on the module path >> when you >> try to launch an application main class which is derived from the JavaFX >> Application class. >> If you try this and the graphics module is not on the module path the >> launch will fail >> with an error message. That's the only reason why JavaFX programs cannot >> be launched >> completely on the classpath and that's where all the trouble starts. If >> you circumvent this >> test with the trick, I have mentioned before, everything becomes nice >> and easy. >> >> So for me there are only two questions. >> 1. Is there any proof of a technical reason why JavaFX could not run >> correctly on the classpath? >> 2. If there is no such reason, then why do we torture all the newbies >> with the "intricacies" of the >> module system instead of just removing this barrier? >> >> As I said before, I have not found any such problem in all the time >> since JavaFX was separated >> from the JDK, so this test seems to be quite artificial to me but of >> course I may be wrong. That's >> why I asked here. >> >> Am 20.04.20 um 17:25 schrieb Ty Young: >>> I'm a bit confused here. if you don't want JPMS then you should be >>> able to run everything on the classpath like normal. Netbeans at least >>> doesn't force modules wtih Maven. Or is reflection disabled on >>> classpath as of Java 9 too unless you have a module-info? >>> >>> >>>> Michael >>>> >>>> Am 18.04.20 um 12:58 schrieb Ty Young: >>>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>>>> Getting started with JavaFX is made overly complicated by the fact >>>>>> that the use of the >>>>>> module system is enforced by some code in the JDK. Especially for >>>>>> beginners, who just >>>>>> want to get some small program running, this is almost always a big >>>>>> source of frustration. >>>>>> It is not very good marketing for JavaFX to make these initial >>>>>> steps such a pain. If you >>>>>> need some evidence for this statement, then just follow JavaFX on >>>>>> Stackoverflow or similar >>>>>> sites (and also this mailing list). Almost every day you can read >>>>>> frustrated posts from >>>>>> helpless people who would just like to get some JavaFX project >>>>>> running but are failing >>>>>> because they get lost in the module system jungle. >>>>> >>>>> Speaking as a long time JavaFX user(literally since Java 8), I have >>>>> mostly disagree that the JPMS is hurting JavaFX. >>>>> >>>>> >>>>> That said, I don't think the frustration is misplaced. What you say >>>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>>>> user is *NOT* to be blamed here. >>>>> >>>>> >>>>> Rather, I think what's to blame is poor documentation, JavaFX >>>>> requiring absurd runtime module VM arguments, and poor/buggy IDE >>>>> support. >>>>> >>>>> >>>>> Starting with documentation, JavaFX uses reflection for things like >>>>> TableView(everyone's favorite) and CSS style sheets. While this may >>>>> be obvious for people who are more experienced, those who are not >>>>> may be very confused when they get an onslaught of error messages >>>>> regarding reflection. Better documentation on what requires >>>>> reflection, why, and how to enable it would be useful. >>>>> >>>>> >>>>> Likewise, the notice about having to include javafx.graphics to the >>>>> runtime module arguments here: >>>>> >>>>> >>>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>>>> >>>>> >>>>> Apply to Maven as well, but it's under Ant for some reason. I don't >>>>> know what was changed in JavaFX 14 that now suddenly requires a >>>>> runtime VM argument, but it's a PITA and BS. End users are going to >>>>> struggle with this, and it prevents JavaFX runtime from being purely >>>>> managed by Maven. No other JavaFX version requires this, so it's >>>>> mind boggling that all of a sudden JavaFX needs this. >>>>> >>>>> >>>>> Poor/buggy IDE support is really the big one here. I don't know >>>>> about other IDEs but Netbeans DOES NOT provide a project template >>>>> for creating a JavaFX application with setup dependencies. Netbeans, >>>>> when setup with a Maven project, allows you to select an entire >>>>> project(pom) rather than the individual dependencies(jar) which >>>>> doesn't work. What you search for also matters: if you search for >>>>> "JavaFX" you will get the wrong search results. You need to search >>>>> for "openjfx" which can be confusing. >>>>> >>>>> >>>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>>>> projects and Netbeans because JavaFX puts its src.zip in a folder >>>>> that is supposed to only include the runtime library that has >>>>> existed for years(literally a 1 line fix too). No one really uses >>>>> Ant anymore so it's probably not a big deal now but yeah, getting >>>>> JavaFX working hasn't been "include and done" when it could >>>>> potentially be that way. >>>>> >> >> From mailinglist2020 at protonmail.com Mon Apr 20 19:28:55 2020 From: mailinglist2020 at protonmail.com (Mailing User) Date: Mon, 20 Apr 2020 19:28:55 +0000 Subject: Is it possible to customise the theme of the Scene Builder itself? Message-ID: I have downloaded the latest version from a website called Gluon or something. The problem is that the default theme lacks contrast. It looks like grey text on light grey background. Also the font is too small for me. In File -> Preferences, I can see "Scene Builder Theme", but it only has two themes: Default and Dark. The Dark theme also lacks contrast. It looks like grey text on dark grey background. Is there any way to change the colours or the font size of Scene Builder itself, NOT the scene of my application that I am editing with Scene Builder? From David.Grieve at microsoft.com Mon Apr 20 20:13:49 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 20 Apr 2020 20:13:49 +0000 Subject: Is it possible to customise the theme of the Scene Builder itself? Message-ID: This is probably not the right forum for this question. Try a forum like stackoverflow. Or reach out to great people at Gluon. The short answer, however, is that you can play with the CSS styles that make up the theme. You'd either need to update the stylesheets in the jar or build scene builder yourself. -----Original Message----- From: openjfx-dev On Behalf Of Mailing User Sent: Monday, April 20, 2020 3:29 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Is it possible to customise the theme of the Scene Builder itself? I have downloaded the latest version from a website called Gluon or something. The problem is that the default theme lacks contrast. It looks like grey text on light grey background. Also the font is too small for me. In File -> Preferences, I can see "Scene Builder Theme", but it only has two themes: Default and Dark. The Dark theme also lacks contrast. It looks like grey text on dark grey background. Is there any way to change the colours or the font size of Scene Builder itself, NOT the scene of my application that I am editing with Scene Builder? From David.Grieve at microsoft.com Mon Apr 20 20:25:17 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 20 Apr 2020 20:25:17 +0000 Subject: JavaFX controls have large size on Raspberry Pi Message-ID: The sizes of controls are controlled by CSS styles. Things like borders, backgrounds, padding, insets, all of that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning they are relative to the size of the font. JavaFX CSS will use the Font.getDefault() font size if there is no font explicitly set in either the styles or in the application code. I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. It could also be an issue with the default stylesheets themselves. -----Original Message----- From: openjfx-dev On Behalf Of Alexander Scherbatiy Sent: Monday, April 20, 2020 2:16 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi Hello, I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. This is because of the algorithm which is used by PrismFontFactory.getSystemFontSize() method [1] to select a system font size. If a system is embedded then the font size is calculated as ??? int screenDPI = Screen.getMainScreen().getResolutionY(); ??? systemFontSize = ((float) screenDPI) / 6f; // 12 points and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. I would like to contribute a fix for this but I do not know how the right fix could look like. Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? Is there a way to check that used screen is from embedded device? May be it should be solved in different way? [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 JavaFX application: ---------------------------- import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class ButtonFX extends Application { ??? public static void main(String[] args) { ??????? launch(args); ??? } ??? @Override ??? public void start(Stage primaryStage) { ??????? primaryStage.setTitle("Hello World!"); ??? Button button = new Button("Hello, World!"); ??????? StackPane root = new StackPane(); ??????? root.getChildren().add(button); ??????? primaryStage.setScene(new Scene(root, 300, 250)); ??????? primaryStage.show(); ??? } } ---------------------------- Thanks, Alexander. From tbee at tbee.org Mon Apr 20 20:33:58 2020 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 20 Apr 2020 22:33:58 +0200 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <8826d71f-1f8c-0c56-8aca-3d0b706e5722@tbee.org> JFXtras is split in many modules as well, the question is if it really is that important to do. Splitting up in jars -so you don't need to include what is not needed- is good, but whether they need to be modules... The way I see it is that JPMS requires the same amount of effort as OSGi for example, but does not provide the same functionality (most importantly class load separation) and thus is simply less worthwhile. So either 'we' start adding that last piece (I recently learned there is such a thing as JPMS layers, which provides for that), or it probably will stay a Java core thing only. Regards, Tom On 20-4-2020 20:18, Bruno Borges wrote: > I do wonder why isn't JavaFX in a single module, like Swing? > > > For Java developers to build Swing apps, all they need is a "requires > java.desktop". > > But for JavaFX, there are multiple modules. > > --- > *Bruno Borges* > brunoborges.io > > > On Mon, Apr 20, 2020 at 10:36 AM Michael Paus wrote: > >> Oh I see. You are obviously not familiar with the fact that the JDK has >> a built-in test >> which checks whether the JavaFX graphics module is on the module path >> when you >> try to launch an application main class which is derived from the JavaFX >> Application class. >> If you try this and the graphics module is not on the module path the >> launch will fail >> with an error message. That's the only reason why JavaFX programs cannot >> be launched >> completely on the classpath and that's where all the trouble starts. If >> you circumvent this >> test with the trick, I have mentioned before, everything becomes nice >> and easy. >> >> So for me there are only two questions. >> 1. Is there any proof of a technical reason why JavaFX could not run >> correctly on the classpath? >> 2. If there is no such reason, then why do we torture all the newbies >> with the "intricacies" of the >> module system instead of just removing this barrier? >> >> As I said before, I have not found any such problem in all the time >> since JavaFX was separated >> from the JDK, so this test seems to be quite artificial to me but of >> course I may be wrong. That's >> why I asked here. >> >> Am 20.04.20 um 17:25 schrieb Ty Young: >>> I'm a bit confused here. if you don't want JPMS then you should be >>> able to run everything on the classpath like normal. Netbeans at least >>> doesn't force modules wtih Maven. Or is reflection disabled on >>> classpath as of Java 9 too unless you have a module-info? >>> >>> >>>> Michael >>>> >>>> Am 18.04.20 um 12:58 schrieb Ty Young: >>>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>>>> Getting started with JavaFX is made overly complicated by the fact >>>>>> that the use of the >>>>>> module system is enforced by some code in the JDK. Especially for >>>>>> beginners, who just >>>>>> want to get some small program running, this is almost always a big >>>>>> source of frustration. >>>>>> It is not very good marketing for JavaFX to make these initial >>>>>> steps such a pain. If you >>>>>> need some evidence for this statement, then just follow JavaFX on >>>>>> Stackoverflow or similar >>>>>> sites (and also this mailing list). Almost every day you can read >>>>>> frustrated posts from >>>>>> helpless people who would just like to get some JavaFX project >>>>>> running but are failing >>>>>> because they get lost in the module system jungle. >>>>> >>>>> Speaking as a long time JavaFX user(literally since Java 8), I have >>>>> mostly disagree that the JPMS is hurting JavaFX. >>>>> >>>>> >>>>> That said, I don't think the frustration is misplaced. What you say >>>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>>>> user is *NOT* to be blamed here. >>>>> >>>>> >>>>> Rather, I think what's to blame is poor documentation, JavaFX >>>>> requiring absurd runtime module VM arguments, and poor/buggy IDE >>>>> support. >>>>> >>>>> >>>>> Starting with documentation, JavaFX uses reflection for things like >>>>> TableView(everyone's favorite) and CSS style sheets. While this may >>>>> be obvious for people who are more experienced, those who are not >>>>> may be very confused when they get an onslaught of error messages >>>>> regarding reflection. Better documentation on what requires >>>>> reflection, why, and how to enable it would be useful. >>>>> >>>>> >>>>> Likewise, the notice about having to include javafx.graphics to the >>>>> runtime module arguments here: >>>>> >>>>> >>>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>>>> >>>>> >>>>> Apply to Maven as well, but it's under Ant for some reason. I don't >>>>> know what was changed in JavaFX 14 that now suddenly requires a >>>>> runtime VM argument, but it's a PITA and BS. End users are going to >>>>> struggle with this, and it prevents JavaFX runtime from being purely >>>>> managed by Maven. No other JavaFX version requires this, so it's >>>>> mind boggling that all of a sudden JavaFX needs this. >>>>> >>>>> >>>>> Poor/buggy IDE support is really the big one here. I don't know >>>>> about other IDEs but Netbeans DOES NOT provide a project template >>>>> for creating a JavaFX application with setup dependencies. Netbeans, >>>>> when setup with a Maven project, allows you to select an entire >>>>> project(pom) rather than the individual dependencies(jar) which >>>>> doesn't work. What you search for also matters: if you search for >>>>> "JavaFX" you will get the wrong search results. You need to search >>>>> for "openjfx" which can be confusing. >>>>> >>>>> >>>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>>>> projects and Netbeans because JavaFX puts its src.zip in a folder >>>>> that is supposed to only include the runtime library that has >>>>> existed for years(literally a 1 line fix too). No one really uses >>>>> Ant anymore so it's probably not a big deal now but yeah, getting >>>>> JavaFX working hasn't been "include and done" when it could >>>>> potentially be that way. >>>>> >> >> From kevin.rushforth at oracle.com Mon Apr 20 20:56:44 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 13:56:44 -0700 Subject: JavaFX controls have large size on Raspberry Pi In-Reply-To: References: Message-ID: <8343639b-c75e-0e72-3420-62100b60bdc4@oracle.com> Another thing to check is that the reported DPI of the screen is correct. -- Kevin On 4/20/2020 1:25 PM, David Grieve wrote: > The sizes of controls are controlled by CSS styles. Things like borders, backgrounds, padding, insets, all of > that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning they are relative to the size > of the font. JavaFX CSS will use the Font.getDefault() font size if there is no font explicitly set in either the > styles or in the application code. > > I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. > It could also be an issue with the default stylesheets themselves. > > -----Original Message----- > From: openjfx-dev On Behalf Of Alexander Scherbatiy > Sent: Monday, April 20, 2020 2:16 PM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi > > Hello, > > I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. > > This is because of the algorithm which is used by > PrismFontFactory.getSystemFontSize() method [1] to select a system font size. > If a system is embedded then the font size is calculated as > > ??? int screenDPI = Screen.getMainScreen().getResolutionY(); > ??? systemFontSize = ((float) screenDPI) / 6f; // 12 points > > and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. > > Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. > > I would like to contribute a fix for this but I do not know how the right fix could look like. > Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? > Is there a way to check that used screen is from embedded device? > May be it should be solved in different way? > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 > [2] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 > > JavaFX application: > ---------------------------- > import javafx.application.Application; > import javafx.event.ActionEvent; > import javafx.event.EventHandler; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.StackPane; > import javafx.stage.Stage; > > public class ButtonFX extends Application { > ??? public static void main(String[] args) { > ??????? launch(args); > ??? } > > ??? @Override > ??? public void start(Stage primaryStage) { > ??????? primaryStage.setTitle("Hello World!"); > ??? Button button = new Button("Hello, World!"); > > ??????? StackPane root = new StackPane(); > ??????? root.getChildren().add(button); > ??????? primaryStage.setScene(new Scene(root, 300, 250)); > ??????? primaryStage.show(); > ??? } > } > ---------------------------- > > Thanks, > Alexander. > > From philip.race at oracle.com Mon Apr 20 21:18:37 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 Apr 2020 14:18:37 -0700 Subject: JavaFX controls have large size on Raspberry Pi In-Reply-To: <8343639b-c75e-0e72-3420-62100b60bdc4@oracle.com> References: <8343639b-c75e-0e72-3420-62100b60bdc4@oracle.com> Message-ID: <5E9E11AD.3070901@oracle.com> > I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. I think the code below is the code that decides what the code above should return > Another thing to check is that the reported DPI of the screen is correct. The way I read the code below is that it wants the default font to be 1/6 of an inch high on the screen. I think any smaller than 6 lines per inch and it will be hard to read. To do this correctly, it relies on the y-res being accurate for the device. So I would follow the path Kevin suggests. For example if something is wrongly returning the *dimension* of the screen when it should be the *dpi* of the screen then you'd have 6 lines of text filling up the screen. -phil. On 4/20/20, 1:56 PM, Kevin Rushforth wrote: > Another thing to check is that the reported DPI of the screen is correct. > > -- Kevin > > > On 4/20/2020 1:25 PM, David Grieve wrote: >> The sizes of controls are controlled by CSS styles. Things like >> borders, backgrounds, padding, insets, all of >> that defaults to the styles in a stylesheet. Most sizes are 'em' >> units, meaning they are relative to the size >> of the font. JavaFX CSS will use the Font.getDefault() font size if >> there is no font explicitly set in either the >> styles or in the application code. >> >> I would start by looking at what Font.getDefault().getSize() returns >> since everything should be based off that. >> It could also be an issue with the default stylesheets themselves. >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Alexander Scherbatiy >> Sent: Monday, April 20, 2020 2:16 PM >> To: openjfx-dev at openjdk.java.net >> Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi >> >> Hello, >> >> I run a simple JavaFX application which shows a button with jdk >> 14.0.1 on Raspberry Pi and the drawn button has large size. >> >> This is because of the algorithm which is used by >> PrismFontFactory.getSystemFontSize() method [1] to select a system >> font size. >> If a system is embedded then the font size is calculated as >> >> int screenDPI = Screen.getMainScreen().getResolutionY(); >> systemFontSize = ((float) screenDPI) / 6f; // 12 points >> >> and the system is detected as embedded because the armv6hf >> architecture is defined as embedded in the armv6hf.gradle file [2]. >> >> Raspberri Pi can work both with small touch displays and with big >> monitors. It looks like Raspberry Pi should support two modes for >> font size calculation: one for small screens and another for large. >> >> I would like to contribute a fix for this but I do not know how the >> right fix could look like. >> Should there be a special screen size so for smaller screens the font >> is is proportional to the screen size and for bigger screens the font >> size is fixed? >> Is there a way to check that used screen is from embedded device? >> May be it should be solved in different way? >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 >> >> [2] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 >> >> >> JavaFX application: >> ---------------------------- >> import javafx.application.Application; >> import javafx.event.ActionEvent; >> import javafx.event.EventHandler; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.StackPane; >> import javafx.stage.Stage; >> >> public class ButtonFX extends Application { >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) { >> primaryStage.setTitle("Hello World!"); >> Button button = new Button("Hello, World!"); >> >> StackPane root = new StackPane(); >> root.getChildren().add(button); >> primaryStage.setScene(new Scene(root, 300, 250)); >> primaryStage.show(); >> } >> } >> ---------------------------- >> >> Thanks, >> Alexander. >> >> > From kevin.rushforth at oracle.com Mon Apr 20 22:54:22 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Apr 2020 15:54:22 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> Message-ID: <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> As of JDK 9, there are a few places in JavaFX that assume the JavaFX modules are, in fact modules. While it would likely be technically possible to find them all, and make modifications that will allow running JavaFX either on the classpath or on the module path, I am not in favor of that. I think it would be a step backwards. For one thing, we would lose the encapsulation that the module system provides, and applications would be able to access internal packages without so much as a warning that it's not public API. Also it would increase the testing burden, since that would be one more mode in which it would need to be tested to ensure that it doesn't break. I tend to agree with those who say that this is mostly a documentation issue. I suppose it's also a bit of a tooling problem, since first class support for modules is still in progress in various IDEs and build tools (gradle, maven, etc). The support in the IDEs is pretty good now, and gradle 6.4 reportedly has full support for modules. Someone with more familiarity with Maven can comment about their module support. -- Kevin On 4/20/2020 10:31 AM, Michael Paus wrote: > Oh I see. You? are obviously not familiar with the fact that the JDK > has a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the > JavaFX Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs > cannot be launched > completely on the classpath and that's where all the trouble starts. > If you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: >> >> I'm a bit confused here. if you don't want JPMS then you should be >> able to run everything on the classpath like normal. Netbeans at >> least doesn't force modules wtih Maven. Or is reflection disabled on >> classpath as of Java 9 too unless you have a module-info? >> >> >>> >>> Michael >>> >>> Am 18.04.20 um 12:58 schrieb Ty Young: >>>> >>>> On 4/18/20 5:01 AM, Michael Paus wrote: >>>>> Getting started with JavaFX is made overly complicated by the fact >>>>> that the use of the >>>>> module system is enforced by some code in the JDK. Especially for >>>>> beginners, who just >>>>> want to get some small program running, this is almost always a >>>>> big source of frustration. >>>>> It is not very good marketing for JavaFX to make these initial >>>>> steps such a pain. If you >>>>> need some evidence for this statement, then just follow JavaFX on >>>>> Stackoverflow or similar >>>>> sites (and also this mailing list). Almost every day you can read >>>>> frustrated posts from >>>>> helpless people who would just like to get some JavaFX project >>>>> running but are failing >>>>> because they get lost in the module system jungle. >>>> >>>> >>>> Speaking as a long time JavaFX user(literally since Java 8), I have >>>> mostly disagree that the JPMS is hurting JavaFX. >>>> >>>> >>>> That said, I don't think the frustration is misplaced. What you say >>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end >>>> user is *NOT* to be blamed here. >>>> >>>> >>>> Rather, I think what's to blame is poor documentation, JavaFX >>>> requiring absurd runtime module VM arguments, and poor/buggy IDE >>>> support. >>>> >>>> >>>> Starting with documentation, JavaFX uses reflection for things like >>>> TableView(everyone's favorite) and CSS style sheets. While this may >>>> be obvious for people who are more experienced, those who are not >>>> may be very confused when they get an onslaught of error messages >>>> regarding reflection. Better documentation on what requires >>>> reflection, why, and how to enable it would be useful. >>>> >>>> >>>> Likewise, the notice about having to include javafx.graphics to the >>>> runtime module arguments here: >>>> >>>> >>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans >>>> >>>> >>>> Apply to Maven as well, but it's under Ant for some reason. I don't >>>> know what was changed in JavaFX 14 that now suddenly requires a >>>> runtime VM argument, but it's a PITA and BS. End users are going to >>>> struggle with this, and it prevents JavaFX runtime from being >>>> purely managed by Maven. No other JavaFX version requires this, so >>>> it's mind boggling that all of a sudden JavaFX needs this. >>>> >>>> >>>> Poor/buggy IDE support is really the big one here. I don't know >>>> about other IDEs but Netbeans DOES NOT provide a project template >>>> for creating a JavaFX application with setup dependencies. >>>> Netbeans, when setup with a Maven project, allows you to select an >>>> entire project(pom) rather than the individual dependencies(jar) >>>> which doesn't work. What you search for also matters: if you search >>>> for "JavaFX" you will get the wrong search results. You need to >>>> search for "openjfx" which can be confusing. >>>> >>>> >>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based >>>> projects and Netbeans because JavaFX puts its src.zip in a folder >>>> that is supposed to only include the runtime library that has >>>> existed for years(literally a 1 line fix too). No one really uses >>>> Ant anymore so it's probably not a big deal now but yeah, getting >>>> JavaFX working hasn't been "include and done" when it could >>>> potentially be that way. >>>> >>> > > From bruno.borges at gmail.com Tue Apr 21 01:04:10 2020 From: bruno.borges at gmail.com (Bruno Borges) Date: Mon, 20 Apr 2020 18:04:10 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> Message-ID: One thing I do miss in openjfx.io website in terms of documentation is the definition of a jmods file and the sdk. For new developers looking at the download page, it's really not simple to figure it out. On Mon, Apr 20, 2020, 15:55 Kevin Rushforth wrote: > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > modules are, in fact modules. While it would likely be technically > possible to find them all, and make modifications that will allow > running JavaFX either on the classpath or on the module path, I am not > in favor of that. I think it would be a step backwards. For one thing, > we would lose the encapsulation that the module system provides, and > applications would be able to access internal packages without so much > as a warning that it's not public API. Also it would increase the > testing burden, since that would be one more mode in which it would need > to be tested to ensure that it doesn't break. > > I tend to agree with those who say that this is mostly a documentation > issue. I suppose it's also a bit of a tooling problem, since first class > support for modules is still in progress in various IDEs and build tools > (gradle, maven, etc). The support in the IDEs is pretty good now, and > gradle 6.4 reportedly has full support for modules. Someone with more > familiarity with Maven can comment about their module support. > > -- Kevin > > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > Oh I see. You are obviously not familiar with the fact that the JDK > > has a built-in test > > which checks whether the JavaFX graphics module is on the module path > > when you > > try to launch an application main class which is derived from the > > JavaFX Application class. > > If you try this and the graphics module is not on the module path the > > launch will fail > > with an error message. That's the only reason why JavaFX programs > > cannot be launched > > completely on the classpath and that's where all the trouble starts. > > If you circumvent this > > test with the trick, I have mentioned before, everything becomes nice > > and easy. > > > > So for me there are only two questions. > > 1. Is there any proof of a technical reason why JavaFX could not run > > correctly on the classpath? > > 2. If there is no such reason, then why do we torture all the newbies > > with the "intricacies" of the > > module system instead of just removing this barrier? > > > > As I said before, I have not found any such problem in all the time > > since JavaFX was separated > > from the JDK, so this test seems to be quite artificial to me but of > > course I may be wrong. That's > > why I asked here. > > > > Am 20.04.20 um 17:25 schrieb Ty Young: > >> > >> I'm a bit confused here. if you don't want JPMS then you should be > >> able to run everything on the classpath like normal. Netbeans at > >> least doesn't force modules wtih Maven. Or is reflection disabled on > >> classpath as of Java 9 too unless you have a module-info? > >> > >> > >>> > >>> Michael > >>> > >>> Am 18.04.20 um 12:58 schrieb Ty Young: > >>>> > >>>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>>> Getting started with JavaFX is made overly complicated by the fact > >>>>> that the use of the > >>>>> module system is enforced by some code in the JDK. Especially for > >>>>> beginners, who just > >>>>> want to get some small program running, this is almost always a > >>>>> big source of frustration. > >>>>> It is not very good marketing for JavaFX to make these initial > >>>>> steps such a pain. If you > >>>>> need some evidence for this statement, then just follow JavaFX on > >>>>> Stackoverflow or similar > >>>>> sites (and also this mailing list). Almost every day you can read > >>>>> frustrated posts from > >>>>> helpless people who would just like to get some JavaFX project > >>>>> running but are failing > >>>>> because they get lost in the module system jungle. > >>>> > >>>> > >>>> Speaking as a long time JavaFX user(literally since Java 8), I have > >>>> mostly disagree that the JPMS is hurting JavaFX. > >>>> > >>>> > >>>> That said, I don't think the frustration is misplaced. What you say > >>>> is true(Netbeans mailing list is fill of JavaFX issues) and the end > >>>> user is *NOT* to be blamed here. > >>>> > >>>> > >>>> Rather, I think what's to blame is poor documentation, JavaFX > >>>> requiring absurd runtime module VM arguments, and poor/buggy IDE > >>>> support. > >>>> > >>>> > >>>> Starting with documentation, JavaFX uses reflection for things like > >>>> TableView(everyone's favorite) and CSS style sheets. While this may > >>>> be obvious for people who are more experienced, those who are not > >>>> may be very confused when they get an onslaught of error messages > >>>> regarding reflection. Better documentation on what requires > >>>> reflection, why, and how to enable it would be useful. > >>>> > >>>> > >>>> Likewise, the notice about having to include javafx.graphics to the > >>>> runtime module arguments here: > >>>> > >>>> > >>>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>>> > >>>> > >>>> Apply to Maven as well, but it's under Ant for some reason. I don't > >>>> know what was changed in JavaFX 14 that now suddenly requires a > >>>> runtime VM argument, but it's a PITA and BS. End users are going to > >>>> struggle with this, and it prevents JavaFX runtime from being > >>>> purely managed by Maven. No other JavaFX version requires this, so > >>>> it's mind boggling that all of a sudden JavaFX needs this. > >>>> > >>>> > >>>> Poor/buggy IDE support is really the big one here. I don't know > >>>> about other IDEs but Netbeans DOES NOT provide a project template > >>>> for creating a JavaFX application with setup dependencies. > >>>> Netbeans, when setup with a Maven project, allows you to select an > >>>> entire project(pom) rather than the individual dependencies(jar) > >>>> which doesn't work. What you search for also matters: if you search > >>>> for "JavaFX" you will get the wrong search results. You need to > >>>> search for "openjfx" which can be confusing. > >>>> > >>>> > >>>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>>> that is supposed to only include the runtime library that has > >>>> existed for years(literally a 1 line fix too). No one really uses > >>>> Ant anymore so it's probably not a big deal now but yeah, getting > >>>> JavaFX working hasn't been "include and done" when it could > >>>> potentially be that way. > >>>> > >>> > > > > > > From github.com+4208131+bhaweshkc at openjdk.java.net Tue Apr 21 09:05:27 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 21 Apr 2020 09:05:27 GMT Subject: [Rev 01] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: added unit test for 8191758 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/180/files - new: https://git.openjdk.java.net/jfx/pull/180/files/d3d3e716..43c7cbf1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/180/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/180/webrev.00-01 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/180/head:pull/180 PR: https://git.openjdk.java.net/jfx/pull/180 From fastegal at swingempire.de Tue Apr 21 11:06:47 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 21 Apr 2020 13:06:47 +0200 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> Message-ID: <20200421130647.Horde.9OZ6De4A76UMi5Og6Hg7Lg1@webmail.df.eu> part of the confusion might be the reporter's workaround in https://bugs.openjdk.java.net/browse/JDK-8193286 which effectively clamps (doesn't make a difference, having amountPerStep=1 and not incrementing programatically) commented that bug with an alternative implemenation and a couple of tests (for the most simple case ;) -- Jeanette Zitat von Kevin Rushforth : > I just took another look at the SpinnerValueFactory API docs. The > use of the term "circular" heavily implies modulo arithmetic as the > expected behavior if wrapAround is true. That the usual meaning of > "wrap" versus "clamp" when you have a range bounded on both ends. > Maybe the confusion comes from the fact that it isn't stated as > clearly as it might be, coupled with a single example of a step by > one going from max to min (if incrementing). I note that example > doesn't say what the amountToStepBy is, but it wasn't trying to be > prescriptive. > > Since the current behavior of "wrap around unless you happen to wrap > a bit too much and then we'll clamp" doesn't make sense in any > universe that I can think of, it is fine to treat this as a bug. I'm > not worried about "bug compatibility" here. > > Clarifying the spec at the same time seems like a good idea to me. A > related issue is that the default value of wrapAround is not > specified (the default is `false`, but you wouldn't know that from > reading the docs). This should also be addressed at the same time. > > You mentioned that this is specific to IntegerValueFactory, but it > looks like DoubleValueFactory (and maybe ListValueFactory) have the > same bug. Or am I missing something? > > On an unrelated note, I just noticed that the SpinnerValueFactory > constructor has no documentation. This is because it is an > implicitly added constructor, which is an anti-pattern for public > API. I'll file a separate issue for that. > > -- Kevin > > > On 4/15/2020 2:23 AM, Jeanette Winzenburg wrote: >> Hi Ajit, >> >> yes, I read the doc, probably a bit differently - could well be my >> misunderstanding and misunderstandable wording :) >> >> Trying again: >> >> - I read your suggestion (in >> https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. >> that being at value and incrementing a full-cycle (that is max -min >> +1), I will land on value again >> - for me the doc seemed to imply that in such a case I would land >> on min. Though, given the "circular" as you pointed out correctly, >> was my misunderstanding >> - the current implementation is buggy >> (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating >> the remainder (which is what the first bullet amounts to) >> incorrectly for min != 0 >> >> Where do I err? >> >> -- Jeanette >> >> >> Zitat von Ajit Ghaisas : >> >>> Hi Jeanette, >>> >>> The doc never assumes amountPerStep = 1. I am quoting it here - >>> ?The wrapAround property is used to specify whether the value >>> factory should be circular. For example, should an integer-based >>> value model increment from the maximum value back to the minimum >>> value (and vice versa).? >>> >>> The word ?circular? clarifies that once we exceed maximum value, >>> we should start from minimum. >>> I think, the doc is OK in it?s current form, but implementation >>> needs to be corrected. >>> >>> Regards, >>> Ajit >>> >>> >>>> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg >>>> wrote: >>>> >>>> >>>> Hi Ajit, >>>> >>>> thought the doc was simply bad (in specifying the behavior for >>>> amountPerStep = 1 and not thinking of larger amounts) - my >>>> expection is a calculated wrap, that is the target as you suggest >>>> via modulo the difference from current value. Don't know if >>>> anybody took the doc literally .. >>>> >>>> -- Jeanette >>>> >>>> Zitat von Ajit Ghaisas : >>>> >>>>> Hi, >>>>> >>>>> ? Once I fix JDK-8193286, I would like to take up JDK-8242553 >>>>> (IntegerSpinner does not wrap around values correctly if >>>>> amountToStepBy is larger than total numbers between Max and Min) >>>>> >>>>> ? The current implementation is not as per what is documented. >>>>> ? Refer : >>>>> https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>>>> >>>>> ? I propose to fix the current buggy behavior of IntegerSpinner. >>>>> ? Although it is a corner case, I would like to know if anybody >>>>> relies on this buggy behavior? >>>>> >>>>> Regards, >>>>> Ajit >>>> >>>> >>>> >> >> >> From mike at plan99.net Tue Apr 21 11:30:21 2020 From: mike at plan99.net (Mike Hearn) Date: Tue, 21 Apr 2020 04:30:21 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com> <92c5463c-abef-5955-8944-fa35320245f6@jugs.org> <75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org> <326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com> Message-ID: Maybe openjfx.io needs more maintainers? I opened a PR against that repo some days ago and it's not been looked at. The JavaFX docs are certainly a weak point right now, given that the Java 8 era docs aren't really being maintained, and aren't open source, and the main docsite isn't really actively worked on either. On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges wrote: > One thing I do miss in openjfx.io website in terms of documentation is > the definition of a jmods file and the sdk. > > For new developers looking at the download page, it's really not simple to > figure it out. > > On Mon, Apr 20, 2020, 15:55 Kevin Rushforth > wrote: > > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > modules are, in fact modules. While it would likely be technically possible > to find them all, and make modifications that will allow running JavaFX > either on the classpath or on the module path, I am not in favor of that. I > think it would be a step backwards. For one thing, we would lose the > encapsulation that the module system provides, and applications would be > able to access internal packages without so much as a warning that it's not > public API. Also it would increase the testing burden, since that would be > one more mode in which it would need to be tested to ensure that it doesn't > break. > > I tend to agree with those who say that this is mostly a documentation > issue. I suppose it's also a bit of a tooling problem, since first class > support for modules is still in progress in various IDEs and build tools > (gradle, maven, etc). The support in the IDEs is pretty good now, and > gradle 6.4 reportedly has full support for modules. Someone with more > familiarity with Maven can comment about their module support. > > -- Kevin > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > Oh I see. You are obviously not familiar with the fact that the JDK has a > built-in test > which checks whether the JavaFX graphics module is on the module path when > you > try to launch an application main class which is derived from the JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs cannot > be launched > completely on the classpath and that's where all the trouble starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice and > easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies with > the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time since > JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > I'm a bit confused here. if you don't want JPMS then you should be able to > run everything on the classpath like normal. Netbeans at least doesn't > force modules wtih Maven. Or is reflection disabled on classpath as of Java > 9 too unless you have a module-info? > > Michael > > Am 18.04.20 um 12:58 schrieb Ty Young: > > On 4/18/20 5:01 AM, Michael Paus wrote: > > Getting started with JavaFX is made overly complicated by the fact that > the use of the > module system is enforced by some code in the JDK. Especially for > beginners, who just > want to get some small program running, this is almost always a big source > of frustration. > It is not very good marketing for JavaFX to make these initial steps such > a pain. If you > need some evidence for this statement, then just follow JavaFX on > Stackoverflow or similar > sites (and also this mailing list). Almost every day you can read > frustrated posts from > helpless people who would just like to get some JavaFX project running but > are failing > because they get lost in the module system jungle. > > Speaking as a long time JavaFX user(literally since Java 8), I have mostly > disagree that the JPMS is hurting JavaFX. > > That said, I don't think the frustration is misplaced. What you say is > true(Netbeans mailing list is fill of JavaFX issues) and the end user is > *NOT* to be blamed here. > > Rather, I think what's to blame is poor documentation, JavaFX requiring > absurd runtime module VM arguments, and poor/buggy IDE support. > > Starting with documentation, JavaFX uses reflection for things like > TableView(everyone's favorite) and CSS style sheets. While this may be > obvious for people who are more experienced, those who are not may be very > confused when they get an onslaught of error messages regarding reflection. > Better documentation on what requires reflection, why, and how to enable it > would be useful. > > Likewise, the notice about having to include javafx.graphics to the > runtime module arguments here: > > https://openjfx.io/openjfx-docs/#IDE-NetBeans > > Apply to Maven as well, but it's under Ant for some reason. I don't know > what was changed in JavaFX 14 that now suddenly requires a runtime VM > argument, but it's a PITA and BS. End users are going to struggle with > this, and it prevents JavaFX runtime from being purely managed by Maven. No > other JavaFX version requires this, so it's mind boggling that all of a > sudden JavaFX needs this. > > Poor/buggy IDE support is really the big one here. I don't know about > other IDEs but Netbeans DOES NOT provide a project template for creating a > JavaFX application with setup dependencies. Netbeans, when setup with a > Maven project, allows you to select an entire project(pom) rather than the > individual dependencies(jar) which doesn't work. What you search for also > matters: if you search for "JavaFX" you will get the wrong search results. > You need to search for "openjfx" which can be confusing. > > Anyway, yeah, it's a PITA. There is also an issue with Ant based projects > and Netbeans because JavaFX puts its src.zip in a folder that is supposed > to only include the runtime library that has existed for years(literally a > 1 line fix too). No one really uses Ant anymore so it's probably not a big > deal now but yeah, getting JavaFX working hasn't been "include and done" > when it could potentially be that way. > > From Rony.Flatscher at wu.ac.at Tue Apr 21 11:56:03 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 21 Apr 2020 13:56:03 +0200 Subject: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <3e2a3ff5-e2bf-9102-bf5f-c9a7648a50cb@wu.ac.at> Message-ID: <1b9da0de-e3ef-2631-56b4-a3924037ef93@wu.ac.at> Hi Michael, thank you very much for sharing this link, which is very interesting! Reading the limitation section is interesting and also reveals current assumptions of the GraalVM developers that may not meet reality in full, hence making it a little bit cumbersome/difficult to fully support it in use cases that they have not thought of or have not seen a need for (e.g. not invoking finalize() because it got deprecated in Java 9, where the discussions that led to that deprecation annotation were related to stated misuse of finalize() by Java programmers; but in those discussions it also was undisputed that there are use cases where finalize() is actually useful and important, e.g. in native bridges where finalize() gets used to clean-up Java proxies and their non-Java peers; for that reason finalize() was not "deprecated for removal" and should only be deployed, if there is a good reason; removing the invocation of finalize() is just a wrong decision in that context with implications leading to scenarios where GraalVM might be considered to not be usable). However, GraalVM is also a project in motion/development and as long as the ultimate goal is to become fully compatible with Java hopes are that eventually the current shortcomings/restrictions get solved/lifted (but some may prefer to wait until that has happened). In any case it is impressive already that you guys have become able to use GraalVM for allowing JavaFX to run on iOS and Android. Again, thank you very much for your link which helps me a lot to assess that route (and to think about solutions for current problems that may exist in GraalVM in supporting a dynamic language, that needs reflective support and uses JNI). ---rony On 20.04.2020 19:29, Michael Paus wrote: > The Android/iOS work is based on GraalVMs Native Image which has some limitations. > These can be found here: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md > I stumbled over the problem with Method Handles when I tried to integrate some third-party > software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and fixed the problems in > NSMenuFX.) > > Am 20.04.20 um 15:26 schrieb Rony G. Flatscher: >> On 20.04.2020 15:06, Michael Paus wrote: >>> This is deviating quite a bit from the original issue of this thread, isn't it? >>> >>> As a side note: MethodHandles are not supported by GraalVM native image >>> and so this would probably collide with the attempts to get JavaFX running >>> on Android/iOS. >> Would you have some link where there would be a technical overview about how Java and JavaFX support >> gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on >> that platform, ie. is java.lang.reflect available? >> >> ---rony From kcr at openjdk.java.net Tue Apr 21 12:19:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Apr 2020 12:19:11 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: References: Message-ID: On Mon, 20 Apr 2020 12:23:16 GMT, Jeanette Winzenburg wrote: > The issue is that ChoiceBoxSkin > a) doesn't update the text of the label if the value is not contained in the items > b) doesn't respect converter for label text > > Fixed by > - listening to value changes to update the label > - removing ad-hoc updates (not needed), added update on converter change > - passing all label updates through converter > > Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, > so for coveragy, contains also tests that passed before as well as after) @aghaisas @arapte can you review? ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From kcr at openjdk.java.net Tue Apr 21 12:50:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Apr 2020 12:50:54 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 11:41:22 GMT, Kevin Rushforth wrote: >> This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. > > @aghaisas can you review this? @aghaisas can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From kcr at openjdk.java.net Tue Apr 21 12:53:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Apr 2020 12:53:06 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <9MjMro5u1APJ2tdaHk3Mwtq2m8Cg-bOAmCcclrZrs4o=.88aea0b5-c8bd-459d-89a4-27be96af88b8@github.com> Message-ID: On Thu, 2 Apr 2020 17:37:26 GMT, Dalibor Topic wrote: >> https://bugs.openjdk.java.net/browse/JDK-8197991 >> >> The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. >> >> This greatly improves the response when selecting multiple items in ListView and TableView. >> >> However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of >> TreeUtil.getTreeItem (). >> Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) >> >> ListView >> * selectAll: 400_000-> 10_000_000 >> * selectRange: 7_000-> 70_000 >> >> TableView >> * selectAll: 8_000-> 700_000 >> * selectRange: 7_000-> 50_000 >> >> >> You can see performance improvements in the following applications: >> >> >> SelectListViewTest.java >> import javafx.application.Application; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.ListView; >> import javafx.scene.control.SelectionMode; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class SelectListViewTest extends Application { >> final int ROW_COUNT = 70_000; >> // final int ROW_COUNT = 400_000; >> // final int ROW_COUNT = 10_000_000; >> // final int ROW_COUNT = 7_000; >> >> @Override >> public void start(Stage stage) { >> ListView listView = new ListView<>(); >> listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> >> >> ObservableList items = listView.getItems(); >> for(int i=0; i> String rec = String.valueOf(i); >> items.add(rec); >> } >> BorderPane root = new BorderPane(listView); >> Button selectAll = new Button("selectAll"); >> Button clearSelection = new Button("clearSelection"); >> Button selectToStart = new Button("selectToStart"); >> Button selectToEnd = new Button("selectToEnd"); >> Button selectPrevious = new Button("selectPrevious"); >> Button selectNext= new Button("selectNext"); >> >> selectAll.setFocusTraversable(true); >> clearSelection.setFocusTraversable(true); >> selectToStart.setFocusTraversable(true); >> selectToEnd.setFocusTraversable(true); >> selectPrevious.setFocusTraversable(true); >> selectNext.setFocusTraversable(true); >> >> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); >> stage.setScene(new Scene(root, 600, 600)); >> >> selectAll.setOnAction((e)->selectAll(listView)); >> clearSelection.setOnAction((e)->clearSelection(listView)); >> selectToStart.setOnAction((e)->selectToStart(listView)); >> selectToEnd.setOnAction((e)->selectToLast(listView)); >> selectPrevious.setOnAction((e)->selectPrevious(listView)); >> selectNext.setOnAction((e)->selectNext(listView)); >> >> stage.show(); >> } >> >> private void selectAll(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectAll(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void clearSelection(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().clearSelection(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToStart(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToLast(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectPrevious(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectPrevious(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectNext(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectNext(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> public static void main(String[] args) { >> Application.launch(args); >> } >> } >> >> SelectTableViewTest.java >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.SelectionMode; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class SelectTableViewTest extends Application { >> >> final int ROW_COUNT = 700_000; >> // final int ROW_COUNT = 80_000; >> // final int ROW_COUNT = 50_000; >> // final int ROW_COUNT = 8_000; >> final int COL_COUNT = 3; >> >> @Override >> public void start(Stage stage) { >> TableView tableView = new TableView<>(); >> tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); >> >> final ObservableList> columns = tableView.getColumns(); >> for(int i=0; i> TableColumn column = new TableColumn<>("Col"+i); >> final int colIndex=i; >> column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); >> column.setPrefWidth(150); >> columns.add(column); >> } >> >> ObservableList items = tableView.getItems(); >> for(int i=0; i> String[] rec = new String[COL_COUNT]; >> for(int j=0; j> rec[j] = i+":"+j; >> } >> items.add(rec); >> } >> BorderPane root = new BorderPane(tableView); >> Button selectAll = new Button("selectAll"); >> Button clearSelection = new Button("clearSelection"); >> Button selectToStart = new Button("selectToStart"); >> Button selectToEnd = new Button("selectToEnd"); >> Button selectPrevious = new Button("selectPrevious"); >> Button selectNext= new Button("selectNext"); >> >> selectAll.setFocusTraversable(true); >> clearSelection.setFocusTraversable(true); >> selectToStart.setFocusTraversable(true); >> selectToEnd.setFocusTraversable(true); >> selectPrevious.setFocusTraversable(true); >> selectNext.setFocusTraversable(true); >> >> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); >> stage.setScene(new Scene(root, 600, 600)); >> >> selectAll.setOnAction((e)->selectAll(tableView)); >> clearSelection.setOnAction((e)->clearSelection(tableView)); >> selectToStart.setOnAction((e)->selectToStart(tableView)); >> selectToEnd.setOnAction((e)->selectToLast(tableView)); >> selectPrevious.setOnAction((e)->selectPrevious(tableView)); >> selectNext.setOnAction((e)->selectNext(tableView)); >> >> stage.show(); >> } >> >> private void selectAll(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectAll(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void clearSelection(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().clearSelection(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToStart(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToLast(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), >> tableView.getItems().size()); System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectPrevious(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectPrevious(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectNext(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectNext(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> } > > Hi, > I couldn't find you listed at https://www.oracle.com/technetwork/community/oca-486395.html . Please send me an e-mail > at dalibor.topic at oracle.com with information about your OCA, so that I can look it up. @aghaisas can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From thomas.manz+JFX at gmail.com Tue Apr 21 15:36:32 2020 From: thomas.manz+JFX at gmail.com (thomas.manz+JFX at gmail.com) Date: Tue, 21 Apr 2020 17:36:32 +0200 Subject: JavaFX controls have large size on Raspberry Pi Message-ID: <005401d617f2$a2a8e330$e7faa990$@gmail.com> I debugged this topic already last week and what I saw was that this was still working with release 13 and now in 14 it?s broken. I guess the problem was introduced with the change ?8236448: Remove unused and repair broken Android/Dalvik code? (https://github.com/openjdk/jfx/pull/75) where the file modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java was changed; the function staticScreen_getScreens() now sets width and height in the returned Screen object where before DPI was set: https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfd (line 228) I don?t understand the background of this change but I think this is the root cause why Screen.getMainScreen().getResolutionY() now returns 480 (pixel) instead of 96 (DPI) on the Raspberry Pi resulting in a default font size of 80 instead of 16 for all(!) controls. Best regards, Thomas Von: Thomas Manz [mailto:thomas.manz+JFX at gmail.com] Gesendet: Dienstag, 21. April 2020 11:12 An: openjfx-dev at openjdk.java.net Betreff: Re: JavaFX controls have large size on Raspberry Pi ---------- Forwarded message ---------- From: Kevin Rushforth To: openjfx-dev at openjdk.java.net Cc: Bcc: Date: Mon, 20 Apr 2020 13:56:44 -0700 Subject: Re: JavaFX controls have large size on Raspberry Pi Another thing to check is that the reported DPI of the screen is correct. -- Kevin On 4/20/2020 1:25 PM, David Grieve wrote: > The sizes of controls are controlled by CSS styles. Things like borders, backgrounds, padding, insets, all of > that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning they are relative to the size > of the font. JavaFX CSS will use the Font.getDefault() font size if there is no font explicitly set in either the > styles or in the application code. > > I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. > It could also be an issue with the default stylesheets themselves. > > -----Original Message----- > From: openjfx-dev On Behalf Of Alexander Scherbatiy > Sent: Monday, April 20, 2020 2:16 PM > To: openjfx-dev at openjdk.java.net > Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi > > Hello, > > I run a simple JavaFX application which shows a button with jdk 14.0.1 on Raspberry Pi and the drawn button has large size. > > This is because of the algorithm which is used by > PrismFontFactory.getSystemFontSize() method [1] to select a system font size. > If a system is embedded then the font size is calculated as > > int screenDPI = Screen.getMainScreen().getResolutionY(); > systemFontSize = ((float) screenDPI) / 6f; // 12 points > > and the system is detected as embedded because the armv6hf architecture is defined as embedded in the armv6hf.gradle file [2]. > > Raspberri Pi can work both with small touch displays and with big monitors. It looks like Raspberry Pi should support two modes for font size calculation: one for small screens and another for large. > > I would like to contribute a fix for this but I do not know how the right fix could look like. > Should there be a special screen size so for smaller screens the font is is proportional to the screen size and for bigger screens the font size is fixed? > Is there a way to check that used screen is from embedded device? > May be it should be solved in different way? > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944 &data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 > [2] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182 &data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 > > JavaFX application: > ---------------------------- > import javafx.application.Application; > import javafx.event.ActionEvent; > import javafx.event.EventHandler; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.StackPane; > import javafx.stage.Stage; > > public class ButtonFX extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) { > primaryStage.setTitle("Hello World!"); > Button button = new Button("Hello, World!"); > > StackPane root = new StackPane(); > root.getChildren().add(button); > primaryStage.setScene(new Scene(root, 300, 250)); > primaryStage.show(); > } > } > ---------------------------- > > Thanks, > Alexander. > > ---------- Forwarded message ---------- From: Philip Race To: Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Bcc: Date: Mon, 20 Apr 2020 14:18:37 -0700 Subject: Re: JavaFX controls have large size on Raspberry Pi > I would start by looking at what Font.getDefault().getSize() returns since everything should be based off that. I think the code below is the code that decides what the code above should return > Another thing to check is that the reported DPI of the screen is correct. The way I read the code below is that it wants the default font to be 1/6 of an inch high on the screen. I think any smaller than 6 lines per inch and it will be hard to read. To do this correctly, it relies on the y-res being accurate for the device. So I would follow the path Kevin suggests. For example if something is wrongly returning the *dimension* of the screen when it should be the *dpi* of the screen then you'd have 6 lines of text filling up the screen. -phil. On 4/20/20, 1:56 PM, Kevin Rushforth wrote: > Another thing to check is that the reported DPI of the screen is correct. > > -- Kevin > > > On 4/20/2020 1:25 PM, David Grieve wrote: >> The sizes of controls are controlled by CSS styles. Things like >> borders, backgrounds, padding, insets, all of >> that defaults to the styles in a stylesheet. Most sizes are 'em' >> units, meaning they are relative to the size >> of the font. JavaFX CSS will use the Font.getDefault() font size if >> there is no font explicitly set in either the >> styles or in the application code. >> >> I would start by looking at what Font.getDefault().getSize() returns >> since everything should be based off that. >> It could also be an issue with the default stylesheets themselves. >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Alexander Scherbatiy >> Sent: Monday, April 20, 2020 2:16 PM >> To: openjfx-dev at openjdk.java.net >> Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi >> >> Hello, >> >> I run a simple JavaFX application which shows a button with jdk >> 14.0.1 on Raspberry Pi and the drawn button has large size. >> >> This is because of the algorithm which is used by >> PrismFontFactory.getSystemFontSize() method [1] to select a system >> font size. >> If a system is embedded then the font size is calculated as >> >> int screenDPI = Screen.getMainScreen().getResolutionY(); >> systemFontSize = ((float) screenDPI) / 6f; // 12 points >> >> and the system is detected as embedded because the armv6hf >> architecture is defined as embedded in the armv6hf.gradle file [2]. >> >> Raspberri Pi can work both with small touch displays and with big >> monitors. It looks like Raspberry Pi should support two modes for >> font size calculation: one for small screens and another for large. >> >> I would like to contribute a fix for this but I do not know how the >> right fix could look like. >> Should there be a special screen size so for smaller screens the font >> is is proportional to the screen size and for bigger screens the font >> size is fixed? >> Is there a way to check that used screen is from embedded device? >> May be it should be solved in different way? >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944 &data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 >> >> [2] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182 &data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 >> >> >> JavaFX application: >> ---------------------------- >> import javafx.application.Application; >> import javafx.event.ActionEvent; >> import javafx.event.EventHandler; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.layout.StackPane; >> import javafx.stage.Stage; >> >> public class ButtonFX extends Application { >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) { >> primaryStage.setTitle("Hello World!"); >> Button button = new Button("Hello, World!"); >> >> StackPane root = new StackPane(); >> root.getChildren().add(button); >> primaryStage.setScene(new Scene(root, 300, 250)); >> primaryStage.show(); >> } >> } >> ---------------------------- >> >> Thanks, >> Alexander. >> >> From ebresie at gmail.com Tue Apr 21 15:49:19 2020 From: ebresie at gmail.com (Eric Bresie) Date: Tue, 21 Apr 2020 10:49:19 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: CANEZrP1nUWDxKxh5sRkZ5-KkGcu2vfGHuPYH5_XMsmfF6NdAxA@mail.gmail.com References: 9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org 3cfc87a3-6c76-a281-8f5b-fdeacabc55ca@gmail.com 92c5463c-abef-5955-8944-fa35320245f6@jugs.org ba83efbc-a8e8-c198-319b-49840ffd6468@gmail.com 75c0a098-616e-2d2e-a333-8014b679f1f1@jugs.org 326db81b-280c-aa3a-5c02-a9cfc1ba9522@oracle.com CADKGCne3oFte6Ddpp_rj_mixOgDY9uhRYqs+FY1qbS1_8R49Ug@mail.gmail.com CADKGCne3oFte6Ddpp_rj_mixOgDY9uhRYqs+FY1qbS1_8R49Ug@mail.gmail.com Message-ID: <5f4e25af-d5b3-4f28-b5fa-827338ffb34b@Erics-iPhone-X> Thought I would provide a few references (1,2,3,4,5) on JPMS over time with a few pros and cons embedded within them . Maybe some will be of help. (1) https://blog.joda.org/2018/03/jpms-negative-benefits.html?m=1 (2) https://jaxenter.com/java-9-modules-jpms-basics-135885.html (3) http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html (4) https://stackoverflow.com/questions/45655210/benefits-of-jpms-project-jigsaw-for-small-applications-libraries (5) https://www.javaworld.com/article/2878952/modularity-in-java-9.html Eric Bresie Ebresie at gmail.com > On April 21, 2020 at 6:30:21 AM CDT, Mike Hearn wrote: > Maybe openjfx.io needs more maintainers? I opened a PR against that repo > some days ago and it's not been looked at. The JavaFX docs are certainly a > weak point right now, given that the Java 8 era docs aren't really being > maintained, and aren't open source, and the main docsite isn't really > actively worked on either. > > > > On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges > wrote: > > > One thing I do miss in openjfx.io website in terms of documentation is > > the definition of a jmods file and the sdk. > > > > For new developers looking at the download page, it's really not simple to > > figure it out. > > > > On Mon, Apr 20, 2020, 15:55 Kevin Rushforth > > wrote: > > > > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > > modules are, in fact modules. While it would likely be technically possible > > to find them all, and make modifications that will allow running JavaFX > > either on the classpath or on the module path, I am not in favor of that. I > > think it would be a step backwards. For one thing, we would lose the > > encapsulation that the module system provides, and applications would be > > able to access internal packages without so much as a warning that it's not > > public API. Also it would increase the testing burden, since that would be > > one more mode in which it would need to be tested to ensure that it doesn't > > break. > > > > I tend to agree with those who say that this is mostly a documentation > > issue. I suppose it's also a bit of a tooling problem, since first class > > support for modules is still in progress in various IDEs and build tools > > (gradle, maven, etc). The support in the IDEs is pretty good now, and > > gradle 6.4 reportedly has full support for modules. Someone with more > > familiarity with Maven can comment about their module support. > > > > -- Kevin > > > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > > > Oh I see. You are obviously not familiar with the fact that the JDK has a > > built-in test > > which checks whether the JavaFX graphics module is on the module path when > > you > > try to launch an application main class which is derived from the JavaFX > > Application class. > > If you try this and the graphics module is not on the module path the > > launch will fail > > with an error message. That's the only reason why JavaFX programs cannot > > be launched > > completely on the classpath and that's where all the trouble starts. If > > you circumvent this > > test with the trick, I have mentioned before, everything becomes nice and > > easy. > > > > So for me there are only two questions. > > 1. Is there any proof of a technical reason why JavaFX could not run > > correctly on the classpath? > > 2. If there is no such reason, then why do we torture all the newbies with > > the "intricacies" of the > > module system instead of just removing this barrier? > > > > As I said before, I have not found any such problem in all the time since > > JavaFX was separated > > from the JDK, so this test seems to be quite artificial to me but of > > course I may be wrong. That's > > why I asked here. > > > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be able to > > run everything on the classpath like normal. Netbeans at least doesn't > > force modules wtih Maven. Or is reflection disabled on classpath as of Java > > 9 too unless you have a module-info? > > > > Michael > > > > Am 18.04.20 um 12:58 schrieb Ty Young: > > > > On 4/18/20 5:01 AM, Michael Paus wrote: > > > > Getting started with JavaFX is made overly complicated by the fact that > > the use of the > > module system is enforced by some code in the JDK. Especially for > > beginners, who just > > want to get some small program running, this is almost always a big source > > of frustration. > > It is not very good marketing for JavaFX to make these initial steps such > > a pain. If you > > need some evidence for this statement, then just follow JavaFX on > > Stackoverflow or similar > > sites (and also this mailing list). Almost every day you can read > > frustrated posts from > > helpless people who would just like to get some JavaFX project running but > > are failing > > because they get lost in the module system jungle. > > > > Speaking as a long time JavaFX user(literally since Java 8), I have mostly > > disagree that the JPMS is hurting JavaFX. > > > > That said, I don't think the frustration is misplaced. What you say is > > true(Netbeans mailing list is fill of JavaFX issues) and the end user is > > *NOT* to be blamed here. > > > > Rather, I think what's to blame is poor documentation, JavaFX requiring > > absurd runtime module VM arguments, and poor/buggy IDE support. > > > > Starting with documentation, JavaFX uses reflection for things like > > TableView(everyone's favorite) and CSS style sheets. While this may be > > obvious for people who are more experienced, those who are not may be very > > confused when they get an onslaught of error messages regarding reflection. > > Better documentation on what requires reflection, why, and how to enable it > > would be useful. > > > > Likewise, the notice about having to include javafx.graphics to the > > runtime module arguments here: > > > > https://openjfx.io/openjfx-docs/#IDE-NetBeans > > > > Apply to Maven as well, but it's under Ant for some reason. I don't know > > what was changed in JavaFX 14 that now suddenly requires a runtime VM > > argument, but it's a PITA and BS. End users are going to struggle with > > this, and it prevents JavaFX runtime from being purely managed by Maven. No > > other JavaFX version requires this, so it's mind boggling that all of a > > sudden JavaFX needs this. > > > > Poor/buggy IDE support is really the big one here. I don't know about > > other IDEs but Netbeans DOES NOT provide a project template for creating a > > JavaFX application with setup dependencies. Netbeans, when setup with a > > Maven project, allows you to select an entire project(pom) rather than the > > individual dependencies(jar) which doesn't work. What you search for also > > matters: if you search for "JavaFX" you will get the wrong search results. > > You need to search for "openjfx" which can be confusing. > > > > Anyway, yeah, it's a PITA. There is also an issue with Ant based projects > > and Netbeans because JavaFX puts its src.zip in a folder that is supposed > > to only include the runtime library that has existed for years(literally a > > 1 line fix too). No one really uses Ant anymore so it's probably not a big > > deal now but yeah, getting JavaFX working hasn't been "include and done" > > when it could potentially be that way. > > > > From github.com+4208131+bhaweshkc at openjdk.java.net Tue Apr 21 16:34:11 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 21 Apr 2020 16:34:11 GMT Subject: [Rev 02] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. Bhawesh Choudhary has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: added unit test for jdk-8191758 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/180/files - new: https://git.openjdk.java.net/jfx/pull/180/files/43c7cbf1..f6fb1075 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/180/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/180/webrev.01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/180/head:pull/180 PR: https://git.openjdk.java.net/jfx/pull/180 From alexsch at openjdk.java.net Tue Apr 21 16:56:12 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 21 Apr 2020 16:56:12 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi Message-ID: See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) method code from > ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() to > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" so the font size is not properly calculated based on the given DPI value. I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app works in the same way. ------------- Commit messages: - 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi Changes: https://git.openjdk.java.net/jfx/pull/193/files Webrev: https://webrevs.openjdk.java.net/jfx/193/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243255 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/193/head:pull/193 PR: https://git.openjdk.java.net/jfx/pull/193 From steve at weblite.ca Tue Apr 21 17:48:43 2020 From: steve at weblite.ca (Steve Hannah) Date: Tue, 21 Apr 2020 10:48:43 -0700 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <5f4e25af-d5b3-4f28-b5fa-827338ffb34b@Erics-iPhone-X> References: <5f4e25af-d5b3-4f28-b5fa-827338ffb34b@Erics-iPhone-X> Message-ID: Personally, the lack of a "just add these jars to your classpath" install option is a big enough pain point that I avoid dependence on JavaFX as much as possible. Many of the things I develop are distributed as jar files and the requirements are (JDK8+). If I use JavaFX the requirements change to either ZuluFX8+, or JDK8+ PLUS appropriate JavaFX distribution for your version of OS/JDK combination. I've had to develop elaborate bootstrap systems to detect the OS/JDK version, and download the correct version of JavaFX for the platform before launch... but these are hacky and painful. And I'm regularly looking for options to purge the remaining JavaFX dependencies so I don't need to do this anymore. I know my use case is not the same as everyone else's (I make developer tools mostly), but thought I'd throw that in here in case it resonates with others. On Tue, Apr 21, 2020 at 8:50 AM Eric Bresie wrote: > > Thought I would provide a few references (1,2,3,4,5) on JPMS over time > with a few pros and cons embedded within them . > > Maybe some will be of help. > > (1) https://blog.joda.org/2018/03/jpms-negative-benefits.html?m=1 > > (2) https://jaxenter.com/java-9-modules-jpms-basics-135885.html > > (3) > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html > > (4) > https://stackoverflow.com/questions/45655210/benefits-of-jpms-project-jigsaw-for-small-applications-libraries > > (5) https://www.javaworld.com/article/2878952/modularity-in-java-9.html > > Eric Bresie > Ebresie at gmail.com > > On April 21, 2020 at 6:30:21 AM CDT, Mike Hearn wrote: > > Maybe openjfx.io needs more maintainers? I opened a PR against that repo > > some days ago and it's not been looked at. The JavaFX docs are certainly > a > > weak point right now, given that the Java 8 era docs aren't really being > > maintained, and aren't open source, and the main docsite isn't really > > actively worked on either. > > > > > > > > On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges > > wrote: > > > > > One thing I do miss in openjfx.io website in terms of documentation is > > > the definition of a jmods file and the sdk. > > > > > > For new developers looking at the download page, it's really not > simple to > > > figure it out. > > > > > > On Mon, Apr 20, 2020, 15:55 Kevin Rushforth < > kevin.rushforth at oracle.com> > > > wrote: > > > > > > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > > > modules are, in fact modules. While it would likely be technically > possible > > > to find them all, and make modifications that will allow running JavaFX > > > either on the classpath or on the module path, I am not in favor of > that. I > > > think it would be a step backwards. For one thing, we would lose the > > > encapsulation that the module system provides, and applications would > be > > > able to access internal packages without so much as a warning that > it's not > > > public API. Also it would increase the testing burden, since that > would be > > > one more mode in which it would need to be tested to ensure that it > doesn't > > > break. > > > > > > I tend to agree with those who say that this is mostly a documentation > > > issue. I suppose it's also a bit of a tooling problem, since first > class > > > support for modules is still in progress in various IDEs and build > tools > > > (gradle, maven, etc). The support in the IDEs is pretty good now, and > > > gradle 6.4 reportedly has full support for modules. Someone with more > > > familiarity with Maven can comment about their module support. > > > > > > -- Kevin > > > > > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > > > > > Oh I see. You are obviously not familiar with the fact that the JDK > has a > > > built-in test > > > which checks whether the JavaFX graphics module is on the module path > when > > > you > > > try to launch an application main class which is derived from the > JavaFX > > > Application class. > > > If you try this and the graphics module is not on the module path the > > > launch will fail > > > with an error message. That's the only reason why JavaFX programs > cannot > > > be launched > > > completely on the classpath and that's where all the trouble starts. If > > > you circumvent this > > > test with the trick, I have mentioned before, everything becomes nice > and > > > easy. > > > > > > So for me there are only two questions. > > > 1. Is there any proof of a technical reason why JavaFX could not run > > > correctly on the classpath? > > > 2. If there is no such reason, then why do we torture all the newbies > with > > > the "intricacies" of the > > > module system instead of just removing this barrier? > > > > > > As I said before, I have not found any such problem in all the time > since > > > JavaFX was separated > > > from the JDK, so this test seems to be quite artificial to me but of > > > course I may be wrong. That's > > > why I asked here. > > > > > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > > > I'm a bit confused here. if you don't want JPMS then you should be > able to > > > run everything on the classpath like normal. Netbeans at least doesn't > > > force modules wtih Maven. Or is reflection disabled on classpath as of > Java > > > 9 too unless you have a module-info? > > > > > > Michael > > > > > > Am 18.04.20 um 12:58 schrieb Ty Young: > > > > > > On 4/18/20 5:01 AM, Michael Paus wrote: > > > > > > Getting started with JavaFX is made overly complicated by the fact that > > > the use of the > > > module system is enforced by some code in the JDK. Especially for > > > beginners, who just > > > want to get some small program running, this is almost always a big > source > > > of frustration. > > > It is not very good marketing for JavaFX to make these initial steps > such > > > a pain. If you > > > need some evidence for this statement, then just follow JavaFX on > > > Stackoverflow or similar > > > sites (and also this mailing list). Almost every day you can read > > > frustrated posts from > > > helpless people who would just like to get some JavaFX project running > but > > > are failing > > > because they get lost in the module system jungle. > > > > > > Speaking as a long time JavaFX user(literally since Java 8), I have > mostly > > > disagree that the JPMS is hurting JavaFX. > > > > > > That said, I don't think the frustration is misplaced. What you say is > > > true(Netbeans mailing list is fill of JavaFX issues) and the end user > is > > > *NOT* to be blamed here. > > > > > > Rather, I think what's to blame is poor documentation, JavaFX requiring > > > absurd runtime module VM arguments, and poor/buggy IDE support. > > > > > > Starting with documentation, JavaFX uses reflection for things like > > > TableView(everyone's favorite) and CSS style sheets. While this may be > > > obvious for people who are more experienced, those who are not may be > very > > > confused when they get an onslaught of error messages regarding > reflection. > > > Better documentation on what requires reflection, why, and how to > enable it > > > would be useful. > > > > > > Likewise, the notice about having to include javafx.graphics to the > > > runtime module arguments here: > > > > > > https://openjfx.io/openjfx-docs/#IDE-NetBeans > > > > > > Apply to Maven as well, but it's under Ant for some reason. I don't > know > > > what was changed in JavaFX 14 that now suddenly requires a runtime VM > > > argument, but it's a PITA and BS. End users are going to struggle with > > > this, and it prevents JavaFX runtime from being purely managed by > Maven. No > > > other JavaFX version requires this, so it's mind boggling that all of a > > > sudden JavaFX needs this. > > > > > > Poor/buggy IDE support is really the big one here. I don't know about > > > other IDEs but Netbeans DOES NOT provide a project template for > creating a > > > JavaFX application with setup dependencies. Netbeans, when setup with a > > > Maven project, allows you to select an entire project(pom) rather than > the > > > individual dependencies(jar) which doesn't work. What you search for > also > > > matters: if you search for "JavaFX" you will get the wrong search > results. > > > You need to search for "openjfx" which can be confusing. > > > > > > Anyway, yeah, it's a PITA. There is also an issue with Ant based > projects > > > and Netbeans because JavaFX puts its src.zip in a folder that is > supposed > > > to only include the runtime library that has existed for > years(literally a > > > 1 line fix too). No one really uses Ant anymore so it's probably not a > big > > > deal now but yeah, getting JavaFX working hasn't been "include and > done" > > > when it could potentially be that way. > > > > > > > -- Steve Hannah Web Lite Solutions Corp. From github.com+4208131+bhaweshkc at openjdk.java.net Tue Apr 21 18:08:09 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 21 Apr 2020 18:08:09 GMT Subject: RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: <0DP4RK9VivwtnXIldwdRzbT-ywX4zvIsXTE7dbJvhc4=.2a1e2493-7fde-43b4-9d48-1cb440389fc7@github.com> On Fri, 17 Apr 2020 18:06:06 GMT, Phil Race wrote: >> Can you add a unit test to go along with this fix? > > Per the opentype spec, 700 is bold. 600 is semi-bold > https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass > > CSS agrees : https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight > > So are you saying webkit has been using bold at a lower weight than these specs suggest ? > I see the logic all comes from Source/WebCore/platform/graphics/FontSelectionAlgorithm.h > > I suppose the existing code thinks that if we have reached what that file calls the bold threshold of 600 then we > should use bold. It isn't necessarily "wrong" but I think I agree that it is more important to be consistent with the > rest of Java FX ... which I believe is the point of this change ? @prrace yes, webkit is set to use 600 weight where javafx consider 700 weight for it to be consider bold. https://docs.oracle.com/javafx/2/api/javafx/scene/text/FontWeight.html ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From kcr at openjdk.java.net Tue Apr 21 23:36:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Apr 2020 23:36:18 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: Message-ID: <451hmsCrm-8sojurEtP8rK3z64iKDT46gZpDRMryzxQ=.0822d67c-83e5-45c3-9e3a-e2bf6f1ad12c@github.com> On Mon, 13 Apr 2020 06:59:08 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 > > Root Cause : > Incorrect implementation. > Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. > Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. > > Fix : > Added a method for IntegerSpinnerValueFactory with separate implementation. > > Testing : > Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. > > Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed > separately. I checked and there is a case that (mostly) works today that will break with your proposed fix. I left a couple inline comments. I wonder if it is better to wait and fix it completely in [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). modules/javafx.controls/src/main/java/javafx/scene/control/Spinner.java line 793: > 792: */ > 793: static int wrapValue(int value, int min, int max, boolean wrapUp) { > 794: int ret = 0; This is essentially a throw-away function. While it does handle the specific case in the bug, namely that of incrementing or decrementing a positive number of steps of an `amountToStepBy` that is also positive as long as `currentVal + nsteps * amountToStepBy <= `2 * max`. It does it by taking a boolean parameter and doing a simple subtractions, which is not how it eventually needs to be fixed. It won't handle the case of wrapping around by more than `max-min+1` nor will it handle the case of wrapping around with a negative `amountToStepBy`. Also, I did find one case where it will yield differently incorrect behavior from today. in the case where min = 0, and you step by an amount that puts the new value at `newValue > 2 * max` the old code would at least compute an almost-correct value using `newVal % max`. The new code will cause it to be clamped at max. modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 581: > 580: final int newIndex = getValue() - steps * getAmountToStepBy(); > 581: setValue(newIndex >= min ? newIndex : (isWrapAround() ? Spinner.wrapValue(newIndex, min, max, false) : > min)); 582: } This will eventually need a new wrapValue function that doesn't take a boolean parameter. The existing one is broken, but passing a boolean isn't the right answer, either. modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 395: > 394: // TODO : This should wrap around and select a value between min and max > 395: @Test public void intSpinner_testWrapAround_increment_LargeStep() { > 396: intValueFactory.setWrapAround(true); I don't like the testing for known buggy behavior. If a partial fix is still planned, a better thing would be a test that verifies correct behavior that is `@Ignore`d pending the final fix. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/174 From kcr at openjdk.java.net Tue Apr 21 23:58:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Apr 2020 23:58:12 GMT Subject: RFR: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine In-Reply-To: References: Message-ID: On Sun, 19 Apr 2020 08:12:07 GMT, Abhinay Agarwal wrote: > Update WebEngine's Javadoc to add information on how it switches to HttpClient instead of URLConnection in JavaFX 14 > when used with JDK 12 or later. > Identification the correct client is important as both these clients may offer different ways to achieve a task. One > such task can be bypassing insecure HTTPS connection. This looks good to me. I'd also like @guruhb to take a look. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/189 From kcr at openjdk.java.net Wed Apr 22 00:01:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 00:01:03 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 09:34:00 GMT, Jesper Skov wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java line 196: >> >>> 195: private ObjectProperty toggleGroup; >>> 196: @Override >>> 197: public final void setToggleGroup(ToggleGroup value) { >> >> This is unrelated to the fix. The changes in this file should be reverted. > > OK. They are gone. > > Would this (keeping the changes very specific to the bug?) be worth mentioning in CONTRIBUTING.md? > That is, like the note about imports: do not fix warnings that are not directly related to the issue? Good idea. I'll add that to my growing list of things to improve in CONTRIBUTING.md. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Wed Apr 22 00:19:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 00:19:07 GMT Subject: RFR: 8241582: Infinite animation does not start from the end when started with a negative rate In-Reply-To: References: Message-ID: <6QuleeSBmh5QxrdAEWBxiq0xlVBjMTODweC4UmpFmyY=.31dba230-e692-4727-9b96-a63423571779@github.com> On Fri, 10 Apr 2020 06:31:39 GMT, Nir Lisker wrote: > ### Cause > > `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly. This causes > `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start the animation not from the end, depending > on the modulo calculation. ### Fix > > For infinite cycles, use the `cycleDuration` as the destination since that is the effective end point. > > ### Tests > > * Added an `testJumpTo_IndefiniteCycles` test that fails without the patch and passes after it. > * Added a `testJumpTo_IndefiniteCycleDuration` that passes both before and after, just to make sure that this type of > infinite duration is correct. > * Removed a test in `SequentialTransition` that fails with this patch, but it passed before it only because the modulo > value happened to land in the right place. Changing the duration of one of the child animation can cause it to fail, so > the test is faulty anyway at this stage. > > ### Future work > > Playing backwards will still not work correctly, but at least now it start from the correct value. This is the first of > a series of fixes under the umbrella issue [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238). Looks good. I left a question about one of the tests (for my own curiosity), but I'm approving it anyway. modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationTest.java line 271: > 270: animation.jumpTo("end"); > 271: assertEquals(Duration.millis(Long.MAX_VALUE / 6), animation.getCurrentTime()); > 272: } Why `/ 6` ? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/169 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Apr 22 06:45:42 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 22 Apr 2020 06:45:42 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Sat, 11 Apr 2020 09:53:46 GMT, Ambarish Rapte wrote: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Hi @arapte, Great work on the PR ?? Don't you think that all the changes in `ListViewSkin` can be moved to `ListViewBehavior`? All that we do in the skin class is to call `ListViewBehavior#updateSelectionModeKeyMapping`, which smells like feature envy. Moreover, `ListViewBehavior` already has change listener attached to `selectionModelProperty`, waiting for us to re-use it ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From apurwaagr at gmail.com Wed Apr 22 08:36:55 2020 From: apurwaagr at gmail.com (Apurwa Agrawal) Date: Wed, 22 Apr 2020 14:06:55 +0530 Subject: Scene Builder Support for javafx 14 Message-ID: Is Scene Builder not supported by Javafx 14? I tried downloading the latest version of Scene Builder but its not compatible with javafx. Thanks and Regards Apurwa Agrawal From fastegal at openjdk.java.net Wed Apr 22 09:08:18 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 22 Apr 2020 09:08:18 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: <451hmsCrm-8sojurEtP8rK3z64iKDT46gZpDRMryzxQ=.0822d67c-83e5-45c3-9e3a-e2bf6f1ad12c@github.com> References: <451hmsCrm-8sojurEtP8rK3z64iKDT46gZpDRMryzxQ=.0822d67c-83e5-45c3-9e3a-e2bf6f1ad12c@github.com> Message-ID: On Tue, 21 Apr 2020 23:34:07 GMT, Kevin Rushforth wrote: > > I wonder if it is better to wait and fix it completely in > [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). good idea - do it correctly once and for all :) ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From fkirmaier at openjdk.java.net Wed Apr 22 10:55:29 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 10:55:29 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 18:56:21 GMT, Ambarish Rapte wrote: >> This version doesn't work for me. >> With this change, I get the following error: >> test.javafx.stage.FocusedWindowTest > testLeak FAILED >> junit.framework.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at test.util.Util.runAndWait(Util.java:163) >> at test.util.Util.runAndWait(Util.java:134) >> at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:82) > > This is happening because after the last stage is closed JavaFX runtime shuts down implicitly unless specified > otherwise using `Platform.setImplicitExit(false);`. So `initFX()` should look as, > ``` > @BeforeClass > public static void initFX() throws Exception { > startupLatch = new CountDownLatch(1); > Platform.startup(startupLatch::countDown); > Platform.setImplicitExit(false); > Assert.assertTrue("Timeout waiting for FX runtime to start", > startupLatch.await(15, TimeUnit.MILLISECONDS)); > } It works now, great! ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Wed Apr 22 10:58:37 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 10:58:37 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> References: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> Message-ID: On Fri, 17 Apr 2020 12:50:50 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> Some code cleanups > > tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 103: > >> 102: assertCollectable(closedFocusedStageWeak); >> 103: } >> 104: > > The current test does not assure that stage is shown when `close()` is called or it is closed when `requestFocus()` is > called, I would recommend the test to be as, > @Test > public void testClosedFocusedStageLeak() throws Exception { > CountDownLatch latch = new CountDownLatch(1); > Util.runAndWait(() -> { > closedFocusedStage = new Stage(); > closedFocusedStage.setTitle("Focused Stage"); > closedFocusedStageWeak = new WeakReference<>(closedFocusedStage); > TextField textField = new TextField(); > closedFocusedStage.setScene(new Scene(textField)); > closedFocusedStage.setOnShown(l -> { > latch.countDown(); > }); > closedFocusedStage.show(); > }); > Assert.assertTrue("Timeout waiting for closedFocusedStage to show`", > latch.await(15, TimeUnit.MILLISECONDS)); > > CountDownLatch hideLatch = new CountDownLatch(1); > closedFocusedStage.setOnHidden(a -> { > hideLatch.countDown(); > }); > Util.runAndWait(() -> closedFocusedStage.close()); > Assert.assertTrue("Timeout waiting for closedFocusedStage to hide`", > hideLatch.await(15, TimeUnit.MILLISECONDS)); > > closedFocusedStage.requestFocus(); > closedFocusedStage = null; > assertCollectable(closedFocusedStageWeak); > } I've changed it accordingly. I've also verified that the new version catches the old leak and works with my suggested changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Wed Apr 22 11:12:59 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 11:12:59 GMT Subject: [Rev 02] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8241840 small cleanup based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/20865db8..59925508 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.01-02 Stats: 36 lines in 1 file changed: 9 ins; 16 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Wed Apr 22 11:29:16 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 11:29:16 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> References: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> Message-ID: On Fri, 17 Apr 2020 12:06:05 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> Some code cleanups > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java line 124: > >> 123: int index = getWindowIndex(window); >> 124: if (index != -1 && window.isVisible()) { >> 125: focusedWindow = window; > > This change is sufficient for the test to pass, are there any other scenarios for which the changes in Window.java are > needed. If so could you please add the relevant tests. You are correct. The change happened, because of the leak for first noticeable in the Window class. I've now removed the change from the Window class because it's not required. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Wed Apr 22 11:29:15 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 11:29:15 GMT Subject: [Rev 03] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8241840 removed change to the window class, because it wasn't required for the fix. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/59925508..d5cb902a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From ajit.ghaisas at oracle.com Wed Apr 22 11:48:00 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 22 Apr 2020 17:18:00 +0530 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <20200421130647.Horde.9OZ6De4A76UMi5Og6Hg7Lg1@webmail.df.eu> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> <20200421130647.Horde.9OZ6De4A76UMi5Og6Hg7Lg1@webmail.df.eu> Message-ID: <6AAD16E5-93C7-4F35-A3C8-D85AEE34413A@oracle.com> Jeanette and Kevin, Thanks for taking a look at this in detail. Regarding DoubleSpinnerValueFactory - The wraparound behavior is incorrect with DoubleSpinnerValueFactory as well. If amountToStepBy is lesser than max-min, once we try to increment from max, we just clamp to min and start incrementing from there. If amountToStepBy is greater than max-min, once we try to increment from max, we clamp it to min - and further increments just keep on calming to min. Regarding ListSpinnerValueFactory - It fares better than other two SpinnerValueFactories - as ListSpinnerValueFactory does not support amountToStepBy in constructor. min is alway 0, and max is (number of items in the list - 1). There is a way to specify number of steps in increment and decrement functions. If we specify this to be more than number of items in the list, modulo calculation is in place to select correct value. Nothing needs to be done for ListSpinnerValueFactory as of now - but it uses common Spinner.wrapValue() method. Need to test it after correcting the modulo logic for IntegerSpinnerValueFactory. What I garnered from this discussion is - below changes need to be made - SpinnerValueFactory: - Update the documentation about the ?circular? way of wrap around behavior to be more explicit - Update the documentation about default value of wraparound property IntegerSpinnerValueFactory: - Fix the wraparound behavior for all valid values (smaller and larger amountToStepBy * no of steps) - The correct way to fix this is to do modulo calculation DoubleSpinnerValueFactory: - Fix the wraparound behavior for all valid values (smaller and larger amountToStepBy* no of steps) - Need to decide what would be the best fit for this as the current implementation is to clamp and again continue from there. One possible options is to mimic the logic (with Double values) to match what we will end up doing for IntegerSpinnerValueFactory. ListSpinnerValueFactory: - Test that it continues to work as it works now after fixing IntegerSpinnerValueFactory. Two questions : 1. Need to decide what would be better way to fix DoubleSpinnerValueFactory wrapAround behavior? 2. Do we really care about negative values in no of steps OR amountToStepBy? I am asking this as we already have separate increment() and decrement() methods. Should we bar such negative values? That?s another behavior change though :) Regards, Ajit > On 21-Apr-2020, at 4:36 PM, Jeanette Winzenburg wrote: > > > part of the confusion might be the reporter's workaround in https://bugs.openjdk.java.net/browse/JDK-8193286 which effectively clamps (doesn't make a difference, having amountPerStep=1 and not incrementing programatically) > > commented that bug with an alternative implemenation and a couple of tests (for the most simple case ;) > > -- Jeanette > > Zitat von Kevin Rushforth : > >> I just took another look at the SpinnerValueFactory API docs. The use of the term "circular" heavily implies modulo arithmetic as the expected behavior if wrapAround is true. That the usual meaning of "wrap" versus "clamp" when you have a range bounded on both ends. Maybe the confusion comes from the fact that it isn't stated as clearly as it might be, coupled with a single example of a step by one going from max to min (if incrementing). I note that example doesn't say what the amountToStepBy is, but it wasn't trying to be prescriptive. >> >> Since the current behavior of "wrap around unless you happen to wrap a bit too much and then we'll clamp" doesn't make sense in any universe that I can think of, it is fine to treat this as a bug. I'm not worried about "bug compatibility" here. >> >> Clarifying the spec at the same time seems like a good idea to me. A related issue is that the default value of wrapAround is not specified (the default is `false`, but you wouldn't know that from reading the docs). This should also be addressed at the same time. >> >> You mentioned that this is specific to IntegerValueFactory, but it looks like DoubleValueFactory (and maybe ListValueFactory) have the same bug. Or am I missing something? >> >> On an unrelated note, I just noticed that the SpinnerValueFactory constructor has no documentation. This is because it is an implicitly added constructor, which is an anti-pattern for public API. I'll file a separate issue for that. >> >> -- Kevin >> >> >> On 4/15/2020 2:23 AM, Jeanette Winzenburg wrote: >>> Hi Ajit, >>> >>> yes, I read the doc, probably a bit differently - could well be my misunderstanding and misunderstandable wording :) >>> >>> Trying again: >>> >>> - I read your suggestion (in https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. that being at value and incrementing a full-cycle (that is max -min +1), I will land on value again >>> - for me the doc seemed to imply that in such a case I would land on min. Though, given the "circular" as you pointed out correctly, was my misunderstanding >>> - the current implementation is buggy (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating the remainder (which is what the first bullet amounts to) incorrectly for min != 0 >>> >>> Where do I err? >>> >>> -- Jeanette >>> >>> >>> Zitat von Ajit Ghaisas : >>> >>>> Hi Jeanette, >>>> >>>> The doc never assumes amountPerStep = 1. I am quoting it here - >>>> ?The wrapAround property is used to specify whether the value factory should be circular. For example, should an integer-based value model increment from the maximum value back to the minimum value (and vice versa).? >>>> >>>> The word ?circular? clarifies that once we exceed maximum value, we should start from minimum. >>>> I think, the doc is OK in it?s current form, but implementation needs to be corrected. >>>> >>>> Regards, >>>> Ajit >>>> >>>> >>>>> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg wrote: >>>>> >>>>> >>>>> Hi Ajit, >>>>> >>>>> thought the doc was simply bad (in specifying the behavior for amountPerStep = 1 and not thinking of larger amounts) - my expection is a calculated wrap, that is the target as you suggest via modulo the difference from current value. Don't know if anybody took the doc literally .. >>>>> >>>>> -- Jeanette >>>>> >>>>> Zitat von Ajit Ghaisas : >>>>> >>>>>> Hi, >>>>>> >>>>>> Once I fix JDK-8193286, I would like to take up JDK-8242553 (IntegerSpinner does not wrap around values correctly if amountToStepBy is larger than total numbers between Max and Min) >>>>>> >>>>>> The current implementation is not as per what is documented. >>>>>> Refer : https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>>>>> >>>>>> I propose to fix the current buggy behavior of IntegerSpinner. >>>>>> Although it is a corner case, I would like to know if anybody relies on this buggy behavior? >>>>>> >>>>>> Regards, >>>>>> Ajit >>>>> >>>>> >>>>> >>> >>> >>> > > > From aghaisas at openjdk.java.net Wed Apr 22 12:02:30 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 22 Apr 2020 12:02:30 GMT Subject: RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: <451hmsCrm-8sojurEtP8rK3z64iKDT46gZpDRMryzxQ=.0822d67c-83e5-45c3-9e3a-e2bf6f1ad12c@github.com> Message-ID: On Wed, 22 Apr 2020 09:06:09 GMT, Jeanette Winzenburg wrote: >> I checked and there is a case that (mostly) works today that will break with your proposed fix. I left a couple inline >> comments. >> I wonder if it is better to wait and fix it completely in >> [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). > >> >> I wonder if it is better to wait and fix it completely in >> [JDK-8242553](https://bugs.openjdk.java.net/browse/JDK-8242553). > > good idea - do it correctly once and for all :) Thanks @kevinrushforth for taking a detailed look at this. I wanted to fix this and then fix the buggy behavior change in JDK-8242553 separately. As my proposed Spinner.wrapValue() does not work well in some cases and it's going to get modified anyway - I guess, you and @kleopatra are right in suggesting to fix it entirely in JDK-8242553. I will close this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From fkirmaier at openjdk.java.net Wed Apr 22 12:03:34 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 12:03:34 GMT Subject: [Rev 04] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8241840 The tests are now reused for native and monocle tests. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/d5cb902a..3f618c11 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.03-04 Stats: 334 lines in 4 files changed: 214 ins; 120 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Wed Apr 22 12:03:45 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Apr 2020 12:03:45 GMT Subject: [Rev 01] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> References: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> Message-ID: On Fri, 17 Apr 2020 12:58:00 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> Some code cleanups > > Changes requested by arapte (Reviewer). I don't think the class MeshManagerCacheLeakTest is a good base to write monocle + native tests. It required input/output parsing which would be a bit too much. In my latest commit, I've added a simple solution to how the test can be reused. On my side, both tests are always green, but I'm using a mac. If one of the tests is unstable on windows, then it would be great if we could consider it as 2 bugs, so this PR can be finished. Afterwards it would be great if someone else could continue the windows-bug because I don't have a very productive setup to work on it and I also don't really understand the native windows code. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From aghaisas at openjdk.java.net Wed Apr 22 12:18:14 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 22 Apr 2020 12:18:14 GMT Subject: [Closed] RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly In-Reply-To: References: Message-ID: On Mon, 13 Apr 2020 06:59:08 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 > > Root Cause : > Incorrect implementation. > Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. > Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. > > Fix : > Added a method for IntegerSpinnerValueFactory with separate implementation. > > Testing : > Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. > > Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed > separately. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/174 From kevin.rushforth at oracle.com Wed Apr 22 12:40:08 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 Apr 2020 05:40:08 -0700 Subject: Proposed IntegerSpinner buggy behavior correction - JDK-8242553 In-Reply-To: <6AAD16E5-93C7-4F35-A3C8-D85AEE34413A@oracle.com> References: <266CDE92-FCF7-4AD3-BE71-5E496ADB129B@oracle.com> <20200414163145.Horde.UOo02NPoh4IaMpZErRw87w1@webmail.df.eu> <9000CB5E-8E49-4AC9-9DA1-0AC55ADA57C6@oracle.com> <20200415112310.Horde.yhc0tAA6ZdYEFAKmj_tU6w1@webmail.df.eu> <926bc2dd-21d6-2eed-c145-e00e9f034348@oracle.com> <20200421130647.Horde.9OZ6De4A76UMi5Og6Hg7Lg1@webmail.df.eu> <6AAD16E5-93C7-4F35-A3C8-D85AEE34413A@oracle.com> Message-ID: Hi Ajit, Thanks for writing this up. I think we are clear on what should happen for IntegerSpinnerValueFactory and ListSpinnerValueFactory. To answer your two questions, I'll take the second one first: > 2. Do we really care about negative values in no of steps OR > amountToStepBy? > I am asking this as we already have separate increment() and > decrement() methods. Should we bar such negative values? That?s > another behavior change though :) Once you switch to a proper modulo function, the easy answer is that negative values will "just work". A negative amountToStepBy might even make sense in some use cases (think of an increasing debt value), so there is no reason not to support it. A negative number of steps doesn't really make sense, since if you want to call increment(-N) you could equivalently call decrement(N), but again, it will "just work" as expected once the wrapping function is fixed. If we were designing from scratch I'd specify that nsteps must be >= 0, but it isn't worth it to make the change now (which would require a CSR) to prohibit it. > 1. Need to decide what would be better way to fix > DoubleSpinnerValueFactory wrapAround behavior? It might be helpful to compare it to the Integer flavor. By definition, IntegerSpinnerValueFactory represents a set of discrete values: min and max are two distinct values, and there is a well-defined ordering when wrapping. If you wrap, it should be a continuous (in both positive and negative directions) list of values like so: min, min+1, min+2, ... max-2, max-1, max, min, min+1, min+2, ... The formula is simple. After incrementing or decrementing by N * amountToStepBy, do the following if wrapAround is true: ??? if (val < min || val > max) val = (val - min) % (max - min + 1) + min; The above works regardless of step size because integers are naturally discrete values. It is well-behaved and natural to consider max and min being 1 apart from each other when wrapping. By contrast, it's harder to know what the right answer is for DoubleSpinnerValueFactory. It's quite possible that in some cases, the app expects the values of DoubleValue factory to also be discrete when it comes to wrapping, meaning that min and max are distinct values such that if your step was 1.0, you might expect to go from max-1.0 to max to min to min+1.0 (although even that definition has problems for non-integer values of amountToStepBy, but it's (mostly) solvable). It's also quite likely for other cases -- especially ones that would lend themselves to wrapAround mode in graphical apps -- where it isn't a set of discrete values, but rather is such that min and max represent the same value (i.e., the same end result). The simplest example is an angle in degrees where 0.0 and 360.0 mean the same thing when used as a rotation angle. In this latter use case, stepping from 359.0 to 360.0 to 0.0 to 1.0 would cause a discontinuous pause in motion if you mapped the output to a rotation angle. I'm not sure what the right answer is, but the latter seems like a valid use case and I would guess at least as common as a "set of discrete values" for doubles. Another thing to consider is that even in what I will call "discrete" mode (no I'm not really proposing that we add a property to control it), you have to take the step size into account; otherwise when the step size is < 0.5 you will get stuck at max when incrementing by 1 amountToStepBy, unless you have special case logic for that. Any thoughts from other developers? -- Kevin On 4/22/2020 4:48 AM, Ajit Ghaisas wrote: > Jeanette and Kevin, > > Thanks for taking a look at this in detail. > > Regarding DoubleSpinnerValueFactory - > The wraparound behavior is incorrect with DoubleSpinnerValueFactory as well. > If amountToStepBy is lesser than max-min, once we try to increment from max, we just clamp to min and start incrementing from there. > If amountToStepBy is greater than max-min, once we try to increment from max, we clamp it to min - and further increments just keep on calming to min. > > Regarding ListSpinnerValueFactory - > It fares better than other two SpinnerValueFactories - as ListSpinnerValueFactory does not support amountToStepBy in constructor. > min is alway 0, and max is (number of items in the list - 1). > There is a way to specify number of steps in increment and decrement functions. If we specify this to be more than number of items in the list, modulo calculation is in place to select correct value. > Nothing needs to be done for ListSpinnerValueFactory as of now - but it uses common Spinner.wrapValue() method. > Need to test it after correcting the modulo logic for IntegerSpinnerValueFactory. > > > What I garnered from this discussion is - below changes need to be made - > > SpinnerValueFactory: > - Update the documentation about the ?circular? way of wrap around behavior to be more explicit > - Update the documentation about default value of wraparound property > > IntegerSpinnerValueFactory: > - Fix the wraparound behavior for all valid values (smaller and larger amountToStepBy * no of steps) - The correct way to fix this is to do modulo calculation > > DoubleSpinnerValueFactory: > - Fix the wraparound behavior for all valid values (smaller and larger amountToStepBy* no of steps) - Need to decide what would be the best fit for this as the current implementation is to clamp and again continue from there. One possible options is to mimic the logic (with Double values) to match what we will end up doing for IntegerSpinnerValueFactory. > > ListSpinnerValueFactory: > - Test that it continues to work as it works now after fixing IntegerSpinnerValueFactory. > > > Two questions : > 1. Need to decide what would be better way to fix DoubleSpinnerValueFactory wrapAround behavior? > 2. Do we really care about negative values in no of steps OR amountToStepBy? > I am asking this as we already have separate increment() and decrement() methods. Should we bar such negative values? That?s another behavior change though :) > > Regards, > Ajit > > >> On 21-Apr-2020, at 4:36 PM, Jeanette Winzenburg wrote: >> >> >> part of the confusion might be the reporter's workaround in https://bugs.openjdk.java.net/browse/JDK-8193286 which effectively clamps (doesn't make a difference, having amountPerStep=1 and not incrementing programatically) >> >> commented that bug with an alternative implemenation and a couple of tests (for the most simple case ;) >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> I just took another look at the SpinnerValueFactory API docs. The use of the term "circular" heavily implies modulo arithmetic as the expected behavior if wrapAround is true. That the usual meaning of "wrap" versus "clamp" when you have a range bounded on both ends. Maybe the confusion comes from the fact that it isn't stated as clearly as it might be, coupled with a single example of a step by one going from max to min (if incrementing). I note that example doesn't say what the amountToStepBy is, but it wasn't trying to be prescriptive. >>> >>> Since the current behavior of "wrap around unless you happen to wrap a bit too much and then we'll clamp" doesn't make sense in any universe that I can think of, it is fine to treat this as a bug. I'm not worried about "bug compatibility" here. >>> >>> Clarifying the spec at the same time seems like a good idea to me. A related issue is that the default value of wrapAround is not specified (the default is `false`, but you wouldn't know that from reading the docs). This should also be addressed at the same time. >>> >>> You mentioned that this is specific to IntegerValueFactory, but it looks like DoubleValueFactory (and maybe ListValueFactory) have the same bug. Or am I missing something? >>> >>> On an unrelated note, I just noticed that the SpinnerValueFactory constructor has no documentation. This is because it is an implicitly added constructor, which is an anti-pattern for public API. I'll file a separate issue for that. >>> >>> -- Kevin >>> >>> >>> On 4/15/2020 2:23 AM, Jeanette Winzenburg wrote: >>>> Hi Ajit, >>>> >>>> yes, I read the doc, probably a bit differently - could well be my misunderstanding and misunderstandable wording :) >>>> >>>> Trying again: >>>> >>>> - I read your suggestion (in https://bugs.openjdk.java.net/browse/JDK-8242553) to imply f.i. that being at value and incrementing a full-cycle (that is max -min +1), I will land on value again >>>> - for me the doc seemed to imply that in such a case I would land on min. Though, given the "circular" as you pointed out correctly, was my misunderstanding >>>> - the current implementation is buggy (https://bugs.openjdk.java.net/browse/JDK-8193286) in calculating the remainder (which is what the first bullet amounts to) incorrectly for min != 0 >>>> >>>> Where do I err? >>>> >>>> -- Jeanette >>>> >>>> >>>> Zitat von Ajit Ghaisas : >>>> >>>>> Hi Jeanette, >>>>> >>>>> The doc never assumes amountPerStep = 1. I am quoting it here - >>>>> ?The wrapAround property is used to specify whether the value factory should be circular. For example, should an integer-based value model increment from the maximum value back to the minimum value (and vice versa).? >>>>> >>>>> The word ?circular? clarifies that once we exceed maximum value, we should start from minimum. >>>>> I think, the doc is OK in it?s current form, but implementation needs to be corrected. >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>>> On 14-Apr-2020, at 8:01 PM, Jeanette Winzenburg wrote: >>>>>> >>>>>> >>>>>> Hi Ajit, >>>>>> >>>>>> thought the doc was simply bad (in specifying the behavior for amountPerStep = 1 and not thinking of larger amounts) - my expection is a calculated wrap, that is the target as you suggest via modulo the difference from current value. Don't know if anybody took the doc literally .. >>>>>> >>>>>> -- Jeanette >>>>>> >>>>>> Zitat von Ajit Ghaisas : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Once I fix JDK-8193286, I would like to take up JDK-8242553 (IntegerSpinner does not wrap around values correctly if amountToStepBy is larger than total numbers between Max and Min) >>>>>>> >>>>>>> The current implementation is not as per what is documented. >>>>>>> Refer : https://openjfx.io/javadoc/14/javafx.controls/javafx/scene/control/SpinnerValueFactory.html#wrapAroundProperty >>>>>>> >>>>>>> I propose to fix the current buggy behavior of IntegerSpinner. >>>>>>> Although it is a corner case, I would like to know if anybody relies on this buggy behavior? >>>>>>> >>>>>>> Regards, >>>>>>> Ajit >>>>>> >>>>>> >>>> >>>> >> >> From aghaisas at openjdk.java.net Wed Apr 22 12:54:59 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 22 Apr 2020 12:54:59 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Sun, 12 Apr 2020 21:21:07 GMT, John Hendrikx wrote: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 426: > 425: > 426: height += lineSpacing; > 427: Modifying 'height' parameter seems incorrect as this parameter is used in other calculations below. If needed, use a separate local variable to use 'height+lineSpacing' modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 427: > 426: height += lineSpacing; > 427: > 428: String ellipsis = (truncationStyle == CLIP) ? "" : ellipsisString; This method makes a call to - double eHeight = computeTextHeight(font, ellipsis, 0, boundsType); What is the behavior if we make a call to the other method that takes in lineSpacing? double eHeight = computeTextHeight(font, ellipsis, 0, lineSpacing, boundsType); ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From nlisker at openjdk.java.net Wed Apr 22 12:58:53 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 22 Apr 2020 12:58:53 GMT Subject: RFR: 8241582: Infinite animation does not start from the end when started with a negative rate In-Reply-To: <6QuleeSBmh5QxrdAEWBxiq0xlVBjMTODweC4UmpFmyY=.31dba230-e692-4727-9b96-a63423571779@github.com> References: <6QuleeSBmh5QxrdAEWBxiq0xlVBjMTODweC4UmpFmyY=.31dba230-e692-4727-9b96-a63423571779@github.com> Message-ID: <9XmC6LDGbJt8_G2yLRVvjQWmVFLgNj7j-OE97aaYtL4=.c4a81bf2-2eae-4f91-bf73-2ffe1d1e8275@github.com> On Wed, 22 Apr 2020 00:08:05 GMT, Kevin Rushforth wrote: >> ### Cause >> >> `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly. This causes >> `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start the animation not from the end, depending >> on the modulo calculation. ### Fix >> >> For infinite cycles, use the `cycleDuration` as the destination since that is the effective end point. >> >> ### Tests >> >> * Added an `testJumpTo_IndefiniteCycles` test that fails without the patch and passes after it. >> * Added a `testJumpTo_IndefiniteCycleDuration` that passes both before and after, just to make sure that this type of >> infinite duration is correct. >> * Removed a test in `SequentialTransition` that fails with this patch, but it passed before it only because the modulo >> value happened to land in the right place. Changing the duration of one of the child animation can cause it to fail, so >> the test is faulty anyway at this stage. >> >> ### Future work >> >> Playing backwards will still not work correctly, but at least now it start from the correct value. This is the first of >> a series of fixes under the umbrella issue [JDK-8210238](https://bugs.openjdk.java.net/browse/JDK-8210238). > > modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationTest.java line 271: > >> 270: animation.jumpTo("end"); >> 271: assertEquals(Duration.millis(Long.MAX_VALUE / 6), animation.getCurrentTime()); >> 272: } > > Why `/ 6` ? This is a good question and I think I should have explained it in a comment because it also points to a mini-flaw. The short answer is that the 6 comes from the `TicksCalculation` class, which defines `TICKS_PER_SECOND = 6000` and `TICKS_PER_MILI = TICKS_PER_SECOND / 1000.0` which is 6. The test works as follows: This is the "ticks from duration" calculation for jumping to the end (`Duration.INDEFINITE`), demonstrated by mathematical substitutions: double millis = Duration.INDEFINITE.toMillis() = Double.POSITIVE_INFINITY long ticks = TickCalculation.fromMillis(millis) = Math.round(TICKS_PER_MILI * millis) = Math.round(6 * Double.POSITIVE_INFINITY) = Math.round(Double.POSITIVE_INFINITY) = Long.MAX_VALUE (as per the spec. of Math.round) Notice that we lose precision when multiplying `POSITIVE_INFINITY`. Then getting the current time calculates "duration from ticks": animation.getCurrentTime() = TickCalculation.toDuration(currentTicks) = ticks / TICKS_PER_MILI = Long.MAX_VALUE / 6 So the division carries out normally (there's no `Long.POSITIVE_INFINITY`), but the multiplication does not. Maybe we shouldn't convert between the `double`-based `Duration` and the `long` ticks so much, but I think that this is somewhat negligible. My next patch is refactoring in preparation of the next, heavier, changes, so I will add this explanation on the test. ------------- PR: https://git.openjdk.java.net/jfx/pull/169 From sebastian.stenzel at gmail.com Wed Apr 22 13:39:58 2020 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 22 Apr 2020 15:39:58 +0200 Subject: JavaFX System Tray Support Message-ID: <396A740B-EC91-4570-96C2-49F15A444559@gmail.com> Hi all, I don't think I have to mention that java.awt.TrayIcon is a pretty outdated API with an especially bad implementation [1] on Linux that is only just kept alive at the mercy of distribution devs and in many cases SystemTray.isSupported() returns false despite there being a tray. Judging from the comments in the aforementioned issues it doesn't seem like we can expect anything to change on AWT side. This is why it has often been requested to create an alternative using JavaFX. [2] That said, it has always been postponed. This led to projects like this [3] which try to work around these limitations but require a lot of different approaches for the various systems. Isn't it time to tackle system tray support? Since this would be a completely new feature, there is no need to be backwards compatible to the same extend as changes to the AWT system tray might needs to be (which dates back to 2005). A JavaFX system tray could instead consume modern APIs like libappindicator on Linux. The situation on Mac and Windows isn't that bad, but still it feels strange to write a JavaFX application and adding AWT only for the tray support. May I therefore ask, if it is even planned to add a tray API to JavaFX? What are the reasons for it being postponed for nearly 9 years now? Or should I better look for other solutions like the aforementioned project that depend on JNI? Cheers! Sebastian [1] see https://bugs.openjdk.java.net/browse/JDK-8176256 , https://bugs.openjdk.java.net/browse/JDK-6926494 , [2] https://bugs.openjdk.java.net/browse/JDK-8092115 [3] https://github.com/dorkbox/SystemTray From Sergey.Bylokhov at oracle.com Wed Apr 22 15:41:31 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Apr 2020 08:41:31 -0700 Subject: JavaFX System Tray Support In-Reply-To: <396A740B-EC91-4570-96C2-49F15A444559@gmail.com> References: <396A740B-EC91-4570-96C2-49F15A444559@gmail.com> Message-ID: <9a6167a1-64e6-749f-6c8d-27d2785c2b06@oracle.com> On 4/22/20 6:39 am, Sebastian Stenzel wrote: > Judging from the comments in the aforementioned issues it doesn't seem like we can expect anything to change on AWT side. This is why it has often been requested to create an alternative using JavaFX. [2] That said, it has always been postponed. This led to projects like this [3] which try to work around these limitations but require a lot of different approaches for the various systems. For the record, if anyone has a desire to improve the behavior of tray icon in AWT on Linux, you are welcome to send a patch to awt-dev! -- Best regards, Sergey. From jhendrikx at openjdk.java.net Wed Apr 22 15:52:50 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 22 Apr 2020 15:52:50 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: <_zGha6-oAfBlocb9pRMtusl-lzx2unNkJkp5yPkKeIw=.56841bc8-c28b-46b2-b702-1d77f12a2759@github.com> On Wed, 22 Apr 2020 12:51:54 GMT, Ajit Ghaisas wrote: >> This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 427: > >> 426: height += lineSpacing; >> 427: >> 428: String ellipsis = (truncationStyle == CLIP) ? "" : ellipsisString; > > This method makes a call to - > double eHeight = computeTextHeight(font, ellipsis, 0, boundsType); > > What is the behavior if we make a call to the other method that takes in lineSpacing? > double eHeight = computeTextHeight(font, ellipsis, 0, lineSpacing, boundsType); The call only determines the ellipsis height (eHeight) to see if the space is so small that even an ellipsis wouldn't fit. For a multi-line ellipsis (if there is such a thing) we could pass in the line spacing here. ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From fastegal at openjdk.java.net Wed Apr 22 15:54:23 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 22 Apr 2020 15:54:23 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> On Wed, 22 Apr 2020 06:43:31 GMT, Abhinay Agarwal wrote: > Don't you think that all the changes in `ListViewSkin` can be moved to `ListViewBehavior`? All that we do in the skin > class is to call `ListViewBehavior#updateSelectionModeKeyMapping`, which smells like feature envy. > Moreover, `ListViewBehavior` already has change listener attached to `selectionModelProperty`, waiting for us to re-use > it ?? good point :) Though - I don't like listeners to control properties in behaviors, and much less listeners to path properties (they tend to not getting cleaned on dispose). In the particular case of behaviors of controls with selectionModels they do (must?) because the selectionModel is not api complete (having no notion of anchor), so they jump in to cover up. Hopefully that design flaw will be fixed at some time in future, which would remove the existing listener, anyway. With just another responsibility - difference based on selectionMode - such cleanup would be harder. Here the basic approach is to add/remove a keyMapping for multiple/single selection. Compared to current state, there's a subtle side-effect (the event bubbles up if the mapping if removed). We can achieve the same behavior (with the same side-effect) by making the mapping consume depending on whether it is handled (to select all) or not. In code that would be pattern like: // in constructor KeyMapping selectAllMapping; addDefaultMapping(listViewInputMap, ... selectAll = new KeyMapping(new KeyBinding(A).shortcut(), this:: selectAll), ... }; selectAllMapping.setAutoConsume(false); // selectAll with modified signature /** * Calls selectAll on selectionModel and consumes the event, if * the model is available and in multimode, * does nothing otherwise. */ private void selectAll(KeyEvent key) { MultipleSelectionModel sm = getNode().getSelectionModel(); // do nothing, let it bubble up if (sm == null || sm.getSelectionMode() == SelectionMode.SINGLE) return; // handle and consume sm.selectAll(); key.consume(); } BTW, there are other keys that don't work as expected (from the perspective of the editor in the combo): f.i. shift-home/end is mapped to scrollToFirst/LastRow - that's hampering ux if f.i. the user has typed some input, uses them and sees her input lost because first/last row is selected. Sry to not have noticed earlier in my bug report :( So whatever approach we choose (mappings being removed/added or their handlers not/consuming doesn't matter), we would have to do it for several keys. Plus we have the side-effect mentioned above. The mass of change _for all listviews_ has a certain risk of breaking existing code. Think f.i. global accelerators that might (or not) get triggered depending on selection mode. On the other hand, different mappings are needed only when the list resides in the combo's popup (and probably only if the combo is editable, didn't dig though). An alternative might be a different inputMap (or containing different mappings) when used in combo's popup (which is similar to what Swing/X does .. no wonder I would prefer it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From jhendrikx at openjdk.java.net Wed Apr 22 15:56:21 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 22 Apr 2020 15:56:21 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 12:46:03 GMT, Ajit Ghaisas wrote: >> This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 426: > >> 425: >> 426: height += lineSpacing; >> 427: > > Modifying 'height' parameter seems incorrect as this parameter is used in other calculations below. If needed, use a > separate local variable to use 'height+lineSpacing' The height used needs to be changed everywhere. However, I can move this to the caller instead, with a comment explaining why: > The computeClippedWrappedText call works with full lines (height of line + line spacing), including the last line. > However the wrap height does not include the line spacing for the last line. In order to avoid wrapping the last line > of text even though there is sufficient space the wrap height passed to computeClippedWrappedText is increased with the > line spacing so it computes the correct text. ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From arapte at openjdk.java.net Wed Apr 22 16:12:05 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 22 Apr 2020 16:12:05 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> Message-ID: On Wed, 22 Apr 2020 15:52:11 GMT, Jeanette Winzenburg wrote: > `ListViewBehavior` already has change listener attached to `selectionModelProperty`, waiting for us to re-use it Hi @abhinayagarwal, Thanks for the suggestion. This sound good to me too. I shall make this change in next commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From dlemmermann at gmail.com Wed Apr 22 17:46:08 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Wed, 22 Apr 2020 19:46:08 +0200 Subject: White box / window flicker upon launch Message-ID: Hi everyone, is it just me or did something change in the launch behaviour of JavaFX applications? It seems we are back to the old ?grey box? bug of Swing where the window would appear first before filling its content. I noticed the same (but white) effect now for my JavaFX apps, especially when running on mobile devices via Gluon. Once I saw it there I paid attention to it and also noticed it when running my desktop apps (on MacOS). I must admit that I am also not certain if it has been different before. Maybe I simply notice it now? To verify run this little program. You have to pay close attention but if I am not mistaken then the window first shows up with a white background before showing its content, which is orange. Can somebody confirm? If so, I will create a bug ticket. Regards, Dirk import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class BugDemo extends Application { public void start(Stage stage) { VBox root = new VBox(); root.setStyle("-fx-background-color: orange;"); Scene scene = new Scene(root, 1000, 800); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } From Rony.Flatscher at wu.ac.at Wed Apr 22 18:01:20 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 22 Apr 2020 20:01:20 +0200 Subject: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at> References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at> Message-ID: Hi Kevin, as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes: Summary ======= Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine implements the javax.script.Compilable interface to speed up execution. In case compilation throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow control of script compilation with a "compile" PI for FXML files. Problem ======= javafx.fxml.FXMLLoader is able to execute scripts in Java script languages (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file. If a script engine implements the javax.script.Compilable interface, then such scripts could be compiled and the resulting javax.script.CompiledScript could be executed instead using its eval() methods. Evaluating the javax.script.CompiledScript objects may help speed up the execution of script invocations, especially for scripts defined for event attributes in FXML elements (e.g. like onMouseMove) which may be repetitively invoked and evaluated. Solution? ======== Before evaluating the script code test whether the javax.script.ScriptEngine implements javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first and then use its eval() method to evaluate the script, otherwise continue to use the javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield (unexpectedly) a javax.script.ScriptException then fall back to using the javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML files. Specification ============= If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its compile() method to compile the script to a javax.script.CompiledScript object and use its eval() method to run the script. In the case that the compilation throws (unexpectedly) a javax.script.ScriptException log a warning and fall back to using the javax.script.ScriptEngine's eval() method instead. To allow setting this feature off and on while processing the FXML file a "compile" process instruction ("" or "") gets defined that allows to turn compilation off and on throughout a FXML file. Having never seen a real CSR I hope that this matches what is expected and is helpful for assessment. If not please advise (got the name of these fields from [1]). --- Also added brief information about the respective test units (what they test and yield) in the WIP? [2]. ---rony [1] "CSR-FAQ": [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts #192":? On 20.04.2020 14:58, Rony G. Flatscher wrote: > There is a new WIP at : > > This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a > warning gets issued about this fact and evaluation of the script will be done without > compilation. Because of the fallback scripts get compiled with this version by default. It > extends PR 187 #187. > > To further ease spotting scripts that cause a ScriptException a message in the form of > "filename: caused ScriptException" gets added to the exception handling in either of the three > locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three > different kinds of reporting ScriptExceptions may be questioned, however none of these tear down > the FXML GUI). > > This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged > whenever a script cannot be compiled and the fallback gets used. > > It is suggested to use this WIP as it includes the compilation by default with a safe fallback to > evaluate the uncompiled script, if compilation (unexpectedly) fails. > > Again, any feedback, discussion welcome! > > ---rony > > P.S.: In the log history there is a commit message "Make message more pregnant.", it should have > read "Make messages more terse." instead|.|| > | > > > On 17.04.2020 19:37, Rony G. Flatscher wrote: >> There is a new WIP at which adds a compile PI (process >> instruction) for turning on and off script compilation if the script engine implements the >> Compilable interface. >> >> By default compilation is off (no compilation), such that one needs to add a compile PI >> ("") at the top to activate this feature. Supplying "true" (default) or "false" as the PI >> data turns this feature on and off. >> >> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off", >> alternating using "compile on and off", and alternating using "compile off and on". This will test >> all variants of applying the compile PI for all categories of scripts. >> >> Any feedback appreciated! >> >> ---rony >> >> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get >> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes. >> >> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a >> fallback solution in case a compilation is (unexpectedly) not successful, reverting to >> (interpretative) evaluation/execution of the script. In that version it is planned to have >> compilation on by default as in the case of a compilation failure there will be a safe backup solution. >> >> >> On 14.04.2020 19:52, Kevin Rushforth wrote: >>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to >>> create the CSR until the review is far enough along to know which direction we intend to go. >>> >>> Unless there is a real concern about possible regressions if scripts are compiled by default, I >>> think "enabled by default" is the way to go. Your argument that such script engines are broken >>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable >>> in the first place. We still might want to add way to turn compilation off for individual scripts. >>> One other thing to consider is that if compilation fails, it might make sense to log a warning and >>> fall back to the existing interpreted mode. >>> >>> Does anyone else have any concerns with this? >>> >>> -- Kevin >>> >>> >>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: >>>> Hi there, >>>> >>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days >>>> with the PR as per Kevin's suggestion. >>>> >>>> (For the case that this feature should not be active by default, the CSR will suggest to define a >>>> new "compile" PI in the form (default, if no PI data given: true), which >>>> is independent of the existence of a language PI (this way it becomes also possible to allow >>>> compilation of external scripts denoted with the script-element, which do not need a page language >>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for >>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI >>>> or ? to FXML files (and to turn off), which seems to >>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation >>>> of scripts on and off throughout an FXML file.) >>>> >>>> ---rony >>>> >>>> >>>> On 04.04.2020 18:03, Rony G. Flatscher wrote: >>>> >>>>> Hi Kevin, >>>>> >>>>> On 03.04.2020 01:21, Kevin Rushforth wrote: >>>>>> I see that you updated the PR and sent it for review. >>>>>> >>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>>>>> feature, and if so, what form this feature should take. >>>>>> >>>>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>>>>> from it? >>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code >>>>> may >>>>> benefit. >>>>> >>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause >>>>> the reparsing of that script's source and interpreting it on each invocation, which may be >>>>> expensive >>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the >>>>> compiled >>>>> script by the script engine. >>>>> >>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >>>>> In principle there are three possibilities: >>>>> >>>>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the >>>>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and >>>>> ???? execute the compiled script each time its registered event fires. >>>>> >>>>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts >>>>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >>>>> ???????? compiling but have been employed successfully in interpreted mode >>>>> >>>>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >>>>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script >>>>> ???? engine implements the javax.script.Compilable interface. If missing it would default to >>>>> "false". >>>>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >>>>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the >>>>> ???? "language" PI was not.) >>>>> >>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the >>>>> language >>>>> ???????? PI gets changed >>>>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts >>>>> >>>>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script >>>>> and >>>>> ???? node elements and only compile the scripts, if the property is set to true >>>>> >>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >>>>> ???????? accordingly >>>>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that >>>>> host scripts >>>>> >>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >>>>> overruled individually by 3. >>>>> >>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that >>>>> compilation >>>>> of scripts by the script engines would find the same errors as while interpreting the very same >>>>> scripts (if not, the script engine is badly broken and it could be argued that then the >>>>> interpretation part of the script engine might be expected to be broken as well which would be >>>>> quite >>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the >>>>> compiled script would behave differently to interpreting the very same script by the same script >>>>> engine). >>>>> >>>>> The current WIP implements 1 above and includes an appropriate test unit. >>>>> >>>>>> What do others think? >>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the >>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>>>>> but we would need to ensure that. >>>>> The compilation of scripts needs to be done by the Java script engines (implementing both, >>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >>>>> scripts ([javax.script.CompiledScript] >>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >>>>> >>>>> >>>>> ---rony >>>>> >>>>> >>>>> >>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>>>>> After merging master, applying some fixes and changing the title to reflect the change from >>>>>>> WIP to a >>>>>>> pull request I would kindly request a review of this pull request! >>>>>>> >>>>>>> Here the URL: , title changed to: "8238080: >>>>>>> FXMLLoader: if >>>>>>> script engines implement javax.script.Compilable compile scripts". >>>>>>> >>>>>>> ---rony >>>>>>> >>>>>>> >>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in >>>>>>>> review, and >>>>>>>> has an appropriate test unit going with it as well, please review. >>>>>>>> >>>>>>>> There should be no compatibility issue with this implementation. >>>>>>>> >>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML >>>>>>>> files. >>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts >>>>>>>> if the >>>>>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>>>>> value >>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML >>>>>>>> with >>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up >>>>>>>> with a >>>>>>>> respective solution as well. >>>>>>>> >>>>>>>> ---rony >>>>>>>> >>>>>>>> [1] "Implementation and test unit": >>>>>>>> >>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>>>>> scripts": >>>>>>>> >>>>>>>> >>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>>>>> >>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to >>>>>>>>> illustrate >>>>>>>>> the concept). >>>>>>>>> >>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>>>>> Just filed a RFE with the following information: >>>>>>>>>> >>>>>>>>>> ???? * Component: >>>>>>>>>> ???????? o JavaFX >>>>>>>>>> >>>>>>>>>> ???? * Subcomponent: >>>>>>>>>> ???????? o fxml: JavaFX FXML >>>>>>>>>> >>>>>>>>>> ???? * Synopsis: >>>>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>>>>> >>>>>>>>>> ???? * Descriptions: >>>>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>>>>> (javax.script.ScriptEngine >>>>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller >>>>>>>>>> language in >>>>>>>>>> ?????????? the FXML file. >>>>>>>>>> >>>>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such >>>>>>>>>> scripts >>>>>>>>>> could >>>>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>>>>> using >>>>>>>>>> ?????????? its eval() methods. >>>>>>>>>> >>>>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>>>>> invocations, >>>>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>>>>> onMouseMove) >>>>>>>>>> ?????????? which may be repetitevly invoked and evaluated." >>>>>>>>>> >>>>>>>>>> ???? * System /OS/Java Runtime Information: >>>>>>>>>> ???????? o "All systems." >>>>>>>>>> >>>>>>>>>> Received the internal review ID: "9063426" >>>>>>>>>> >>>>>>>>>> ---rony From kcr at openjdk.java.net Wed Apr 22 18:14:48 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 18:14:48 GMT Subject: RFR: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 18:07:09 GMT, Kevin Rushforth wrote: > This PR will allow javafx.web unit tests to run to completion and pass on Windows with Visual Studio 2019. > > Two of the WebKit tests load the native WebKit library without initializing the JavaFX runtime. This will lead to test > failures and will hang the test run if those tests are run before the other tests, and if the system doesn't have all > the needed runtime libraries. The simple fix is to call the Toolkit method to load those libraries. This is only > needed for unit tests that don't already initialize the JavaFX runtime (e.g., by calling `Platform::startup` or > `Application::launch`) and call internal methods that execute native code as part of the test. @guruhb can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/194 From kcr at openjdk.java.net Wed Apr 22 18:14:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 18:14:47 GMT Subject: RFR: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded Message-ID: This PR will allow javafx.web unit tests to run to completion and pass on Windows with Visual Studio 2019. Two of the WebKit tests load the native WebKit library without initializing the JavaFX runtime. This will lead to test failures and will hang the test run if those tests are run before the other tests, and if the system doesn't have all the needed runtime libraries. The simple fix is to call the Toolkit method to load those libraries. This is only needed for unit tests that don't already initialize the JavaFX runtime (e.g., by calling `Platform::startup` or `Application::launch`) and call internal methods that execute native code as part of the test. ------------- Commit messages: - 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded Changes: https://git.openjdk.java.net/jfx/pull/194/files Webrev: https://webrevs.openjdk.java.net/jfx/194/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242505 Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/194/head:pull/194 PR: https://git.openjdk.java.net/jfx/pull/194 From tom.schindl at bestsolution.at Wed Apr 22 18:17:16 2020 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 22 Apr 2020 20:17:16 +0200 Subject: White box / window flicker upon launch In-Reply-To: References: Message-ID: <06627dc5-567f-abf8-a35e-90d192268340@bestsolution.at> yes I do but I think this is by nature: a) you use CSS so only after the first CSS-Pass the color could be set appropriately, this CSS pass could happen after the Native-Window is shown => you can mitigate that a bit using root.setBackground(new Background(new BackgroundFill(Color.ORANGE, CornerRadii.EMPTY, Insets.EMPTY))); b) if the above gives you short flash (IMHO shorter than with CSS) and you can see that by setting eg RED or GREEN as the Scene-Fill so then it gets more prominent So the flash is gone if you put the same color to Scene.setFill() as your root-Pane but now something slightly unexpected happens. The trim is colored slighly in your scene-color ;-) Tom Am 22.04.20 um 19:46 schrieb Dirk Lemmermann: > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class BugDemo extends Application { > > public void start(Stage stage) { > VBox root = new VBox(); > root.setStyle("-fx-background-color: orange;"); > Scene scene = new Scene(root, 1000, 800); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From kcr at openjdk.java.net Wed Apr 22 18:20:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 18:20:32 GMT Subject: RFR: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 18:07:53 GMT, Kevin Rushforth wrote: >> This PR will allow javafx.web unit tests to run to completion and pass on Windows with Visual Studio 2019. >> >> Two of the WebKit tests load the native WebKit library without initializing the JavaFX runtime. This will lead to test >> failures and will hang the test run if those tests are run before the other tests, and if the system doesn't have all >> the needed runtime libraries. The simple fix is to call the Toolkit method to load those libraries. This is only >> needed for unit tests that don't already initialize the JavaFX runtime (e.g., by calling `Platform::startup` or >> `Application::launch`) and call internal methods that execute native code as part of the test. > > @guruhb can you review this? Worth noting is that it is possible for this to fail even with the VS2017 compiler on some systems, but I haven't seen it myself (I've seen similar enough failures to know that it's possible). ------------- PR: https://git.openjdk.java.net/jfx/pull/194 From kcr at openjdk.java.net Wed Apr 22 18:54:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 18:54:20 GMT Subject: RFR: 8242507: Add support for Visual Studio 2019 In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 18:46:29 GMT, Kevin Rushforth wrote: > This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not change the default compiler, which > remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be proposed in a future PR using a new bug ID, > and isn't planned until after the JDK updates their compiler. In order to allow developer builds to use Microsoft > Visual Studio 2019, we need the following changes at build time and runtime. > At build time: > > 1. Copy `vsruntime140_1.dll` (if present) to output `sdk/bin` dir > 2. Don't copy the unused `concrt140.dll` (it is not used in VS 2017 either) > > At runtime: > > 1. Load `vsruntime140_1.dll` if present > 2. Don't load the unused `concrt140.dll` > > Additionally, I removed two unused build variables, `ext.MSVCR` and `ext.MSVCP`, which would otherwise have needed to > be updated. > I have done a full build and test run using both VS 2017 (which is still the default), and VS 2019. @arapte can you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/195 From kcr at openjdk.java.net Wed Apr 22 18:54:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 18:54:20 GMT Subject: RFR: 8242507: Add support for Visual Studio 2019 Message-ID: This PR adds support for Microsoft Visual Studio 2019 (VS 2019), but does not change the default compiler, which remains at VS 2017 15.9.16. Changing the build compiler to VS 2019 will be proposed in a future PR using a new bug ID, and isn't planned until after the JDK updates their compiler. In order to allow developer builds to use Microsoft Visual Studio 2019, we need the following changes at build time and runtime. At build time: 1. Copy `vsruntime140_1.dll` (if present) to output `sdk/bin` dir 2. Don't copy the unused `concrt140.dll` (it is not used in VS 2017 either) At runtime: 1. Load `vsruntime140_1.dll` if present 2. Don't load the unused `concrt140.dll` Additionally, I removed two unused build variables, `ext.MSVCR` and `ext.MSVCP`, which would otherwise have needed to be updated. I have done a full build and test run using both VS 2017 (which is still the default), and VS 2019. ------------- Commit messages: - 8242507: Add support for Visual Studio 2019 Changes: https://git.openjdk.java.net/jfx/pull/195/files Webrev: https://webrevs.openjdk.java.net/jfx/195/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242507 Stats: 11 lines in 3 files changed: 1 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/195.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/195/head:pull/195 PR: https://git.openjdk.java.net/jfx/pull/195 From tom.schindl at bestsolution.at Wed Apr 22 22:26:29 2020 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 23 Apr 2020 00:26:29 +0200 Subject: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light Message-ID: Hi Kevin / Phil, I'd like to start working on JDK-8090423 but before I start investing time I wanted to make sure nobody is working on that and if you have any input, ideas already how to address that problem help me not wasting time. Tom From philip.race at oracle.com Wed Apr 22 22:40:13 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 22 Apr 2020 15:40:13 -0700 Subject: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light In-Reply-To: References: Message-ID: <5EA0C7CD.6000208@oracle.com> Sadly no one is working on it. It probably is not that hard to do, the weight should be in the OS/2 table -phil On 4/22/20, 3:26 PM, Tom Schindl wrote: > Hi Kevin / Phil, > > I'd like to start working on JDK-8090423 but before I start investing > time I wanted to make sure nobody is working on that and if you have > any input, ideas already how to address that problem help me not > wasting time. > > Tom From kcr at openjdk.java.net Wed Apr 22 23:11:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Apr 2020 23:11:30 GMT Subject: [Rev 01] RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel In-Reply-To: References: Message-ID: <8cfzuYks-NQFIleZTv1wmgF2M2B1ydeofCnC0l7JSFI=.0205d695-ffbe-484b-ae0a-b59603396ba7@github.com> On Wed, 15 Apr 2020 10:52:26 GMT, Ambarish Rapte wrote: >> `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being >> GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. >> If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member >> `selectionModel`. >> The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for >> [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Add tests Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/175 From philip.race at oracle.com Thu Apr 23 01:02:07 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 22 Apr 2020 18:02:07 -0700 Subject: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light In-Reply-To: <5EA0C7CD.6000208@oracle.com> References: <5EA0C7CD.6000208@oracle.com> Message-ID: <5EA0E90F.70103@oracle.com> I was mulling over why if it is so easy we didn't do it and I suspect (haven't checked, and so long ago I can't remember off hand) that this code needed to run on top of the old Java 2D pipeline (wrongly called the Swing pipeline). And 2D did not and does not provide this functionality either. -phil. On 4/22/20, 3:40 PM, Philip Race wrote: > Sadly no one is working on it. > It probably is not that hard to do, the weight should be in the OS/2 > table > > -phil > > On 4/22/20, 3:26 PM, Tom Schindl wrote: >> Hi Kevin / Phil, >> >> I'd like to start working on JDK-8090423 but before I start investing >> time I wanted to make sure nobody is working on that and if you have >> any input, ideas already how to address that problem help me not >> wasting time. >> >> Tom From ajoseph at openjdk.java.net Thu Apr 23 05:44:20 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 23 Apr 2020 05:44:20 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms Message-ID: fillPath() and fillRect() functions in [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as ImagePattern doesn't have the same attribute. So, the final image won't be transformed. ------------- Commit messages: - Change order of translate - Minimal fix - Remove unwanted changes - Implement setFillPattern - Implement setPattern - Create WCPattern - Add patternTransform in ImagePattern Changes: https://git.openjdk.java.net/jfx/pull/190/files Webrev: https://webrevs.openjdk.java.net/jfx/190/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242861 Stats: 50 lines in 3 files changed: 32 ins; 11 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Apr 23 06:53:29 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 23 Apr 2020 06:53:29 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> Message-ID: On Wed, 22 Apr 2020 15:52:11 GMT, Jeanette Winzenburg wrote: > Compared to current state, there's a subtle side-effect (the event bubbles up if the mapping if removed). We can > achieve the same behavior (with the same side-effect) by making the mapping consume depending on whether it is handled > (to select all) or not. Changing the behavior inside `selectAll` is also a good option (and much cleaner as well) > So whatever approach we choose (mappings being removed/added or their handlers not/consuming doesn't matter), we would > have to do it for several keys. Plus we have the side-effect mentioned above. The mass of change for all listviews has > a certain risk of breaking existing code. Think f.i. global accelerators that might (or not) get triggered depending on > selection mode. It's sad that we can't easily override (InputMapping created in) `ListViewBehavior` :( ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From github.com+2720909+jskov at openjdk.java.net Thu Apr 23 07:57:23 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Thu, 23 Apr 2020 07:57:23 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Sun, 19 Apr 2020 13:50:18 GMT, Jesper Skov wrote: >> Uh, the exception is (as the comment note suggests) from using a prebuilt webkit. >> I will try a locally built one now. > > Ah, well. Ended with the same VM crash when building webkit myself. > > So I am kinda stuck. Suggestions? I have found out that my :web:test failed because I did not have the media libs properly installed. So the changes in this PR pass all tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From tom.schindl at bestsolution.at Thu Apr 23 07:58:41 2020 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 23 Apr 2020 09:58:41 +0200 Subject: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light In-Reply-To: <5EA0E90F.70103@oracle.com> References: <5EA0C7CD.6000208@oracle.com> <5EA0E90F.70103@oracle.com> Message-ID: <118caaf7-a0b4-86a5-2b3c-2f59551712d4@bestsolution.at> Hi Phil, I haven't looked too deep into that but to the "only" problem I see is how the internal lookup tree is structured in "PrismFontFactory". And yes you are right the OS/2-Table (there's even a comment in PrismFontFile mentionning usWeightClass) contains the necessary information, some mac-fonts use the header-segment so there one has to distinction but those font would be simply classified as BOLD(700). I'll put that on my opensource working queue, to look a bit deeper into that and get back with a more in depth report (and probably questions). The current in ability to use FontWeight is a real problem compared to WebUIs, and although there is a work around not using FontWeight in CSS it is very cumbersome. Tom Am 23.04.20 um 03:02 schrieb Philip Race: > I was mulling over why if it is so easy we didn't do it and I suspect > (haven't checked, and so long ago I can't remember off hand) that > this code needed to run on top of the old Java 2D pipeline (wrongly > called the Swing pipeline). And 2D did not and does not provide > this functionality either. > > -phil. > > On 4/22/20, 3:40 PM, Philip Race wrote: >> Sadly no one is working on it. >> It probably is not that hard to do, the weight should be in the OS/2 >> table >> >> -phil >> >> On 4/22/20, 3:26 PM, Tom Schindl wrote: >>> Hi Kevin / Phil, >>> >>> I'd like to start working on JDK-8090423 but before I start investing >>> time I wanted to make sure nobody is working on that and if you have >>> any input, ideas already how to address that problem help me not >>> wasting time. >>> >>> Tom From jskov at zoftcorp.dk Thu Apr 23 08:14:07 2020 From: jskov at zoftcorp.dk (Jesper Skov) Date: Thu, 23 Apr 2020 10:14:07 +0200 Subject: Gradle support for getting :web:test working properly Message-ID: Hi I struggled somewhat to get :web:test running with -PSTUB_RUNTIME. The JVM kept crashing by what turned out to be missing media libraries (the failure message was hidden). I tried building with -PCOMPILE_WEBKIT=true, but it takes a terrible long time on my laptop. And did not in itself fix the problem. Frustrations and lost time was the only real outcome of this :) So I would suggest adding logic to the build file to allow something like: gradlew -PSTUB_RUNTIME_USE=15-ea+4 all test This should download org.openjfx:javafx-web and org.openjfx:javafx-media artifacts in the specified version. Then unpack the shared libraries to a build folder, and make them availble via the STUB_RUNTIME logic. Plus an addition to the CONTRIBUTING.md documenting this. I would be happy to help make and/or test the changes, but am only able to work on Linux. Thanks, Jesper From jskov at zoftcorp.dk Thu Apr 23 08:29:01 2020 From: jskov at zoftcorp.dk (Jesper Skov) Date: Thu, 23 Apr 2020 10:29:01 +0200 Subject: CONTRIBUTING.md suggestion Message-ID: Hi again, I have an additional suggestion for CONTRIBUTING.md changes. In the Code Review section: If any changes are needed, you would push additional commits to the branch from which you made the pull request. Maybe add something to the effect that; These additional commits should have commit message describing the change, not the bug issue name. Note that this will upset jcheck. (maybe jcheck should be fixed to only complain if the original commit has a bad message, so the last sentence is not needed) Cheers, Jesper From aghaisas at openjdk.java.net Thu Apr 23 08:55:23 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 23 Apr 2020 08:55:23 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 15:54:09 GMT, John Hendrikx wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 426: >> >>> 425: >>> 426: height += lineSpacing; >>> 427: >> >> Modifying 'height' parameter seems incorrect as this parameter is used in other calculations below. If needed, use a >> separate local variable to use 'height+lineSpacing' > > The height used needs to be changed everywhere. However, I can move this to the caller instead, with a comment > explaining why: >> The computeClippedWrappedText call works with full lines (height of line + line spacing), including the last line. >> However the wrap height does not include the line spacing for the last line. In order to avoid wrapping the last line >> of text even though there is sufficient space the wrap height passed to computeClippedWrappedText is increased with the >> line spacing so it computes the correct text. I see your point. I am OK with the changes that you have done. ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From aghaisas at openjdk.java.net Thu Apr 23 10:53:18 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 23 Apr 2020 10:53:18 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Sun, 12 Apr 2020 21:21:07 GMT, John Hendrikx wrote: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From aghaisas at openjdk.java.net Thu Apr 23 10:53:18 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 23 Apr 2020 10:53:18 GMT Subject: RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Tue, 21 Apr 2020 12:48:37 GMT, Kevin Rushforth wrote: >> @aghaisas can you review this? > > @aghaisas can you also review this? I tested with the test program in the bug and can confirm that this PR fixes the reported issue. I found that the unit test (together with stub) passes without the code fix as well. I think, this is a limitation of our test framework that we need to do code fix + stub fix as well. I find that you have done these changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From jhendrikx at openjdk.java.net Thu Apr 23 11:12:19 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 23 Apr 2020 11:12:19 GMT Subject: [Rev 01] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8242548: Honor line spacing in Labeled reflow calculation ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/173/files - new: https://git.openjdk.java.net/jfx/pull/173/files/86b2f011..8d6084eb Webrevs: - full: https://webrevs.openjdk.java.net/jfx/173/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/173/webrev.00-01 Stats: 15 lines in 2 files changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/173/head:pull/173 PR: https://git.openjdk.java.net/jfx/pull/173 From jhendrikx at openjdk.java.net Thu Apr 23 11:32:26 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 23 Apr 2020 11:32:26 GMT Subject: [Rev 02] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8242548: Honor line spacing in Labeled reflow calculation ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/173/files - new: https://git.openjdk.java.net/jfx/pull/173/files/8d6084eb..20ccd127 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/173/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/173/webrev.01-02 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/173/head:pull/173 PR: https://git.openjdk.java.net/jfx/pull/173 From jhendrikx at openjdk.java.net Thu Apr 23 11:32:26 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 23 Apr 2020 11:32:26 GMT Subject: [Rev 02] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Thu, 23 Apr 2020 10:51:05 GMT, Ajit Ghaisas wrote: >> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. The pull request contains one new commit since >> the last revision: >> 8242548: Honor line spacing in Labeled reflow calculation > > Marked as reviewed by aghaisas (Reviewer). I added a comment clarification and passed the line spacing to the ellipsis height calculation as well (just in case there is a multi line ellipsis). The test indeed doesn't quite cover the change, the StubTextLayout is not advanced enough to actually do line wrapping calculations (it ignores wrap height), and would need to be updated. ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From dlemmermann at gmail.com Thu Apr 23 11:40:56 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 23 Apr 2020 13:40:56 +0200 Subject: White box / window flicker upon launch In-Reply-To: <06627dc5-567f-abf8-a35e-90d192268340@bestsolution.at> References: <06627dc5-567f-abf8-a35e-90d192268340@bestsolution.at> Message-ID: <7AD41DD1-A1C6-431D-91DF-3B8EC4841871@gmail.com> I think this is a bug ? I will create a ticket for it. When this behaviour was fixed for Swing in Java 6 it made a huge difference in the perception of the quality and performance of Java applications. Could do the same for JavaFX. Dirk > On 22 Apr 2020, at 20:17, Tom Schindl wrote: > > yes I do but I think this is by nature: > > a) you use CSS so only after the first CSS-Pass the color could be set > appropriately, this CSS pass could happen after the Native-Window is > shown > => you can mitigate that a bit using > root.setBackground(new Background(new BackgroundFill(Color.ORANGE, > CornerRadii.EMPTY, Insets.EMPTY))); > > b) if the above gives you short flash (IMHO shorter than with CSS) and > you can see that by setting eg RED or GREEN as the Scene-Fill so then > it gets more prominent > > So the flash is gone if you put the same color to Scene.setFill() as your root-Pane but now something slightly unexpected happens. The trim is colored slighly in your scene-color ;-) > > Tom > > Am 22.04.20 um 19:46 schrieb Dirk Lemmermann: >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> public class BugDemo extends Application { >> public void start(Stage stage) { >> VBox root = new VBox(); >> root.setStyle("-fx-background-color: orange;"); >> Scene scene = new Scene(root, 1000, 800); >> stage.setScene(scene); >> stage.show(); >> } >> public static void main(String[] args) { >> launch(args); >> } >> } From dlemmermann at gmail.com Thu Apr 23 11:52:51 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 23 Apr 2020 13:52:51 +0200 Subject: White box / window flicker upon launch In-Reply-To: <7AD41DD1-A1C6-431D-91DF-3B8EC4841871@gmail.com> References: <06627dc5-567f-abf8-a35e-90d192268340@bestsolution.at> <7AD41DD1-A1C6-431D-91DF-3B8EC4841871@gmail.com> Message-ID: <195CE0A5-7112-45AD-8882-71488FBBD4E8@gmail.com> Ticket created: ID 9064689 Dirk > On 23 Apr 2020, at 13:40, Dirk Lemmermann wrote: > > I think this is a bug ? I will create a ticket for it. When this behaviour was fixed for Swing in Java 6 it made a huge difference in the perception of the quality and performance of Java applications. Could do the same for JavaFX. > > Dirk > > >> On 22 Apr 2020, at 20:17, Tom Schindl wrote: >> >> yes I do but I think this is by nature: >> >> a) you use CSS so only after the first CSS-Pass the color could be set >> appropriately, this CSS pass could happen after the Native-Window is >> shown >> => you can mitigate that a bit using >> root.setBackground(new Background(new BackgroundFill(Color.ORANGE, >> CornerRadii.EMPTY, Insets.EMPTY))); >> >> b) if the above gives you short flash (IMHO shorter than with CSS) and >> you can see that by setting eg RED or GREEN as the Scene-Fill so then >> it gets more prominent >> >> So the flash is gone if you put the same color to Scene.setFill() as your root-Pane but now something slightly unexpected happens. The trim is colored slighly in your scene-color ;-) >> >> Tom >> >> Am 22.04.20 um 19:46 schrieb Dirk Lemmermann: >>> import javafx.application.Application; >>> import javafx.scene.Scene; >>> import javafx.scene.layout.VBox; >>> import javafx.stage.Stage; >>> public class BugDemo extends Application { >>> public void start(Stage stage) { >>> VBox root = new VBox(); >>> root.setStyle("-fx-background-color: orange;"); >>> Scene scene = new Scene(root, 1000, 800); >>> stage.setScene(scene); >>> stage.show(); >>> } >>> public static void main(String[] args) { >>> launch(args); >>> } >>> } > From kcr at openjdk.java.net Thu Apr 23 12:11:50 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Apr 2020 12:11:50 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> <1uh4MkBZkUdpS2b4vmAdgFcKsqPx7-3beLqSpARbO2Q=.de1013bd-5359-4aad-bc62-7c140be02e36@github.com> Message-ID: On Thu, 23 Apr 2020 07:55:06 GMT, Jesper Skov wrote: >> Ah, well. Ended with the same VM crash when building webkit myself. >> >> So I am kinda stuck. Suggestions? > > I have found out that my :web:test failed because I did not have the > media libs properly installed. > > So the changes in this PR pass all tests. Good to know. I'll finish my review today. ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Thu Apr 23 12:23:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Apr 2020 12:23:24 GMT Subject: [Rev 02] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Thu, 23 Apr 2020 11:22:18 GMT, John Hendrikx wrote: >> Marked as reviewed by aghaisas (Reviewer). > > I added a comment clarification and passed the line spacing to the ellipsis height calculation as well (just in case > there is a multi line ellipsis). > The test indeed doesn't quite cover the change, the StubTextLayout is not advanced enough to actually do line wrapping > calculations (it ignores wrap height), and would need to be updated. @hjohn Updates to a PR under review should be done as additional commits. Please do not force push to your branch. This makes it more difficult for reviewers, since the incremental diffs from the last time it was reviewed are lost. A force push of your branch should only be used in extraordinary circumstances. ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From ajoseph at openjdk.java.net Thu Apr 23 12:31:34 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 23 Apr 2020 12:31:34 GMT Subject: [Rev 01] RFR: 8242861: Update ImagePattern to apply SVG pattern transforms In-Reply-To: References: Message-ID: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add CanvasTest ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/c1066e95..76e4745d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.00-01 Stats: 58 lines in 1 file changed: 58 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From johan.vos at gluonhq.com Thu Apr 23 12:36:16 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 23 Apr 2020 14:36:16 +0200 Subject: backport request: JDK-8235627 Message-ID: Hi Kevin, I request permission to backport https://bugs.openjdk.java.net/browse/JDK-8235627 to JavaFX 11. Thanks, - Johan From kevin.rushforth at oracle.com Thu Apr 23 13:15:57 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Apr 2020 06:15:57 -0700 Subject: backport request: JDK-8235627 In-Reply-To: References: Message-ID: <3b8e89bf-2e6d-92e6-f385-e22702ac89af@oracle.com> +1 On 4/23/2020 5:36 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport > https://bugs.openjdk.java.net/browse/JDK-8235627 to JavaFX 11. > > Thanks, > > - Johan From David.Grieve at microsoft.com Thu Apr 23 14:00:19 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Thu, 23 Apr 2020 14:00:19 +0000 Subject: White box / window flicker upon launch Message-ID: Another possible workaround is to call Node#applyCss() before stage.show(). There is an example in the Javadoc for the applyCss() method. -----Original Message----- From: openjfx-dev On Behalf Of Dirk Lemmermann Sent: Wednesday, April 22, 2020 1:46 PM To: OpenJFX Subject: [EXTERNAL] White box / window flicker upon launch Hi everyone, is it just me or did something change in the launch behaviour of JavaFX applications? It seems we are back to the old ?grey box? bug of Swing where the window would appear first before filling its content. I noticed the same (but white) effect now for my JavaFX apps, especially when running on mobile devices via Gluon. Once I saw it there I paid attention to it and also noticed it when running my desktop apps (on MacOS). I must admit that I am also not certain if it has been different before. Maybe I simply notice it now? To verify run this little program. You have to pay close attention but if I am not mistaken then the window first shows up with a white background before showing its content, which is orange. Can somebody confirm? If so, I will create a bug ticket. Regards, Dirk import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class BugDemo extends Application { public void start(Stage stage) { VBox root = new VBox(); root.setStyle("-fx-background-color: orange;"); Scene scene = new Scene(root, 1000, 800); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } From dlemmermann at gmail.com Thu Apr 23 14:16:41 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 23 Apr 2020 16:16:41 +0200 Subject: White box / window flicker upon launch In-Reply-To: References: Message-ID: <7FC68095-3E91-473D-84AD-9E2FDCC43E83@gmail.com> I notice the word ?workaround? :-) So you would agree it is a bug? And if so ?. regression? I never noticed it before. > On 23 Apr 2020, at 16:00, David Grieve wrote: > > Another possible workaround is to call Node#applyCss() before stage.show(). There is an example in the Javadoc for the applyCss() method. > > -----Original Message----- > From: openjfx-dev On Behalf Of Dirk Lemmermann > Sent: Wednesday, April 22, 2020 1:46 PM > To: OpenJFX > Subject: [EXTERNAL] White box / window flicker upon launch > > Hi everyone, > > is it just me or did something change in the launch behaviour of JavaFX applications? It seems we are back to the old ?grey box? bug of Swing where the window would appear first before filling its content. I noticed the same (but white) effect now for my JavaFX apps, especially when running on mobile devices via Gluon. Once I saw it there I paid attention to it and also noticed it when running my desktop apps (on MacOS). I must admit that I am also not certain if it has been different before. Maybe I simply notice it now? > > To verify run this little program. You have to pay close attention but if I am not mistaken then the window first shows up with a white background before showing its content, which is orange. > > Can somebody confirm? If so, I will create a bug ticket. > > Regards, > > Dirk > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class BugDemo extends Application { > > public void start(Stage stage) { > VBox root = new VBox(); > root.setStyle("-fx-background-color: orange;"); > Scene scene = new Scene(root, 1000, 800); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From dlemmermann at gmail.com Thu Apr 23 14:20:00 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Thu, 23 Apr 2020 16:20:00 +0200 Subject: White box / window flicker upon launch In-Reply-To: References: Message-ID: <7A39D5C5-277E-4D4F-B8FF-D1322655336F@gmail.com> I tried as you suggested. Problem is still there. > On 23 Apr 2020, at 16:00, David Grieve wrote: > > Another possible workaround is to call Node#applyCss() before stage.show(). There is an example in the Javadoc for the applyCss() method. > > -----Original Message----- > From: openjfx-dev On Behalf Of Dirk Lemmermann > Sent: Wednesday, April 22, 2020 1:46 PM > To: OpenJFX > Subject: [EXTERNAL] White box / window flicker upon launch > > Hi everyone, > > is it just me or did something change in the launch behaviour of JavaFX applications? It seems we are back to the old ?grey box? bug of Swing where the window would appear first before filling its content. I noticed the same (but white) effect now for my JavaFX apps, especially when running on mobile devices via Gluon. Once I saw it there I paid attention to it and also noticed it when running my desktop apps (on MacOS). I must admit that I am also not certain if it has been different before. Maybe I simply notice it now? > > To verify run this little program. You have to pay close attention but if I am not mistaken then the window first shows up with a white background before showing its content, which is orange. > > Can somebody confirm? If so, I will create a bug ticket. > > Regards, > > Dirk > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class BugDemo extends Application { > > public void start(Stage stage) { > VBox root = new VBox(); > root.setStyle("-fx-background-color: orange;"); > Scene scene = new Scene(root, 1000, 800); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From David.Grieve at microsoft.com Thu Apr 23 14:37:00 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Thu, 23 Apr 2020 14:37:00 +0000 Subject: White box / window flicker upon launch Message-ID: It doesn't reproduce for me on windows with JavaFX 11.0.2. Whether this is a bug and/or a regression I cannot say. -----Original Message----- From: Dirk Lemmermann Sent: Thursday, April 23, 2020 10:20 AM To: David Grieve Cc: OpenJFX Subject: [EXTERNAL] Re: White box / window flicker upon launch I tried as you suggested. Problem is still there. > On 23 Apr 2020, at 16:00, David Grieve wrote: > > Another possible workaround is to call Node#applyCss() before stage.show(). There is an example in the Javadoc for the applyCss() method. > > -----Original Message----- > From: openjfx-dev On Behalf Of > Dirk Lemmermann > Sent: Wednesday, April 22, 2020 1:46 PM > To: OpenJFX > Subject: [EXTERNAL] White box / window flicker upon launch > > Hi everyone, > > is it just me or did something change in the launch behaviour of JavaFX applications? It seems we are back to the old ?grey box? bug of Swing where the window would appear first before filling its content. I noticed the same (but white) effect now for my JavaFX apps, especially when running on mobile devices via Gluon. Once I saw it there I paid attention to it and also noticed it when running my desktop apps (on MacOS). I must admit that I am also not certain if it has been different before. Maybe I simply notice it now? > > To verify run this little program. You have to pay close attention but if I am not mistaken then the window first shows up with a white background before showing its content, which is orange. > > Can somebody confirm? If so, I will create a bug ticket. > > Regards, > > Dirk > > > import javafx.application.Application; import javafx.scene.Scene; > import javafx.scene.layout.VBox; import javafx.stage.Stage; > > public class BugDemo extends Application { > > public void start(Stage stage) { > VBox root = new VBox(); > root.setStyle("-fx-background-color: orange;"); > Scene scene = new Scene(root, 1000, 800); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From kevin.rushforth at oracle.com Thu Apr 23 17:40:38 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Apr 2020 10:40:38 -0700 Subject: Gradle support for getting :web:test working properly In-Reply-To: References: Message-ID: <177a75cd-3fe4-7b8c-b5e0-eaa2c7d26a4f@oracle.com> That's an interesting idea that might be worth pursuing. It would help mitigate what has been a long-standing pain point for developers who don't want to build media or web, but would like to run them. I would caution, though, that it is still not a substitute for building both media and WebKit yourself, since it will still not work reliably in the case where there is an interface change or some other mutually dependent change between the native media or web library and Java class files. In those cases you are stuck until a new EA build is available. If you do want to pursue this, then as long as the dependency on org.openjfx:javafx-web and org.openjfx:javafx-media is localized to the downloading and unpacking step you mentioned, this would be fine with me. Maybe others could help test it on Mac and Windows. As for the name of the new property, maybe STUB_RUNTIME_OPENJFX? The easiest way to implement this might be to set the value of `defaultStubRuntime` to the directory into which you unpack it (underneath either build or buildSrc/build). -- Kevin On 4/23/2020 1:14 AM, Jesper Skov wrote: > Hi > > I struggled somewhat to get :web:test running with -PSTUB_RUNTIME. > > The JVM kept crashing by what turned out to be missing media > libraries (the failure message was hidden). > > I tried building with -PCOMPILE_WEBKIT=true, but it takes a terrible > long time on my laptop. And did not in itself fix the problem. > > Frustrations and lost time was the only real outcome of this :) > > > > > So I would suggest adding logic to the build file to allow something > like: > > gradlew -PSTUB_RUNTIME_USE=15-ea+4 all test > > This should download org.openjfx:javafx-web and > org.openjfx:javafx-media artifacts in the specified version. > > Then unpack the shared libraries to a build folder, and make them > availble via the STUB_RUNTIME logic. > > > Plus an addition to the CONTRIBUTING.md documenting this. > > > I would be happy to help make and/or test the changes, but am only > able to work on Linux. > > > Thanks, > Jesper From nlisker at gmail.com Thu Apr 23 19:55:04 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 23 Apr 2020 22:55:04 +0300 Subject: Community request to test 3D performance Message-ID: Hi all, My PR [1] for adding attenuation for PointLight is pending tests from setups with recent NVidia or AMD GPUs. If anyone has such a setup, it would greatly help to get tests results from it. Thanks, Nir [1] https://github.com/openjdk/jfx/pull/43 From nlisker at gmail.com Thu Apr 23 21:41:21 2020 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 24 Apr 2020 00:41:21 +0300 Subject: RE; Community request to test 3D performance In-Reply-To: References: Message-ID: I think so. The test is relatively simple, so it should be worth it. Thanks. On Fri, Apr 24, 2020 at 12:04 AM David Grieve wrote: > I have an NVIDIA Quadro P400. Will that help? > > -----Original Message----- > From: openjfx-dev On Behalf Of Nir > Lisker > Sent: Thursday, April 23, 2020 3:55 PM > To: openjfx-dev at openjdk.java.net Mailing > Subject: [EXTERNAL] Community request to test 3D performance > > Hi all, > > My PR [1] for adding attenuation for PointLight is pending tests from > setups with recent NVidia or AMD GPUs. If anyone has such a setup, it would > greatly help to get tests results from it. > > Thanks, > Nir > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C6fb8b89f9d724c990dd608d7e7c0c848%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232687495430880&sdata=OCgL7t6vDim%2F9Lek4htImF8dMZmzAbETAzmoj91T9SE%3D&reserved=0 > From kevin.rushforth at oracle.com Thu Apr 23 21:59:23 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Apr 2020 14:59:23 -0700 Subject: RE; Community request to test 3D performance In-Reply-To: References: Message-ID: <059277f9-2ffa-6fc4-b2d7-32018af76100@oracle.com> Thanks, David. I presume you will be running Windows? Ideally we would get results on Windows and Mac. Nir: I can upload the modified version of the benchmark, unless you have a working version. -- Kevin On 4/23/2020 2:41 PM, Nir Lisker wrote: > I think so. The test is relatively simple, so it should be worth it. Thanks. > > On Fri, Apr 24, 2020 at 12:04 AM David Grieve > wrote: > >> I have an NVIDIA Quadro P400. Will that help? >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of Nir >> Lisker >> Sent: Thursday, April 23, 2020 3:55 PM >> To: openjfx-dev at openjdk.java.net Mailing >> Subject: [EXTERNAL] Community request to test 3D performance >> >> Hi all, >> >> My PR [1] for adding attenuation for PointLight is pending tests from >> setups with recent NVidia or AMD GPUs. If anyone has such a setup, it would >> greatly help to get tests results from it. >> >> Thanks, >> Nir >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C6fb8b89f9d724c990dd608d7e7c0c848%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232687495430880&sdata=OCgL7t6vDim%2F9Lek4htImF8dMZmzAbETAzmoj91T9SE%3D&reserved=0 >> From nlisker at gmail.com Thu Apr 23 22:04:38 2020 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 24 Apr 2020 01:04:38 +0300 Subject: RE; Community request to test 3D performance In-Reply-To: <059277f9-2ffa-6fc4-b2d7-32018af76100@oracle.com> References: <059277f9-2ffa-6fc4-b2d7-32018af76100@oracle.com> Message-ID: Isn't it this one? https://github.com/openjdk/jfx/pull/43#issuecomment-599080407 On Fri, Apr 24, 2020 at 1:02 AM Kevin Rushforth wrote: > Thanks, David. > > I presume you will be running Windows? Ideally we would get results on > Windows and Mac. > > Nir: I can upload the modified version of the benchmark, unless you have > a working version. > > -- Kevin > > > On 4/23/2020 2:41 PM, Nir Lisker wrote: > > I think so. The test is relatively simple, so it should be worth it. > Thanks. > > > > On Fri, Apr 24, 2020 at 12:04 AM David Grieve < > David.Grieve at microsoft.com> > > wrote: > > > >> I have an NVIDIA Quadro P400. Will that help? > >> > >> -----Original Message----- > >> From: openjfx-dev On Behalf Of > Nir > >> Lisker > >> Sent: Thursday, April 23, 2020 3:55 PM > >> To: openjfx-dev at openjdk.java.net Mailing > >> Subject: [EXTERNAL] Community request to test 3D performance > >> > >> Hi all, > >> > >> My PR [1] for adding attenuation for PointLight is pending tests from > >> setups with recent NVidia or AMD GPUs. If anyone has such a setup, it > would > >> greatly help to get tests results from it. > >> > >> Thanks, > >> Nir > >> > >> [1] > >> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C6fb8b89f9d724c990dd608d7e7c0c848%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232687495430880&sdata=OCgL7t6vDim%2F9Lek4htImF8dMZmzAbETAzmoj91T9SE%3D&reserved=0 > >> > > From github.com+1413266+jgneff at openjdk.java.net Thu Apr 23 22:45:45 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 23 Apr 2020 22:45:45 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Tue, 21 Apr 2020 16:47:44 GMT, Alexander Scherbatiy wrote: > See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html > > The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes > [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) > method code from >> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() > > to > > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" > > so the font size is not properly calculated based on the given DPI value. > > I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On > Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app > works in the same way. I couldn't understand why I wasn't hitting this error on the embedded Monocle EPD platform. Stepping through the code with the debugger, I found that JavaFX is looking for the *javafx.platform.properties* file in the wrong place. I moved the file to its parent directory, the location JavaFX expects, and saw the problem right away. The first image below shows the button and text without the properties file, and the second image shows the problem once the properties file is loaded: ![normal](https://user-images.githubusercontent.com/1413266/80154159-e05ac600-8573-11ea-897b-49a82baaa10f.png) ![toobig](https://user-images.githubusercontent.com/1413266/80154165-e3ee4d00-8573-11ea-8b67-45670b17b7f1.png) So there might be a secondary problem. After unzipping the SDK archive under *$HOME/lib*, the properties file is located at the following location on my system: /home/ubuntu/lib/armv6hf-sdk/lib/javafx.platform.properties Yet [`com.sun.javafx.PlatformUtil.loadProperties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java#L248) looks in the following three locations, in order: /home/ubuntu/lib/armv6hf-sdk/javafx.platform.properties /home/ubuntu/opt/jdk-14.0.1+7/lib/javafx.platform.properties /javafx.platform.properties The first is based on the "runtime directory," the second is based on the value of *java.home*, and the third is based on the value of *javafx.runtime.path*, which is `null` on my system. @AlexanderScherbatiy Did you move the *javafx.platform.properties* file to its parent directory manually, as I just did? ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From github.com+1413266+jgneff at openjdk.java.net Fri Apr 24 00:00:28 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 24 Apr 2020 00:00:28 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 23 Apr 2020 22:43:30 GMT, John Neffenger wrote: >> See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html >> >> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >> [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) >> method code from >>> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() >> >> to >> > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" >> >> so the font size is not properly calculated based on the given DPI value. >> >> I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On >> Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app >> works in the same way. > > I couldn't understand why I wasn't hitting this error on the embedded Monocle EPD platform. Stepping through the code > with the debugger, I found that JavaFX is looking for the *javafx.platform.properties* file in the wrong place. I moved > the file to its parent directory, the location JavaFX expects, and saw the problem right away. The first image below > shows the button and text without the properties file, and the second image shows the problem once the properties file > is loaded: > ![normal](https://user-images.githubusercontent.com/1413266/80154159-e05ac600-8573-11ea-897b-49a82baaa10f.png) > ![toobig](https://user-images.githubusercontent.com/1413266/80154165-e3ee4d00-8573-11ea-8b67-45670b17b7f1.png) So > there might be a secondary problem. After unzipping the SDK archive under *$HOME/lib*, the properties file is located > at the following location on my system: /home/ubuntu/lib/armv6hf-sdk/lib/javafx.platform.properties > > Yet > [`com.sun.javafx.PlatformUtil.loadProperties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java#L248) > looks in the following three locations, in order: /home/ubuntu/lib/armv6hf-sdk/javafx.platform.properties > /home/ubuntu/opt/jdk-14.0.1+7/lib/javafx.platform.properties > /javafx.platform.properties > > The first is based on the "runtime directory," the second is based on the value of *java.home*, and the third is based > on the value of *javafx.runtime.path*, which is `null` on my system. > @AlexanderScherbatiy Did you move the *javafx.platform.properties* file to its parent directory manually, as I just did? Wow, this is going to take some getting used to. ?? Below is a photograph of the button and text with two changes: 1. the code from this pull request, and 2. the `javafx.platform.properties` file moved to its parent directory. ![withfix](https://user-images.githubusercontent.com/1413266/80160191-d344d380-8581-11ea-8fd4-09023ad30610.jpg) The native screen on this platform returns 167 for its DPI. In general, the devices I'm testing have pixel densities of either 167 or 300 pixels per inch. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From nlisker at openjdk.java.net Fri Apr 24 01:23:55 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 24 Apr 2020 01:23:55 GMT Subject: RFR: 8242523: Update the animation and clip envelope classes Message-ID: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging of methods. Summery of changes: ### Animation * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks. * Added `isStopped`, `isRunning` and `isPaused` convenience methods. * Added `runHandler` method to deal with running the handler. * Moved methods to be grouped closer to where they are used rather than by visibility. * Removed the static import for `TickCalculation`. * Various small subjective readability changes. * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily initializing the `cuePoints` map. ### Clip Envelopes * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes. * Rearranged methods order to be consistent. * Replaced the `checkBounds` method with a new overload of `Utils.clamp`. * Renamed `pos` to `cyclePos`. * Extracted common methods: `changedDirection` and `ticksRateChange` * Added internal documentation. Also corrected a typo in `TicksCalculation` and added an explanation for an animation test. ------------- Commit messages: - Removed whitespace - Merge branch 'master' into 8242523_Update_the_Animation_and_ClipEnvelope_classes - Removing cycleNumber for now - Fix typo in TicksCalculation & add an explanation for an animation test - Initial push of 8242523 - Comment out erroneous test - Fix IndefiniteCycleDuration test - Fixed single loop test - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/196/files Webrev: https://webrevs.openjdk.java.net/jfx/196/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242523 Stats: 648 lines in 9 files changed: 336 ins; 174 del; 138 mod Patch: https://git.openjdk.java.net/jfx/pull/196.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/196/head:pull/196 PR: https://git.openjdk.java.net/jfx/pull/196 From github.com+1413266+jgneff at openjdk.java.net Fri Apr 24 01:29:50 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 24 Apr 2020 01:29:50 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 23 Apr 2020 23:58:19 GMT, John Neffenger wrote: >> I couldn't understand why I wasn't hitting this error on the embedded Monocle EPD platform. Stepping through the code >> with the debugger, I found that JavaFX is looking for the *javafx.platform.properties* file in the wrong place. I moved >> the file to its parent directory, the location JavaFX expects, and saw the problem right away. The first image below >> shows the button and text without the properties file, and the second image shows the problem once the properties file >> is loaded: >> ![normal](https://user-images.githubusercontent.com/1413266/80154159-e05ac600-8573-11ea-897b-49a82baaa10f.png) >> ![toobig](https://user-images.githubusercontent.com/1413266/80154165-e3ee4d00-8573-11ea-8b67-45670b17b7f1.png) So >> there might be a secondary problem. After unzipping the SDK archive under *$HOME/lib*, the properties file is located >> at the following location on my system: /home/ubuntu/lib/armv6hf-sdk/lib/javafx.platform.properties >> >> Yet >> [`com.sun.javafx.PlatformUtil.loadProperties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java#L248) >> looks in the following three locations, in order: /home/ubuntu/lib/armv6hf-sdk/javafx.platform.properties >> /home/ubuntu/opt/jdk-14.0.1+7/lib/javafx.platform.properties >> /javafx.platform.properties >> >> The first is based on the "runtime directory," the second is based on the value of *java.home*, and the third is based >> on the value of *javafx.runtime.path*, which is `null` on my system. >> @AlexanderScherbatiy Did you move the *javafx.platform.properties* file to its parent directory manually, as I just did? > > Wow, this is going to take some getting used to. ?? Below is a photograph of the button and text with two changes: > > 1. the code from this pull request, and > 2. the `javafx.platform.properties` file moved to its parent directory. > > ![withfix](https://user-images.githubusercontent.com/1413266/80160191-d344d380-8581-11ea-8fd4-09023ad30610.jpg) > > The native screen on this platform returns 167 for its DPI. In general, the devices I'm testing have pixel densities of > either 167 or 300 pixels per inch. I got out my trusty C-Thru Ruler (GA-96), and the type now measures 12 points, just as intended. **PrismFontFactory.getSystemFontSize** } else if (isEmbedded) { try { int screenDPI = Screen.getMainScreen().getResolutionY(); systemFontSize = ((float) screenDPI) / 6f; // 12 points } catch (NullPointerException npe) { // if no screen is defined systemFontSize = 13f; // same as desktop Linux } } else { systemFontSize = 13f; // Gnome uses 13. } Without the platform properties file, I've been running (for years!) with a default font size of 13 pixels, which on this device is very small: (13 px ? 167 px/in) ? 72 points/in = 5.60 points. Now JavaFX is setting `isEmbedded` to `true`, picking up the correct screen DPI, and I'm finally getting a good default font size: ((167 px/in ? 6 per in) ? 167 px/in) ? 72 points/in = 12.0 points. Amazing. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From kevin.rushforth at oracle.com Fri Apr 24 01:51:15 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Apr 2020 18:51:15 -0700 Subject: RE; Community request to test 3D performance In-Reply-To: References: <059277f9-2ffa-6fc4-b2d7-32018af76100@oracle.com> Message-ID: <1fd2654b-83f6-ebf9-0fcd-8dc9e4a81c22@oracle.com> That one had a compilation error (I think). Anyway, I uploaded a new one that is very slightly modified to allow setting the number of quads via a system property: https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip -- Kevin On 4/23/2020 3:04 PM, Nir Lisker wrote: > Isn't it this one? > https://github.com/openjdk/jfx/pull/43#issuecomment-599080407 > > On Fri, Apr 24, 2020 at 1:02 AM Kevin Rushforth > > wrote: > > Thanks, David. > > I presume you will be running Windows? Ideally we would get > results on > Windows and Mac. > > Nir: I can upload the modified version of the benchmark, unless > you have > a working version. > > -- Kevin > > > On 4/23/2020 2:41 PM, Nir Lisker wrote: > > I think so. The test is relatively simple, so it should be worth > it. Thanks. > > > > On Fri, Apr 24, 2020 at 12:04 AM David Grieve > > > > wrote: > > > >> I have an NVIDIA Quadro P400. Will that help? > >> > >> -----Original Message----- > >> From: openjfx-dev > On Behalf Of Nir > >> Lisker > >> Sent: Thursday, April 23, 2020 3:55 PM > >> To: openjfx-dev at openjdk.java.net > Mailing > > > >> Subject: [EXTERNAL] Community request to test 3D performance > >> > >> Hi all, > >> > >> My PR [1] for adding attenuation for PointLight is pending > tests from > >> setups with recent NVidia or AMD GPUs. If anyone has such a > setup, it would > >> greatly help to get tests results from it. > >> > >> Thanks, > >> Nir > >> > >> [1] > >> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C6fb8b89f9d724c990dd608d7e7c0c848%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232687495430880&sdata=OCgL7t6vDim%2F9Lek4htImF8dMZmzAbETAzmoj91T9SE%3D&reserved=0 > >> > From kcr at openjdk.java.net Fri Apr 24 01:52:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Apr 2020 01:52:26 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> Message-ID: On Sat, 18 Apr 2020 15:45:32 GMT, Kevin Rushforth wrote: >> I discussed this with a graphics engineer. He said that a couple of branches do not have any real performance impact >> even on modern mobile devices, and that, e.g., on iOS 7 using half floats instead of floats was improving shader >> execution dramatically. Desktops with NVIDIA or AMD and even Intel modern cards can process dozens of branches with no >> significant performance degradation. He suggested actually to have all the light types in a single shader file >> (looking ahead here). He also suggested not to permute on shaders based on the number of lights and just pass in a >> uniform for that number and loop over it. The permutations on the bump, specular and self illuminations components are >> correct (not sure we are not doing that for the diffuse component). If we add later shadows, which is not on my near >> to-do list, then we should permute there. It also depends on our target hardware. If we take into account hardware >> from, say, 2005 then maybe branching will cause significant performance loss, but that hinders our ability to increase >> performance for newer hardware. What is the policy here? I have a Win10 laptop with a GeForce 610M that I will test >> this weekend to see if the mobile NVidia cards have some issue. > > I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so > far is on graphics accelerators that are a few years old by now. Integrated graphics chipsets (such as Intel HD) either > old or new seem largely unaffected by the shader changes. What we are missing is performance metrics from newer > graphics accelerators on Mac and Windows. Even with the performance drop on older graphics devices, I'm leaning > towards not having the shaders to be shaders to be doubled, since this is an artificial stress test with huge quads. If > we could get performance data from a couple more recent graphics accelerators that would be best. Here is a slightly modified test program. It fixes a compilation error in the previous, and also adds a system property to set the number of quads: It creates 200 quads by default. If you need to increase this or decrease it to get something in the ~ 10 fps range you can do that with `-DnumQuads=NNNN`. [pointlighttest.zip](https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip) ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From abhinay_agarwal at live.com Fri Apr 24 04:25:11 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 24 Apr 2020 04:25:11 +0000 Subject: Scene Builder Support for javafx 14 In-Reply-To: References: Message-ID: Hi Apurwa, Any FXML created by Scene Builder 11 can be used by JavaFX 14. > I tried downloading the latest version of Scene Builder but its not compatible with javafx. Can you pleases explain what incompatibility issues are you facing? -- Abhinay ________________________________ From: openjfx-dev on behalf of Apurwa Agrawal Sent: Wednesday, April 22, 2020 2:06 PM To: openjfx-dev at openjdk.java.net Subject: Scene Builder Support for javafx 14 Is Scene Builder not supported by Javafx 14? I tried downloading the latest version of Scene Builder but its not compatible with javafx. Thanks and Regards Apurwa Agrawal From prr at openjdk.java.net Fri Apr 24 05:09:08 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 24 Apr 2020 05:09:08 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> Message-ID: <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> On Fri, 24 Apr 2020 01:50:11 GMT, Kevin Rushforth wrote: >> I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so >> far is on graphics accelerators that are a few years old by now. Integrated graphics chipsets (such as Intel HD) either >> old or new seem largely unaffected by the shader changes. What we are missing is performance metrics from newer >> graphics accelerators on Mac and Windows. Even with the performance drop on older graphics devices, I'm leaning >> towards not having the shaders to be shaders to be doubled, since this is an artificial stress test with huge quads. If >> we could get performance data from a couple more recent graphics accelerators that would be best. > > Here is a slightly modified test program. It fixes a compilation error in the previous, and also adds a system property > to set the number of quads: > It creates 200 quads by default. If you need to increase this or decrease it to get something in the ~ 10 fps range you > can do that with `-DnumQuads=NNNN`. > [pointlighttest.zip](https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip) @kevinrushforth Member kevinrushforth commented Apr 18, 2020 I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so far is on graphics accelerators that are a few years old by now. So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent macbook pros ? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From abhinay_agarwal at live.com Fri Apr 24 05:18:20 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 24 Apr 2020 05:18:20 +0000 Subject: Is it possible to customise the theme of the Scene Builder itself? In-Reply-To: References: Message-ID: Hi, Scene Builder is open-sourced [1]. If you find something can be improved, please feel free to send a PR. All the style-sheets use to style Scene Builder can be found in the repository [2]. -- Abhinay [1] https://github.com/gluonhq/scenebuilder [2] https://github.com/gluonhq/scenebuilder/tree/master/kit/src/main/resources/com/oracle/javafx/scenebuilder/kit/css ________________________________ From: openjfx-dev on behalf of Mailing User Sent: Tuesday, April 21, 2020 12:58 AM To: openjfx-dev at openjdk.java.net Subject: Is it possible to customise the theme of the Scene Builder itself? I have downloaded the latest version from a website called Gluon or something. The problem is that the default theme lacks contrast. It looks like grey text on light grey background. Also the font is too small for me. In File -> Preferences, I can see "Scene Builder Theme", but it only has two themes: Default and Dark. The Dark theme also lacks contrast. It looks like grey text on dark grey background. Is there any way to change the colours or the font size of Scene Builder itself, NOT the scene of my application that I am editing with Scene Builder? From abhinay_agarwal at live.com Fri Apr 24 07:14:34 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 24 Apr 2020 07:14:34 +0000 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com>, Message-ID: Hi Ty Young, I am trying to identify which part of the documentation changed after JavaFX 13. The JVM arguments that you have specified are required since JavaFX 11. Alternatively, user doesn't need to pass these arguments if they are using javafx-maven-plugin to build and run the application. I might be missing something here. Can you be kind enough to point me to the specific issue and the related section in docs so that it can be fixed? Thanks in advance. -- Abhinay ________________________________ From: openjfx-dev on behalf of Ty Young Sent: Monday, April 20, 2020 10:07 PM To: openjfx-dev at openjdk.java.net Subject: Re: Remove JavaFX JPMS enforcement On 4/20/20 11:36 AM, Ty Young wrote: > > On 4/20/20 10:47 AM, Mark Raynsford wrote: >> Am I missing something here? What absurd arguments are required for >> Maven projects? >> >> I have multiple applications here running in full module-path mode (the >> applications are modularized, and JavaFX is on the module path), using >> plain Maven builds with no special arguments, and IDEA as the IDE. >> This is on JDK 13, with the 13.0.2 JavaFX release from Central. >> > > From the second warning on this page: > > > https://openjfx.io/openjfx-docs/ > > > That's the absurd part. JavaFX 14 now requires this as a JVM runtime > argument: > > > --module-path /path/to/javafx-sdk-12/lib --add-modules > javafx.controls,javafx.fxml > > > Which wasn't required before. Not only is this a PITA and confusing > but it also prevents Maven from just handling everything. Netbeans > uses a custom file for runtime arguments, which the above is added to. > Also, it gives JavaFX 12 as an example, which is wrong. It should be 14. From alexsch at openjdk.java.net Fri Apr 24 08:22:13 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 24 Apr 2020 08:22:13 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Fri, 24 Apr 2020 01:27:42 GMT, John Neffenger wrote: >> Wow, this is going to take some getting used to. ?? Below is a photograph of the button and text with two changes: >> >> 1. the code from this pull request, and >> 2. the `javafx.platform.properties` file moved to its parent directory. >> >> ![withfix](https://user-images.githubusercontent.com/1413266/80160191-d344d380-8581-11ea-8fd4-09023ad30610.jpg) >> >> The native screen on this platform returns 167 for its DPI. In general, the devices I'm testing have pixel densities of >> either 167 or 300 pixels per inch. > > I got out my trusty C-Thru Ruler (GA-96), and the type now measures 12 points, just as intended. > > **PrismFontFactory.getSystemFontSize** > } else if (isEmbedded) { > try { > int screenDPI = Screen.getMainScreen().getResolutionY(); > systemFontSize = ((float) screenDPI) / 6f; // 12 points > } catch (NullPointerException npe) { > // if no screen is defined > systemFontSize = 13f; // same as desktop Linux > } > } else { > systemFontSize = 13f; // Gnome uses 13. > } > > Without the platform properties file, I've been running (for years!) with a default font size of 13 pixels, which on > this device is very small: (13 px ? 167 px/in) ? 72 points/in = 5.60 points. > Now JavaFX is setting `isEmbedded` to `true`, picking up the correct screen DPI, and I'm finally getting a good default > font size: ((167 px/in ? 6 per in) ? 167 px/in) ? 72 points/in = 12.0 points. Amazing. > @AlexanderScherbatiy Did you move the _javafx.platform.properties_ file to its parent directory manually, as I just did? I used the full version of jdk 14.0.1 on Raspberry Pi where JavaFX is included in jdk so the file _javafx.platform.properties_ is already in jdk-14.0.1-full/lib directory. To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the file _javafx.platform.properties_ from the full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without JavaFX which I used to run my java application with JavaFX modules from armv6hf-sdk/lib. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From youngty1997 at gmail.com Fri Apr 24 12:20:26 2020 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 24 Apr 2020 07:20:26 -0500 Subject: Remove JavaFX JPMS enforcement In-Reply-To: References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> Message-ID: <28aa93d2-861d-0264-eb05-e64916e3bcd9@gmail.com> On 4/24/20 2:14 AM, Abhinay Agarwal wrote: > Hi Ty Young, > > I am trying to identify which part of the documentation changed after > JavaFX 13. The JVM arguments that you have specified are required > since JavaFX 11. Alternatively, user doesn't need to pass these > arguments if they are using javafx-maven-plugin to build and run the > application. > > I might be missing something here. Can you be kind enough to point me > to the specific issue and the related section in docs so that it can > be fixed? Right, so I think I got the issue sorted out. TL;DR, you HAVE to use the archtype. Netbeans WILL NOT adjust its own runtime "nbactions.xml" file if you decided to create a barebones project and add JavaFX later, which is why runtime components are missing and following the advice for Ant will fix the issue. In Netbeans 12.3 Beta(what I'm using now) everything works. In other words, as of Netbeans 12-3, **don't do this**: New Project -> Java with Maven -> Java Application -> add JavaFX from maven central do this: New Project -> Java with Maven -> Simple JavaFX Application Archtype(Gluon) They changed the UI in Netbeans 12-3 beta, so the documentation will need to be updated for it. > > Thanks in advance. > > -- Abhinay > ------------------------------------------------------------------------ > *From:* openjfx-dev on behalf > of Ty Young > *Sent:* Monday, April 20, 2020 10:07 PM > *To:* openjfx-dev at openjdk.java.net > *Subject:* Re: Remove JavaFX JPMS enforcement > > On 4/20/20 11:36 AM, Ty Young wrote: > > > > On 4/20/20 10:47 AM, Mark Raynsford wrote: > >> Am I missing something here? What absurd arguments are required for > >> Maven projects? > >> > >> I have multiple applications here running in full module-path mode (the > >> applications are modularized, and JavaFX is on the module path), using > >> plain Maven builds with no special arguments, and IDEA as the IDE. > >> This is on JDK 13, with the 13.0.2 JavaFX release from Central. > >> > > > > From the second warning on this page: > > > > > > https://openjfx.io/openjfx-docs/ > > > > > > That's the absurd part. JavaFX 14 now requires this as a JVM runtime > > argument: > > > > > > --module-path /path/to/javafx-sdk-12/lib --add-modules > > javafx.controls,javafx.fxml > > > > > > Which wasn't required before. Not only is this a PITA and confusing > > but it also prevents Maven from just handling everything. Netbeans > > uses a custom file for runtime arguments, which the above is added to. > > > > Also, it gives JavaFX 12 as an example, which is wrong. It should be 14. > From abhinay_agarwal at live.com Fri Apr 24 13:19:57 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 24 Apr 2020 13:19:57 +0000 Subject: Remove JavaFX JPMS enforcement In-Reply-To: <28aa93d2-861d-0264-eb05-e64916e3bcd9@gmail.com> References: <9ca264dd-1338-7fb8-ee7c-17ef75187c18@jugs.org> <20200420154750.7a38ec8b@sunflower.int.arc7.info> <480fa5c7-b66d-7ac9-a211-d28816387124@gmail.com> , <28aa93d2-861d-0264-eb05-e64916e3bcd9@gmail.com> Message-ID: Hi Ty Young, Thank you for reverting back. Basic documentation has not changed since JavaFX 11. Since it is difficult to keep up with the ever changing IDEs, we added a disclaimer on the top of each IDE section denoting the JavaFX and IDE version used for the tutorial. And as always, in case you feel something can be improved, feel free to raise a PR [1]. -- Abhinay [1] https://github.com/openjfx/openjfx-docs/ [https://avatars1.githubusercontent.com/u/43116912?s=400&v=4] GitHub - openjfx/openjfx-docs: Getting started guide for JavaFX 11 Getting started guide for JavaFX 11. Contribute to openjfx/openjfx-docs development by creating an account on GitHub. github.com ________________________________ From: openjfx-dev on behalf of Ty Young Sent: Friday, April 24, 2020 5:50 PM To: openjfx-dev at openjdk.java.net Subject: Re: Remove JavaFX JPMS enforcement On 4/24/20 2:14 AM, Abhinay Agarwal wrote: > Hi Ty Young, > > I am trying to identify which part of the documentation changed after > JavaFX 13. The JVM arguments that you have specified are required > since JavaFX 11. Alternatively, user doesn't need to pass these > arguments if they are using javafx-maven-plugin to build and run the > application. > > I might be missing something here. Can you be kind enough to point me > to the specific issue and the related section in docs so that it can > be fixed? Right, so I think I got the issue sorted out. TL;DR, you HAVE to use the archtype. Netbeans WILL NOT adjust its own runtime "nbactions.xml" file if you decided to create a barebones project and add JavaFX later, which is why runtime components are missing and following the advice for Ant will fix the issue. In Netbeans 12.3 Beta(what I'm using now) everything works. In other words, as of Netbeans 12-3, **don't do this**: New Project -> Java with Maven -> Java Application -> add JavaFX from maven central do this: New Project -> Java with Maven -> Simple JavaFX Application Archtype(Gluon) They changed the UI in Netbeans 12-3 beta, so the documentation will need to be updated for it. > > Thanks in advance. > > -- Abhinay > ------------------------------------------------------------------------ > *From:* openjfx-dev on behalf > of Ty Young > *Sent:* Monday, April 20, 2020 10:07 PM > *To:* openjfx-dev at openjdk.java.net > *Subject:* Re: Remove JavaFX JPMS enforcement > > On 4/20/20 11:36 AM, Ty Young wrote: > > > > On 4/20/20 10:47 AM, Mark Raynsford wrote: > >> Am I missing something here? What absurd arguments are required for > >> Maven projects? > >> > >> I have multiple applications here running in full module-path mode (the > >> applications are modularized, and JavaFX is on the module path), using > >> plain Maven builds with no special arguments, and IDEA as the IDE. > >> This is on JDK 13, with the 13.0.2 JavaFX release from Central. > >> > > > > From the second warning on this page: > > > > > > https://openjfx.io/openjfx-docs/ > > > > > > That's the absurd part. JavaFX 14 now requires this as a JVM runtime > > argument: > > > > > > --module-path /path/to/javafx-sdk-12/lib --add-modules > > javafx.controls,javafx.fxml > > > > > > Which wasn't required before. Not only is this a PITA and confusing > > but it also prevents Maven from just handling everything. Netbeans > > uses a custom file for runtime arguments, which the above is added to. > > > > Also, it gives JavaFX 12 as an example, which is wrong. It should be 14. > From arapte at openjdk.java.net Fri Apr 24 14:07:44 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 24 Apr 2020 14:07:44 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: References: Message-ID: On Tue, 21 Apr 2020 12:16:57 GMT, Kevin Rushforth wrote: >> The issue is that ChoiceBoxSkin >> a) doesn't update the text of the label if the value is not contained in the items >> b) doesn't respect converter for label text >> >> Fixed by >> - listening to value changes to update the label >> - removing ad-hoc updates (not needed), added update on converter change >> - passing all label updates through converter >> >> Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, >> so for coveragy, contains also tests that passed before as well as after) > > @aghaisas @arapte can you review? I have not reviewed the code but have only tested it. The value of index is not defined when an uncontained item is selected. With the current implementation (with and without this PR change) there is a difference of behavior when an uncontained item is selected Vs when an existing item is selected, in scenarios as below, => clearSelection() a) scenario 1 1. Select/set an uncontained item. `selectedIndex` would be -1. 2. call `clearSelection()`, Does NOT clear the selected item to null b) scenario 2 1. Select an item at index 2, `selectedIndex` would be 2. 2. Select/set an uncontained item. `selectedIndex` would remain 2. 3. call `clearSelection()`, => clears the selected item to null and selected index to -1 and similarly the difference of behavior can be observed with `selectNext()`, `selectPrevious()` This is not formally documented(nor decided), so we might need to decide on a value of index for an uncontained value. ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From fastegal at openjdk.java.net Fri Apr 24 15:10:10 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 24 Apr 2020 15:10:10 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: References: Message-ID: On Fri, 24 Apr 2020 14:05:27 GMT, Ambarish Rapte wrote: > I have not reviewed the code but have only tested it. Thanks for taking an initial look :) Just keep in mind that this issue is focused on displaying of the box' value reliably. > The value of index is not defined when an uncontained item is selected. yeah the spec is rather .. well, suboptimal at some crucial points (see also [JDK-8088012](https://bugs.openjdk.java.net/browse/JDK-8088012)). To keep the state logically consistent, we need an invariant like: assertEquals(getItems().indexOf(selectedItem), selectedIndex) Which seems to be hinted at in a code comment in `SingleSelectionModel.select(item)`: // if we are here, we did not find the item in the entire data model. // Even still, we allow for this item to be set to the give object. // We expect that in concrete subclasses of this class we observe the // data model such that we check to see if the given item exists in it, // whilst SelectedIndex == -1 && SelectedItem != null. For ChoiceBox, that will be fixed in [JDK-8241999](https://bugs.openjdk.java.net/browse/JDK-8241999) (ready for push as soon as this is integrated). > With the current implementation (with and without this PR change) there is a difference of behavior when an uncontained > item is selected Vs when an existing item is selected, in scenarios as below, > => clearSelection() > a) scenario 1 > > 1. Select/set an uncontained item. `selectedIndex` would be -1. > > 2. call `clearSelection()`, Does NOT clear the selected item to null true, that's spec'ed in ComboBox only .. so by analogy I considered it being the same here. Hmm .. might need an update of the doc? > b) scenario 2 > > 3. Select an item at index 2, `selectedIndex` would be 2. > > 4. Select/set an uncontained item. `selectedIndex` would remain 2. > exactly that is [JDK-8241999](https://bugs.openjdk.java.net/browse/JDK-8241999) > 5. call `clearSelection()`, => clears the selected item to null and selected index to -1 > interesting, hadn't noticed yet - will add a test to the other fix, thanks :) > > and similarly the difference of behavior can be observed with `selectNext()`, `selectPrevious()` > yeah, that's another issue .. selection issues are a bottomless pit .. > This is not formally documented(nor decided), so we might need to decide on a value of index for an uncontained value. see the "natural" constraint above - without we get into hell, IMO. Good points all, thanks again! ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From jskov at zoftcorp.dk Fri Apr 24 15:13:10 2020 From: jskov at zoftcorp.dk (Jesper Skov) Date: Fri, 24 Apr 2020 17:13:10 +0200 Subject: Gradle support for getting :web:test working properly In-Reply-To: <177a75cd-3fe4-7b8c-b5e0-eaa2c7d26a4f@oracle.com> References: <177a75cd-3fe4-7b8c-b5e0-eaa2c7d26a4f@oracle.com> Message-ID: Thanks, I will give it a shot. Jesper On Thu, Apr 23, 2020 at 7:45 PM Kevin Rushforth wrote: > That's an interesting idea that might be worth pursuing. It would help > mitigate what has been a long-standing pain point for developers who > don't want to build media or web, but would like to run them. I would > caution, though, that it is still not a substitute for building both > media and WebKit yourself, since it will still not work reliably in the > case where there is an interface change or some other mutually dependent > change between the native media or web library and Java class files. In > those cases you are stuck until a new EA build is available. > > If you do want to pursue this, then as long as the dependency on > org.openjfx:javafx-web and org.openjfx:javafx-media is localized to the > downloading and unpacking step you mentioned, this would be fine with > me. Maybe others could help test it on Mac and Windows. > > As for the name of the new property, maybe STUB_RUNTIME_OPENJFX? The > easiest way to implement this might be to set the value of > `defaultStubRuntime` to the directory into which you unpack it > (underneath either build or buildSrc/build). > > -- Kevin > > > On 4/23/2020 1:14 AM, Jesper Skov wrote: > > Hi > > > > I struggled somewhat to get :web:test running with -PSTUB_RUNTIME. > > > > The JVM kept crashing by what turned out to be missing media > > libraries (the failure message was hidden). > > > > I tried building with -PCOMPILE_WEBKIT=true, but it takes a terrible > > long time on my laptop. And did not in itself fix the problem. > > > > Frustrations and lost time was the only real outcome of this :) > > > > > > > > > > So I would suggest adding logic to the build file to allow something > > like: > > > > gradlew -PSTUB_RUNTIME_USE=15-ea+4 all test > > > > This should download org.openjfx:javafx-web and > > org.openjfx:javafx-media artifacts in the specified version. > > > > Then unpack the shared libraries to a build folder, and make them > > availble via the STUB_RUNTIME logic. > > > > > > Plus an addition to the CONTRIBUTING.md documenting this. > > > > > > I would be happy to help make and/or test the changes, but am only > > able to work on Linux. > > > > > > Thanks, > > Jesper > From David.Grieve at microsoft.com Fri Apr 24 16:23:40 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 24 Apr 2020 16:23:40 +0000 Subject: Community request to test 3D performance Message-ID: Yes, windows. I can run on a Mac, but it's just a laptop with the standard Intel HD Graphics card. -----Original Message----- From: openjfx-dev On Behalf Of Kevin Rushforth Sent: Thursday, April 23, 2020 5:59 PM To: openjfx-dev at openjdk.java.net Subject: [EXTERNAL] Re: RE; Community request to test 3D performance Thanks, David. I presume you will be running Windows? Ideally we would get results on Windows and Mac. Nir: I can upload the modified version of the benchmark, unless you have a working version. -- Kevin On 4/23/2020 2:41 PM, Nir Lisker wrote: > I think so. The test is relatively simple, so it should be worth it. Thanks. > > On Fri, Apr 24, 2020 at 12:04 AM David Grieve > > wrote: > >> I have an NVIDIA Quadro P400. Will that help? >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of >> Nir Lisker >> Sent: Thursday, April 23, 2020 3:55 PM >> To: openjfx-dev at openjdk.java.net Mailing >> >> Subject: [EXTERNAL] Community request to test 3D performance >> >> Hi all, >> >> My PR [1] for adding attenuation for PointLight is pending tests from >> setups with recent NVidia or AMD GPUs. If anyone has such a setup, it >> would greatly help to get tests results from it. >> >> Thanks, >> Nir >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit >> hub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%4 >> 0microsoft.com%7Cc7e4abcf102f4a570f6208d7e7d1debc%7C72f988bf86f141af9 >> 1ab2d7cd011db47%7C1%7C0%7C637232760879569256&sdata=EF9g8h8jIL6Dzw >> 7s4ZwFIBFIiYuiAgvLErCDQWVhyB4%3D&reserved=0 >> From github.com+1413266+jgneff at openjdk.java.net Fri Apr 24 16:41:19 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 24 Apr 2020 16:41:19 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Fri, 24 Apr 2020 08:20:02 GMT, Alexander Scherbatiy wrote: > To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the file _javafx.platform.properties_ from the > full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without JavaFX which I used to run my java application > with JavaFX modules from armv6hf-sdk/lib. May I then suggest one additional change to this pull request? It's a two-line fix: --- a/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java +++ b/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java @@ -238,8 +238,7 @@ public class PlatformUtil { // Strip everything after the last "/" or "" to get rid of the jar filename int lastIndexOfSlash = Math.max( s.lastIndexOf('/'), s.lastIndexOf('\')); - return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()) - .getParentFile(); + return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()); } catch (MalformedURLException e) { return null; } That change corrects the code to look for the `javafx.platform.properties` file in the same directory as the `javafx.base.jar` file instead of looking for it in the parent directory of the JAR file. I just stepped through the code with this change, and the method `PlatformUtil.loadProperties` now finds the properties file in the location where it is packaged by the build in the SDK. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From github.com+1413266+jgneff at openjdk.java.net Fri Apr 24 17:09:39 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 24 Apr 2020 17:09:39 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Fri, 24 Apr 2020 16:39:07 GMT, John Neffenger wrote: >>> @AlexanderScherbatiy Did you move the _javafx.platform.properties_ file to its parent directory manually, as I just did? >> >> I used the full version of jdk 14.0.1 on Raspberry Pi where JavaFX is included in jdk so the file >> _javafx.platform.properties_ is already in jdk-14.0.1-full/lib directory. >> To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the file _javafx.platform.properties_ from >> the full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without JavaFX which I used to run my java >> application with JavaFX modules from armv6hf-sdk/lib. > >> To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the file _javafx.platform.properties_ from the >> full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without JavaFX which I used to run my java application >> with JavaFX modules from armv6hf-sdk/lib. > > May I then suggest one additional change to this pull request? It's a two-line fix: > > --- a/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java > +++ b/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java > @@ -238,8 +238,7 @@ public class PlatformUtil { > // Strip everything after the last "/" or "" to get rid of the jar filename > int lastIndexOfSlash = Math.max( > s.lastIndexOf('/'), s.lastIndexOf('\')); > - return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()) > - .getParentFile(); > + return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()); > } catch (MalformedURLException e) { > return null; > } > > That change corrects the code to look for the `javafx.platform.properties` file in the same directory as the > `javafx.base.jar` file instead of looking for it in the parent directory of the JAR file. I just stepped through the > code with this change, and the method `PlatformUtil.loadProperties` now finds the properties file in the location where > it is packaged by the build in the SDK. Related issues, including the original request for enhancement: * [JDK-8100775](https://bugs.openjdk.java.net/browse/JDK-8100775): Means of bundling platform specific settings for glass/runtime * [JDK-8115678](https://bugs.openjdk.java.net/browse/JDK-8115678): JavaFX preview on Raspberry Pi requires -Djavafx.platform=eglfb to be set * [JDK-8117705](https://bugs.openjdk.java.net/browse/JDK-8117705): Embedded JavaFX can't find javafx.platform.properties ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From kcr at openjdk.java.net Sat Apr 25 17:09:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 25 Apr 2020 17:09:36 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> Message-ID: <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4esypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> On Fri, 24 Apr 2020 05:06:56 GMT, Phil Race wrote: >> Here is a slightly modified test program. It fixes a compilation error in the previous, and also adds a system property >> to set the number of quads: >> It creates 200 quads by default. If you need to increase this or decrease it to get something in the ~ 10 fps range you >> can do that with `-DnumQuads=NNNN`. >> [pointlighttest.zip](https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip) > > @kevinrushforth > Member > kevinrushforth commented Apr 18, 2020 > > I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so > far is on graphics accelerators that are a few years old by now. > So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent macbook pros ? If this were an even remotely representative use case, then no, the performance hit would not be OK. The test was designed as an artificial "worst-case" stress test: a single mesh with a large number of very large (window-sized) quads stacked on top of each other. Any real-world use case won't do this. We should make sure that we aren't seeing any significant performance drop when rendering spheres (at a couple different tessellation levels) or boxes. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From mp at jugs.org Sat Apr 25 17:32:40 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 25 Apr 2020 19:32:40 +0200 Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4esypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4esypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> Message-ID: Am 25.04.20 um 19:09 schrieb Kevin Rushforth: > On Fri, 24 Apr 2020 05:06:56 GMT, Phil Race wrote: > >>> Here is a slightly modified test program. It fixes a compilation error in the previous, and also adds a system property >>> to set the number of quads: >>> It creates 200 quads by default. If you need to increase this or decrease it to get something in the ~ 10 fps range you >>> can do that with `-DnumQuads=NNNN`. >>> [pointlighttest.zip](https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip) >> @kevinrushforth >> Member >> kevinrushforth commented Apr 18, 2020 >> >> I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so >> far is on graphics accelerators that are a few years old by now. >> So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent macbook pros ? > If this were an even remotely representative use case, then no, the performance hit would not be OK. The test was > designed as an artificial "worst-case" stress test: a single mesh with a large number of very large (window-sized) > quads stacked on top of each other. Any real-world use case won't do this. > > We should make sure that we aren't seeing any significant performance drop when rendering spheres (at a couple > different tessellation levels) or boxes. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/43 Will there also be any performance drop in case you just use the default parameters for the lighting? The default, which corresponds to the current lighting, should not need any additional computations and thus no performance drop. From johan.vos at gluonhq.com Sat Apr 25 18:02:06 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 25 Apr 2020 20:02:06 +0200 Subject: backport request: JDK-8234916 Message-ID: Hi Kevin, I request permission to backport JDK-8234916 ([macos 10.15] Garbled text running with native-image) to OpenJFX 11. The patch applies clean. - Johan From fastegal at openjdk.java.net Sun Apr 26 10:44:26 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 26 Apr 2020 10:44:26 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Sun, 19 Apr 2020 10:37:56 GMT, Craig Cavanaugh wrote: > For me / my users / and the open bug, it is a bug due to the current behavior being unexpected. It creates the > illusion of a preselected value not actually being selected because it's not visible if the list is large and has been > shown. It creates doubt and the user has to scroll to reconfirm their selection which takes extra unnecessary effort > and time. > Yes, I understand the perspective of the users (would be unhappy with it as well) - but from the perspective of the fx, it's the job of the application developer to keep a selected item visible. Which s/he could do easily enough, even for a comboBox. Also I agree, that in the case of the combo it feels unexpected to not the selected item on opening the popup. So we could do something about it - but we have to specify _exactly_ what that something should be. > With my testing, for the ComboBox, behavior was smooth and natural. I've not made any attempt to change selection with > it shown and I'm not certain it can happen unless done programmatically. User selection within the list requires > scrolling, so the selected value is already visible. > Hmm, probably wasn't clear enough: have a combo with many items, open the popup, navigate (via keys like page/up/down ..) and compare the behavior before/after the fix. I see considerable differences in behavior. F.i. keyDown does move the selection one-down without scrolling before and scrolls down by one after (making the selected item visually "stick" at the top). Do you see that as well or did I goof somehow (also a possibility :) ? Navigation behavior should be the same before/after, I think. There might be other behavior changes introduced (didn't check further, it's your issue :), that we should actively look out for. > I'm not opposed to taking this approach. My current work around by extending ComboBox is based on scrolling when the > value is set (restored) programmatically. I could see how it may be more efficient if multiple selections were being > performed programmatically, but not sure why someone would write code this way. I would think it's a one shot process > to select the final value. > not sure what you mean by "one shot process" and "final value": the fix scrolls the list to top whenever the value changes, and the value is changed whenever the selectedItem is changed which happens on navigation (that is user interaction) as well as changing it programatically. Maybe we should really go back to square one and _exactly_ specify when we want the value be scrolled into view. The current fix does so for _each_ selection (which has rather broad effects). If it could be bounded a bit more, the effects would be narrower. That's why I suggested to limit it f.i. to the time of opening the popup (which is rather rare compared to selection change). > Implementing the change in ListView would not change/improve ChoiceBox simply because it does not use an underlying > ListView. yeah, forget about ChoiceBox, I was wrong - whoever needs to scroll to the selected value is using the wrong control .. > My search on uses of ListView only reviled ComboBox other than itself. Since ListView by itself is not > collapsed/hidden for typical uses, would automatic scrolling within ListView create a confusing experience? Ahh, guilty of having been unclear again, sry - what I meant is to add support of doing a well-behaved scrolling in ListView (and the other virtualized controls): scrollTo is not overly well-behaved. And I agree, doing it always and unconditionally, might introduce a bad user experience. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From nlisker at gmail.com Sun Apr 26 19:39:39 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 26 Apr 2020 22:39:39 +0300 Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4esypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> Message-ID: > > Will there also be any performance drop in case you just use the default > parameters for the lighting? That's what we're testing. The default, which corresponds to the current lighting, should not need > any additional computations > and thus no performance drop. But there is no way to know if you're using the default values unless you check for it, and that already is a cost. The only way to guarantee that there is no performance drop is to add a boolean that enables/disables these changes, and that will require generating double the shaders - for the "on" case and for the "off" case. We are trying to avoid this. These changes should be negligible according to "current knowledge", but we have to test. For some reason we saw a drop in one of the hardware configurations that was tested. On Sat, Apr 25, 2020 at 8:33 PM Michael Paus wrote: > Am 25.04.20 um 19:09 schrieb Kevin Rushforth: > > On Fri, 24 Apr 2020 05:06:56 GMT, Phil Race wrote: > > > >>> Here is a slightly modified test program. It fixes a compilation error > in the previous, and also adds a system property > >>> to set the number of quads: > >>> It creates 200 quads by default. If you need to increase this or > decrease it to get something in the ~ 10 fps range you > >>> can do that with `-DnumQuads=NNNN`. > >>> [pointlighttest.zip]( > https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip) > >> @kevinrushforth > >> Member > >> kevinrushforth commented Apr 18, 2020 > >> > >> I think most of those are good suggestions going forward. As for the > performance drop, the only place we've seen it so > >> far is on graphics accelerators that are a few years old by now. > >> So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent > macbook pros ? > > If this were an even remotely representative use case, then no, the > performance hit would not be OK. The test was > > designed as an artificial "worst-case" stress test: a single mesh with a > large number of very large (window-sized) > > quads stacked on top of each other. Any real-world use case won't do > this. > > > > We should make sure that we aren't seeing any significant performance > drop when rendering spheres (at a couple > > different tessellation levels) or boxes. > > > > ------------- > > > > PR: https://git.openjdk.java.net/jfx/pull/43 > > Will there also be any performance drop in case you just use the default > parameters for the lighting? > The default, which corresponds to the current lighting, should not need > any additional computations > and thus no performance drop. > > From ajoseph at openjdk.java.net Mon Apr 27 08:44:23 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 27 Apr 2020 08:44:23 GMT Subject: RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct Message-ID: After [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900), initializeThickness() moved from ScrollBarThemeImpl to ScrollBarWidget but the implementation was kept the same by using testSBRef to call setThickness() for setting ScrollBarTheme.thickness. Modifying initializeThickness() to set ScrollBarTheme.thickness once and removing testSBRef. ------------- Commit messages: - 8171898: [WebView] ScrollBarWidget thickness calculation is not correct Changes: https://git.openjdk.java.net/jfx/pull/197/files Webrev: https://webrevs.openjdk.java.net/jfx/197/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8171898 Stats: 22 lines in 2 files changed: 0 ins; 15 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/197.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/197/head:pull/197 PR: https://git.openjdk.java.net/jfx/pull/197 From alexsch at openjdk.java.net Mon Apr 27 11:11:04 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 27 Apr 2020 11:11:04 GMT Subject: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Fri, 24 Apr 2020 17:07:25 GMT, John Neffenger wrote: >>> To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the file _javafx.platform.properties_ from the >>> full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without JavaFX which I used to run my java application >>> with JavaFX modules from armv6hf-sdk/lib. >> >> May I then suggest one additional change to this pull request? It's a two-line fix: >> >> --- a/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java >> +++ b/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java >> @@ -238,8 +238,7 @@ public class PlatformUtil { >> // Strip everything after the last "/" or "" to get rid of the jar filename >> int lastIndexOfSlash = Math.max( >> s.lastIndexOf('/'), s.lastIndexOf('\')); >> - return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()) >> - .getParentFile(); >> + return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()); >> } catch (MalformedURLException e) { >> return null; >> } >> >> That change corrects the code to look for the `javafx.platform.properties` file in the same directory as the >> `javafx.base.jar` file instead of looking for it in the parent directory of the JAR file. I just stepped through the >> code with this change, and the method `PlatformUtil.loadProperties` now finds the properties file in the location where >> it is packaged by the build in the SDK. > > Related issues, including the original request for enhancement: > > * [JDK-8100775](https://bugs.openjdk.java.net/browse/JDK-8100775): Means of bundling platform specific settings for > glass/runtime > * [JDK-8115678](https://bugs.openjdk.java.net/browse/JDK-8115678): JavaFX preview on Raspberry Pi > requires -Djavafx.platform=eglfb to be set > * [JDK-8117705](https://bugs.openjdk.java.net/browse/JDK-8117705): Embedded JavaFX can't find javafx.platform.properties > > The last two issues listed above were fixed by the following changeset: > > [Fix for RT-28035 (Can't find embedded platform properties) and RT-27194 (Must set > javafx.platform)](https://hg.openjdk.java.net/openjfx/8/master/rt/rev/e4577fd9c0f1) > In JDK 8, all of the Java property files, including `javafx.platform.properties`, are located under the `jre/lib` > directory of the JDK, but the JavaFX 8 JAR file `jfxrt.jar` in found in the subdirectory `jre/lib/ext`. The changeset > above fixed the JavaFX 8 code to look in the parent directory for its properties. Now, though, the JavaFX SDK puts the > JAR file `javafx.base.jar` in the same `lib` directory as the property files, so we need to remove the method call that > changes the path to its parent. > May I then suggest one additional change to this pull request? It's a two-line fix. > That change corrects the code to look for the `javafx.platform.properties` file in the same directory as the > `javafx.base.jar` file instead of looking for it in the parent directory of the JAR file. I have added the fix for `PlatformUtil.getRTDir()` method to the current pull request. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From alexsch at openjdk.java.net Mon Apr 27 11:09:51 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 27 Apr 2020 11:09:51 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: > See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html > > The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes > [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) > method code from >> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() > > to > > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" > > so the font size is not properly calculated based on the given DPI value. > > I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On > Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app > works in the same way. Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Search javafx.platform.properties in jfx-runtime/lib directory ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/193/files - new: https://git.openjdk.java.net/jfx/pull/193/files/2551ce75..058e760a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/193/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/193/webrev.00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/193/head:pull/193 PR: https://git.openjdk.java.net/jfx/pull/193 From arapte at openjdk.java.net Mon Apr 27 11:21:51 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 27 Apr 2020 11:21:51 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: References: Message-ID: On Fri, 24 Apr 2020 15:07:59 GMT, Jeanette Winzenburg wrote: > Which seems to be hinted at in a code comment in `SingleSelectionModel.select(item)`: I agree that selectedIndex should be -1 for an uncontained value, so that the below condition always holds true. And this is already working well with ComboBox. `assertEquals(getItems().indexOf(selectedItem), selectedIndex)` The fix for [JDK-8241999](https://bugs.openjdk.java.net/browse/JDK-8241999) would solve most of the behavior differences of contained Vs uncontained item selection. (that I was looking at selectPrevious(), selectNext()). > true, that's spec'ed in ComboBox only .. so by analogy I considered it being the same here. Hmm .. might need an update > of the doc? Thanks for the the pointer, After reading it, I have a doubtful understanding about it as, that, The spec is only about `ComboBox.valueProperty()` and not about `SelectionModel.selectedIndex` or `SelectionModel.selectedItem`. so clearSelection() can/should clear the SelectionModel state but should not clear ComboBox.valueProperty(). And ComboBox does not follow this spec, In below scenario `ComboBox.valueProperty()` is cleared to NULL. `comboBox.getSelectionModel().select(comboBox.getItems(1));` `comboBox.getSelectionModel().clearSelection();` => clears the SelectionModel.selectedIndex to -1, SelectionModel.selectedItem and ComboBox.getValue() to NULL. So I think, for ChoieBox, In addition to doc change we would need fix the behavior as well, and maintain same behavior of `clearSelection()` with contained and uncontained items. But again this is a different issue and not related to this fix. So the fix itself looks good to me along with the upcoming fix for [JDK-8241999](https://bugs.openjdk.java.net/browse/JDK-8241999). ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From arapte at openjdk.java.net Mon Apr 27 11:21:51 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 27 Apr 2020 11:21:51 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: References: Message-ID: <7lwXsqpWkO9xrCczNsTBVY0z7pciuFonDCOcLzZOdAA=.7ef868a8-bbba-42f8-a81e-192f96a581de@github.com> On Mon, 20 Apr 2020 12:23:16 GMT, Jeanette Winzenburg wrote: > The issue is that ChoiceBoxSkin > a) doesn't update the text of the label if the value is not contained in the items > b) doesn't respect converter for label text > > Fixed by > - listening to value changes to update the label > - removing ad-hoc updates (not needed), added update on converter change > - passing all label updates through converter > > Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, > so for coveragy, contains also tests that passed before as well as after) Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From jhendrikx at openjdk.java.net Mon Apr 27 11:48:25 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 27 Apr 2020 11:48:25 GMT Subject: RFR: 8243115: Unregister bindings when unbind called multiple times Message-ID: This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first. I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail. ------------- Commit messages: - 8243115: Unregister bindings when unbind called multiple times Changes: https://git.openjdk.java.net/jfx/pull/198/files Webrev: https://webrevs.openjdk.java.net/jfx/198/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243115 Stats: 206 lines in 9 files changed: 147 ins; 43 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/198.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/198/head:pull/198 PR: https://git.openjdk.java.net/jfx/pull/198 From aghaisas at openjdk.java.net Mon Apr 27 12:03:32 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Apr 2020 12:03:32 GMT Subject: RFR: 8175358: Memory leak when moving MenuButton into another Scene Message-ID: Issue : https://bugs.openjdk.java.net/browse/JDK-8175358 Root cause : When a MenuItem is removed from a Scene, if any accelerator has been set on MenuItem, it does not get removed from Scene's list of accelerators. Fix : If Scene changes for a Menu, remove the registered accelerators from Scene. Testing : Added a unit test that fails before the fix and passes with it. ------------- Commit messages: - menuItem_accelerator_fix Changes: https://git.openjdk.java.net/jfx/pull/199/files Webrev: https://webrevs.openjdk.java.net/jfx/199/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8175358 Stats: 46 lines in 2 files changed: 44 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/199.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/199/head:pull/199 PR: https://git.openjdk.java.net/jfx/pull/199 From aghaisas at openjdk.java.net Mon Apr 27 12:34:45 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Apr 2020 12:34:45 GMT Subject: [Rev 02] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: <5MRc8JtCra7FDIIt9NMHXprhbKHUKEcUynHva4FLHR4=.f6086b9a-f822-4bf2-82fd-6753e5bbcade@github.com> On Thu, 23 Apr 2020 11:32:26 GMT, John Hendrikx wrote: >> This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. > > John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 432: > 431: // line spacing wouldn't fit, the height used for the calculation > 432: // is increase here with the line spacing amount. > 433: increase -> increased ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From aghaisas at openjdk.java.net Mon Apr 27 12:35:11 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Apr 2020 12:35:11 GMT Subject: [Rev 01] RFR: 8175358: Memory leak when moving MenuButton into another Scene In-Reply-To: References: Message-ID: <80QsZzE5X1-HnY9LQZ-COezkq7wGC0KgezI60wuQrhc=.071a905a-425a-476e-8e53-eb30dfa18ac8@github.com> > Issue : https://bugs.openjdk.java.net/browse/JDK-8175358 > > Root cause : When a MenuItem is removed from a Scene, if any accelerator has been set on MenuItem, it does not get > removed from Scene's list of accelerators. > Fix : If Scene changes for a Menu, remove the registered accelerators from Scene. > > Testing : Added a unit test that fails before the fix and passes with it. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: spelling_correction ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/199/files - new: https://git.openjdk.java.net/jfx/pull/199/files/e18b0cc9..8e3cfd25 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/199/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/199/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/199.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/199/head:pull/199 PR: https://git.openjdk.java.net/jfx/pull/199 From kevin.rushforth at oracle.com Mon Apr 27 13:05:11 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 27 Apr 2020 06:05:11 -0700 Subject: backport request: JDK-8234916 In-Reply-To: References: Message-ID: <6494d890-59d1-c469-0087-594b9867a9db@oracle.com> +1 On 4/25/2020 11:02 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport JDK-8234916 ([macos 10.15] Garbled text > running with native-image) to OpenJFX 11. > > The patch applies clean. > > - Johan From kcr at openjdk.java.net Mon Apr 27 13:16:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Apr 2020 13:16:01 GMT Subject: RFR: 8243115: Unregister bindings when unbind called multiple times In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 11:43:28 GMT, John Hendrikx wrote: > This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in > subsequent unbind calls to be no-ops, unless bind was called again first. > I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new > test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other > tests fail. The title of this PR should match exactly the title of the JBS bug. So: 8243115: Spurious invalidations due to bug in IntegerBinding and other classes ------------- PR: https://git.openjdk.java.net/jfx/pull/198 From kcr at openjdk.java.net Mon Apr 27 13:22:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Apr 2020 13:22:12 GMT Subject: RFR: 8243115: Unregister bindings when unbind called multiple times In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 13:13:44 GMT, Kevin Rushforth wrote: >> This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in >> subsequent unbind calls to be no-ops, unless bind was called again first. >> I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new >> test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other >> tests fail. > > The title of this PR should match exactly the title of the JBS bug. So: > > 8243115: Spurious invalidations due to bug in IntegerBinding and other classes @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/198 From jhendrikx at openjdk.java.net Mon Apr 27 14:02:42 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 27 Apr 2020 14:02:42 GMT Subject: [Rev 03] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: > This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix typo in comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/173/files - new: https://git.openjdk.java.net/jfx/pull/173/files/20ccd127..8fa8f3f0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/173/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/173/webrev.02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/173/head:pull/173 PR: https://git.openjdk.java.net/jfx/pull/173 From fastegal at openjdk.java.net Mon Apr 27 14:47:27 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 27 Apr 2020 14:47:27 GMT Subject: RFR: 8175358: Memory leak when moving MenuButton into another Scene In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 11:57:58 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8175358 > > Root cause : When a MenuItem is removed from a Scene, if any accelerator has been set on MenuItem, it does not get > removed from Scene's list of accelerators. > Fix : If Scene changes for a Menu, remove the registered accelerators from Scene. > > Testing : Added a unit test that fails before the fix and passes with it. fix looks good to me :) Seeing the code, I think we have two follow-up issues (not introduced here, they just jump to visibility in the light of reading the code and recent fixes around memory leaks :) - the listener to the control's sceneProperty is never removed, introducing a memory leak, a fix could be similar to that of the recently [fixed JDK-8236840](https://bugs.openjdk.java.net/browse/JDK-8236840) - we have the exact same issue with accelerators in a contextMenu of a control that's removed from the scene (the accelerators are still active, as can be seen in adapting your test method). Not sure which collaborator should be responsible for the cleanup, could be the helper class, the control, or ? ------------- PR: https://git.openjdk.java.net/jfx/pull/199 From fastegal at openjdk.java.net Mon Apr 27 14:47:27 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 27 Apr 2020 14:47:27 GMT Subject: [Rev 01] RFR: 8175358: Memory leak when moving MenuButton into another Scene In-Reply-To: <80QsZzE5X1-HnY9LQZ-COezkq7wGC0KgezI60wuQrhc=.071a905a-425a-476e-8e53-eb30dfa18ac8@github.com> References: <80QsZzE5X1-HnY9LQZ-COezkq7wGC0KgezI60wuQrhc=.071a905a-425a-476e-8e53-eb30dfa18ac8@github.com> Message-ID: On Mon, 27 Apr 2020 12:35:11 GMT, Ajit Ghaisas wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8175358 >> >> Root cause : When a MenuItem is removed from a Scene, if any accelerator has been set on MenuItem, it does not get >> removed from Scene's list of accelerators. >> Fix : If Scene changes for a Menu, remove the registered accelerators from Scene. >> >> Testing : Added a unit test that fails before the fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > spelling_correction forgot to formally start a review - and approving it :) ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/199 From arapte at openjdk.java.net Mon Apr 27 15:11:28 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 27 Apr 2020 15:11:28 GMT Subject: [Rev 04] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 12:03:34 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > The tests are now reused for native and monocle tests. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 1325: > 1324: this.isFocused = focused; > 1325: if (this.isFocused && this.isVisible) { > 1326: setFocusedWindow(this); On my Window10 machine, with this change, `Window.focusedWindow` remains `null` even after the first window is shown onto the screen and is focused. And It continues to remain `null` until some mouse or key action is performed on the window. I am not sure if this causes any side effects. It looks like the `Window.focusedWindow` is mostly(only) used for Monocle. Can you please confirm the behavior that `Window.focusedWindow` remain `null` and check for any side effects. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From github.com+1413266+jgneff at openjdk.java.net Mon Apr 27 15:51:47 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 27 Apr 2020 15:51:47 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 11:09:51 GMT, Alexander Scherbatiy wrote: >> See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html >> >> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >> [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) >> method code from >>> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() >> >> to >> > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" >> >> so the font size is not properly calculated based on the given DPI value. >> >> I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On >> Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app >> works in the same way. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Search javafx.platform.properties in jfx-runtime/lib directory Thanks, Alexander! I just tested your pull request again, and JavaFX is now picking up the properties file along with the correct native screen DPI on my Monocle ARM platform. ------------- Marked as reviewed by jgneff at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jfx/pull/193 From David.Grieve at microsoft.com Mon Apr 27 15:53:48 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Mon, 27 Apr 2020 15:53:48 +0000 Subject: Community request to test 3D performance Message-ID: Results with NVIDIA Quadro P400: Without the fix, 1000 quads, average FPS ~7.4 With the fix, 1000 quads, average FPS ~6.1 (this is with Kevin?s pointlighttest.zip) From: Nir Lisker Sent: Thursday, April 23, 2020 5:41 PM To: David Grieve ; openjfx-dev at openjdk.java.net Mailing Subject: [EXTERNAL] Re: RE; Community request to test 3D performance I think so. The test is relatively simple, so it should be worth it. Thanks. On Fri, Apr 24, 2020 at 12:04 AM David Grieve > wrote: I have an NVIDIA Quadro P400. Will that help? -----Original Message----- From: openjfx-dev > On Behalf Of Nir Lisker Sent: Thursday, April 23, 2020 3:55 PM To: openjfx-dev at openjdk.java.net Mailing > Subject: [EXTERNAL] Community request to test 3D performance Hi all, My PR [1] for adding attenuation for PointLight is pending tests from setups with recent NVidia or AMD GPUs. If anyone has such a setup, it would greatly help to get tests results from it. Thanks, Nir [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43&data=02%7C01%7CDavid.Grieve%40microsoft.com%7C6fb8b89f9d724c990dd608d7e7c0c848%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232687495430880&sdata=OCgL7t6vDim%2F9Lek4htImF8dMZmzAbETAzmoj91T9SE%3D&reserved=0 From dgrieve at openjdk.java.net Mon Apr 27 15:54:32 2020 From: dgrieve at openjdk.java.net (David Grieve) Date: Mon, 27 Apr 2020 15:54:32 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4esypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> Message-ID: <8eDtHNzZdUjbVCCf0O8QZuu18gqoJ_vg1jhJVoWVtgg=.76214dc6-564b-4e13-a91b-8831d1556639@github.com> On Sat, 25 Apr 2020 17:07:21 GMT, Kevin Rushforth wrote: >> @kevinrushforth >> Member >> kevinrushforth commented Apr 18, 2020 >> >> I think most of those are good suggestions going forward. As for the performance drop, the only place we've seen it so >> far is on graphics accelerators that are a few years old by now. >> So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent macbook pros ? > > If this were an even remotely representative use case, then no, the performance hit would not be OK. The test was > designed as an artificial "worst-case" stress test: a single mesh with a large number of very large (window-sized) > quads stacked on top of each other. Any real-world use case won't do this. We should make sure that we aren't seeing > any significant performance drop when rendering spheres (at a couple different tessellation levels) or boxes. Results with NVIDIA Quadro P400: Without the fix, 1000 quads, average FPS ~7.4 With the fix, 1000 quads, average FPS ~6.1 ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From jvos at openjdk.java.net Mon Apr 27 17:45:23 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 27 Apr 2020 17:45:23 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 15:49:31 GMT, John Neffenger wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Search javafx.platform.properties in jfx-runtime/lib directory > > Thanks, Alexander! I just tested your pull request again, and JavaFX is now picking up the properties file along with > the correct native screen DPI on my Monocle ARM platform. > > @AlexanderScherbatiy Did you move the _javafx.platform.properties_ file to its parent directory manually, as I just did? > > I used the full version of jdk 14.0.1 on Raspberry Pi where JavaFX is included in jdk so the file > _javafx.platform.properties_ is already in jdk-14.0.1-full/lib directory. > To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the file _javafx.platform.properties_ from the > full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without JavaFX which I used to run my java application > with JavaFX modules from armv6hf-sdk/lib. I'm confused by this, what is the full version of JDK 14.0.1? JavaFX is not part of the JDK anymore, therefore I don't expect a javafx.platform.properties in the JDK. Iif this is the case, it seems a serious bug to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From jvos at openjdk.java.net Mon Apr 27 17:49:48 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 27 Apr 2020 17:49:48 GMT Subject: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 19:11:19 GMT, John Neffenger wrote: >> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements >> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* >> repository. Some of the changes were made to support the new device models, while others are minor changes to the >> existing support in JavaFX 13. The following changes were made to support the new device models. >> * Work around problems on the Kobo Glo HD Model N437. >> >> Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is >> ignored by the driver on the Kobo Glo HD where the error occurs, anyway. >> >> Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of >> the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame >> buffer device driver can be an incorrect value. >> >> * Work around problems on the Kobo Clara HD Model N249. >> >> The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the >> normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The >> work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. >> >> The following changes were made to the existing code that supports e-paper displays in JavaFX 13. >> >> * Use the correct constant for the number of bytes per pixel. >> >> Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when >> calculating the capacity of the 32-bit off-screen byte buffer. >> >> * Do not round the luma value to the nearest integer. >> >> Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of >> rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 >> percent and doesn't seem worth it for a display with just 16 levels of gray. >> >> * Change camel case of system property *y8inverted*. >> >> Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it >> is consistent with the other system properties containing Y1, Y4, and Y8 in their names. >> >> * Improve error handling when mapping the frame buffer. >> >> Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a >> `null` return value from `EPDFrameBuffer.getMappedBuffer`. >> >> * Replace non-ASCII characters with their ASCII equivalent. >> >> Replace non-ASCII characters in comments and log messages as follows: >> >> * "?" with "x" for display resolution and color depth, >> * "?" with "*" for multiplication, >> * "?" with "to" for transition, and >> * "?C" with "degrees Celsius" for temperature. >> >> * Add descriptions to Monocle EPD system properties. >> >> Add Javadoc comments to each constant that defines a Monocle EPD system property. >> >> * Rename `IntStructure.getInteger` to `IntStructure.get`. >> >> Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method >> `Integer.getInteger`, which gets the integer value of a system property. >> >> Below are some of the more interesting test results. >> >> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray >> values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. >> >> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black >> for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that >> displays black for values `0x7F` or less and white for values `0x80` or greater. >> >> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the >> tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame >> buffer. I plan to investigate the cause of the performance difference. >> >> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold >> increase in the number of pixels in their displays. The table below shows the animation speed of each model in >> milliseconds per frame and frames per second. >> >> | Product Name | Speed (ms) | Rate (fps) | >> | ------------- |:----------:|:----------:| >> | Kobo Touch B | 125 | 8.0 | >> | Kobo Touch C | 130 | 7.7 | >> | Kobo Glo HD | 140 | 7.1 | >> | Kobo Clara HD | 145 | 6.9 | > > John Neffenger has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. The pull request contains one new commit since > the last revision: > 8227425: Add support for e-paper displays on i.MX6 devices Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From alexsch at openjdk.java.net Mon Apr 27 18:14:09 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 27 Apr 2020 18:14:09 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 17:43:09 GMT, Johan Vos wrote: > I'm confused by this, what is the full version of JDK 14.0.1? JavaFX is not part of the JDK anymore, therefore I don't > expect a javafx.platform.properties in the JDK. Iif this is the case, it seems a serious bug to me. I used non Oracle jdk 14.0.1 build which full version includes JavaFX. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From arapte at openjdk.java.net Mon Apr 27 18:49:07 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 27 Apr 2020 18:49:07 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: On Sun, 19 Apr 2020 09:51:07 GMT, Jesper Skov wrote: >> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. >> >> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 > > Jesper Skov has updated the pull request incrementally with three additional commits since the last revision: > > - Fail instead of print message > - addedToggles list is final > - Leave unrelated file alone Fix and tests look good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/167 From kcr at openjdk.java.net Mon Apr 27 23:25:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Apr 2020 23:25:32 GMT Subject: [Rev 01] RFR: 8175358: Memory leak when moving MenuButton into another Scene In-Reply-To: References: <80QsZzE5X1-HnY9LQZ-COezkq7wGC0KgezI60wuQrhc=.071a905a-425a-476e-8e53-eb30dfa18ac8@github.com> Message-ID: On Mon, 27 Apr 2020 14:45:19 GMT, Jeanette Winzenburg wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> spelling_correction > > forgot to formally start a review - and approving it :) @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/199 From kcr at openjdk.java.net Mon Apr 27 23:32:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Apr 2020 23:32:28 GMT Subject: RFR: 8242523: Update the animation and clip envelope classes In-Reply-To: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com> References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com> Message-ID: On Fri, 24 Apr 2020 00:58:30 GMT, Nir Lisker wrote: > Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging > of methods. Summery of changes: > ### Animation > * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks. > * Added `isStopped`, `isRunning` and `isPaused` convenience methods. > * Added `runHandler` method to deal with running the handler. > * Moved methods to be grouped closer to where they are used rather than by visibility. > * Removed the static import for `TickCalculation`. > * Various small subjective readability changes. > * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily > initializing the `cuePoints` map. > > ### Clip Envelopes > * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes. > * Rearranged methods order to be consistent. > * Replaced the `checkBounds` method with a new overload of `Utils.clamp`. > * Renamed `pos` to `cyclePos`. > * Extracted common methods: `changedDirection` and `ticksRateChange` > * Added internal documentation. > > Also corrected a typo in `TicksCalculation` and added an explanation for an animation test. @arapte can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/196 From nlisker at openjdk.java.net Mon Apr 27 23:34:20 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 27 Apr 2020 23:34:20 GMT Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding and other classes In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 13:19:49 GMT, Kevin Rushforth wrote: >> The title of this PR should match exactly the title of the JBS bug. So: >> >> 8243115: Spurious invalidations due to bug in IntegerBinding and other classes > > @arapte can you also review this? I will review this too anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/198 From kcr at openjdk.java.net Mon Apr 27 23:54:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Apr 2020 23:54:00 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 11:09:51 GMT, Alexander Scherbatiy wrote: >> See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html >> >> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >> [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) >> method code from >>> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() >> >> to >> > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" >> >> so the font size is not properly calculated based on the given DPI value. >> >> I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On >> Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app >> works in the same way. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Search javafx.platform.properties in jfx-runtime/lib directory modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java line 241: > 240: s.lastIndexOf('/'), s.lastIndexOf('\\')); > 241: return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()); > 242: } catch (MalformedURLException e) { The previous code looks like a hold-over from JDK 8, where jfxrt.jar was in `lib/ext`. It also assumes that the JavaFX runtime is being loaded from a jar URL, which isn't necessarily the case. Probably the only reason it hasn't caused problems before now is that it is only used to locate `javafx.platform.properties`. Worth noting is that we won't get here in the case JavaFX is jlinked into the Java runtime, although in that case, the fallback method of locating it relative to the JDK should be used. I'll take a closer look this specific change, but I think it should be OK. I'll defer the review as a whole to Johan. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From kcr at openjdk.java.net Mon Apr 27 23:58:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Apr 2020 23:58:45 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms In-Reply-To: References: Message-ID: On Mon, 20 Apr 2020 05:40:51 GMT, Arun Joseph wrote: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Since this is in a common method used by all shapes, and not just WebView, we will need to ensure no regressions. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From kcr at openjdk.java.net Tue Apr 28 00:02:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 00:02:37 GMT Subject: RFR: 8243115: Spurious invalidations due to bug in IntegerBinding and other classes In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 23:32:04 GMT, Nir Lisker wrote: > I will review this too anyway. Thank you. That will be helpful. ------------- PR: https://git.openjdk.java.net/jfx/pull/198 From arapte at openjdk.java.net Tue Apr 28 04:40:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 28 Apr 2020 04:40:06 GMT Subject: [Rev 01] RFR: 8175358: Memory leak when moving MenuButton into another Scene In-Reply-To: <80QsZzE5X1-HnY9LQZ-COezkq7wGC0KgezI60wuQrhc=.071a905a-425a-476e-8e53-eb30dfa18ac8@github.com> References: <80QsZzE5X1-HnY9LQZ-COezkq7wGC0KgezI60wuQrhc=.071a905a-425a-476e-8e53-eb30dfa18ac8@github.com> Message-ID: On Mon, 27 Apr 2020 12:35:11 GMT, Ajit Ghaisas wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8175358 >> >> Root cause : When a MenuItem is removed from a Scene, if any accelerator has been set on MenuItem, it does not get >> removed from Scene's list of accelerators. >> Fix : If Scene changes for a Menu, remove the registered accelerators from Scene. >> >> Testing : Added a unit test that fails before the fix and passes with it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > spelling_correction Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/199 From aghaisas at openjdk.java.net Tue Apr 28 06:24:33 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 28 Apr 2020 06:24:33 GMT Subject: [Rev 03] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 14:02:42 GMT, John Hendrikx wrote: >> This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comment Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From aghaisas at openjdk.java.net Tue Apr 28 07:11:26 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 28 Apr 2020 07:11:26 GMT Subject: RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: <7lwXsqpWkO9xrCczNsTBVY0z7pciuFonDCOcLzZOdAA=.7ef868a8-bbba-42f8-a81e-192f96a581de@github.com> References: <7lwXsqpWkO9xrCczNsTBVY0z7pciuFonDCOcLzZOdAA=.7ef868a8-bbba-42f8-a81e-192f96a581de@github.com> Message-ID: On Mon, 27 Apr 2020 11:19:33 GMT, Ambarish Rapte wrote: >> The issue is that ChoiceBoxSkin >> a) doesn't update the text of the label if the value is not contained in the items >> b) doesn't respect converter for label text >> >> Fixed by >> - listening to value changes to update the label >> - removing ad-hoc updates (not needed), added update on converter change >> - passing all label updates through converter >> >> Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, >> so for coveragy, contains also tests that passed before as well as after) > > Marked as reviewed by arapte (Reviewer). The fix is OK. Test file header should have year 2020 and not 2019. ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From fastegal at openjdk.java.net Tue Apr 28 09:38:56 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 28 Apr 2020 09:38:56 GMT Subject: [Rev 01] RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: References: Message-ID: <2R_F5rtPbf9j2Z0LGXKtW_DjOOHMTnsjDCCozDODirY=.876b7048-5516-457e-aab1-fc72ae9002c0@github.com> > The issue is that ChoiceBoxSkin > a) doesn't update the text of the label if the value is not contained in the items > b) doesn't respect converter for label text > > Fixed by > - listening to value changes to update the label > - removing ad-hoc updates (not needed), added update on converter change > - passing all label updates through converter > > Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, > so for coveragy, contains also tests that passed before as well as after) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/191/files - new: https://git.openjdk.java.net/jfx/pull/191/files/e7f9e398..9b9a28a9 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/191/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/191/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/191.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/191/head:pull/191 PR: https://git.openjdk.java.net/jfx/pull/191 From aghaisas at openjdk.java.net Tue Apr 28 10:06:57 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 28 Apr 2020 10:06:57 GMT Subject: [Rev 01] RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: <2R_F5rtPbf9j2Z0LGXKtW_DjOOHMTnsjDCCozDODirY=.876b7048-5516-457e-aab1-fc72ae9002c0@github.com> References: <2R_F5rtPbf9j2Z0LGXKtW_DjOOHMTnsjDCCozDODirY=.876b7048-5516-457e-aab1-fc72ae9002c0@github.com> Message-ID: On Tue, 28 Apr 2020 09:38:56 GMT, Jeanette Winzenburg wrote: >> The issue is that ChoiceBoxSkin >> a) doesn't update the text of the label if the value is not contained in the items >> b) doesn't respect converter for label text >> >> Fixed by >> - listening to value changes to update the label >> - removing ad-hoc updates (not needed), added update on converter change >> - passing all label updates through converter >> >> Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, >> so for coveragy, contains also tests that passed before as well as after) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright year Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From fastegal at swingempire.de Tue Apr 28 11:18:07 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 28 Apr 2020 13:18:07 +0200 Subject: Automate copyright year? In-Reply-To: <5cbbcdc4-913f-df30-df9d-6204c23da6da@oracle.com> References: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> <5cbbcdc4-913f-df30-df9d-6204c23da6da@oracle.com> Message-ID: <20200428131807.Horde.jzhhLYRVydtt-zMaXu28nw2@webmail.df.eu> Okay, thanks for the info :) Then we might decide not to request a change in review if only the copyright is not updated? If the second reviewers does it after the first already approved, the first has to re-approve - additional bureaucratic work and might lead to a bit of time lag across continents. Not such a big deal, but if it doesn't really matter .. -- Jeanette Zitat von Kevin Rushforth : > Not that I know of. FWIW, I'm not too bothered by this, since I run > a script 2-3 times a year to update the copyright years for those > files fixed in the current year. > > -- Kevin > > > On 4/13/2020 3:48 AM, Jeanette Winzenburg wrote: >> >> Seeing that missing to update of copyright year in the header is >> rather common (in my own pull requests as well as in others :) is >> there any means to do so automatically or some source tool (for me >> that would be for Eclipse) that would do on request? >> >> -- Jeanette >> From ghb at openjdk.java.net Tue Apr 28 11:57:08 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 28 Apr 2020 11:57:08 GMT Subject: RFR: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine In-Reply-To: References: Message-ID: On Sun, 19 Apr 2020 08:12:07 GMT, Abhinay Agarwal wrote: > Update WebEngine's Javadoc to add information on how it switches to HttpClient instead of URLConnection in JavaFX 14 > when used with JDK 12 or later. > Identification of the correct client is important as both these clients may offer different ways to achieve a task. One > such task can be bypassing insecure HTTPS connection. looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/189 From arapte at openjdk.java.net Tue Apr 28 12:17:35 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 28 Apr 2020 12:17:35 GMT Subject: [Rev 01] RFR: 8087555: [ChoiceBox] uncontained value not shown In-Reply-To: <2R_F5rtPbf9j2Z0LGXKtW_DjOOHMTnsjDCCozDODirY=.876b7048-5516-457e-aab1-fc72ae9002c0@github.com> References: <2R_F5rtPbf9j2Z0LGXKtW_DjOOHMTnsjDCCozDODirY=.876b7048-5516-457e-aab1-fc72ae9002c0@github.com> Message-ID: On Tue, 28 Apr 2020 09:38:56 GMT, Jeanette Winzenburg wrote: >> The issue is that ChoiceBoxSkin >> a) doesn't update the text of the label if the value is not contained in the items >> b) doesn't respect converter for label text >> >> Fixed by >> - listening to value changes to update the label >> - removing ad-hoc updates (not needed), added update on converter change >> - passing all label updates through converter >> >> Added test for text updates that failed before the fix and pass after (note: there were no tests for the display text, >> so for coveragy, contains also tests that passed before as well as after) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright year Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/191 From kevin.rushforth at oracle.com Tue Apr 28 12:55:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 28 Apr 2020 05:55:52 -0700 Subject: Automate copyright year? In-Reply-To: <20200428131807.Horde.jzhhLYRVydtt-zMaXu28nw2@webmail.df.eu> References: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> <5cbbcdc4-913f-df30-df9d-6204c23da6da@oracle.com> <20200428131807.Horde.jzhhLYRVydtt-zMaXu28nw2@webmail.df.eu> Message-ID: <9699b25d-cf52-33a2-97ee-a1409fadcd41@oracle.com> > Then we might decide not to request a change in review if only the copyright is not updated? Yes, this is a good idea. I don't generally flag this in my reviews, for example. The exceptions would be: 1) if a new file springs to life with the wrong initial copyright year; 2) if an incorrect update was made to a copyright year. -- Kevin On 4/28/2020 4:18 AM, Jeanette Winzenburg wrote: > > Okay, thanks for the info :) > > Then we might decide not to request a change in review if only the > copyright is not updated? If the second reviewers does it after the > first already approved, the first has to re-approve - additional > bureaucratic work and might lead to a bit of time lag across > continents. Not such a big deal, but if it doesn't really matter .. > > -- Jeanette > > Zitat von Kevin Rushforth : > >> Not that I know of. FWIW, I'm not too bothered by this, since I run a >> script 2-3 times a year to update the copyright years for those files >> fixed in the current year. >> >> -- Kevin >> >> >> On 4/13/2020 3:48 AM, Jeanette Winzenburg wrote: >>> >>> Seeing that missing to update of copyright year in the header is >>> rather common (in my own pull requests as well as in others :) is >>> there any means to do so automatically or some source tool (for me >>> that would be for Eclipse) that would do on request? >>> >>> -- Jeanette >>> > > > From fastegal at swingempire.de Tue Apr 28 13:15:48 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 28 Apr 2020 15:15:48 +0200 Subject: Automate copyright year? In-Reply-To: <9699b25d-cf52-33a2-97ee-a1409fadcd41@oracle.com> References: <20200413124816.Horde.9WwftUqyWjC92PymPTJ7Lg1@webmail.df.eu> <5cbbcdc4-913f-df30-df9d-6204c23da6da@oracle.com> <20200428131807.Horde.jzhhLYRVydtt-zMaXu28nw2@webmail.df.eu> <9699b25d-cf52-33a2-97ee-a1409fadcd41@oracle.com> Message-ID: <20200428151548.Horde.ls_fUXe9L9lGOdfvDsvYZA1@webmail.df.eu> sounds good :) Zitat von Kevin Rushforth : >> Then we might decide not to request a change in review if only the > copyright is not updated? > > Yes, this is a good idea. I don't generally flag this in my reviews, > for example. The exceptions would be: 1) if a new file springs to > life with the wrong initial copyright year; 2) if an incorrect > update was made to a copyright year. > > -- Kevin > > > On 4/28/2020 4:18 AM, Jeanette Winzenburg wrote: >> >> Okay, thanks for the info :) >> >> Then we might decide not to request a change in review if only the >> copyright is not updated? If the second reviewers does it after the >> first already approved, the first has to re-approve - additional >> bureaucratic work and might lead to a bit of time lag across >> continents. Not such a big deal, but if it doesn't really matter .. >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> Not that I know of. FWIW, I'm not too bothered by this, since I >>> run a script 2-3 times a year to update the copyright years for >>> those files fixed in the current year. >>> >>> -- Kevin >>> >>> >>> On 4/13/2020 3:48 AM, Jeanette Winzenburg wrote: >>>> >>>> Seeing that missing to update of copyright year in the header is >>>> rather common (in my own pull requests as well as in others :) is >>>> there any means to do so automatically or some source tool (for >>>> me that would be for Eclipse) that would do on request? >>>> >>>> -- Jeanette >>>> >> >> >> From Rony.Flatscher at wu.ac.at Tue Apr 28 13:15:54 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 28 Apr 2020 15:15:54 +0200 Subject: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" In-Reply-To: References: <21d34256-6c2a-8b55-ceed-e2a1576eba1e@wu.ac.at> <5596f9d3-a2a2-5d04-6339-fe278ac57f79@wu.ac.at> <74438657-a8b3-2aac-0052-521c519bf14a@oracle.com> <0ba416aa-a460-cdc5-a029-91081e9f7fe6@wu.ac.at> <1f67a8ee-d111-944a-cae2-5fdaa9785629@wu.ac.at> <55cfde05-a747-6a15-21b3-9702f418abec@wu.ac.at> Message-ID: <34d30efa-a87c-261e-36b3-e5f68f38c389@wu.ac.at> Hi Kevin, what should be the next steps? Should I remove "WIP" from the title in and add the CSR draft text of my last e-mail as a "CSR" comment with PR # 192, thereby requesting it to be added to ? Please advise. TIA, ---rony P.S.: This is the RFE: * RFE (2020-01-24): These are the three versions (all with appropriate unit tests) that I came up with chronologically to implement the RFE, would prefer the latest version (PR # 192): * Compile if Compilable implemented (2020-02-28): * Compile if compile PI and Compilable is implemented (2020-04-11): * Compile with fallback, if Compilable is implemented, compile PI for fine-grained control (2020-04-14): On 22.04.2020 20:01, Rony G. Flatscher wrote: > Hi Kevin, > > as I am not able to file a CSR with the issue you suggested to come up with a draft, so here it goes: > > Summary > ======= > Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if the script engine > implements the javax.script.Compilable interface to speed up execution. In case compilation > throws a javax.script.ScriptException fall back to evaluating the uncompiled script. Allow > control of script compilation with a "compile" PI for FXML files. > > Problem > ======= > javafx.fxml.FXMLLoader is able to execute scripts in Java script languages > (javax.script.ScriptEngine implementations) referred to or embedded in a FXML file. > > If a script engine implements the javax.script.Compilable interface, then such scripts could be > compiled and the resulting javax.script.CompiledScript could be executed instead using its > eval() methods. > > Evaluating the javax.script.CompiledScript objects may help speed up the execution of script > invocations, especially for scripts defined for event attributes in FXML elements (e.g. like > onMouseMove) which may be repetitively invoked and evaluated. > > Solution? > ======== > Before evaluating the script code test whether the javax.script.ScriptEngine implements > javax.script.Compilable. If so, compile the script to a javax.script.CompiledScript object first > and then use its eval() method to evaluate the script, otherwise continue to use the > javax.script.ScriptEngine's eval() method instead. Should compilation of a script yield > (unexpectedly) a javax.script.ScriptException then fall back to using the > javax.script.ScriptEngine's eval() method. A new process instruction "compile" allows control of > the compilation of scripts ("true" sets compilation on, "false" to set compilation off) in FXML > files. > > Specification > ============= > If a javax.script.ScriptEngine implements the javax.script.Compilable interface, then use its > compile() method to compile the script to a javax.script.CompiledScript object and use its > eval() method to run the script. In the case that the compilation throws (unexpectedly) a > javax.script.ScriptException log a warning and fall back to using the > javax.script.ScriptEngine's eval() method instead. > To allow setting this feature off and on while processing the FXML file a "compile" process > instruction ("" or "") gets defined that allows to turn > compilation off and on throughout a FXML file. > > Having never seen a real CSR I hope that this matches what is expected and is helpful for > assessment. If not please advise (got the name of these fields from [1]). > > --- > > Also added brief information about the respective test units (what they test and yield) in the WIP? [2]. > > ---rony > > [1] "CSR-FAQ": > > [2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script engines implement > javax.script.Compilable compile scripts #192":? > > > On 20.04.2020 14:58, Rony G. Flatscher wrote: >> There is a new WIP at : >> >> This WIP adds the ability for a fallback in case compilation of scripts fails, in which case a >> warning gets issued about this fact and evaluation of the script will be done without >> compilation. Because of the fallback scripts get compiled with this version by default. It >> extends PR 187 #187. >> >> To further ease spotting scripts that cause a ScriptException a message in the form of >> "filename: caused ScriptException" gets added to the exception handling in either of the three >> locations: an error message, a stack trace or a wrap-up into a RuntimeException (having three >> different kinds of reporting ScriptExceptions may be questioned, however none of these tear down >> the FXML GUI). >> >> This WIP comes with proper test units as well. As per Kevin's suggestion a warning gets logged >> whenever a script cannot be compiled and the fallback gets used. >> >> It is suggested to use this WIP as it includes the compilation by default with a safe fallback to >> evaluate the uncompiled script, if compilation (unexpectedly) fails. >> >> Again, any feedback, discussion welcome! >> >> ---rony >> >> P.S.: In the log history there is a commit message "Make message more pregnant.", it should have >> read "Make messages more terse." instead|.|| >> | >> >> >> On 17.04.2020 19:37, Rony G. Flatscher wrote: >>> There is a new WIP at which adds a compile PI (process >>> instruction) for turning on and off script compilation if the script engine implements the >>> Compilable interface. >>> >>> By default compilation is off (no compilation), such that one needs to add a compile PI >>> ("") at the top to activate this feature. Supplying "true" (default) or "false" as the PI >>> data turns this feature on and off. >>> >>> The WIP comes with adapted test units that test "compile on" for an entire fxml file, "compile off", >>> alternating using "compile on and off", and alternating using "compile off and on". This will test >>> all variants of applying the compile PI for all categories of scripts. >>> >>> Any feedback appreciated! >>> >>> ---rony >>> >>> P.S.: FXML files that contain unknown PIs do not cause a runtime error by FXMLLoader, they just get >>> ignored. Therefore one could apply the compile PI to FXML files that are used in older JavaFX runtimes. >>> >>> P.P.S.: In the next days I will also add Kevin's idea in a separate version that will have a >>> fallback solution in case a compilation is (unexpectedly) not successful, reverting to >>> (interpretative) evaluation/execution of the script. In that version it is planned to have >>> compilation on by default as in the case of a compilation failure there will be a safe backup solution. >>> >>> >>> On 14.04.2020 19:52, Kevin Rushforth wrote: >>>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I would wait a bit to >>>> create the CSR until the review is far enough along to know which direction we intend to go. >>>> >>>> Unless there is a real concern about possible regressions if scripts are compiled by default, I >>>> think "enabled by default" is the way to go. Your argument that such script engines are broken >>>> seems reasonable, since this only applies to script engines that implement javax.script.Compilable >>>> in the first place. We still might want to add way to turn compilation off for individual scripts. >>>> One other thing to consider is that if compilation fails, it might make sense to log a warning and >>>> fall back to the existing interpreted mode. >>>> >>>> Does anyone else have any concerns with this? >>>> >>>> -- Kevin >>>> >>>> >>>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote: >>>>> Hi there, >>>>> >>>>> as there was probably enough time that has passed by I would intend to create a CSR in the next days >>>>> with the PR as per Kevin's suggestion. >>>>> >>>>> (For the case that this feature should not be active by default, the CSR will suggest to define a >>>>> new "compile" PI in the form (default, if no PI data given: true), which >>>>> is independent of the existence of a language PI (this way it becomes also possible to allow >>>>> compilation of external scripts denoted with the script-element, which do not need a page language >>>>> to be set as the file's extension allows the appropriate script engine to be loaded and used for >>>>> execution). A compile-PI would allow for turning compilation of scripts on by just adding the PI >>>>> or ? to FXML files (and to turn off), which seems to >>>>> be simple and self-documentary. In general employing such compile PIs allows for setting compilation >>>>> of scripts on and off throughout an FXML file.) >>>>> >>>>> ---rony >>>>> >>>>> >>>>> On 04.04.2020 18:03, Rony G. Flatscher wrote: >>>>> >>>>>> Hi Kevin, >>>>>> >>>>>> On 03.04.2020 01:21, Kevin Rushforth wrote: >>>>>>> I see that you updated the PR and sent it for review. >>>>>>> >>>>>>> Before we formally review it in the PR, let's finish the discussion as to whether this is a useful >>>>>>> feature, and if so, what form this feature should take. >>>>>>> >>>>>>> ?From my point of view, this does seem like a useful feature. Would other users of FXML benefit >>>>>>> from it? >>>>>> Script code should be executed faster after compilation, so any FXML page that hosts script code >>>>>> may >>>>>> benefit. >>>>>> >>>>>> The benefits depend on the type of script (and maybe its size and its complexity) and also on the >>>>>> types of event handlers the scripts serve, e.g. move or drag event handlers may benefit >>>>>> significantly. This is because repeated invocation of compiled script event handlers do not cause >>>>>> the reparsing of that script's source and interpreting it on each invocation, which may be >>>>>> expensive >>>>>> depending on the script engine, but rather allows the immediate evaluation/execution of the >>>>>> compiled >>>>>> script by the script engine. >>>>>> >>>>>>> I'm not certain whether we want it to be implicit, compiling the script if the script engine in >>>>>>> question implements Compilable, or via a new keyword or tag. What are the pros / cons? >>>>>> In principle there are three possibilities: >>>>>> >>>>>> ???? 1) If a script engine implements javax.script.Compilable, compile the script and execute the >>>>>> ???? compiled version. In the case of event handlers compile and buffer the compiled script and >>>>>> ???? execute the compiled script each time its registered event fires. >>>>>> >>>>>> ?????? o Pro: immediately benefits all existing FXML pages that host scripts >>>>>> ?????? o Con: it is theoretically possible (albeit quite unlikely) that there are scripts that fail >>>>>> ???????? compiling but have been employed successfully in interpreted mode >>>>>> >>>>>> ???? 2) Introduce some form of an optional attribute (e.g. "compile={true|false}") to the FXML >>>>>> ???? language PI that switches on compilation of scripts hosted in FXML definitions if the script >>>>>> ???? engine implements the javax.script.Compilable interface. If missing it would default to >>>>>> "false". >>>>>> ???? (Alternatively, add a "compile" PI, that if present causes the compilation of scripts, if the >>>>>> ???? script engine supports it. It would be an error if the "compile" PI was present, but the >>>>>> ???? "language" PI was not.) >>>>>> >>>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition of the >>>>>> language >>>>>> ???????? PI gets changed >>>>>> ?????? o Con: benefit not made available automatically to existing FXML pages that host scripts >>>>>> >>>>>> ???? 3) Another possibility would be to define a boolean attribute/property "compile" for script >>>>>> and >>>>>> ???? node elements and only compile the scripts, if the property is set to true >>>>>> >>>>>> ?????? o Pro: compilation of FXML hosted scripts is done only, if the FXML definition gets changed >>>>>> ???????? accordingly >>>>>> ?????? o Con: potential benefit not made available automatically to existing FXML pages that >>>>>> host scripts >>>>>> >>>>>> 2 and 3 could be combined, where 2 would define the default compilation behavior that then could be >>>>>> overruled individually by 3. >>>>>> >>>>>> The question would be whether 2 or/and 3 are really necessary as it can be expected that >>>>>> compilation >>>>>> of scripts by the script engines would find the same errors as while interpreting the very same >>>>>> scripts (if not, the script engine is badly broken and it could be argued that then the >>>>>> interpretation part of the script engine might be expected to be broken as well which would be >>>>>> quite >>>>>> dangerous from an integrity POV; the same consideration applies as well if the execution of the >>>>>> compiled script would behave differently to interpreting the very same script by the same script >>>>>> engine). >>>>>> >>>>>> The current WIP implements 1 above and includes an appropriate test unit. >>>>>> >>>>>>> What do others think? >>>>>>> In either case, we would need to make sure that this doesn't present any security concerns in the >>>>>>> presence of a security manager. As long as a user-provided class is on the stack, it will be fine, >>>>>>> but we would need to ensure that. >>>>>> The compilation of scripts needs to be done by the Java script engines (implementing both, >>>>>> javax.script.Engine and javax.script.Compilable) as well as controlling the execution of compiled >>>>>> scripts ([javax.script.CompiledScript] >>>>>> (https://docs.oracle.com/en/java/javase/14/docs/api/java.scripting/javax/script/CompiledScript.html)). >>>>>> >>>>>> >>>>>> ---rony >>>>>> >>>>>> >>>>>> >>>>>>> On 4/2/2020 10:41 AM, Rony G. Flatscher wrote: >>>>>>>> After merging master, applying some fixes and changing the title to reflect the change from >>>>>>>> WIP to a >>>>>>>> pull request I would kindly request a review of this pull request! >>>>>>>> >>>>>>>> Here the URL: , title changed to: "8238080: >>>>>>>> FXMLLoader: if >>>>>>>> script engines implement javax.script.Compilable compile scripts". >>>>>>>> >>>>>>>> ---rony >>>>>>>> >>>>>>>> >>>>>>>> On 28.02.2020 19:22, Rony G. Flatscher wrote: >>>>>>>>> Here is a WIP [1] implementation of [2]. The WIP is based on [3], which is currently in >>>>>>>>> review, and >>>>>>>>> has an appropriate test unit going with it as well, please review. >>>>>>>>> >>>>>>>>> There should be no compatibility issue with this implementation. >>>>>>>>> >>>>>>>>> Discussion: another solution could be to not compile by default. Rather compile, if some new >>>>>>>>> information is present with the FXML file which cannot possibly be present in existing FXML >>>>>>>>> files. >>>>>>>>> In this scenario one possible and probably simple solution would be to only compile scripts >>>>>>>>> if the >>>>>>>>> language process instruction (e.g. ) contains an appropriate attribute with a >>>>>>>>> value >>>>>>>>> indicating that compilation should be carried out (e.g.: compile="true"). This way only FXML >>>>>>>>> with >>>>>>>>> PIs having this attribute set to true would be affected. If desired I could try to come up >>>>>>>>> with a >>>>>>>>> respective solution as well. >>>>>>>>> >>>>>>>>> ---rony >>>>>>>>> >>>>>>>>> [1] "Implementation and test unit": >>>>>>>>> >>>>>>>>> [2] "JDK-8238080 : FXMLLoader: if script engines implement javax.script.Compilable compile >>>>>>>>> scripts": >>>>>>>>> >>>>>>>>> >>>>>>>>> [3] "8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV": >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 24.01.2020 16:26, Kevin Rushforth wrote: >>>>>>>>> >>>>>>>>>> Thank you for filing this enhancement request. As an enhancement it should be discussed on this >>>>>>>>>> list before proceeding with a pull request (although a "WIP" or Draft PR can be used to >>>>>>>>>> illustrate >>>>>>>>>> the concept). >>>>>>>>>> >>>>>>>>>> For my part, this seems like a reasonable enhancement, as long as there are no compatibility >>>>>>>>>> issues, but it would be good to hear from application developers who heavily use FXML. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/24/2020 7:21 AM, Rony G. Flatscher wrote: >>>>>>>>>>> Just filed a RFE with the following information: >>>>>>>>>>> >>>>>>>>>>> ???? * Component: >>>>>>>>>>> ???????? o JavaFX >>>>>>>>>>> >>>>>>>>>>> ???? * Subcomponent: >>>>>>>>>>> ???????? o fxml: JavaFX FXML >>>>>>>>>>> >>>>>>>>>>> ???? * Synopsis: >>>>>>>>>>> ???????? o "FXMLLoader: if script engines implement javax.script.Compilabel compile scripts" >>>>>>>>>>> >>>>>>>>>>> ???? * Descriptions: >>>>>>>>>>> ???????? o "FXMLLoader is able to execute scripts in Java script languages >>>>>>>>>>> (javax.script.ScriptEngine >>>>>>>>>>> ?????????? implementations) if such a Java script language gets defined as the controller >>>>>>>>>>> language in >>>>>>>>>>> ?????????? the FXML file. >>>>>>>>>>> >>>>>>>>>>> ?????????? If a script engine implements the javax.script.Compilable interface, then such >>>>>>>>>>> scripts >>>>>>>>>>> could >>>>>>>>>>> ?????????? be compiled and the resulting javax.script.CompiledScript could be executed instead >>>>>>>>>>> using >>>>>>>>>>> ?????????? its eval() methods. >>>>>>>>>>> >>>>>>>>>>> ?????????? Evaluating the CompiledScript objects may help speed up the execution of script >>>>>>>>>>> invocations, >>>>>>>>>>> ?????????? especially for scripts defined for event attributes in FXML elements (e.g. like >>>>>>>>>>> onMouseMove) >>>>>>>>>>> ?????????? which may be repetitevly invoked and evaluated." >>>>>>>>>>> >>>>>>>>>>> ???? * System /OS/Java Runtime Information: >>>>>>>>>>> ???????? o "All systems." >>>>>>>>>>> >>>>>>>>>>> Received the internal review ID: "9063426" >>>>>>>>>>> >>>>>>>>>>> ---rony From fkirmaier at openjdk.java.net Tue Apr 28 14:34:54 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 28 Apr 2020 14:34:54 GMT Subject: [Rev 04] RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 15:09:17 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> The tests are now reused for native and monocle tests. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 1325: > >> 1324: this.isFocused = focused; >> 1325: if (this.isFocused && this.isVisible) { >> 1326: setFocusedWindow(this); > > On my Window10 machine, with this change, `Window.focusedWindow` remains `null` even after the first window (I have not > verified with multiple windows though) is shown onto the screen and is focused. And It continues to remain `null` until > some mouse or key action is performed on the window. I am not sure if this causes any side effects. It looks like the > `Window.focusedWindow` is mostly(only) used for Monocle. Can you please confirm the behavior that > `Window.focusedWindow` remain `null` and check for any side effects. As mentioned - I don't have a good setup to test this code on Windows. But I've checked where focusedWindow/getFocusedWindow is used, and I can verify your assumption. I've searched through the whole project and the variable is only used in the MonocleCode. The fact that focusedWindow get's sometimes set is probably the cause of the irregular happening memoryleak on Window. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From ghb at openjdk.java.net Tue Apr 28 15:13:39 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 28 Apr 2020 15:13:39 GMT Subject: RFR: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded In-Reply-To: References: Message-ID: <5IVeiuuZwgWO4pXCzrfgFVe0NmLagyrtMIEDyeV1o8c=.701acfef-b483-49d8-b09f-56f8d981e5bd@github.com> On Wed, 22 Apr 2020 18:07:09 GMT, Kevin Rushforth wrote: > This PR will allow javafx.web unit tests to run to completion and pass on Windows with Visual Studio 2019. > > Two of the WebKit tests load the native WebKit library without initializing the JavaFX runtime. This will lead to test > failures and will hang the test run if those tests are run before the other tests, and if the system doesn't have all > the needed runtime libraries. The simple fix is to call the Toolkit method to load those libraries. This is only > needed for unit tests that don't already initialize the JavaFX runtime (e.g., by calling `Platform::startup` or > `Application::launch`) and call internal methods that execute native code as part of the test. Looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/194 From kcr at openjdk.java.net Tue Apr 28 15:13:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 15:13:39 GMT Subject: [Integrated] RFR: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 18:07:09 GMT, Kevin Rushforth wrote: > This PR will allow javafx.web unit tests to run to completion and pass on Windows with Visual Studio 2019. > > Two of the WebKit tests load the native WebKit library without initializing the JavaFX runtime. This will lead to test > failures and will hang the test run if those tests are run before the other tests, and if the system doesn't have all > the needed runtime libraries. The simple fix is to call the Toolkit method to load those libraries. This is only > needed for unit tests that don't already initialize the JavaFX runtime (e.g., by calling `Platform::startup` or > `Application::launch`) and call internal methods that execute native code as part of the test. This pull request has now been integrated. Changeset: e0ffca32 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e0ffca32 Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded Reviewed-by: ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/194 From fastegal at openjdk.java.net Tue Apr 28 15:42:55 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 28 Apr 2020 15:42:55 GMT Subject: RFR: 8241999: ChoiceBox: incorrect toggle selected for uncontained Message-ID: The issue is that the toggles is not reliably unselected if an uncontained value is set. The root is ChoiceBoxSelectionModel which doesn't update the index on selecting an uncontained item, in particular it fails to keep the invariant: assertEquals(getItems().indexOf(selectedItem), selectedIndex); The fix here is to override select(item) to guarantee the assert. Added/removed ignore from tests that failed before and pass after the fix. All other tests are passing before and after. ------------- Commit messages: - 8241999: ChoiceBox: incorrect toggle selected for uncontained Changes: https://git.openjdk.java.net/jfx/pull/200/files Webrev: https://webrevs.openjdk.java.net/jfx/200/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241999 Stats: 55 lines in 2 files changed: 44 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/200/head:pull/200 PR: https://git.openjdk.java.net/jfx/pull/200 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Apr 28 16:44:55 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 28 Apr 2020 16:44:55 GMT Subject: [Integrated] RFR: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine In-Reply-To: References: Message-ID: On Sun, 19 Apr 2020 08:12:07 GMT, Abhinay Agarwal wrote: > Update WebEngine's Javadoc to add information on how it switches to HttpClient instead of URLConnection in JavaFX 14 > when used with JDK 12 or later. > Identification of the correct client is important as both these clients may offer different ways to achieve a task. One > such task can be bypassing insecure HTTPS connection. This pull request has now been integrated. Changeset: e30049f0 Author: Abhinay Agarwal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e30049f0 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine Reviewed-by: kcr, ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/189 From johan.vos at gluonhq.com Tue Apr 28 20:19:09 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 28 Apr 2020 22:19:09 +0200 Subject: RFR: 8244042: Change JavaFX release version in 11-dev to 11.0.8 Message-ID: Hi Kevin, Please review http://cr.openjdk.java.net/~jvos/8244042/webrev.00/ which fixes https://bugs.openjdk.java.net/browse/JDK-8244042 Thanks, - Johan From kcr at openjdk.java.net Tue Apr 28 20:27:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 20:27:17 GMT Subject: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: On Sun, 19 Apr 2020 09:51:07 GMT, Jesper Skov wrote: >> Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. >> >> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 > > Jesper Skov has updated the pull request incrementally with three additional commits since the last revision: > > - Fail instead of print message > - addedToggles list is final > - Leave unrelated file alone Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From kevin.rushforth at oracle.com Tue Apr 28 20:45:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 28 Apr 2020 13:45:52 -0700 Subject: RFR: 8244042: Change JavaFX release version in 11-dev to 11.0.8 In-Reply-To: References: Message-ID: +1 On 4/28/2020 1:19 PM, Johan Vos wrote: > Hi Kevin, > > Please review http://cr.openjdk.java.net/~jvos/8244042/webrev.00/ > which fixes https://bugs.openjdk.java.net/browse/JDK-8244042 > > Thanks, > > - Johan From kcr at openjdk.java.net Tue Apr 28 20:46:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 20:46:07 GMT Subject: RFR: 8241999: ChoiceBox: incorrect toggle selected for uncontained In-Reply-To: References: Message-ID: On Tue, 28 Apr 2020 15:36:53 GMT, Jeanette Winzenburg wrote: > The issue is that the toggles is not reliably unselected if an uncontained value is set. > > The root is ChoiceBoxSelectionModel which doesn't update the index on selecting an uncontained item, in particular it > fails to keep the invariant: > assertEquals(getItems().indexOf(selectedItem), selectedIndex); > > The fix here is to override select(item) to guarantee the assert. > > Added/removed ignore from tests that failed before and pass after the fix. All other tests are passing before and after. @aghaisas can you review this? It looks pretty simple so one reviewer should be enough, unless you spot something where you want a second pair of eyes. ------------- PR: https://git.openjdk.java.net/jfx/pull/200 From kcr at openjdk.java.net Tue Apr 28 21:43:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 21:43:37 GMT Subject: RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 08:17:50 GMT, Arun Joseph wrote: > After [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900), initializeThickness() moved from > ScrollBarThemeImpl to ScrollBarWidget but the implementation was kept the same by using testSBRef to call > setThickness() for setting ScrollBarTheme.thickness. Modifying initializeThickness() to set ScrollBarTheme.thickness > once and removing testSBRef. While this might be the right fix, I don't think the evaluation is right. In particular, this doesn't look related to [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900). That refactoring fix was behavior neutral in terms of the object graph -- it uses an accessor pattern rather than the removed public `impl_` methods for encapsulation, but intentionally didn't change anything related to which instance of which objects are used. That fix was not backported to 8u and yet this bug is listed as affecting 8u. So, what I'd like to see in the evaluation is a description of the root cause, and a brief explanation of the fix. Can you also provide a test case that fails without the fix and passes with the fix? I don't see one in JBS that you can leverage, so you may need to create one. ------------- PR: https://git.openjdk.java.net/jfx/pull/197 From kcr at openjdk.java.net Tue Apr 28 22:00:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 22:00:09 GMT Subject: [Rev 02] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: On Tue, 21 Apr 2020 16:34:11 GMT, Bhawesh Choudhary wrote: >> As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to >> fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare >> against 600 font weight. > > Bhawesh Choudhary has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The fix and test look good. I confirm that your new test fails without your fix and passes with your fix. I left one style comment and will approve once you fix that. modules/javafx.web/src/test/java/test/javafx/scene/web/WebViewTest.java line 111: > 110: ); > 111: submit(()->{ > 112: assertFalse("Font weight test failed ", Minor: there should be a space before and after the `->` ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From kcr at openjdk.java.net Tue Apr 28 22:16:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 22:16:33 GMT Subject: [Rev 03] RFR: 8242548: Honor line spacing in Labeled reflow calculation In-Reply-To: References: Message-ID: On Tue, 28 Apr 2020 06:22:16 GMT, Ajit Ghaisas wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in comment > > Marked as reviewed by aghaisas (Reviewer). The code change and test look fine. Please change the PR title to match the JBS issue title, so: 8242548: Wrapped labeled controls using -fx-line-spacing cut text off ------------- PR: https://git.openjdk.java.net/jfx/pull/173 From kcr at openjdk.java.net Tue Apr 28 22:38:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 22:38:55 GMT Subject: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. In-Reply-To: References: <68I6pRPsP00WH4mOdR8r17KSrh3geYjqkbWwho7FG9c=.9ed7c1a9-1aac-453a-a154-5224803b6412@github.com> Message-ID: On Wed, 15 Apr 2020 08:28:22 GMT, Tom Schindl wrote: >> Extract keystate and add to the existing modifier mask, to support eg >> multi-select >> >> https://bugs.openjdk.java.net/browse/JDK-8202296 > > Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: > > 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. > > Fix whitespace errors Looks good to me. I verified that the new test fails without your fix and passes with your fix. In case anyone else is looking at this and wants to run the test, it isn't enabled by default, so you need to run it like this: gradle -PUNSTABLE_TEST=true -PFULL_TEST=true -PUSE_ROBOT=true \ :systemTests:test --tests test.robot.com.sun.glass.ui.monocle.RobotTest ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/170 From kcr at openjdk.java.net Tue Apr 28 23:20:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 23:20:29 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Tue, 28 Apr 2020 23:17:48 GMT, Kevin Rushforth wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Search javafx.platform.properties in jfx-runtime/lib directory > > Marked as reviewed by kcr (Lead). Pending review by @johanvos > modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java line 241: > >> 240: s.lastIndexOf('/'), s.lastIndexOf('\\')); >> 241: return new File(new URL(s.substring(0, lastIndexOfSlash + 1)).getPath()); >> 242: } catch (MalformedURLException e) { > > The previous code looks like a hold-over from JDK 8, where jfxrt.jar was in `lib/ext`. It also assumes that the JavaFX > runtime is being loaded from a jar URL, which isn't necessarily the case. Probably the only reason it hasn't caused > problems before now is that it is only used to locate `javafx.platform.properties`. Worth noting is that we won't get > here in the case JavaFX is jlinked into the Java runtime, although in that case, the fallback method of locating it > relative to the JDK should be used. I'll take a closer look this specific change, but I think it should be OK. I'll > defer the review as a whole to Johan. I can confirm that this part of the fix is correct. The change to DPI looks correct to me, too. ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From kcr at openjdk.java.net Tue Apr 28 23:20:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 23:20:28 GMT Subject: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 11:09:51 GMT, Alexander Scherbatiy wrote: >> See the detailed issue description on: http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html >> >> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >> [MonocleApplication.staticScreen_getScreens()](https://github.com/openjdk/jfx/pull/75/files#diff-b66ff7fe72c6c5cd26003572ca901bfdL228) >> method code from >>> ns.getDPI(), ns.getDPI(), ns.getScale(), ns.getScale(), ns.getScale(), ns.getScale() >> >> to >> > ns.getWidth(), ns.getHeight(), 1.f, 1.f, ns.getScale(), ns.getScale()" >> >> so the font size is not properly calculated based on the given DPI value. >> >> I left the platformScaleX and platformScaleY as 1.f because I do not know how it affects Android/Dalvik platform. On >> Raspberry Pi where I run JavaFX code with Monocle the DispmanScreen is used which have fixed scale 1.0 value so the app >> works in the same way. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Search javafx.platform.properties in jfx-runtime/lib directory Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/193 From kcr at openjdk.java.net Tue Apr 28 23:35:44 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Apr 2020 23:35:44 GMT Subject: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 19:11:19 GMT, John Neffenger wrote: >> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements >> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* >> repository. Some of the changes were made to support the new device models, while others are minor changes to the >> existing support in JavaFX 13. The following changes were made to support the new device models. >> * Work around problems on the Kobo Glo HD Model N437. >> >> Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is >> ignored by the driver on the Kobo Glo HD where the error occurs, anyway. >> >> Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of >> the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame >> buffer device driver can be an incorrect value. >> >> * Work around problems on the Kobo Clara HD Model N249. >> >> The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the >> normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The >> work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. >> >> The following changes were made to the existing code that supports e-paper displays in JavaFX 13. >> >> * Use the correct constant for the number of bytes per pixel. >> >> Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when >> calculating the capacity of the 32-bit off-screen byte buffer. >> >> * Do not round the luma value to the nearest integer. >> >> Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of >> rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 >> percent and doesn't seem worth it for a display with just 16 levels of gray. >> >> * Change camel case of system property *y8inverted*. >> >> Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it >> is consistent with the other system properties containing Y1, Y4, and Y8 in their names. >> >> * Improve error handling when mapping the frame buffer. >> >> Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a >> `null` return value from `EPDFrameBuffer.getMappedBuffer`. >> >> * Replace non-ASCII characters with their ASCII equivalent. >> >> Replace non-ASCII characters in comments and log messages as follows: >> >> * "?" with "x" for display resolution and color depth, >> * "?" with "*" for multiplication, >> * "?" with "to" for transition, and >> * "?C" with "degrees Celsius" for temperature. >> >> * Add descriptions to Monocle EPD system properties. >> >> Add Javadoc comments to each constant that defines a Monocle EPD system property. >> >> * Rename `IntStructure.getInteger` to `IntStructure.get`. >> >> Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method >> `Integer.getInteger`, which gets the integer value of a system property. >> >> Below are some of the more interesting test results. >> >> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray >> values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. >> >> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black >> for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that >> displays black for values `0x7F` or less and white for values `0x80` or greater. >> >> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the >> tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame >> buffer. I plan to investigate the cause of the performance difference. >> >> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold >> increase in the number of pixels in their displays. The table below shows the animation speed of each model in >> milliseconds per frame and frames per second. >> >> | Product Name | Speed (ms) | Rate (fps) | >> | ------------- |:----------:|:----------:| >> | Kobo Touch B | 125 | 8.0 | >> | Kobo Touch C | 130 | 7.7 | >> | Kobo Glo HD | 140 | 7.1 | >> | Kobo Clara HD | 145 | 6.9 | > > John Neffenger has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. Looks good to me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/60 From thiago.sayao at clamed.com.br Tue Apr 28 23:46:33 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Tue, 28 Apr 2020 23:46:33 +0000 Subject: Discussion on adding a new gtk glass backend In-Reply-To: References: , , Message-ID: Hi Everyone, Just a reminder that this PR exists. ________________________________ De: openjfx-dev em nome de Thiago Milczarek Sayao Enviado: segunda-feira, 6 de abril de 2020 21:13 Para: Kevin Rushforth ; openjfx-dev at openjdk.java.net Assunto: RE: Discussion on adding a new gtk glass backend Hi Kevin, 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? Yes it works and was tested with gtk2. It has version checks for each API that changed since version 2. One thing that I may have to double-check is if it works with the minimum required gtk2 version. 2. How much of the reliance on GDK were you able to eliminate? It is unlikely to eliminate all of gdk because gtk itself requires gdk structures. I mostly reduced it on Drag and Drop (previously with https://github.com/openjdk/jfx/pull/4 and now with the drag dest part). The thought was "if gtk has it, use gtk". The goal was not to remove gdk but use existing gtk functionality if it fits. One example was to use gtk_widget_set_sensitive to make parent windows "insensitive" when on WINDOW_MODAL instead of custom implementation. Other example is in DND - gtk does the handling, just needed to translate it from glass to gtk. About the flag to enable the implementation, what about "javafx.gtk.experimental=true/false" ? ________________________________ De: openjfx-dev em nome de Kevin Rushforth Enviado: segunda-feira, 6 de abril de 2020 18:34 Para: openjfx-dev at openjdk.java.net Assunto: Re: Discussion on adding a new gtk glass backend Hi Thiago, Nice summary! As I mentioned offline, I am generally supportive of this, since I know how fragile the existing Linux Glass implementation is. Unsurprisingly, this has effectively turned into a rewrite of the Linux GTK glass port. It's going to need a very thorough review, including a security review, and that will take some time. Thank you for adding my offline suggestion of making this new implementation an optional library where the old and new versions of the glass library for Linux can coexist. This will allow making separate decisions about when it is ready to go in versus when it is ready to become the default; this is the only way it even has a chance of getting in for JavaFX 15 (and even then it's not a given). Since this is JavaFX only, the command line option should probably be "javafx.gtk..." rather than "jdk.gtk....", or at least something with "javafx" in the name, but that's a detail that can be worked out later. I have a couple high-level questions: 1. In the goals you mention "Update to gtk3 (it was originally a port from gtk2)" I presume that this preserves compatibility with older gtk2 libraries as well? 2. How much of the reliance on GDK were you able to eliminate? I'd like to also hear from Johan and others -- especially other Linux app developers. -- Kevin On 4/4/2020 5:13 PM, Thiago Milczarek Sayao wrote: > Summary > ------- > > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > PR: https://github.com/openjdk/jfx/pull/77 > > Goals > ----- > > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > > Non-Goals > --------- > > * Make Wayland work now. > > > Success Metrics > --------------- > > * Reduced code size (999 lines removed); > * Pass robot tests on Ubuntu 16.04, 18.04 and 20.04, except some of them that always fails; > * Pass manual testing using the Drag and Drop app (java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls) with gtk2 and gtk3 backends; > * Pass manual testing using Ensemble 8 with either gtk2 and gtk3 backends. > > Motivation > ---------- > > While working with OpenJFX on Linux, I have fixed some of it's bugs: > > * Wrong stage gets focused after modal stage creation: https://bugs.openjdk.java.net/browse/JDK-8227366 > * Multi-level Stage::initOwner can crash gnome-shell or X.org server: https://bugs.openjdk.java.net/browse/JDK-8226537 > * DragAndDrop no longer works with GTK3: https://bugs.openjdk.java.net/browse/JDK-8211302 > * [Linux] Dialog height switches between correct and too small when showing and hiding a Dialog repeatedly: https://bugs.openjdk.java.net/browse/JDK-8193502 > * Focus goes to wrong Window when dismissing an Alert: https://bugs.openjdk.java.net/browse/JDK-8210973 > * [GTK3] Stage sometimes shown at top-left before moving to correct position: https://bugs.openjdk.java.net/browse/JDK-8212060 > * Window order is not correct when Modality.WINDOW_MODAL: https://bugs.openjdk.java.net/browse/JDK-8220272 > * Port Linux glass drag source (DND) to use gtk instead of gdk: https://bugs.openjdk.java.net/browse/JDK-8225571 > * Dialog's preferred size no longer accommodates multi-line strings: https://bugs.openjdk.java.net/browse/JDK-8232811 > > While fixing those bugs I got familiar with the code and saw many opportunities to make it better (as the goal lists). > > One special case is that X.org needs a window manager to decorate windows (such as Unity, Metacity, Mutter, and many others), so the toolkit does not know about decoration sizes - it must ask to the window manager trough an extension (https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html). OpenJFX can set sizes by content size and window size - so there is a complexity on the "window size" option - it must know decoration sizes. I could not fully understand the current code because it had a high cyclomatic complexity - this was the main motivation to make it simplier (see JBS https://bugs.openjdk.java.net/browse/JDK-8232811 - it fixes the bug, but it's not very "clean"). > > I refer to "make Linux a first-class platform" on the goal because the PR makes room for more improvements (such as easier to fix bugs). > > > Description > ----------- > > This glass gtk replacement will be active if passing -Djdk.gtk.new=true to the jvm. The proposal is to have this side by side with current Linux glass so people can test and eventually it may become the default glass implementation on Linux. > > * Note: No public API was modified; > > * Specific Code Changes > > * glass_window.cpp / glass_window.h > > - Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore); > - Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; > - Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); > - Frame Extents: Removed the code to request extents and gtk already does it by default; > - Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJFX uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. > - Other Size calculation changes: > - Use gtk_window_set_default_size() for initial size which is the appropriate function; > - Gravity is now ignored as it is on Windows glass impl; > - Avoid sending same sizes to Java (duplicated events); > - Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); > - Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on > apply_geometry(). > - Mouse grab: Reworked it to use to correct functions according to gtk+ version; > - Draw: Reworked it to use the correct calls accord to gtk+ version changes; > - Fixed JDK-8237491; > - Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; > - Reorganized function order on glass_window.cpp to match glass_window.h > - Only work-around Unity bug if window manager is Unity > > * GlassCursor.cpp > > - Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; > - Reworked Gtk+2 to use a function instead of manual calls to find the cursor; > > * GtkWindow.java > > - Moved the extents special case to native glass; > > * GlassApplication.cpp > > - Removed Gdk events where possible (it's now on glass_window as signals); > - Removed applet/web start code; > > * GlassView.cpp > > - Changes to reflect frame extents rework on glass_window > > * GlassWindow.cpp > > - WindowContextTop -> WindowContext > - Removed applet / web start code; > - Removed frame extents (which is not called anymore due to GtkWindow.java change); > > * glass_general.cpp > > - Removed functions that became unused; > - Added is_grab_disabled() that is used on glass_window > > * glass_window_ime.cpp > > - WindowContextTop -> WindowContext; > > * glass_dnd.cpp / glass_dnd.h > > - Ported to Gtk signals; > - Use all possible image formats (supported by GdkPixbuf / OpenJFX) - .gif is now possible (for ex.); > - Allow COMPOUND_TEXT; > - Do not request content while dragging; > - Reduce overall code size. > > > Testing > ------- > > While fixing the bugs listed on "Motivation" I have developed some robot tests that must pass along with the previosly existing ones. > > Note: Non-robot tests do not apply since the changes are glass specific. > > Note2: Must pass -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' to gradle. > > > Risks and Assumptions > --------------------- > > * Testing were done since Ubuntu 16.04 (released 4 years ago) on x64 machines; > * Tested with Mutter (default gnome) and Unity (default on 16.04) - should work on other window managers that follows the specs; > * It's a big change - well tested but might still break something. > > Dependencies > ----------- > > * Simplify and update glass gtk backend: https://bugs.openjdk.java.net/browse/JDK-8236651 > * Maximized undecorated stage behaves inconsistently on different platforms > : https://bugs.openjdk.java.net/browse/JDK-8237491 > From arapte at openjdk.java.net Wed Apr 29 06:27:32 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 29 Apr 2020 06:27:32 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list Message-ID: Issue: When tabs are permuted as mentioned in the issue description as, 1. TabPane.getTabs().setAll(tab0, tab1) 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3); the tab headers do not get permuted in same order as `TabPane.getTabs()`. => tab headers should be shown in order as tab2, tab3, tab0, tab1. => But should are show in order as tab0, tab1, tab2, tab3 Cause: Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list. Fix: Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable. Verification: No existing tests fail due to this change. Added a system test which fails without and pass with fix. ------------- Commit messages: - 8237602: TabPane doesn't respect order of TabPane.getTabs() list Changes: https://git.openjdk.java.net/jfx/pull/201/files Webrev: https://webrevs.openjdk.java.net/jfx/201/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237602 Stats: 71 lines in 2 files changed: 65 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/201/head:pull/201 PR: https://git.openjdk.java.net/jfx/pull/201 From ajoseph at openjdk.java.net Wed Apr 29 06:47:14 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 29 Apr 2020 06:47:14 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms In-Reply-To: References: Message-ID: On Mon, 27 Apr 2020 23:56:37 GMT, Kevin Rushforth wrote: >> fillPath() and fillRect() functions in >> [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) >> use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as >> ImagePattern doesn't have the same attribute. So, the final image won't be transformed. > > Since this is in a common method used by all shapes, and not just WebView, we will need to ensure no regressions. All ImagePattern objects, other than the one from WebView, uses the second constructor which assigns an identity transform as the pattern transform. So, existing calls to PaintHelper concatenates the shader transform with an identity matrix and thus, shouldn't cause any regressions. Only calls from WebView's drawPattern() method in WCGraphicsPrismContext uses the patternTransform attribute. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From arapte at openjdk.java.net Wed Apr 29 07:09:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 29 Apr 2020 07:09:06 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> Message-ID: On Wed, 22 Apr 2020 15:52:11 GMT, Jeanette Winzenburg wrote: > An alternative might be a different inputMap (or containing different mappings) when used in combo's popup (which is > similar to what Swing/X does .. no wonder I would prefer it :) Thanks for the suggestion ?? , I shall try this approach and update the PR. I am not sure if we already do this for any other control. Do you know any, if we do ? Not actively working on this issue, Will soon get back on this :) ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From ajit.ghaisas at oracle.com Wed Apr 29 07:19:52 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 29 Apr 2020 12:49:52 +0530 Subject: RFR: 8175358: Memory leak when moving MenuButton into another Scene In-Reply-To: References: Message-ID: Hi Jeanette, Thanks for spotting additional memory leaks as part of code review. I have filed JDK-8244081 & JDK-8244075 to address them. Regards, Ajit > On 27-Apr-2020, at 8:17 PM, Jeanette Winzenburg wrote: > > On Mon, 27 Apr 2020 11:57:58 GMT, Ajit Ghaisas wrote: > >> Issue : https://bugs.openjdk.java.net/browse/JDK-8175358 >> >> Root cause : When a MenuItem is removed from a Scene, if any accelerator has been set on MenuItem, it does not get >> removed from Scene's list of accelerators. >> Fix : If Scene changes for a Menu, remove the registered accelerators from Scene. >> >> Testing : Added a unit test that fails before the fix and passes with it. > > fix looks good to me :) > > Seeing the code, I think we have two follow-up issues (not introduced here, they just jump to visibility in the light > of reading the code and recent fixes around memory leaks :) > > - the listener to the control's sceneProperty is never removed, introducing a memory leak, a fix could be similar to that > of the recently [fixed JDK-8236840](https://bugs.openjdk.java.net/browse/JDK-8236840) > > - we have the exact same issue with accelerators in a contextMenu of a control that's removed from the scene (the > accelerators are still active, as can be seen in adapting your test method). Not sure which collaborator should be > responsible for the cleanup, could be the helper class, the control, or ? > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/199 From ajoseph at openjdk.java.net Wed Apr 29 07:43:11 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 29 Apr 2020 07:43:11 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms In-Reply-To: References: Message-ID: <6oIh3YZe1rUq3v-4DaDCISKIETUGiYrxia9K8fmen2I=.8478259e-cd56-4c82-b1fe-68208391bc1f@github.com> On Wed, 29 Apr 2020 06:45:04 GMT, Arun Joseph wrote: >> Since this is in a common method used by all shapes, and not just WebView, we will need to ensure no regressions. > > All ImagePattern objects, other than the one from WebView, uses the second constructor which assigns an identity > transform as the pattern transform. So, existing calls to PaintHelper concatenates the shader transform with an > identity matrix and thus, shouldn't cause any regressions. Only calls from WebView's drawPattern() method in > WCGraphicsPrismContext uses the patternTransform attribute. The changes in drawPattern() forces the function to handle the operations for drawPattern (for images) and fillPattern (for shapes) together. If required, a new opcode SET_FILL_PATTERN can be introduced for handling patterns in shapes and part of the implementation can be seen from my previous commits to this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/190 From fastegal at openjdk.java.net Wed Apr 29 09:26:42 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 29 Apr 2020 09:26:42 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <4kFEF29kIH4SKP6lHx7q9HI1pFlhSoQcA_3FvKgR480=.b1e03875-397d-46ba-b047-563da01ee47d@github.com> Message-ID: On Wed, 29 Apr 2020 07:06:49 GMT, Ambarish Rapte wrote: >>> Don't you think that all the changes in `ListViewSkin` can be moved to `ListViewBehavior`? All that we do in the skin >>> class is to call `ListViewBehavior#updateSelectionModeKeyMapping`, which smells like feature envy. >>> Moreover, `ListViewBehavior` already has change listener attached to `selectionModelProperty`, waiting for us to re-use >>> it ?? >> >> good point :) Though - I don't like listeners to control properties in behaviors, and much less listeners to path >> properties (they tend to not getting cleaned on dispose). >> In the particular case of behaviors of controls with selectionModels they do (must?) because the selectionModel is not >> api complete (having no notion of anchor), so they jump in to cover up. Hopefully that design flaw will be fixed at >> some time in future, which would remove the existing listener, anyway. With just another responsibility - difference >> based on selectionMode - such cleanup would be harder. Here the basic approach is to add/remove a keyMapping for >> multiple/single selection. Compared to current state, there's a subtle side-effect (the event bubbles up if the mapping >> if removed). We can achieve the same behavior (with the same side-effect) by making the mapping consume depending on >> whether it is handled (to select all) or not. In code that would be pattern like: >> // in constructor >> >> KeyMapping selectAllMapping; >> addDefaultMapping(listViewInputMap, >> ... >> selectAll = new KeyMapping(new KeyBinding(A).shortcut(), this:: selectAll), >> ... >> }; >> selectAllMapping.setAutoConsume(false); >> >> // selectAll with modified signature >> /** >> * Calls selectAll on selectionModel and consumes the event, if >> * the model is available and in multimode, >> * does nothing otherwise. >> */ >> private void selectAll(KeyEvent key) { >> MultipleSelectionModel sm = getNode().getSelectionModel(); >> // do nothing, let it bubble up >> if (sm == null || sm.getSelectionMode() == SelectionMode.SINGLE) return; >> // handle and consume >> sm.selectAll(); >> key.consume(); >> } >> >> BTW, there are other keys that don't work as expected (from the perspective of the editor in the combo): f.i. >> shift-home/end is mapped to scrollToFirst/LastRow - that's hampering ux if f.i. the user has typed some input, uses >> them and sees her input lost because first/last row is selected. Sry to not have noticed earlier in my bug report :( >> So whatever approach we choose (mappings being removed/added or their handlers not/consuming doesn't matter), we would >> have to do it for several keys. Plus we have the side-effect mentioned above. The mass of change _for all listviews_ >> has a certain risk of breaking existing code. Think f.i. global accelerators that might (or not) get triggered >> depending on selection mode. On the other hand, different mappings are needed only when the list resides in the >> combo's popup (and probably only if the combo is editable, didn't dig though). An alternative might be a different >> inputMap (or containing different mappings) when used in combo's popup (which is similar to what Swing/X does .. no >> wonder I would prefer it :) > >> An alternative might be a different inputMap (or containing different mappings) when used in combo's popup (which is >> similar to what Swing/X does .. no wonder I would prefer it :) > > Thanks for the suggestion ?? , I shall try this approach and update the PR. I am not sure if we already do this for any > other control. Do you know any, if we do ? Not actively working on this issue, Will soon get back on this :) the nearest to different input maps based on control state might be in listViewBehavior itself: it has differrent child maps for vertical/horizontal orientation. Could be possible to widen that a bit with another child map for vertical and in combo popup (provided it has a means to decide being in such a state for the sake of an interceptor, without api change that might be a simple entry in its properties) ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Wed Apr 29 10:00:31 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 29 Apr 2020 10:00:31 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: References: Message-ID: On Wed, 29 Apr 2020 04:40:59 GMT, Ambarish Rapte wrote: > Issue: > When tabs are permuted as mentioned in the issue description as, > 1. TabPane.getTabs().setAll(tab0, tab1) > 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3); > the tab headers do not get permuted in same order as `TabPane.getTabs()`. > > => tab headers should be shown in order as tab2, tab3, tab0, tab1. > => But should are show in order as tab0, tab1, tab2, tab3 > > Cause: > Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does > not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list. > Fix: > Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable. > > Verification: > No existing tests fail due to this change. > Added a system test which fails without and pass with fix. didn't look closely, just wondering why you need a system test for this? ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From ajoseph at openjdk.java.net Wed Apr 29 11:05:40 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 29 Apr 2020 11:05:40 GMT Subject: RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct In-Reply-To: References: Message-ID: On Tue, 28 Apr 2020 21:41:19 GMT, Kevin Rushforth wrote: >> ScrollbarThemeJava delegates scrollbar thickness calculation to ScrollBarWidget::initializeThickness() >> [ScrollBarWidget.java] method. Since "ScrollbarThemeJava::scrollbarThickness" is not associated with any >> "ScrollBarWidget" instance, some workaround was made using special "ScrollBarWidget" instance named testRef. > > While this might be the right fix, I don't think the evaluation is right. In particular, this doesn't look related to > [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900). That refactoring fix was behavior neutral in terms of > the object graph -- it uses an accessor pattern rather than the removed public `impl_` methods for encapsulation, but > intentionally didn't change anything related to which instance of which objects are used. That fix was not backported > to 8u and yet this bug is listed as affecting 8u. So, what I'd like to see in the evaluation is a description of the > root cause, and a brief explanation of the fix. Can you also provide a test case that fails without the fix and passes > with the fix? I don't see one in JBS that you can leverage, so you may need to create one. This PR aims at modifying initializeThickness() to not use testSBRef and so, doesn't change the behavior of ScrollBarWidget. As it's not a bug, test case can't be created. ------------- PR: https://git.openjdk.java.net/jfx/pull/197 From kcr at openjdk.java.net Wed Apr 29 12:48:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 29 Apr 2020 12:48:38 GMT Subject: RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct In-Reply-To: References: Message-ID: <-Rbg2wElJmynfQdeHqRpC7DeazMTfTiCTNbo6fE5cLs=.ed037a14-b5b4-4843-9aec-519b983ad30b@github.com> On Wed, 29 Apr 2020 11:03:22 GMT, Arun Joseph wrote: >> While this might be the right fix, I don't think the evaluation is right. In particular, this doesn't look related to >> [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900). That refactoring fix was behavior neutral in terms of >> the object graph -- it uses an accessor pattern rather than the removed public `impl_` methods for encapsulation, but >> intentionally didn't change anything related to which instance of which objects are used. That fix was not backported >> to 8u and yet this bug is listed as affecting 8u. So, what I'd like to see in the evaluation is a description of the >> root cause, and a brief explanation of the fix. Can you also provide a test case that fails without the fix and passes >> with the fix? I don't see one in JBS that you can leverage, so you may need to create one. > > This PR aims at modifying initializeThickness() to not use testSBRef and so, doesn't change the behavior of > ScrollBarWidget. As it's not a bug, test case can't be created. If it is not a bug, then why should we fix it? ------------- PR: https://git.openjdk.java.net/jfx/pull/197 From github.com+4208131+bhaweshkc at openjdk.java.net Wed Apr 29 14:01:50 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 29 Apr 2020 14:01:50 GMT Subject: [Rev 03] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: <3vN-a-RqcI7btX66Ysw4WSo0JxivVGAmPnj_Of42Uv8=.3809b5f0-4581-435c-91cf-82c22b63d04e@github.com> > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: style format changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/180/files - new: https://git.openjdk.java.net/jfx/pull/180/files/f6fb1075..473eec6c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/180/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/180/webrev.02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/180.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/180/head:pull/180 PR: https://git.openjdk.java.net/jfx/pull/180 From kcr at openjdk.java.net Wed Apr 29 14:11:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 29 Apr 2020 14:11:16 GMT Subject: [Rev 03] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: <3vN-a-RqcI7btX66Ysw4WSo0JxivVGAmPnj_Of42Uv8=.3809b5f0-4581-435c-91cf-82c22b63d04e@github.com> References: <3vN-a-RqcI7btX66Ysw4WSo0JxivVGAmPnj_Of42Uv8=.3809b5f0-4581-435c-91cf-82c22b63d04e@github.com> Message-ID: On Wed, 29 Apr 2020 14:01:50 GMT, Bhawesh Choudhary wrote: >> As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to >> fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare >> against 600 font weight. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > style format changes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From kcr at openjdk.java.net Wed Apr 29 14:44:48 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 29 Apr 2020 14:44:48 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: References: Message-ID: On Wed, 29 Apr 2020 09:58:21 GMT, Jeanette Winzenburg wrote: >> Issue: >> When tabs are permuted as mentioned in the issue description as, >> 1. TabPane.getTabs().setAll(tab0, tab1) >> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3); >> the tab headers do not get permuted in same order as `TabPane.getTabs()`. >> >> => tab headers should be shown in order as tab2, tab3, tab0, tab1. >> => But should are show in order as tab0, tab1, tab2, tab3 >> >> Cause: >> Newly added tabs(tab2, tab3) are not inserted at correct index. The index `Change.getFrom()` (0) used from Change does >> not remain valid after the tabs to be moved(tab0, tab1) are removed from `tabsToAdd` list. >> Fix: >> Use the index of first newly added tab, from `TabPane.getTabs()`, which would be always reliable. >> >> Verification: >> No existing tests fail due to this change. >> Added a system test which fails without and pass with fix. > > didn't look closely, just wondering why you need a system test for this? The following is wrong in your Description: > => tab headers should be shown in order as tab2, tab3, tab0, tab1. > => But should are show in order as tab0, tab1, tab2, tab3 Based on what I see in the bug report (and what I would expect), I'm pretty sure you meant to say: The tab headers should be shown in order as tab0, tab1, tab2, tab3. But are shown in order as tab2, tab3, tab0, tab1. ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From github.com+1413266+jgneff at openjdk.java.net Wed Apr 29 17:30:43 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Wed, 29 Apr 2020 17:30:43 GMT Subject: [Integrated] RFR: 8227425: Add support for e-paper displays on i.MX6 devices In-Reply-To: References: Message-ID: <2xwMvyvFpmgexAff0_OqdufGQu-ydnECt7hDfOwSKMo=.71ca225e-cc7a-4c90-92fc-e2326ce7ed9c@github.com> On Thu, 5 Dec 2019 00:06:21 GMT, John Neffenger wrote: > This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements > [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* > repository. Some of the changes were made to support the new device models, while others are minor changes to the > existing support in JavaFX 13. The following changes were made to support the new device models. > * Work around problems on the Kobo Glo HD Model N437. > > Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is > ignored by the driver on the Kobo Glo HD where the error occurs, anyway. > > Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of > the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame > buffer device driver can be an incorrect value. > > * Work around problems on the Kobo Clara HD Model N249. > > The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the > normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The > work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*. > > The following changes were made to the existing code that supports e-paper displays in JavaFX 13. > > * Use the correct constant for the number of bytes per pixel. > > Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when > calculating the capacity of the 32-bit off-screen byte buffer. > > * Do not round the luma value to the nearest integer. > > Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of > rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 > percent and doesn't seem worth it for a display with just 16 levels of gray. > > * Change camel case of system property *y8inverted*. > > Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it > is consistent with the other system properties containing Y1, Y4, and Y8 in their names. > > * Improve error handling when mapping the frame buffer. > > Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a > `null` return value from `EPDFrameBuffer.getMappedBuffer`. > > * Replace non-ASCII characters with their ASCII equivalent. > > Replace non-ASCII characters in comments and log messages as follows: > > * "?" with "x" for display resolution and color depth, > * "?" with "*" for multiplication, > * "?" with "to" for transition, and > * "?C" with "degrees Celsius" for temperature. > > * Add descriptions to Monocle EPD system properties. > > Add Javadoc comments to each constant that defines a Monocle EPD system property. > > * Rename `IntStructure.getInteger` to `IntStructure.get`. > > Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method > `Integer.getInteger`, which gets the integer value of a system property. > > Below are some of the more interesting test results. > > * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray > values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16. > > * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black > for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that > displays black for values `0x7F` or less and white for values `0x80` or greater. > > * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the > tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame > buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows the animation speed of each model in > milliseconds per frame and frames per second. > > | Product Name | Speed (ms) | Rate (fps) | > | ------------- |:----------:|:----------:| > | Kobo Touch B | 125 | 8.0 | > | Kobo Touch C | 130 | 7.7 | > | Kobo Glo HD | 140 | 7.1 | > | Kobo Clara HD | 145 | 6.9 | This pull request has now been integrated. Changeset: 66c3b385 Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/66c3b385 Stats: 238 lines in 7 files changed: 2 ins; 193 del; 43 mod 8227425: Add support for e-paper displays on i.MX6 devices Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/60 From ajoseph at openjdk.java.net Thu Apr 30 05:28:36 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 30 Apr 2020 05:28:36 GMT Subject: [Rev 03] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: <3vN-a-RqcI7btX66Ysw4WSo0JxivVGAmPnj_Of42Uv8=.3809b5f0-4581-435c-91cf-82c22b63d04e@github.com> References: <3vN-a-RqcI7btX66Ysw4WSo0JxivVGAmPnj_Of42Uv8=.3809b5f0-4581-435c-91cf-82c22b63d04e@github.com> Message-ID: On Wed, 29 Apr 2020 14:01:50 GMT, Bhawesh Choudhary wrote: >> As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to >> fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare >> against 600 font weight. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > style format changes Marked as reviewed by ajoseph (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From arapte at openjdk.java.net Thu Apr 30 07:13:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 30 Apr 2020 07:13:24 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: References: Message-ID: On Wed, 29 Apr 2020 09:58:21 GMT, Jeanette Winzenburg wrote: > > > didn't look closely, just wondering why you need a system test for this? The system test file `TabPanePermuteGetTabsTest` was added to address exact similar kind of issue [JDK-8222457](https://bugs.openjdk.java.net/browse/JDK-8222457). The current issue [JDK-8237602](https://bugs.openjdk.java.net/browse/JDK-8237602) is just another case of same type. So it seems good to add a new test with similar existing tests. I myself had fixed the previous issue, Can't remember why did I not consider of a unit test then ??. ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From arapte at openjdk.java.net Thu Apr 30 07:13:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 30 Apr 2020 07:13:24 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: References: Message-ID: On Wed, 29 Apr 2020 14:42:32 GMT, Kevin Rushforth wrote: > > > The following is wrong in your Description: Thanks Kevin, the description is corrected now. ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From fastegal at openjdk.java.net Thu Apr 30 11:24:40 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 30 Apr 2020 11:24:40 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: References: Message-ID: On Thu, 30 Apr 2020 07:08:24 GMT, Ambarish Rapte wrote: > The system test file `TabPanePermuteGetTabsTest` was added to address exact similar kind of issue > [JDK-8222457](https://bugs.openjdk.java.net/browse/JDK-8222457). The current issue > [JDK-8237602](https://bugs.openjdk.java.net/browse/JDK-8237602) is just another case of same type. So it seems good to > add a new test with similar existing tests. I myself had fixed the previous issue, Can't remember why did I not > consider of a unit test then ??. yeah, if we don't document everything :))) Would you consider moving both into a unit test? Have one locally, could send it to you .. Also a minor quirk as to the naming: it should not name it "permutation" because it isn't from the perspective of the list change: the notification is a "replace". Btw, the pattern in the listener (of collecting up additions/removals) is a bit smelly - will fail as soon as you get disjoint additions (on the bright side: they don't happen in the current implementation of ObservableList but are allowed to), just something to keep in mind :) ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From arapte at openjdk.java.net Thu Apr 30 12:57:16 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 30 Apr 2020 12:57:16 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: References: Message-ID: <8LnxMeO3uGFNIJ6-6c96aCXUuWJ0dfGgSOBi2izVkhQ=.dc5ea7c6-6cfc-4463-8ff3-2fd0bcaf7c3b@github.com> On Thu, 30 Apr 2020 11:22:33 GMT, Jeanette Winzenburg wrote: > Would you consider moving both into a unit test? Have one locally, could send it to you .. A ready test ?? , That's very nice of you. Yes, We can move all the four tests to unit test. But I would prefer to do it as another TEST_BUG. Does that sound good ? > Btw, the pattern in the listener (of collecting up additions/removals) is a bit smelly I did try to change whole implementation, but it looked like a big change for the issue we have. The fix is very minimal and local. > it should not name it "permutation" Shall think of a new name when we move the tests.. ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From fastegal at openjdk.java.net Thu Apr 30 16:04:54 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 30 Apr 2020 16:04:54 GMT Subject: RFR: 8237602: TabPane doesn't respect order of TabPane.getTabs() list In-Reply-To: <8LnxMeO3uGFNIJ6-6c96aCXUuWJ0dfGgSOBi2izVkhQ=.dc5ea7c6-6cfc-4463-8ff3-2fd0bcaf7c3b@github.com> References: <8LnxMeO3uGFNIJ6-6c96aCXUuWJ0dfGgSOBi2izVkhQ=.dc5ea7c6-6cfc-4463-8ff3-2fd0bcaf7c3b@github.com> Message-ID: On Thu, 30 Apr 2020 12:55:02 GMT, Ambarish Rapte wrote: > > A ready test ?? , That's very nice of you. Yes, We can move all the four tests to unit test. But I would prefer to do > it as another TEST_BUG. Does that sound good ? not quite complete, just nearly - attached the unit test to the issue [JDK-8244195](https://bugs.openjdk.java.net/browse/JDK-8244195) you created > > > Btw, the pattern in the listener (of collecting up additions/removals) is a bit smelly > > I did try to change whole implementation, but it looked like a big change for the issue we have. The fix is very > minimal and local. good with me, as long as it covers all possible modifications to the tabs list have a nice weekend (holiday here in Berlin tomorrow, so I might be off, except that with corona there's not so much too do, except working :) ------------- PR: https://git.openjdk.java.net/jfx/pull/201 From github.com+4208131+bhaweshkc at openjdk.java.net Thu Apr 30 16:24:47 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Thu, 30 Apr 2020 16:24:47 GMT Subject: [Integrated] RFR: 8191758: Match WebKit's font weight rendering with JavaFX In-Reply-To: References: Message-ID: On Tue, 14 Apr 2020 10:25:52 GMT, Bhawesh Choudhary wrote: > As per JavaFx 700 font weight is considered to be bold but webkit is using 600 font weight for text to become bold. to > fix issue, use boldWeightValue() function which uses 700 font weight rather than isFontWeightBold() which compare > against 600 font weight. This pull request has now been integrated. Changeset: 8ad58052 Author: bhawesh Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/8ad58052 Stats: 26 lines in 2 files changed: 0 ins; 25 del; 1 mod 8191758: Match WebKit's font weight rendering with JavaFX Reviewed-by: kcr, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/180 From github.com+2720909+jskov at openjdk.java.net Thu Apr 30 17:04:51 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Thu, 30 Apr 2020 17:04:51 GMT Subject: [Integrated] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() In-Reply-To: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> References: <17vHr1LI1HCXZpj3CnMyrwHMjJSmx6tiTLxQJfAzN6U=.e0772b76-2bf9-4095-9401-fcd1fac9e1c4@github.com> Message-ID: On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov wrote: > Make the two ways of associating a ToggleButton with a ToggleGroup interact correctly. > > This fixes https://bugs.openjdk.java.net/browse/JDK-8198402 This pull request has now been integrated. Changeset: 3130fc80 Author: Jesper Skov Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3130fc80 Stats: 114 lines in 2 files changed: 10 ins; 99 del; 5 mod 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles() Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/167 From tsayao at openjdk.java.net Thu Apr 30 17:52:10 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 30 Apr 2020 17:52:10 GMT Subject: [Rev 50] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix window position bug ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/85defa52..3e3aa584 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.50 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.49-50 Stats: 15 lines in 1 file changed: 2 ins; 9 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Thu Apr 30 18:18:35 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 30 Apr 2020 18:18:35 GMT Subject: [Rev 51] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Fix build with merged linux.gradle - Merge branch 'master' into jdk_8236651 - Merge pull request #9 from openjdk/master Merge from upstream - Fix window position bug - Rename flag to javafx.gtk.experimental - Rename flag to javafx.gtk.experimental - Restore comment position - Restore deleted idea file - Smooth scrolling only possible with impl on java side - JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute Reviewed-by: kcr, ghb 8234474: [macos 10.15] Crash in file dialog in sandbox mode Reviewed-by: arapte, prr 8236648: javadoc warning on Text::tabSizeProperty method Reviewed-by: kcr 8233798: Ctrl-L character mistakenly removed from gstreamer.md Reviewed-by: almatvee 8232589: Remove CoreAudio Utility Classes Reviewed-by: kcr, jvos 8236448: Remove unused and repair broken Android/Dalvik code Reviewed-by: kcr 8236808: javafx_iio can not be used in static environment Reviewed-by: kcr 8236733: Change JavaFX release version to 15 Reviewed-by: arapte 8232128: Better formatting for numbers Reviewed-by: rhalade, ghb 8232214: Improved internal validations Reviewed-by: ghb, rhalade 8237078: [macOS] Media build broken on XCode 11 Reviewed-by: kcr, almatvee JDK-8236651 Simplify and update glass gtk backend Cleaning Cleaning + change year to 2020 Fix crash Fix crash Fix crash Revert idea files Fix flickering and sizing issues Pass more tests Small fixes Use gtk_window_set_default_size for before-map sizing which is the appropriate function Better alternative calculation for no _NET_FRAME_EXTENTS WM extension Fix dialog with owner sizing Maybe fix background Big cleanup Allow undecorated windows to be maximized. Mouse pointer grab Work on mouse grab Fix Initial Size Revert "Fix Initial Size" This reverts commit 0c982d60 Better fix for initial size 8157224: isNPOTSupported check is too strict Reviewed-by: kcr 8233942: Update to 609.1 version of WebKit Co-authored-by: Guru HB Co-authored-by: Arun Joseph Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, ajoseph 8236753: Animations do not play backwards after being stopped Reviewed-by: kcr, arapte 8237823: Mark TextTest.testTabSize as unstable Reviewed-by: prr 8236912: NullPointerException when clicking in WebView with Button 4 or Button 5 Reviewed-by: ghb, kcr 8232824: Removing TabPane with strong referenced content causes memory leak from weak one Reviewed-by: kcr, aghaisas 8237372: NullPointerException in TabPaneSkin.stopDrag Reviewed-by: arapte 8237003: Remove hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree Reviewed-by: kcr 8238249: GetPrimitiveArrayCritical passed with hardcoded FALSE value Reviewed-by: kcr 8088198: Exception thrown from snapshot if dimensions are larger than max texture size Reviewed-by: arapte, kcr 8237833: Check glyph size before adding to glyph texture cache Reviewed-by: kcr 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data. Reviewed-by: kcr 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte Revert back focus mechanism Fix seat_grab param Fix POPUP window positioning Fix bug on extents calculation Ajustments Fix pointer grab bug Remove unused var 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas Adjust comment Adjust comment Fix compile error on implicit function declaration on updated g++ fix compilation on ubuntu 16.04 calculate less if _NET_FRAME_EXTENTS is available Fixes for WM that do not support frame extents Mouse grab fixes on Ubuntu 20.04 Gtk+3.20+ Better comment Fix Tab Prefer content size over window size. Fixes for ubuntu 16.04 (which delays frame extents) Just comment fixing More fixes for 16.04 (i mean gtk+ version that ships on 16.04, plus the different window manager - Unity). Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Fix unfullscreen bug on older gtk+ Only work-around Unity bug if Unity is the Window Manager (Ubuntu 16.04). Separate the new gtk glass impl Make gtk3 compile without deprecations Make gtk3 compile without deprecations Make gtk3 compile without deprecations - ... and 5 more: https://git.openjdk.java.net/jfx/compare/08a98abd...7d350bc6 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/3e3aa584..7d350bc6 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.51 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.50-51 Stats: 4836 lines in 111 files changed: 3890 ins; 751 del; 195 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From jskov at zoftcorp.dk Thu Apr 30 18:59:47 2020 From: jskov at zoftcorp.dk (Jesper Skov) Date: Thu, 30 Apr 2020 20:59:47 +0200 Subject: Gradle support for getting :web:test working properly In-Reply-To: References: <177a75cd-3fe4-7b8c-b5e0-eaa2c7d26a4f@oracle.com> Message-ID: I have created https://github.com/openjdk/jfx/pull/202 with a suggested implementation. Looking for feedback. Cheers, Jesper On Fri, Apr 24, 2020 at 5:13 PM Jesper Skov wrote: > Thanks, I will give it a shot. > > Jesper > > > On Thu, Apr 23, 2020 at 7:45 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> That's an interesting idea that might be worth pursuing. It would help >> mitigate what has been a long-standing pain point for developers who >> don't want to build media or web, but would like to run them. I would >> caution, though, that it is still not a substitute for building both >> media and WebKit yourself, since it will still not work reliably in the >> case where there is an interface change or some other mutually dependent >> change between the native media or web library and Java class files. In >> those cases you are stuck until a new EA build is available. >> >> If you do want to pursue this, then as long as the dependency on >> org.openjfx:javafx-web and org.openjfx:javafx-media is localized to the >> downloading and unpacking step you mentioned, this would be fine with >> me. Maybe others could help test it on Mac and Windows. >> >> As for the name of the new property, maybe STUB_RUNTIME_OPENJFX? The >> easiest way to implement this might be to set the value of >> `defaultStubRuntime` to the directory into which you unpack it >> (underneath either build or buildSrc/build). >> >> -- Kevin >> >> >> On 4/23/2020 1:14 AM, Jesper Skov wrote: >> > Hi >> > >> > I struggled somewhat to get :web:test running with -PSTUB_RUNTIME. >> > >> > The JVM kept crashing by what turned out to be missing media >> > libraries (the failure message was hidden). >> > >> > I tried building with -PCOMPILE_WEBKIT=true, but it takes a terrible >> > long time on my laptop. And did not in itself fix the problem. >> > >> > Frustrations and lost time was the only real outcome of this :) >> > >> > >> > >> > >> > So I would suggest adding logic to the build file to allow something >> > like: >> > >> > gradlew -PSTUB_RUNTIME_USE=15-ea+4 all test >> > >> > This should download org.openjfx:javafx-web and >> > org.openjfx:javafx-media artifacts in the specified version. >> > >> > Then unpack the shared libraries to a build folder, and make them >> > availble via the STUB_RUNTIME logic. >> > >> > >> > Plus an addition to the CONTRIBUTING.md documenting this. >> > >> > >> > I would be happy to help make and/or test the changes, but am only >> > able to work on Linux. >> > >> > >> > Thanks, >> > Jesper >> > From kevin.rushforth at oracle.com Thu Apr 30 19:49:22 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Apr 2020 12:49:22 -0700 Subject: Gradle support for getting :web:test working properly In-Reply-To: References: <177a75cd-3fe4-7b8c-b5e0-eaa2c7d26a4f@oracle.com> Message-ID: I went ahead and created the JBS bug that you will need for this: https://bugs.openjdk.java.net/browse/JDK-8244212 -- Kevin On 4/30/2020 11:59 AM, Jesper Skov wrote: > I have created https://github.com/openjdk/jfx/pull/202 with a suggested > implementation. > > Looking for feedback. > > Cheers, > Jesper > > On Fri, Apr 24, 2020 at 5:13 PM Jesper Skov wrote: > >> Thanks, I will give it a shot. >> >> Jesper >> >> >> On Thu, Apr 23, 2020 at 7:45 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> That's an interesting idea that might be worth pursuing. It would help >>> mitigate what has been a long-standing pain point for developers who >>> don't want to build media or web, but would like to run them. I would >>> caution, though, that it is still not a substitute for building both >>> media and WebKit yourself, since it will still not work reliably in the >>> case where there is an interface change or some other mutually dependent >>> change between the native media or web library and Java class files. In >>> those cases you are stuck until a new EA build is available. >>> >>> If you do want to pursue this, then as long as the dependency on >>> org.openjfx:javafx-web and org.openjfx:javafx-media is localized to the >>> downloading and unpacking step you mentioned, this would be fine with >>> me. Maybe others could help test it on Mac and Windows. >>> >>> As for the name of the new property, maybe STUB_RUNTIME_OPENJFX? The >>> easiest way to implement this might be to set the value of >>> `defaultStubRuntime` to the directory into which you unpack it >>> (underneath either build or buildSrc/build). >>> >>> -- Kevin >>> >>> >>> On 4/23/2020 1:14 AM, Jesper Skov wrote: >>>> Hi >>>> >>>> I struggled somewhat to get :web:test running with -PSTUB_RUNTIME. >>>> >>>> The JVM kept crashing by what turned out to be missing media >>>> libraries (the failure message was hidden). >>>> >>>> I tried building with -PCOMPILE_WEBKIT=true, but it takes a terrible >>>> long time on my laptop. And did not in itself fix the problem. >>>> >>>> Frustrations and lost time was the only real outcome of this :) >>>> >>>> >>>> >>>> >>>> So I would suggest adding logic to the build file to allow something >>>> like: >>>> >>>> gradlew -PSTUB_RUNTIME_USE=15-ea+4 all test >>>> >>>> This should download org.openjfx:javafx-web and >>>> org.openjfx:javafx-media artifacts in the specified version. >>>> >>>> Then unpack the shared libraries to a build folder, and make them >>>> availble via the STUB_RUNTIME logic. >>>> >>>> >>>> Plus an addition to the CONTRIBUTING.md documenting this. >>>> >>>> >>>> I would be happy to help make and/or test the changes, but am only >>>> able to work on Linux. >>>> >>>> >>>> Thanks, >>>> Jesper From kcr at openjdk.java.net Thu Apr 30 22:54:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 30 Apr 2020 22:54:20 GMT Subject: RFR: 8237504: Update copyright header for files modified in 2020 Message-ID: Update last modified year of copyright headers for files modified in 2020. ------------- Commit messages: - 8237504: Update copyright header for files modified in 2020 Changes: https://git.openjdk.java.net/jfx/pull/203/files Webrev: https://webrevs.openjdk.java.net/jfx/203/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237504 Stats: 144 lines in 144 files changed: 0 ins; 0 del; 144 mod Patch: https://git.openjdk.java.net/jfx/pull/203.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/203/head:pull/203 PR: https://git.openjdk.java.net/jfx/pull/203