From jvos at openjdk.java.net Sat Feb 1 08:38:08 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 1 Feb 2020 08:38:08 GMT Subject: [Rev 01] RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) In-Reply-To: References: Message-ID: <7TffkIbRRdHIZ6w_LBcagni0AvCO8RGsDH7UYE0A_VE=.d255462f-e491-455e-99c5-7923a91cb91c@github.com> On Sat, 1 Feb 2020 08:38:08 GMT, Kevin Rushforth wrote: >> This is a fix for [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the use of `CGEventTap` when running on macOS 10.15 or later. >> >> The effect of this bug is that a scary dialog is shown for all users the first time they run a JavaFX application and move the mouse is moved into the JavaFX window. It also is reported to block apps from being accepted in the Apple store. >> >> This bug is caused by a change in macOS 10.15 to require additional permissions for using CGEventTap, which JavaFX uses to track touch events. >> >> The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently enough (it tracks events delivered to a specific view, whereas the current code is implemented using a global monitor and a global set of touch points), that it would be too risky to change it this late in the release. >> >> For openjfx14, I am proposing to disable touch events completely if running on macOS 10.15 (or later). This will disable the tracking of native touch events, but those events are not used by default on macOS anyway. For Mac systems with a trackpad we instead rely on macOS to do the gesture recognition by default, and this fix does not intefere with that functionality. >> >> I have verified that this avoids the dialog on macOS 10.15 and that the HelloGestures program still runs correctly and still recognizes trackpad gestures such as zoom and rotate. I also verified that the changes don't affect macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS versions). >> >> See [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) on openjfx-dev for more discussion. > > The pull request has been updated with 1 additional commit. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/102 From kcr at openjdk.java.net Sat Feb 1 14:36:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 1 Feb 2020 14:36:46 GMT Subject: [Integrated] RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) In-Reply-To: References: Message-ID: <13c99a35-a3c1-44ee-b65c-90e53b193242@openjdk.org> Changeset: 2ab40c1c Author: Kevin Rushforth Date: 2020-02-01 14:35:47 +0000 URL: https://git.openjdk.java.net/jfx/commit/2ab40c1c 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos ! modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m From kcr at openjdk.java.net Sat Feb 1 23:41:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 1 Feb 2020 23:41:59 GMT Subject: [Integrated] RFR: 8237770: Error creating fragment phong shader on iOS In-Reply-To: References: Message-ID: <6b8b1693-f027-4746-a9bd-39d1342c4632@openjdk.org> Changeset: 56267e1f Author: Jose Pereda Committer: Kevin Rushforth Date: 2020-02-01 23:41:31 +0000 URL: https://git.openjdk.java.net/jfx/commit/56267e1f 8237770: Error creating fragment phong shader on iOS Reviewed-by: kcr ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/diffuse_color.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/diffuse_none.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/diffuse_texture.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main0Lights.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main2Lights.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main3Lights.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/normalMap_none.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/normalMap_texture.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/selfIllum_none.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/selfIllum_texture.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/specular_color.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/specular_mix.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/specular_none.frag ! modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/specular_texture.frag From nlisker at openjdk.java.net Sun Feb 2 00:29:38 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 2 Feb 2020 00:29:38 GMT Subject: RFR: 8208761: Update constant collections to use the new immutable collections Message-ID: Resubmitting from before the transition to this repo. See linked issue for details. ------------- Commits: - 440e7a88: Initial commit of 8208761 Changes: https://git.openjdk.java.net/jfx/pull/104/files Webrev: https://webrevs.openjdk.java.net/jfx/104/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8208761 Stats: 972 lines in 18 files changed: 180 ins; 279 del; 513 mod Patch: https://git.openjdk.java.net/jfx/pull/104.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/104/head:pull/104 PR: https://git.openjdk.java.net/jfx/pull/104 From ghb at openjdk.java.net Mon Feb 3 08:52:03 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Mon, 3 Feb 2020 08:52:03 GMT Subject: [Integrated] RFR: 8237944: webview native cl "-m32" unknown option for windows 32-bit build In-Reply-To: References: Message-ID: <47d0fa56-c291-422e-9a71-b39c41bf17a4@openjdk.org> Changeset: aa91ebbb Author: Guru Hb Date: 2020-02-03 08:51:25 +0000 URL: https://git.openjdk.java.net/jfx/commit/aa91ebbb 8237944: webview native cl "-m32" unknown option for windows 32-bit build Reviewed-by: kcr ! modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm From arapte at openjdk.java.net Mon Feb 3 10:16:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 3 Feb 2020 10:16:13 GMT Subject: [Rev 01] RFR: 8237975: Non-embedded Animations do not play backwards after being paused In-Reply-To: <74uIjcC3pLjZJJjBgq_mf7eywW9_eAXoPF73avEaBds=.5bf0ac5b-3725-4e6b-8e09-781463a9a689@github.com> References: <74uIjcC3pLjZJJjBgq_mf7eywW9_eAXoPF73avEaBds=.5bf0ac5b-3725-4e6b-8e09-781463a9a689@github.com> Message-ID: On Mon, 3 Feb 2020 10:16:13 GMT, Nir Lisker wrote: >> [8236858](https://bugs.openjdk.java.net/browse/JDK-8236858) (Animations do not play backwards after being paused) has been split to deal with [embedded](https://bugs.openjdk.java.net/browse/JDK-8237974) and [not embedded](https://bugs.openjdk.java.net/browse/JDK-8237975) animations. This is a fix for the latter. >> The reason for the split is that embedded animations have a much more complex behavior. The current state of the relation between an animation and its clip envelope is already messy and should be corrected, even more so for embedded animations whose parent controls their behavior as well (sometimes in conflict with the child's clip envelope). This will require a redesign which can be discussed for 15. See the parent issue [8210238](https://bugs.openjdk.java.net/browse/JDK-8210238) for the list of bugs that arise from it. >> >> This simple fix allows to change the current rate of a `ClipEnvelope` also when the animations is `PAUSED`. A possible issue with this approach is that it changes the buggy behavior of embedded animations to a different buggy behavior. >> >> A concept test has been added, but it does not work yet since the mock clip envelope does not have sufficient behavior (`doTimePulse` does not actually do a time pulse). Open for ideas on how to make it simple, otherwise I will add a method to set a clip envelope and create a new one ad-hoc. > > The pull request has been updated with 1 additional commit. Looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/98 From nlisker at openjdk.java.net Mon Feb 3 12:30:52 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 3 Feb 2020 12:30:52 GMT Subject: [Integrated] RFR: 8237975: Non-embedded Animations do not play backwards after being paused In-Reply-To: References: Message-ID: <9d11c13b-fcad-4b54-a5f9-ae21a12df42b@openjdk.org> Changeset: 1749e854 Author: Nir Lisker Date: 2020-02-03 12:29:43 +0000 URL: https://git.openjdk.java.net/jfx/commit/1749e854 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! modules/javafx.graphics/src/shims/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeShim.java ! modules/javafx.graphics/src/shims/java/javafx/animation/AnimationShim.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationSetRateTest.java From kcr at openjdk.java.net Mon Feb 3 13:17:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 Feb 2020 13:17:29 GMT Subject: RFR: 8237503: Update copyright header for files modified in 2020 Message-ID: Fix for [JDK-8237503](https://bugs.openjdk.java.net/browse/JDK-8237503) to update the "last modified" year in the copyright header for all files modified in 2020 in the `jfx14` branch. NOTE: I'll update this to pick up any last-minute changes integrated to `jfx14` and then remove the WIP. ------------- Commits: - f6dfbd83: Pickup additional files from recent commits - b9e40bbc: Merge remote-tracking branch 'upstream/jfx14' into 8237503-copyr-2020 - 15ca17c2: 8237503: Update copyright header for files modified in 2020 Changes: https://git.openjdk.java.net/jfx/pull/103/files Webrev: https://webrevs.openjdk.java.net/jfx/103/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237503 Stats: 53 lines in 53 files changed: 0 ins; 0 del; 53 mod Patch: https://git.openjdk.java.net/jfx/pull/103.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/103/head:pull/103 PR: https://git.openjdk.java.net/jfx/pull/103 From kcr at openjdk.java.net Mon Feb 3 13:17:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 Feb 2020 13:17:29 GMT Subject: RFR: 8237503: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: On Fri, 31 Jan 2020 23:32:55 GMT, Kevin Rushforth wrote: > Fix for [JDK-8237503](https://bugs.openjdk.java.net/browse/JDK-8237503) to update the "last modified" year in the copyright header for all files modified in 2020 in the `jfx14` branch. > > NOTE: I'll update this to pick up any last-minute changes integrated to `jfx14` and then remove the WIP. @arapte you can take an initial look whenever you are ready. I expect only a few new files to come in, which I will push as an additional commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/103 From arapte at openjdk.java.net Mon Feb 3 13:17:29 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 3 Feb 2020 13:17:29 GMT Subject: RFR: 8237503: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: On Fri, 31 Jan 2020 23:34:02 GMT, Kevin Rushforth wrote: >> Fix for [JDK-8237503](https://bugs.openjdk.java.net/browse/JDK-8237503) to update the "last modified" year in the copyright header for all files modified in 2020 in the `jfx14` branch. >> >> NOTE: I'll update this to pick up any last-minute changes integrated to `jfx14` and then remove the WIP. > > @arapte you can take an initial look whenever you are ready. I expect only a few new files to come in, which I will push as an additional commit. Hi @kevinrushforth , The file list look good. ------------- PR: https://git.openjdk.java.net/jfx/pull/103 From Rony.Flatscher at wu.ac.at Mon Feb 3 13:53:25 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 3 Feb 2020 14:53:25 +0100 Subject: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script In-Reply-To: <6ed49ec2-223c-200b-91aa-b85b8e07431a@oracle.com> References: <5bca4803-6372-7569-254c-3d08a57accb0@wu.ac.at> <91dcbb22-2acf-3c51-6f89-a0d394688bed@wu.ac.at> <1ea149d7-69a5-dd3a-f5d6-82b08921d2a9@oracle.com> <9e391ac6-c9ab-47be-88f4-a1214290f371@oracle.com> <4a81fc93-c933-3ab9-363e-2a9ef54632c6@wu.ac.at> <2f8f8701-5400-ae48-abf1-285de1e18f3b@oracle.com> <39b317bf-4aac-16be-e82d-6519452d8af8@wu.ac.at> <029b4f44-bf12-e99f-bf60-118b5638dcff@wu.ac.at> <12554239-08b5-8440-8c21-f56729a4e928@wu.ac.at> <174bd8e2-1d02-1b14-1164-63e978028585@wu.ac.at> <6ed49ec2-223c-200b-91aa-b85b8e07431a@oracle.com> Message-ID: Hi Kevin, On 29.01.2020 13:24, Kevin Rushforth wrote: > The RFE you filed is now available here: > > https://bugs.openjdk.java.net/browse/JDK-8238080 thank you very much! Cheers ---rony P.S.: Have not received any automatic notification e-mail so far. From Rony.Flatscher at wu.ac.at Mon Feb 3 14:04:28 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 3 Feb 2020 15:04:28 +0100 Subject: Question ad creating a testcase that needs a jar on class- or module path In-Reply-To: <40571aa5-a667-d279-c410-ecb4648a9629@oracle.com> References: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at> <40571aa5-a667-d279-c410-ecb4648a9629@oracle.com> Message-ID: Hi Kevin, On 31.01.2020 16:38, Kevin Rushforth wrote: > And if you need a modular jar, you might look at ModuleLauncherTest instead. thank you very much for this important hint as well! Having no knowledge about gradle it will take me a while to research and digest, but this definitely helps me to jump start to the section where tests get carried out with separately configured JVMs. Would it be o.k. to first submit a pull request for JDK-8234959 and later, when an appropriate test unit using the SPI dependent pseudo script engine is available submitting the test app with different pull request? Or would it be better to submit both with the same pull request? ---rony From arapte at openjdk.java.net Mon Feb 3 14:27:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 3 Feb 2020 14:27:39 GMT Subject: RFR: 8237503: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: On Fri, 31 Jan 2020 23:32:55 GMT, Kevin Rushforth wrote: > Fix for [JDK-8237503](https://bugs.openjdk.java.net/browse/JDK-8237503) to update the "last modified" year in the copyright header for all files modified in 2020 in the `jfx14` branch. > > NOTE: I'll update this to pick up any last-minute changes integrated to `jfx14` and then remove the WIP. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/103 From kcr at openjdk.java.net Mon Feb 3 15:51:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 Feb 2020 15:51:06 GMT Subject: [Integrated] RFR: 8237503: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: <47473275-c4ea-4bb4-950c-e377d75994cd@openjdk.org> Changeset: a4b9f24e Author: Kevin Rushforth Date: 2020-02-03 15:48:52 +0000 URL: https://git.openjdk.java.net/jfx/commit/a4b9f24e 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte ! buildSrc/android.gradle ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/android/DalvikInput.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/AndroidInputDeviceRegistry.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/AndroidPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/DispmanPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/HeadlessPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Platform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/OMAPPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/X11Platform.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! modules/javafx.graphics/src/main/java/javafx/animation/Animation.java ! modules/javafx.graphics/src/main/java/javafx/scene/Scene.java ! modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java ! modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp ! modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp ! modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.h ! modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp ! modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp ! modules/javafx.graphics/src/main/native-glass/monocle/EGL.c ! modules/javafx.graphics/src/main/native-glass/monocle/android/AndroidScreen.c ! modules/javafx.graphics/src/main/native-glass/monocle/android/dalvikUtils.c ! modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.c ! modules/javafx.graphics/src/main/native-glass/monocle/dispman/DispmanScreen.c ! modules/javafx.graphics/src/main/native-iio/jpegloader.c ! modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c ! modules/javafx.graphics/src/main/native-prism-es2/monocle/eglUtils.c ! modules/javafx.graphics/src/shims/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeShim.java ! modules/javafx.graphics/src/shims/java/javafx/animation/AnimationShim.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationSetRateTest.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationTest.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/SequentialTransitionPlayTest.java ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.mm ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFSoundLevelUnit.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFSoundLevelUnit.h ! modules/javafx.web/src/main/java/javafx/scene/web/WebView.java ! modules/javafx.web/src/main/native/Source/WebCore/bindings/java/JavaDOMUtils.h ! modules/javafx.web/src/test/java/test/javafx/scene/web/DOMTest.java ! modules/javafx.web/src/test/java/test/javafx/scene/web/WebViewTest.java ! tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java ! tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java From kcr at openjdk.java.net Mon Feb 3 16:18:48 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 Feb 2020 16:18:48 GMT Subject: RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: On Sun, 2 Feb 2020 00:15:02 GMT, Nir Lisker wrote: > Resubmitting from before the transition to this repo. See linked issue for details. Given the large number of changes, I'd like two reviewers to look it over for any possible typos. ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From kcr at openjdk.java.net Mon Feb 3 16:32:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 Feb 2020 16:32:25 GMT Subject: [Integrated] RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) In-Reply-To: References: Message-ID: <0da140ab-da79-4924-a83b-700b5c56a901@openjdk.org> Changeset: 2ab40c1c Author: Kevin Rushforth Date: 2020-02-01 14:35:47 +0000 URL: https://git.openjdk.java.net/jfx/commit/2ab40c1c 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina) Reviewed-by: prr, jvos ! modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m From nlisker at openjdk.java.net Mon Feb 3 16:32:27 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 3 Feb 2020 16:32:27 GMT Subject: [Integrated] RFR: 8237975: Non-embedded Animations do not play backwards after being paused In-Reply-To: References: Message-ID: <3632cc94-626e-4a0b-b3f6-5a8c66b56878@openjdk.org> Changeset: 1749e854 Author: Nir Lisker Date: 2020-02-03 12:29:43 +0000 URL: https://git.openjdk.java.net/jfx/commit/1749e854 8237975: Non-embedded Animations do not play backwards after being paused Reviewed-by: kcr, arapte ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! modules/javafx.graphics/src/shims/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeShim.java ! modules/javafx.graphics/src/shims/java/javafx/animation/AnimationShim.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationSetRateTest.java From kcr at openjdk.java.net Mon Feb 3 16:32:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 Feb 2020 16:32:33 GMT Subject: [Integrated] RFR: 8237503: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: <7ba852b2-d3a2-4ea6-bf01-c53de3924653@openjdk.org> Changeset: a4b9f24e Author: Kevin Rushforth Date: 2020-02-03 15:48:52 +0000 URL: https://git.openjdk.java.net/jfx/commit/a4b9f24e 8237503: Update copyright header for files modified in 2020 Reviewed-by: arapte ! buildSrc/android.gradle ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/android/DalvikInput.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/AndroidInputDeviceRegistry.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/AndroidPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/DispmanPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/HeadlessPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Platform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/OMAPPlatform.java ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/X11Platform.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/FiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/InfiniteClipEnvelope.java ! modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelope.java ! modules/javafx.graphics/src/main/java/javafx/animation/Animation.java ! modules/javafx.graphics/src/main/java/javafx/scene/Scene.java ! modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java ! modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp ! modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp ! modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.h ! modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp ! modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp ! modules/javafx.graphics/src/main/native-glass/monocle/EGL.c ! modules/javafx.graphics/src/main/native-glass/monocle/android/AndroidScreen.c ! modules/javafx.graphics/src/main/native-glass/monocle/android/dalvikUtils.c ! modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.c ! modules/javafx.graphics/src/main/native-glass/monocle/dispman/DispmanScreen.c ! modules/javafx.graphics/src/main/native-iio/jpegloader.c ! modules/javafx.graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c ! modules/javafx.graphics/src/main/native-prism-es2/monocle/eglUtils.c ! modules/javafx.graphics/src/shims/java/com/sun/scenario/animation/shared/SingleLoopClipEnvelopeShim.java ! modules/javafx.graphics/src/shims/java/javafx/animation/AnimationShim.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationSetRateTest.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/AnimationTest.java ! modules/javafx.graphics/src/test/java/test/javafx/animation/SequentialTransitionPlayTest.java ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.mm ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFSoundLevelUnit.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFSoundLevelUnit.h ! modules/javafx.web/src/main/java/javafx/scene/web/WebView.java ! modules/javafx.web/src/main/native/Source/WebCore/bindings/java/JavaDOMUtils.h ! modules/javafx.web/src/test/java/test/javafx/scene/web/DOMTest.java ! modules/javafx.web/src/test/java/test/javafx/scene/web/WebViewTest.java ! tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java ! tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java From tsayao at openjdk.java.net Mon Feb 3 17:26:49 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 3 Feb 2020 17:26:49 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> Message-ID: On Wed, 29 Jan 2020 12:16:49 GMT, Thiago Milczarek Sayao wrote: >> To anyone willing to test this, here is a binary test-release for linux: >> >> https://github.com/tsayao/jfx/releases/tag/test-glass-gtk > > It's ready for an initial look. > > If anyone has issues with Linux, I will fix it. **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; * Focus Grab: Use gtk_grab_add and gtk window group functions instead of custom code; * 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; * 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 * 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. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Mon Feb 3 17:39:20 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 3 Feb 2020 17:39:20 GMT Subject: [Rev 18] 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) The pull request has been updated with a new target base due to a merge or a rebase. ------------- Commits: - 14a75ce4: Merge branch 'master' into jdk_8236651 - e829b8e9: Better fix for initial size - 058a0992: Revert "Fix Initial Size" - 0c982d60: Fix Initial Size - 694641f6: JDK-8236651 Simplify and update glass gtk backend - 9397a748: Merge pull request #4 from openjdk/master Changes: https://git.openjdk.java.net/jfx/pull/77/files Webrev: https://webrevs.openjdk.java.net/jfx/77/webrev.18 Stats: 3360 lines in 12 files changed: 782 ins; 1797 del; 781 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 neacsu.cristianstefan at gmail.com Tue Feb 4 10:52:51 2020 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Tue, 4 Feb 2020 12:52:51 +0200 Subject: set Destination attribute in printReqAttrSet In-Reply-To: References: <5CD5B191.7070705@oracle.com> Message-ID: Hello, Any updates regarding this matter? :-s Thank you in advance, Cristian-Stefan On Sat, May 11, 2019 at 2:36 AM Neacsu Cristian < neacsu.cristianstefan at gmail.com> wrote: > Damn ... Thank you for your reply and for the ticket submitted. > I created an invoice application for my own company, and imagine that java > 9+ would kill me :) All the invoices are generated automatically through > pdf printer (I tried few free pdf libraries as an alternative, but for what > I need they have poor results). > > I actually posted my ugly solution as well here some time ago: > > https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798 > > I know it is not much, but 89 hits might mean something. People might > fight with it later, when they are going to migrate for new java versions. > > Thank you so much, and looking forward if you guys have time to take care > of it. > > Cristian-Stefan > > > > On Fri, May 10, 2019 at 8:15 PM Philip Race > wrote: > >> Everything you are touching there pre-supposes knowledge >> of today's implementation of the JavaFX printing API, so >> I don't think we can endorse that. >> The right thing to do (maybe years ago!) is to file >> an RFE to request that something like the Destination attribute >> be supported in the FX printing API. I've reviewed the open >> bug list and I don't see that anyone else has asked for this. >> >> I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717 >> >> JFYI, I reviewed some old notes and it was originally planned to be >> supported in the API but during design discussion it was removed >> as a result of a combination of getting it right, not being sure how >> many people would need it (you may be the first) and some perhaps >> over-stated concerns about security. >> >> -phil. >> >> On 5/10/19, 1:39 AM, Neacsu Cristian wrote: >> > For windows print through "Microsoft Print to PDF", there is no way >> right >> > now to pre-define a path programmatically. There is no way to set inside >> > the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, >> to >> > solve this issue. >> > >> > Before jdk 9, I was bypassing it through reflection like this: >> > >> > java.lang.reflect.Field field = >> job.getClass().getDeclaredField("jobImpl"); >> > field.setAccessible(true); >> > PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); >> > field.setAccessible(false); >> > field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); >> > field.setAccessible(true); >> > PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) >> > field.get(jobImpl); >> > field.setAccessible(false); >> > printReqAttrSet.add(new Destination(new File(filePath).toURI())); >> > >> > Now, the module is closed, so I cannot access it through reflection. Is >> > there a way to obtain this behavior again? >> > From sproket at videotron.ca Tue Feb 4 14:18:24 2020 From: sproket at videotron.ca (Dan Howard) Date: Tue, 4 Feb 2020 09:18:24 -0500 Subject: set Destination attribute in printReqAttrSet In-Reply-To: References: <5CD5B191.7070705@oracle.com> Message-ID: Have you tried using normal printing in Java? Just to print something with the usual AWT etc APIs.? If that works you could convert the node to an image to print. On 2/4/2020 5:52 AM, Neacsu Cristian wrote: > Hello, > > Any updates regarding this matter? :-s > > Thank you in advance, > Cristian-Stefan > > On Sat, May 11, 2019 at 2:36 AM Neacsu Cristian < > neacsu.cristianstefan at gmail.com> wrote: > >> Damn ... Thank you for your reply and for the ticket submitted. >> I created an invoice application for my own company, and imagine that java >> 9+ would kill me :) All the invoices are generated automatically through >> pdf printer (I tried few free pdf libraries as an alternative, but for what >> I need they have poor results). >> >> I actually posted my ugly solution as well here some time ago: >> >> https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798 >> >> I know it is not much, but 89 hits might mean something. People might >> fight with it later, when they are going to migrate for new java versions. >> >> Thank you so much, and looking forward if you guys have time to take care >> of it. >> >> Cristian-Stefan >> >> >> >> On Fri, May 10, 2019 at 8:15 PM Philip Race >> wrote: >> >>> Everything you are touching there pre-supposes knowledge >>> of today's implementation of the JavaFX printing API, so >>> I don't think we can endorse that. >>> The right thing to do (maybe years ago!) is to file >>> an RFE to request that something like the Destination attribute >>> be supported in the FX printing API. I've reviewed the open >>> bug list and I don't see that anyone else has asked for this. >>> >>> I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717 >>> >>> JFYI, I reviewed some old notes and it was originally planned to be >>> supported in the API but during design discussion it was removed >>> as a result of a combination of getting it right, not being sure how >>> many people would need it (you may be the first) and some perhaps >>> over-stated concerns about security. >>> >>> -phil. >>> >>> On 5/10/19, 1:39 AM, Neacsu Cristian wrote: >>>> For windows print through "Microsoft Print to PDF", there is no way >>> right >>>> now to pre-define a path programmatically. There is no way to set inside >>>> the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, >>> to >>>> solve this issue. >>>> >>>> Before jdk 9, I was bypassing it through reflection like this: >>>> >>>> java.lang.reflect.Field field = >>> job.getClass().getDeclaredField("jobImpl"); >>>> field.setAccessible(true); >>>> PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); >>>> field.setAccessible(false); >>>> field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); >>>> field.setAccessible(true); >>>> PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) >>>> field.get(jobImpl); >>>> field.setAccessible(false); >>>> printReqAttrSet.add(new Destination(new File(filePath).toURI())); >>>> >>>> Now, the module is closed, so I cannot access it through reflection. Is >>>> there a way to obtain this behavior again? From neacsu.cristianstefan at gmail.com Tue Feb 4 15:52:50 2020 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Tue, 4 Feb 2020 17:52:50 +0200 Subject: set Destination attribute in printReqAttrSet In-Reply-To: References: <5CD5B191.7070705@oracle.com> Message-ID: What I try to achieve, is to use "Microsoft Print to PDF" without inserting the path manually. In java 8 was possible to force adding that Destination parameter through reflection (again an ugly hack), because the API do not expose it. Now being encapsulated in Java 9+ is not achievable anymore... I need to generate automatically 50 nodes (which represents invoices) as PDF. On Tue, Feb 4, 2020 at 4:18 PM Dan Howard wrote: > Have you tried using normal printing in Java? Just to print something > with the usual AWT etc APIs. If that works you could convert the node > to an image to print. > > > On 2/4/2020 5:52 AM, Neacsu Cristian wrote: > > Hello, > > > > Any updates regarding this matter? :-s > > > > Thank you in advance, > > Cristian-Stefan > > > > On Sat, May 11, 2019 at 2:36 AM Neacsu Cristian < > > neacsu.cristianstefan at gmail.com> wrote: > > > >> Damn ... Thank you for your reply and for the ticket submitted. > >> I created an invoice application for my own company, and imagine that > java > >> 9+ would kill me :) All the invoices are generated automatically through > >> pdf printer (I tried few free pdf libraries as an alternative, but for > what > >> I need they have poor results). > >> > >> I actually posted my ugly solution as well here some time ago: > >> > >> > https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798 > >> > >> I know it is not much, but 89 hits might mean something. People might > >> fight with it later, when they are going to migrate for new java > versions. > >> > >> Thank you so much, and looking forward if you guys have time to take > care > >> of it. > >> > >> Cristian-Stefan > >> > >> > >> > >> On Fri, May 10, 2019 at 8:15 PM Philip Race > >> wrote: > >> > >>> Everything you are touching there pre-supposes knowledge > >>> of today's implementation of the JavaFX printing API, so > >>> I don't think we can endorse that. > >>> The right thing to do (maybe years ago!) is to file > >>> an RFE to request that something like the Destination attribute > >>> be supported in the FX printing API. I've reviewed the open > >>> bug list and I don't see that anyone else has asked for this. > >>> > >>> I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717 > >>> > >>> JFYI, I reviewed some old notes and it was originally planned to be > >>> supported in the API but during design discussion it was removed > >>> as a result of a combination of getting it right, not being sure how > >>> many people would need it (you may be the first) and some perhaps > >>> over-stated concerns about security. > >>> > >>> -phil. > >>> > >>> On 5/10/19, 1:39 AM, Neacsu Cristian wrote: > >>>> For windows print through "Microsoft Print to PDF", there is no way > >>> right > >>>> now to pre-define a path programmatically. There is no way to set > inside > >>>> the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, > >>> to > >>>> solve this issue. > >>>> > >>>> Before jdk 9, I was bypassing it through reflection like this: > >>>> > >>>> java.lang.reflect.Field field = > >>> job.getClass().getDeclaredField("jobImpl"); > >>>> field.setAccessible(true); > >>>> PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); > >>>> field.setAccessible(false); > >>>> field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); > >>>> field.setAccessible(true); > >>>> PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) > >>>> field.get(jobImpl); > >>>> field.setAccessible(false); > >>>> printReqAttrSet.add(new Destination(new File(filePath).toURI())); > >>>> > >>>> Now, the module is closed, so I cannot access it through reflection. > Is > >>>> there a way to obtain this behavior again? > From kcr at openjdk.java.net Tue Feb 4 16:46:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Feb 2020 16:46:52 GMT Subject: RFR: 8238434: Ensemble: Update version of Lucene to 7.7.2 Message-ID: Update the version of Lucene used by Ensemble to the latest release of Lucene 7 which is version 7.7.2. Per the instructions in [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt), I made the following chages: 1. Bumped the version numbers from 7.7.1 to 7.7.2 in all needed places 2. Regenerated the index files. I used JDK 11.x to do this (out of an abundance of caution, not because I think it matters). To test this: apply the patch, run `gradle apps`, launch Ensemble8, and search for a sample or JavaFX component in the upper-right search box. ------------- Commits: - efb46435: 8238434: Ensemble: Update version of Lucene to 7.7.2 Changes: https://git.openjdk.java.net/jfx/pull/105/files Webrev: https://webrevs.openjdk.java.net/jfx/105/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238434 Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/105/head:pull/105 PR: https://git.openjdk.java.net/jfx/pull/105 From kcr at openjdk.java.net Tue Feb 4 16:46:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Feb 2020 16:46:52 GMT Subject: RFR: 8238434: Ensemble: Update version of Lucene to 7.7.2 In-Reply-To: References: Message-ID: <8T6X-06auMFtKLUUHmu1S0_W6s_iOdjmJu3dAeVm5hA=.5ac97090-fe6a-4f27-b68e-b7c8f6af4f6a@github.com> On Tue, 4 Feb 2020 16:39:22 GMT, Kevin Rushforth wrote: > Update the version of Lucene used by Ensemble to the latest release of Lucene 7 which is version 7.7.2. > > Per the instructions in [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt), I made the following chages: > > 1. Bumped the version numbers from 7.7.1 to 7.7.2 in all needed places > 2. Regenerated the index files. I used JDK 11.x to do this (out of an abundance of caution, not because I think it matters). > > To test this: apply the patch, run `gradle apps`, launch Ensemble8, and search for a sample or JavaFX component in the upper-right search box. @aghaisas can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/105 From kevin.rushforth at oracle.com Tue Feb 4 17:45:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Feb 2020 09:45:52 -0800 Subject: OpenJFX 14 is in Rampdown Phase Two (RDP2) Message-ID: To: OpenJFX Developers As a reminder, OpenJFX 14 is now in Rampdown Phase Two RDP2. [1] During RDP2, all bug fixes (except for docs and test fixes), and all enhancements will need explicit approval to go in to openjfx/14-dev. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. We will use the same rules for RDP2 that the JDK uses [2], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 14 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx14-fix-request", "openjfx14-fix-yes", "openjfx14-fix-no" and "openjfx14-fix-nmi", "openjfx14-enhancement-request", "openjfx14-enhancement-yes", "openjfx14-enhancement-no" and "openjfx14-enhancement-nmi" as corresponding labels. Note that if a fix is approved to integrate into openjfx14 (with the appropriate approval label added by a lead), then the PR should be targeted to the jfx14 branch. There is no need to also create a separate PR to integrate it into master -- we will continue to periodically sync jfx14 --> master for the duration of the openjfx14 release. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in openjfx14. We need to be extremely careful about including anything that introduces risk. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-December/024331.html [2] http://openjdk.java.net/jeps/3 From ed at kennard.net Tue Feb 4 17:48:13 2020 From: ed at kennard.net (Ed Kennard) Date: Tue, 4 Feb 2020 17:48:13 +0000 Subject: Memory leak issues related to 2 PRs in OpenJFX Message-ID: <8756037A-A788-44EA-8654-FACF78D08730@kennard.net> Hi everyone, I?ve been migrating our codebase to Java 11 LTS and OpenJFX 14. One of our GC-related unit tests is failing now, where one of our custom Tab controls is supposed to be GC?d. The test passes against Java 8. When our GC-related unit tests fail they output exactly what it is that?s blocking GC, and in this case it?s pointing to Node.windowShowingChangedListener. If I disable that listener and recompile JavaFX, then the test fails again but this time due to Node.sceneWindowChangedListener. If I disable that then the test passes. Also, if I re-enable both of these listeners but wrap them in WeakListeners, then the test passes. I believe the two PRs which introduced these listeners are: 8090322: Need new tree visible property in Node that consider Scene and Stage visibility [1] 8216377: Fix memoryleak for initial nodes of Window [2] If I trace when the windowShowingChangedListener is being added or removed for my custom controls, I can see that for one of them (shown as ?Grid? below) they?re being consistently added/removed out of sequence. This seems to result in an attempt to remove a listener which hasn?t been added yet, then later on that missed addition happens, resulting in one listener incorrectly leftover at the end: invalidatedScenes - Adding window.showing listener for MetadataTableView invalidatedScenes - Removing window.showing listener for MetadataTableView *** THIS IS PREMATURE *** invalidatedScenes - Removing window.showing listener for Grid invalidatedScenes - Adding window.showing listener for MetadataTableView invalidatedScenes - Adding window.showing listener for Grid invalidatedScenes - Adding window.showing listener for Grid invalidatedScenes - Removing window.showing listener for MetadataTableView invalidatedScenes - Removing window.showing listener for Grid I?ve been trying hard to reproduce the issue in a simple test along the same lines as the existing one in systemTests?InitialNodesMemoryLeakTest, but so far haven?t managed to. There?s quite a bit going on in our custom controls, with some places where it?s necessary to use Platform.runLater to ensure a control has been properly initialized before performing other setup operations, maybe it?s because of something like that. Anyway, my question is, do you think it might be safer to change these listeners to be weak, in case others manage to create a similar scenario and start leaking nodes like this? If yes, happy to put a PR together for that. Or should I continue my pursuit of the underlying issue which has so far eluded me, and which I appreciate may be caused by something being done in the wrong order in my own code? Thanks Ed [1] https://bugs.openjdk.java.net/browse/JDK-8090322 [2] https://bugs.openjdk.java.net/browse/JDK-8216377 From kevin.rushforth at oracle.com Tue Feb 4 18:40:21 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Feb 2020 10:40:21 -0800 Subject: Memory leak issues related to 2 PRs in OpenJFX In-Reply-To: <8756037A-A788-44EA-8654-FACF78D08730@kennard.net> References: <8756037A-A788-44EA-8654-FACF78D08730@kennard.net> Message-ID: The first of these bugs, 8090322, did introduce at least one memory leak for which 8216377 was the fix. I'd prefer to resolve the underlying problem rather than just making those listeners weak, so it seems worth spending some more time to try to narrow it down. Regarding the out-of-order events, are you doing all operations (including those triggered by binding) on the JavaFX application thread? My guess is that this is unlikely to be the problem, since you say that it is very reproducible, but I thought I'd ask. -- Kevin On 2/4/2020 9:48 AM, Ed Kennard wrote: > Hi everyone, > > I?ve been migrating our codebase to Java 11 LTS and OpenJFX 14. One of our GC-related unit tests is failing now, where one of our custom Tab controls is supposed to be GC?d. The test passes against Java 8. > > When our GC-related unit tests fail they output exactly what it is that?s blocking GC, and in this case it?s pointing to Node.windowShowingChangedListener. If I disable that listener and recompile JavaFX, then the test fails again but this time due to Node.sceneWindowChangedListener. If I disable that then the test passes. Also, if I re-enable both of these listeners but wrap them in WeakListeners, then the test passes. > > I believe the two PRs which introduced these listeners are: > > 8090322: Need new tree visible property in Node that consider Scene and Stage visibility [1] > 8216377: Fix memoryleak for initial nodes of Window [2] > > If I trace when the windowShowingChangedListener is being added or removed for my custom controls, I can see that for one of them (shown as ?Grid? below) they?re being consistently added/removed out of sequence. This seems to result in an attempt to remove a listener which hasn?t been added yet, then later on that missed addition happens, resulting in one listener incorrectly leftover at the end: > > invalidatedScenes - Adding window.showing listener for MetadataTableView > invalidatedScenes - Removing window.showing listener for MetadataTableView > *** THIS IS PREMATURE *** invalidatedScenes - Removing window.showing listener for Grid > invalidatedScenes - Adding window.showing listener for MetadataTableView > invalidatedScenes - Adding window.showing listener for Grid > invalidatedScenes - Adding window.showing listener for Grid > invalidatedScenes - Removing window.showing listener for MetadataTableView > invalidatedScenes - Removing window.showing listener for Grid > > I?ve been trying hard to reproduce the issue in a simple test along the same lines as the existing one in systemTests?InitialNodesMemoryLeakTest, but so far haven?t managed to. There?s quite a bit going on in our custom controls, with some places where it?s necessary to use Platform.runLater to ensure a control has been properly initialized before performing other setup operations, maybe it?s because of something like that. > > Anyway, my question is, do you think it might be safer to change these listeners to be weak, in case others manage to create a similar scenario and start leaking nodes like this? If yes, happy to put a PR together for that. Or should I continue my pursuit of the underlying issue which has so far eluded me, and which I appreciate may be caused by something being done in the wrong order in my own code? > > Thanks > > Ed > > [1] https://bugs.openjdk.java.net/browse/JDK-8090322 > [2] https://bugs.openjdk.java.net/browse/JDK-8216377 > From kcr at openjdk.java.net Tue Feb 4 22:47:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Feb 2020 22:47:18 GMT Subject: [Rev 01] RFR: 8238434: Ensemble: Update version of Lucene to 7.7.2 In-Reply-To: References: Message-ID: > Update the version of Lucene used by Ensemble to the latest release of Lucene 7 which is version 7.7.2. > > Per the instructions in [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt), I made the following chages: > > 1. Bumped the version numbers from 7.7.1 to 7.7.2 in all needed places > 2. Regenerated the index files. I used JDK 11.x to do this (out of an abundance of caution, not because I think it matters). > > To test this: apply the patch, run `gradle apps`, launch Ensemble8, and search for a sample or JavaFX component in the upper-right search box. The pull request has been updated with 1 additional commit. ------------- Added commits: - 6facff5d: Revert changes to binary index files (we do not need to regenerate them) Changes: - all: https://git.openjdk.java.net/jfx/pull/105/files - new: https://git.openjdk.java.net/jfx/pull/105/files/efb46435..6facff5d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/105/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/105/webrev.00-01 Stats: 3 lines in 6 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/105/head:pull/105 PR: https://git.openjdk.java.net/jfx/pull/105 From kcr at openjdk.java.net Tue Feb 4 22:47:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Feb 2020 22:47:27 GMT Subject: RFR: 8238434: Ensemble: Update version of Lucene to 7.7.2 In-Reply-To: <8T6X-06auMFtKLUUHmu1S0_W6s_iOdjmJu3dAeVm5hA=.5ac97090-fe6a-4f27-b68e-b7c8f6af4f6a@github.com> References: <8T6X-06auMFtKLUUHmu1S0_W6s_iOdjmJu3dAeVm5hA=.5ac97090-fe6a-4f27-b68e-b7c8f6af4f6a@github.com> Message-ID: On Tue, 4 Feb 2020 16:41:20 GMT, Kevin Rushforth wrote: >> Update the version of Lucene used by Ensemble to the latest release of Lucene 7 which is version 7.7.2. >> >> Per the instructions in [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt), I made the following changes: >> >> 1. Bumped the version numbers from 7.7.1 to 7.7.2 in all needed places >> >> I did not regenerated the index files, since only the `bugfix` number (the third digit) changed. It is the same `major.minor` release as before. >> >> To test this: apply the patch, run `gradle apps`, launch Ensemble8, and search for a sample or JavaFX component in the upper-right search box. > > @aghaisas can you review this? I pushed a new commit that reverts the changes to the stored binary index files. There is no need to regenerate them when upgrade to a new version where only the `bugfix` number (the third digit) changes. This minimizes the churn and avoids modifying the binary index files needlessly. I added a note to this effect in the updated [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/6facff5d7b7a9160939a5b4231a8355a617377a6/apps/samples/Ensemble8/UPDATING-lucene.txt) file. ------------- PR: https://git.openjdk.java.net/jfx/pull/105 From kcr at openjdk.java.net Tue Feb 4 23:19:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 Feb 2020 23:19:24 GMT Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator In-Reply-To: <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com> References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com> <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com> <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com> <93BQsq7oqMhSbwgKo6P_PKT-rnnRu6AA2U_IxJgI-QI=.7acd2a16-1167-4771-9f07-d33a7af29532@github.com> Message-ID: On Mon, 27 Jan 2020 15:26:48 GMT, Florian Kirmaier wrote: >> The use of static analysis tools to catch certain types of problems is orthogonal to a regression test to validate a bug fix of a specific memory leak. >> >> @FlorianKirmaier as mentioned previously, please file a new JBS Enhancement to propose adding a test utility for memory leak test. You can then start a discussion on the openjfx-dev mailing list. >> >> As for fixing this memory leak, I recommend one of the following two approaches: >> 1. Modify the PR without relying on any new utilities (meaning you would create yet-another adhoc test for memory leaks). >> 2. Close this PR, wait for memory leak test utility to be integrated, and then resubmit the PR for this leak using that utility. >> >> Obviously, approach 1 would get the fix in faster. You could then modify the test to use the new utility as part of implementing the utility. > > A little bit late ... > I have now removed unit-test and it's dependency. > I will add a ticket about adding them again. Rather than removing the test, I was suggesting that you create a test for memory leaks using the same ad hoc approach that our other memory leak tests use. This could later be modified to use the new GC test utility as part of creating that utility. The pattern used in, for example, [TabPaneHeaderLeakTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java), works well enough, even though it repeats a fair amount of boilerplate code. ------------- PR: https://git.openjdk.java.net/jfx/pull/71 From kcr at openjdk.java.net Wed Feb 5 00:12:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 00:12:34 GMT Subject: [Rev 02] RFR: 8237469: Inherited styles don't update when node is moved In-Reply-To: References: <3ZPNIAjoZIvU3Q8tg5owogKh4-NCUNCbV9i1smDRegk=.ad26d542-45d8-4a34-b5b8-287d58d3c0f1@github.com> Message-ID: <2EVg_cZ4KHdVuzVC33xkVvPjzZ2PQY1Cbgi-iajv9wg=.ca6b3a1d-2a5b-4ed7-89d9-7de5cbe89eb2@github.com> On Tue, 28 Jan 2020 09:47:24 GMT, Ajit Ghaisas wrote: >> The pull request has been updated with 1 additional commit. > > Marked as reviewed by aghaisas (Reviewer). I updated the PR title to match the JBS title, so that the commit message will be correct when this PR is integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/87 From kcr at openjdk.java.net Wed Feb 5 00:14:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 00:14:15 GMT Subject: [Rev 02] RFR: 8237469: Inherited styles don't update when node is moved In-Reply-To: <3ZPNIAjoZIvU3Q8tg5owogKh4-NCUNCbV9i1smDRegk=.ad26d542-45d8-4a34-b5b8-287d58d3c0f1@github.com> References: <3ZPNIAjoZIvU3Q8tg5owogKh4-NCUNCbV9i1smDRegk=.ad26d542-45d8-4a34-b5b8-287d58d3c0f1@github.com> Message-ID: <4IKyBzK3Q6sUDC6mVyPTraQscISBc9D2KJWbmMvt414=.69166c59-ea3e-4244-a9d9-68d1dbdf76d7@github.com> On Wed, 5 Feb 2020 00:14:15 GMT, Dean Wookey wrote: >> Everything passes with the fix and 5 of the new tests fail without the fix. >> >> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest >> movingBranchToDifferentBranchGetsNewCssVariableTest >> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue >> removingThenAddingNodeToDifferentBranchGetsIneritableStyle >> movingNodeToDifferentBranchGetsNewFontStyleTest >> >> I doubt this will cause a significant performance decrease. I think it's worth it for correctness. The only other thing is that I kept the fix to the minimum, but technically canReuseHelper now has a side effect. I could try rewrite some things if necessary, or maybe rename the method? Else leave it as is? >> >> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab > > The pull request has been updated with 1 additional commit. This looks good to me. I appreciate all of the added unit tests. I also confirmed that this fixed [JDK-8234877](https://bugs.openjdk.java.net/browse/JDK-8234877), so I will close that one as a duplicate. This is now ready to integrate. Either Ajit or I can sponsor it. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/87 From philip.race at oracle.com Wed Feb 5 00:16:43 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 04 Feb 2020 16:16:43 -0800 Subject: set Destination attribute in printReqAttrSet In-Reply-To: References: <5CD5B191.7070705@oracle.com> Message-ID: <5E3A096B.6030806@oracle.com> I found that there were some bugs in the JDK code that FX calls that need to be fixed first. I started on those but it was reasonably complex to test and so that is still WIP and then the FX part should be possible. -phil. On 2/4/20, 2:52 AM, Neacsu Cristian wrote: > Hello, > > Any updates regarding this matter? :-s > > Thank you in advance, > Cristian-Stefan > > On Sat, May 11, 2019 at 2:36 AM Neacsu Cristian > > wrote: > > Damn ... Thank you for your reply and for the ticket submitted. > I created an invoice application for my own company, and imagine > that java 9+ would kill me :) All the invoices are generated > automatically through pdf printer (I tried few free pdf libraries > as an alternative, but for what I need they have poor results). > > I actually posted my ugly solution as well here some time ago: > https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798 > > I know it is not much, but 89 hits might mean something. People > might fight with it later, when they are going to migrate for new > java versions. > > Thank you so much, and looking forward if you guys have time to > take care of it. > > Cristian-Stefan > > > On Fri, May 10, 2019 at 8:15 PM Philip Race > > wrote: > > Everything you are touching there pre-supposes knowledge > of today's implementation of the JavaFX printing API, so > I don't think we can endorse that. > The right thing to do (maybe years ago!) is to file > an RFE to request that something like the Destination attribute > be supported in the FX printing API. I've reviewed the open > bug list and I don't see that anyone else has asked for this. > > I just submitted : > https://bugs.openjdk.java.net/browse/JDK-8223717 > > JFYI, I reviewed some old notes and it was originally planned > to be > supported in the API but during design discussion it was removed > as a result of a combination of getting it right, not being > sure how > many people would need it (you may be the first) and some perhaps > over-stated concerns about security. > > -phil. > > On 5/10/19, 1:39 AM, Neacsu Cristian wrote: > > For windows print through "Microsoft Print to PDF", there is > no way right > > now to pre-define a path programmatically. There is no way > to set inside > > the printReqAttrSet (J2DPrinterJob), an attribute of type > Destination, to > > solve this issue. > > > > Before jdk 9, I was bypassing it through reflection like this: > > > > java.lang.reflect.Field field = > job.getClass().getDeclaredField("jobImpl"); > > field.setAccessible(true); > > PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); > > field.setAccessible(false); > > field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); > > field.setAccessible(true); > > PrintRequestAttributeSet printReqAttrSet = > (PrintRequestAttributeSet) > > field.get(jobImpl); > > field.setAccessible(false); > > printReqAttrSet.add(new Destination(new > File(filePath).toURI())); > > > > Now, the module is closed, so I cannot access it through > reflection. Is > > there a way to obtain this behavior again? > From B.Peter at gsi.de Wed Feb 5 07:55:21 2020 From: B.Peter at gsi.de (Peter, Benjamin) Date: Wed, 5 Feb 2020 07:55:21 +0000 Subject: Additional Information to JDK-8150263 ObservableListWrapper Message-ID: Hi devs, about JDK-8150263 : ObservableListWrapper fires change notifications from sort() and sort(Comparator) even if list is not changed. I stumbled about the problem and prepared a minimal test case. Is anyone here who could add that to the report? I am not a contributor. I can also confirm it is still reproducable in jfx 11 and 13. It is available as public domain gist on github: https://gist.github.com/dedeibel/02578e276c601448fab8ef014e326e03 Thank you. If this is the wrong channel to provide the information please let me know, I couldn't find another way without being a contributor. Best regards, Benjamin Peter From arapte at openjdk.java.net Wed Feb 5 11:13:49 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 5 Feb 2020 11:13:49 GMT Subject: RFR: 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Message-ID: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> Issue: Dragging a tab and dropping it back to it's original position causes an incorrect reordering of tabs. Incorrect order of tabs can be observed using arrow key traversal through tabs. Cause: Below mechanism of identifying if tab header is dragged and dropped at same position is not reliable. When a tab is selected for dragging, the tab's layout X is stored as `dragHeaderStartX`. When the tab is dropped, the tab's destination layout X is saved as `dragHeaderDestX`. These two values are used to decide if the reordering of tabs is needed. This is an unreliable mechanism in two cases, 1. When the `TabPane.TabClosingPolicy` is set to `TabPane.TabClosingPolicy.SELECTED_TAB`, the close button icon gets added only to the selected tab. Each time when the tab selection is changed, the header region needs a re-layout. When a non selected tab is chosen for dragging `dragHeaderStartX` and `dragHeaderDestX` will always differ. 2. Calculation of `dragHeaderDestX` involves floating point operation. So the computed `dragHeaderDestX` may sometimes vary by fraction than `dragHeaderStartX`. Fix: Use the index of tab header for identifying the tabs which are reordered. Save the index when reordering begins. `dragTabHeaderStartIndex` Save the index when tab is dropped. `dragTabHeaderIndex` If the index are same then reordering of tabs is NOT needed. If the index are NOT same then the tabs from `dragTabHeaderStartIndex` to `dragTabHeaderIndex` are reordered. Verification: This fix is specific to TabPane reordering. No other tests/behavior should be affected. Added a new system test. ------------- Commits: - 835e7aa8: [WIP]8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Changes: https://git.openjdk.java.net/jfx/pull/106/files Webrev: https://webrevs.openjdk.java.net/jfx/106/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237453 Stats: 311 lines in 2 files changed: 300 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/106.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/106/head:pull/106 PR: https://git.openjdk.java.net/jfx/pull/106 From kcr at openjdk.java.net Wed Feb 5 13:49:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 13:49:11 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: Message-ID: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> On Fri, 10 Jan 2020 00:34:18 GMT, Kevin Rushforth wrote: >>> This will need a fair bit of testing to ensure that there are no regressions either in functionality or (especially) performance, in addition to tests for the new functionality. >> >> Which tests for the new functionality should I write? Up to the shader itself it's mostly just passing on variables, and the API is standard `DoubleProperty`s. I can test the dirty bits / redraw logic. >> >>> On the performance aspect, the inner loop of the lighting calculation now has an additional if test for the max range and additional arithmetic calculations for the attenuation. What we will need is a test program that we can run on Mac and Windows to measure the performance of rendering in a fill-rate-limited case. Ideally, we would not pay much of a performance hit in the default case where `ca == 1, la == 0, qa == 0`, but we first need to be able to measure the drop in performance before we can say whether it is acceptable. >> >> Can you point me to a similar performance test? I didn't see a way to easily measure FPS. >> I don't know how to avoid the `if` test for the `maxRange`, I'm open to suggestions. The only thing I can think of is if `maxRange` is infinite (the default), we will swap the shader for one that doesn't make that check. However, swapping shaders also costs performance. > > We have a few performance tests in apps/performance, but I don't know how up to date they are. They might give you a starting point on how to measure FPS, but really the harder part is going to be coming up with a workload -- a scene with a number of Shape3Ds with large triangles (so that they are fill-rate limited) and 1-3 lights, etc -- that you can use to measure rendering performance without measuring overhead. Typically you want a scene that is rendering continuously in the < 30 fps range, and more like 10 fps to minimize the overhead even more. > > Before we figure out whether we need to double the number of shaders (which was one of the ideas that I had as well), we need to know how much of a problem it is. Is it < 2% performance drop on typical cases on a variety of machines or it is a 25% drop (or more likely somewhere in between). If the perf drop is negligible, then it isn't worth doubling the shaders. If it is significant, then we probably need to. > > If we do need to double the shaders, I wouldn't do it based on the maxRange being infinite, rather I would do it based on whether attenuation is being used. That way the existing shaders would be unchanged, while the new shader would deal with both attenuation and the maxRange test. > > Hopefully, there won't be enough of a perf hit to require doubling the shaders, but we need to be able to measure it. > > For functional testing, in addition to the simple API tests, we want to make sure that the basic rendering is working with and without attenuation. Some sort of visual test where you verify that attenuation is / isn't happening as well as testing the cutoff. I wouldn't get too fancy with these...just a sanity test. Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't complete. An incomplete CSR should be treated the same way as an insufficient number of reviewers. I filed [SKARA-262](https://bugs.openjdk.java.net/browse/SKARA-262) to track this. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From neacsu.cristianstefan at gmail.com Wed Feb 5 14:05:35 2020 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Wed, 5 Feb 2020 16:05:35 +0200 Subject: set Destination attribute in printReqAttrSet In-Reply-To: <5E3A096B.6030806@oracle.com> References: <5CD5B191.7070705@oracle.com> <5E3A096B.6030806@oracle.com> Message-ID: Awesome :) good to know that is in WIP state. Really looking forward for it. Good luck in solving the bugs! ^_^ Cristian-Stefan On Wed, Feb 5, 2020 at 2:16 AM Philip Race wrote: > I found that there were some bugs in the JDK code that FX calls > that need to be fixed first. I started on those but it was reasonably > complex to test and so that is still WIP and then the FX part should > be possible. > > -phil. > > On 2/4/20, 2:52 AM, Neacsu Cristian wrote: > > Hello, > > Any updates regarding this matter? :-s > > Thank you in advance, > Cristian-Stefan > > On Sat, May 11, 2019 at 2:36 AM Neacsu Cristian < > neacsu.cristianstefan at gmail.com> wrote: > >> Damn ... Thank you for your reply and for the ticket submitted. >> I created an invoice application for my own company, and imagine that >> java 9+ would kill me :) All the invoices are generated automatically >> through pdf printer (I tried few free pdf libraries as an alternative, but >> for what I need they have poor results). >> >> I actually posted my ugly solution as well here some time ago: >> >> https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798 >> >> I know it is not much, but 89 hits might mean something. People might >> fight with it later, when they are going to migrate for new java versions. >> >> Thank you so much, and looking forward if you guys have time to take care >> of it. >> >> Cristian-Stefan >> >> >> >> On Fri, May 10, 2019 at 8:15 PM Philip Race >> wrote: >> >>> Everything you are touching there pre-supposes knowledge >>> of today's implementation of the JavaFX printing API, so >>> I don't think we can endorse that. >>> The right thing to do (maybe years ago!) is to file >>> an RFE to request that something like the Destination attribute >>> be supported in the FX printing API. I've reviewed the open >>> bug list and I don't see that anyone else has asked for this. >>> >>> I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717 >>> >>> JFYI, I reviewed some old notes and it was originally planned to be >>> supported in the API but during design discussion it was removed >>> as a result of a combination of getting it right, not being sure how >>> many people would need it (you may be the first) and some perhaps >>> over-stated concerns about security. >>> >>> -phil. >>> >>> On 5/10/19, 1:39 AM, Neacsu Cristian wrote: >>> > For windows print through "Microsoft Print to PDF", there is no way >>> right >>> > now to pre-define a path programmatically. There is no way to set >>> inside >>> > the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, >>> to >>> > solve this issue. >>> > >>> > Before jdk 9, I was bypassing it through reflection like this: >>> > >>> > java.lang.reflect.Field field = >>> job.getClass().getDeclaredField("jobImpl"); >>> > field.setAccessible(true); >>> > PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job); >>> > field.setAccessible(false); >>> > field = jobImpl.getClass().getDeclaredField("printReqAttrSet"); >>> > field.setAccessible(true); >>> > PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet) >>> > field.get(jobImpl); >>> > field.setAccessible(false); >>> > printReqAttrSet.add(new Destination(new File(filePath).toURI())); >>> > >>> > Now, the module is closed, so I cannot access it through reflection. Is >>> > there a way to obtain this behavior again? >>> >> From nlisker at gmail.com Wed Feb 5 15:47:02 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 5 Feb 2020 17:47:02 +0200 Subject: Additional Information to JDK-8150263 ObservableListWrapper In-Reply-To: References: Message-ID: Thanks Peter, I added the info. - Nir On Wed, Feb 5, 2020 at 9:55 AM Peter, Benjamin wrote: > Hi devs, > > about JDK-8150263 : ObservableListWrapper fires change notifications from > sort() and sort(Comparator) even if list is not changed. > > I stumbled about the problem and prepared a minimal test case. Is anyone > here who could add that to the report? I am not a contributor. > > I can also confirm it is still reproducable in jfx 11 and 13. > > It is available as public domain gist on github: > https://gist.github.com/dedeibel/02578e276c601448fab8ef014e326e03 > > > Thank you. If this is the wrong channel to provide the information please > let me know, I couldn't find another way without being a contributor. > > > Best regards, > > Benjamin Peter > From kcr at openjdk.java.net Wed Feb 5 19:19:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 19:19:59 GMT Subject: RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: Message-ID: <7xLTpTychIXFFofD8IEPhHbgdok-1Z2t9KCrjE9Z_KY=.2cc1d32c-6da8-42ce-b3eb-0916ee2dbaf7@github.com> On Tue, 14 Jan 2020 19:50:28 GMT, Johan Kaving wrote: > This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the > current system menubar alone when other menubars are changed. > > It also adds a test case that reproduces the problem before the fix. This looks good to me. I confirm that this fixes the bug, and that the new unit test catches the problem. I added a minor comment about the import statement. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/MenuBarSkinTest.java line 33: > 32: import com.sun.javafx.stage.WindowHelper; > 33: import javafx.scene.control.MenuItem; > 34: import test.com.sun.javafx.pgstub.StubToolkit; Minor: can you move this next to the other `javafx.scene.control` imports? (I know they aren't all sorted, but most are) ------------- PR: https://git.openjdk.java.net/jfx/pull/86 From kcr at openjdk.java.net Wed Feb 5 22:51:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 22:51:01 GMT Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> References: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> Message-ID: <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> On Wed, 5 Feb 2020 22:50:59 GMT, Ambarish Rapte wrote: >> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html). >> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed. >> >> The change is, >> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes. >> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize(). For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java. >> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method. >> >> Verification: >> Verified that the newly added dispose() methods get invoked as required and no OOM occurs. >> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop. >> 2. Run the program using -Dprism.order=sw, -Dprism.verbose=true. (optional -Xmx50m) >> Expected Behavior: >> a. Maximum memory consumption after this change should reduce or remain same as that of before this change. >> b. No OOM should occur with this change or without this change. > > The pull request has been updated with a new target base due to a merge or a rebase. The code changes look good to me, with a couple minor points. I tested it and it does what I would expect. modules/javafx.graphics/src/main/java/com/sun/pisces/JavaSurface.java line 46: > 45: initialize(dataType, width, height); > 46: addDisposerRecord(); > 47: } Should this be called from the superclass instead? It works as-is, but if there were ever another subclass added, it would have to be replicated there as well. modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Best to revert this or make it 2020. modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 189: > 188: static void > 189: disposeNativeImpl(JNIEnv* env, jobject objectHandle) { > 190: AbstractSurface* surface; Since you removed `disposeNativeImpl`, you can also remove the static declaration on [line 40](https://github.com/openjdk/jfx/blob/0591e41f9106e93ae957cb9d80cf2e9e2c6fd805/modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c#L40). ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From kcr at openjdk.java.net Wed Feb 5 23:29:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 23:29:58 GMT Subject: RFR: 8227619: Potential memory leak in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Fri, 10 Jan 2020 08:17:12 GMT, Ambarish Rapte wrote: > `ListView` does not get GCed because `SelectedItemsReadOnlyObservableList` adds a `ListChangeListener` to the (`ObservableList`) items of `ListView`. > > Adding a `WeakListChangeListener` instead of `ListChangeListener` fixes the issue. > > Added a unit test and verified that existing tests do not fail due to this change. Presuming that using a weak reference causes no other issues, the fix looks fine and will resolve the leak. How confident are you that there are no cases where the listener might be prematurely garbage collected? ------------- PR: https://git.openjdk.java.net/jfx/pull/84 From kcr at openjdk.java.net Wed Feb 5 23:31:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 23:31:38 GMT Subject: RFR: 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering In-Reply-To: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> References: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> Message-ID: On Wed, 5 Feb 2020 11:07:39 GMT, Ambarish Rapte wrote: > Issue: > Dragging a tab and dropping it back to it's original position causes an incorrect reordering of tabs. Incorrect order of tabs can be observed using arrow key traversal through tabs. > > Cause: > Below mechanism of identifying if tab header is dragged and dropped at same position is not reliable. > When a tab is selected for dragging, the tab's layout X is stored as `dragHeaderStartX`. > When the tab is dropped, the tab's destination layout X is saved as `dragHeaderDestX`. > These two values are used to decide if the reordering of tabs is needed. > This is an unreliable mechanism in two cases, > > 1. When the `TabPane.TabClosingPolicy` is set to `TabPane.TabClosingPolicy.SELECTED_TAB`, the close button icon gets added only to the selected tab. > Each time when the tab selection is changed, the header region needs a re-layout. When a non selected tab is chosen for dragging `dragHeaderStartX` and `dragHeaderDestX` will always differ. > > 2. Calculation of `dragHeaderDestX` involves floating point operation. So the computed `dragHeaderDestX` may sometimes vary by fraction than `dragHeaderStartX`. > > Fix: > Use the index of tab header for identifying the tabs which are reordered. > Save the index when reordering begins. `dragTabHeaderStartIndex` > Save the index when tab is dropped. `dragTabHeaderIndex` > If the index are same then reordering of tabs is NOT needed. > If the index are NOT same then the tabs from `dragTabHeaderStartIndex` to `dragTabHeaderIndex` are reordered. > > Verification: > This fix is specific to TabPane reordering. No other tests/behavior should be affected. > Added a new system test. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/106 From kcr at openjdk.java.net Wed Feb 5 23:39:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 Feb 2020 23:39:09 GMT Subject: RFR: 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering In-Reply-To: References: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> Message-ID: On Wed, 5 Feb 2020 23:31:29 GMT, Kevin Rushforth wrote: >> Issue: >> Dragging a tab and dropping it back to it's original position causes an incorrect reordering of tabs. Incorrect order of tabs can be observed using arrow key traversal through tabs. >> >> Cause: >> Below mechanism of identifying if tab header is dragged and dropped at same position is not reliable. >> When a tab is selected for dragging, the tab's layout X is stored as `dragHeaderStartX`. >> When the tab is dropped, the tab's destination layout X is saved as `dragHeaderDestX`. >> These two values are used to decide if the reordering of tabs is needed. >> This is an unreliable mechanism in two cases, >> >> 1. When the `TabPane.TabClosingPolicy` is set to `TabPane.TabClosingPolicy.SELECTED_TAB`, the close button icon gets added only to the selected tab. >> Each time when the tab selection is changed, the header region needs a re-layout. When a non selected tab is chosen for dragging `dragHeaderStartX` and `dragHeaderDestX` will always differ. >> >> 2. Calculation of `dragHeaderDestX` involves floating point operation. So the computed `dragHeaderDestX` may sometimes vary by fraction than `dragHeaderStartX`. >> >> Fix: >> Use the index of tab header for identifying the tabs which are reordered. >> Save the index when reordering begins. `dragTabHeaderStartIndex` >> Save the index when tab is dropped. `dragTabHeaderIndex` >> If the index are same then reordering of tabs is NOT needed. >> If the index are NOT same then the tabs from `dragTabHeaderStartIndex` to `dragTabHeaderIndex` are reordered. >> >> Verification: >> This fix is specific to TabPane reordering. No other tests/behavior should be affected. >> Added a new system test. > > Looks good. I'd like @agahisas to take a look as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/106 From ed at kennard.net Thu Feb 6 01:12:49 2020 From: ed at kennard.net (Ed Kennard) Date: Thu, 6 Feb 2020 01:12:49 +0000 Subject: Memory leak issues related to 2 PRs in OpenJFX In-Reply-To: References: <8756037A-A788-44EA-8654-FACF78D08730@kennard.net> Message-ID: <77F5546F-4C1C-452E-AD9D-11421696F156@kennard.net> Hi Kevin, I found the problem with this, and I've pushed a small commit to my fork which I think reproduces the behavior I described [1]. Per comments in the code, to run the test you'll need to make the ControlsFX library v11 available to the build, sorry I didn't do that myself but I'm not familiar with Gradle and it's late in the eve for me now. We rely on ControlsFX's validation framework in our forms, and it's that which seems to be triggering the scene to be updated in a way that throws out the timing of the adding/removing of the listeners in Node, at least during initialization. I think after initializing the first time, everything works as expected. Hope that helps - pls let me know what you think. Regarding our code, I've worked around the issue by adding a flag to pause the validation decorations during intialization, so I'm able to move forward now. Thanks Ed [1] https://github.com/edkennard/jfx/commit/5c724670cd2ff14ec98d37faf8841e74a7e08039 ?On 04/02/2020, 19:41, "openjfx-dev on behalf of Kevin Rushforth" wrote: The first of these bugs, 8090322, did introduce at least one memory leak for which 8216377 was the fix. I'd prefer to resolve the underlying problem rather than just making those listeners weak, so it seems worth spending some more time to try to narrow it down. Regarding the out-of-order events, are you doing all operations (including those triggered by binding) on the JavaFX application thread? My guess is that this is unlikely to be the problem, since you say that it is very reproducible, but I thought I'd ask. -- Kevin On 2/4/2020 9:48 AM, Ed Kennard wrote: > Hi everyone, > > I?ve been migrating our codebase to Java 11 LTS and OpenJFX 14. One of our GC-related unit tests is failing now, where one of our custom Tab controls is supposed to be GC?d. The test passes against Java 8. > > When our GC-related unit tests fail they output exactly what it is that?s blocking GC, and in this case it?s pointing to Node.windowShowingChangedListener. If I disable that listener and recompile JavaFX, then the test fails again but this time due to Node.sceneWindowChangedListener. If I disable that then the test passes. Also, if I re-enable both of these listeners but wrap them in WeakListeners, then the test passes. > > I believe the two PRs which introduced these listeners are: > > 8090322: Need new tree visible property in Node that consider Scene and Stage visibility [1] > 8216377: Fix memoryleak for initial nodes of Window [2] > > If I trace when the windowShowingChangedListener is being added or removed for my custom controls, I can see that for one of them (shown as ?Grid? below) they?re being consistently added/removed out of sequence. This seems to result in an attempt to remove a listener which hasn?t been added yet, then later on that missed addition happens, resulting in one listener incorrectly leftover at the end: > > invalidatedScenes - Adding window.showing listener for MetadataTableView > invalidatedScenes - Removing window.showing listener for MetadataTableView > *** THIS IS PREMATURE *** invalidatedScenes - Removing window.showing listener for Grid > invalidatedScenes - Adding window.showing listener for MetadataTableView > invalidatedScenes - Adding window.showing listener for Grid > invalidatedScenes - Adding window.showing listener for Grid > invalidatedScenes - Removing window.showing listener for MetadataTableView > invalidatedScenes - Removing window.showing listener for Grid > > I?ve been trying hard to reproduce the issue in a simple test along the same lines as the existing one in systemTests?InitialNodesMemoryLeakTest, but so far haven?t managed to. There?s quite a bit going on in our custom controls, with some places where it?s necessary to use Platform.runLater to ensure a control has been properly initialized before performing other setup operations, maybe it?s because of something like that. > > Anyway, my question is, do you think it might be safer to change these listeners to be weak, in case others manage to create a similar scenario and start leaking nodes like this? If yes, happy to put a PR together for that. Or should I continue my pursuit of the underlying issue which has so far eluded me, and which I appreciate may be caused by something being done in the wrong order in my own code? > > Thanks > > Ed > > [1] https://bugs.openjdk.java.net/browse/JDK-8090322 > [2] https://bugs.openjdk.java.net/browse/JDK-8216377 > From ghb at openjdk.java.net Thu Feb 6 09:30:43 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 6 Feb 2020 09:30:43 GMT Subject: RFR: 8238526: Cherry pick GTK WebKit 2.26.3 changes Message-ID: Fix contains https://webkitgtk.org/2020/01/22/webkitgtk2.26.3-released.html ------------- Commits: - 025373db: 8238526: Cherry pick GTK WebKit 2.26.3 changes Changes: https://git.openjdk.java.net/jfx/pull/107/files Webrev: https://webrevs.openjdk.java.net/jfx/107/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238526 Stats: 123 lines in 19 files changed: 39 ins; 59 del; 25 mod Patch: https://git.openjdk.java.net/jfx/pull/107.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/107/head:pull/107 PR: https://git.openjdk.java.net/jfx/pull/107 From danny.gonzalez at screamingfrog.co.uk Thu Feb 6 09:40:14 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Thu, 6 Feb 2020 09:40:14 +0000 Subject: TableView with many columns poor ui performance Message-ID: Hi, We have been struggling with our migration from Java 8 to Java 11 due to various issues we are having with TableView. The main issue is the general UI lag and slow TableView scroll performance. For context here some links around the issues: TableView has a horrific performance with many columns #409 https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 JDK-8088394 : Huge memory consumption in TableView with too many columns https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088394 JavaFX TreeTableView slow scroll performance https://bugs.openjdk.java.net/browse/JDK-8166956 TableRowSkinBase fails to correctly virtualise cells in horizontal direction https://bugs.openjdk.java.net/browse/JDK-8185887 OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html We have a TableView that is being populated with rows dynamically around the rate of 2 rows per second. The issue we are experiencing is the lagginess of the UI when these rows are being inserted. TableViews with fewer columns don?t seem to exhibit the behaviour quite as badly. I can see that there was an optimisation in Java 8 that would alleviate the TableView performance issue. If you used a fixed cell size in your TableView, a bit of optimisation code in TableRowSkinBase.isColumnPartiallyOrFullyVisible would only render the visible columns. This code, as has been documented in the first link above, used to work in Java 8 but not now in Java 11. It also has a bug where the visible columns calculation is incorrect and instead calculates the visibility on the whole width of the TableView rather than the visible columns. I have tried fixing this up, and even with this code fixed, it brings in other issues where resizing the TableView results in blank columns. I have done some testing and can see that the main issues with the slow down is to do with the thousands of listeners that are being removed in TableView when you add rows or scroll. It is taking up to 60% of the JavaFX Application thread. For whatever reason the amount of listeners registering/unregistering has jumped significantly between Java 8 and Java 11. The following changeset for example (which added an extra listener on the Node class) impacted TableView performance significantly: 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 I can see that the code for removing listeners in ExpressionHelper.Generic is extremely sub optimal and uses a linear search through an array to remove listeners. I have rewritten this class to use a Set instead of an Array and it has fixed our major TableView issues where the performance of the UI seriously deteriorated to the point of not being usable. The CPU usage of com.sun.javafx.binding.ExpressionHelper.removeListener in the JavaFX Application Thread has dropped from 60% to less than 1%. I believe this fix will alleviate the major issues of TableViews detailed in the above links. I have run my fix through the unit test suite and believe it is functionally equivalent to the original code, just much faster. I am happy to submit a pull request. I am new to openJFX contributing so any pointers of what I need to do here would be appreciated. Thanks Danny From ed at kennard.net Thu Feb 6 09:50:24 2020 From: ed at kennard.net (Ed Kennard) Date: Thu, 6 Feb 2020 09:50:24 +0000 Subject: TableView with many columns poor ui performance In-Reply-To: References: Message-ID: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> Hi Danny, This is great news, I've previously written about perf issues with TableView, do you have a branch I could try out which is rebased off current jfx master? ?On 06/02/2020, 10:40, "openjfx-dev on behalf of Danny Gonzalez" wrote: Hi, We have been struggling with our migration from Java 8 to Java 11 due to various issues we are having with TableView. The main issue is the general UI lag and slow TableView scroll performance. For context here some links around the issues: TableView has a horrific performance with many columns #409 https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 JDK-8088394 : Huge memory consumption in TableView with too many columns https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088394 JavaFX TreeTableView slow scroll performance https://bugs.openjdk.java.net/browse/JDK-8166956 TableRowSkinBase fails to correctly virtualise cells in horizontal direction https://bugs.openjdk.java.net/browse/JDK-8185887 OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html We have a TableView that is being populated with rows dynamically around the rate of 2 rows per second. The issue we are experiencing is the lagginess of the UI when these rows are being inserted. TableViews with fewer columns don?t seem to exhibit the behaviour quite as badly. I can see that there was an optimisation in Java 8 that would alleviate the TableView performance issue. If you used a fixed cell size in your TableView, a bit of optimisation code in TableRowSkinBase.isColumnPartiallyOrFullyVisible would only render the visible columns. This code, as has been documented in the first link above, used to work in Java 8 but not now in Java 11. It also has a bug where the visible columns calculation is incorrect and instead calculates the visibility on the whole width of the TableView rather than the visible columns. I have tried fixing this up, and even with this code fixed, it brings in other issues where resizing the TableView results in blank columns. I have done some testing and can see that the main issues with the slow down is to do with the thousands of listeners that are being removed in TableView when you add rows or scroll. It is taking up to 60% of the JavaFX Application thread. For whatever reason the amount of listeners registering/unregistering has jumped significantly between Java 8 and Java 11. The following changeset for example (which added an extra listener on the Node class) impacted TableView performance significantly: 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 I can see that the code for removing listeners in ExpressionHelper.Generic is extremely sub optimal and uses a linear search through an array to remove listeners. I have rewritten this class to use a Set instead of an Array and it has fixed our major TableView issues where the performance of the UI seriously deteriorated to the point of not being usable. The CPU usage of com.sun.javafx.binding.ExpressionHelper.removeListener in the JavaFX Application Thread has dropped from 60% to less than 1%. I believe this fix will alleviate the major issues of TableViews detailed in the above links. I have run my fix through the unit test suite and believe it is functionally equivalent to the original code, just much faster. I am happy to submit a pull request. I am new to openJFX contributing so any pointers of what I need to do here would be appreciated. Thanks Danny From kcr at openjdk.java.net Thu Feb 6 13:16:41 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Feb 2020 13:16:41 GMT Subject: [Integrated] RFR: 8237469: CssStyleHelper reuse check fixed In-Reply-To: References: Message-ID: Changeset: 6968e38d Author: Dean Wookey Committer: Kevin Rushforth Date: 2020-02-06 13:16:16 +0000 URL: https://git.openjdk.java.net/jfx/commit/6968e38d 8237469: Inherited styles don't update when node is moved Reviewed-by: dgrieve, aghaisas, kcr ! modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java + modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java From github.com+725090+jkaving at openjdk.java.net Thu Feb 6 13:29:02 2020 From: github.com+725090+jkaving at openjdk.java.net (Johan Kaving) Date: Thu, 6 Feb 2020 13:29:02 GMT Subject: [Rev 01] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: Message-ID: > This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the > current system menubar alone when other menubars are changed. > > It also adds a test case that reproduces the problem before the fix. The pull request has been updated with 1 additional commit. ------------- Added commits: - 94b2dba1: Move import statement Changes: - all: https://git.openjdk.java.net/jfx/pull/86/files - new: https://git.openjdk.java.net/jfx/pull/86/files/7910ab27..94b2dba1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/86/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/86/webrev.00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/86/head:pull/86 PR: https://git.openjdk.java.net/jfx/pull/86 From github.com+725090+jkaving at openjdk.java.net Thu Feb 6 13:46:06 2020 From: github.com+725090+jkaving at openjdk.java.net (Johan Kaving) Date: Thu, 6 Feb 2020 13:46:06 GMT Subject: [Rev 02] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: Message-ID: > This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the > current system menubar alone when other menubars are changed. > > It also adds a test case that reproduces the problem before the fix. Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR. ------------- Added commits: - 811035a6: Move import statement Changes: - all: https://git.openjdk.java.net/jfx/pull/86/files - new: https://git.openjdk.java.net/jfx/pull/86/files/94b2dba1..811035a6 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/86/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/86/webrev.01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/86/head:pull/86 PR: https://git.openjdk.java.net/jfx/pull/86 From github.com+725090+jkaving at openjdk.java.net Thu Feb 6 13:46:07 2020 From: github.com+725090+jkaving at openjdk.java.net (Johan Kaving) Date: Thu, 6 Feb 2020 13:46:07 GMT Subject: [Rev 02] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: <7xLTpTychIXFFofD8IEPhHbgdok-1Z2t9KCrjE9Z_KY=.2cc1d32c-6da8-42ce-b3eb-0916ee2dbaf7@github.com> References: <7xLTpTychIXFFofD8IEPhHbgdok-1Z2t9KCrjE9Z_KY=.2cc1d32c-6da8-42ce-b3eb-0916ee2dbaf7@github.com> Message-ID: <83OjrxHXwFob56YmpCzPHtaNFGAcOJFVJyHmUD2X7ec=.700d68bd-97fb-4540-87e1-faeec3f94183@github.com> On Wed, 5 Feb 2020 19:15:23 GMT, Kevin Rushforth wrote: >> Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/MenuBarSkinTest.java line 33: > >> 32: import com.sun.javafx.stage.WindowHelper; >> 33: import javafx.scene.control.MenuItem; >> 34: import test.com.sun.javafx.pgstub.StubToolkit; > > Minor: can you move this next to the other `javafx.scene.control` imports? (I know they aren't all sorted, but most are) Of, course - I've added a commit that moves the import statement. ------------- PR: https://git.openjdk.java.net/jfx/pull/86 From github.com+725090+jkaving at openjdk.java.net Thu Feb 6 13:46:07 2020 From: github.com+725090+jkaving at openjdk.java.net (Johan Kaving) Date: Thu, 6 Feb 2020 13:46:07 GMT Subject: [Rev 02] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: <83OjrxHXwFob56YmpCzPHtaNFGAcOJFVJyHmUD2X7ec=.700d68bd-97fb-4540-87e1-faeec3f94183@github.com> References: <7xLTpTychIXFFofD8IEPhHbgdok-1Z2t9KCrjE9Z_KY=.2cc1d32c-6da8-42ce-b3eb-0916ee2dbaf7@github.com> <83OjrxHXwFob56YmpCzPHtaNFGAcOJFVJyHmUD2X7ec=.700d68bd-97fb-4540-87e1-faeec3f94183@github.com> Message-ID: On Thu, 6 Feb 2020 13:18:00 GMT, Johan Kaving wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/MenuBarSkinTest.java line 33: >> >>> 32: import com.sun.javafx.stage.WindowHelper; >>> 33: import javafx.scene.control.MenuItem; >>> 34: import test.com.sun.javafx.pgstub.StubToolkit; >> >> Minor: can you move this next to the other `javafx.scene.control` imports? (I know they aren't all sorted, but most are) > > Of, course - I've added a commit that moves the import statement. > I just realised that I did not make the commit with the same email address that I used on the OCA (but both addresses are linked to my GitHub account). And I now did the mistake of committing using the email address on the OCA, which is different than the one used in the previous commit. `jcheck` complained about the differing email addresses so I have force pushed a commit using the same address as before. ------------- PR: https://git.openjdk.java.net/jfx/pull/86 From kcr at openjdk.java.net Thu Feb 6 13:46:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Feb 2020 13:46:07 GMT Subject: [Rev 02] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: <7xLTpTychIXFFofD8IEPhHbgdok-1Z2t9KCrjE9Z_KY=.2cc1d32c-6da8-42ce-b3eb-0916ee2dbaf7@github.com> <83OjrxHXwFob56YmpCzPHtaNFGAcOJFVJyHmUD2X7ec=.700d68bd-97fb-4540-87e1-faeec3f94183@github.com> Message-ID: <1GcRHWMi1X0B0qbDoY3pAosaJmCMP4RySQVtsy60cIg=.f82abbd6-16a3-46de-8507-4074fef07ac5@github.com> On Thu, 6 Feb 2020 13:23:54 GMT, Johan Kaving wrote: >> Of, course - I've added a commit that moves the import statement. > >> I just realised that I did not make the commit with the same email address that I used on the OCA (but both addresses are linked to my GitHub account). > > And I now did the mistake of committing using the email address on the OCA, which is different than the one used in the previous commit. > `jcheck` complained about the differing email addresses so I have force pushed a commit using the same address as before. Oh, I see. I was going to ask you about the force-push, but this explains it. ------------- PR: https://git.openjdk.java.net/jfx/pull/86 From kcr at openjdk.java.net Thu Feb 6 16:05:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Feb 2020 16:05:59 GMT Subject: [Rev 02] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 16:05:59 GMT, Johan Kaving wrote: >> This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the >> current system menubar alone when other menubars are changed. >> >> It also adds a test case that reproduces the problem before the fix. > > Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/86 From danny.gonzalez at screamingfrog.co.uk Thu Feb 6 16:27:05 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Thu, 6 Feb 2020 16:27:05 +0000 Subject: TableView with many columns poor ui performance In-Reply-To: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> References: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> Message-ID: <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> Hi Ed, I have submitted a pull request and the branch is here: https://github.com/screamingfrog/jfx/tree/listeners_optimisation Danny On 6 Feb 2020, at 09:50, Ed Kennard > wrote: Hi Danny, This is great news, I've previously written about perf issues with TableView, do you have a branch I could try out which is rebased off current jfx master? ?On 06/02/2020, 10:40, "openjfx-dev on behalf of Danny Gonzalez" on behalf of danny.gonzalez at screamingfrog.co.uk> wrote: Hi, We have been struggling with our migration from Java 8 to Java 11 due to various issues we are having with TableView. The main issue is the general UI lag and slow TableView scroll performance. For context here some links around the issues: TableView has a horrific performance with many columns #409 https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 JDK-8088394 : Huge memory consumption in TableView with too many columns https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088394 JavaFX TreeTableView slow scroll performance https://bugs.openjdk.java.net/browse/JDK-8166956 TableRowSkinBase fails to correctly virtualise cells in horizontal direction https://bugs.openjdk.java.net/browse/JDK-8185887 OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html We have a TableView that is being populated with rows dynamically around the rate of 2 rows per second. The issue we are experiencing is the lagginess of the UI when these rows are being inserted. TableViews with fewer columns don?t seem to exhibit the behaviour quite as badly. I can see that there was an optimisation in Java 8 that would alleviate the TableView performance issue. If you used a fixed cell size in your TableView, a bit of optimisation code in TableRowSkinBase.isColumnPartiallyOrFullyVisible would only render the visible columns. This code, as has been documented in the first link above, used to work in Java 8 but not now in Java 11. It also has a bug where the visible columns calculation is incorrect and instead calculates the visibility on the whole width of the TableView rather than the visible columns. I have tried fixing this up, and even with this code fixed, it brings in other issues where resizing the TableView results in blank columns. I have done some testing and can see that the main issues with the slow down is to do with the thousands of listeners that are being removed in TableView when you add rows or scroll. It is taking up to 60% of the JavaFX Application thread. For whatever reason the amount of listeners registering/unregistering has jumped significantly between Java 8 and Java 11. The following changeset for example (which added an extra listener on the Node class) impacted TableView performance significantly: 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 I can see that the code for removing listeners in ExpressionHelper.Generic is extremely sub optimal and uses a linear search through an array to remove listeners. I have rewritten this class to use a Set instead of an Array and it has fixed our major TableView issues where the performance of the UI seriously deteriorated to the point of not being usable. The CPU usage of com.sun.javafx.binding.ExpressionHelper.removeListener in the JavaFX Application Thread has dropped from 60% to less than 1%. I believe this fix will alleviate the major issues of TableViews detailed in the above links. I have run my fix through the unit test suite and believe it is functionally equivalent to the original code, just much faster. I am happy to submit a pull request. I am new to openJFX contributing so any pointers of what I need to do here would be appreciated. Thanks Danny From ed at kennard.net Thu Feb 6 17:07:09 2020 From: ed at kennard.net (Ed Kennard) Date: Thu, 6 Feb 2020 17:07:09 +0000 Subject: TableView with many columns poor ui performance In-Reply-To: <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> References: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> Message-ID: <43375B40-28C3-49D2-BD27-81BF0C1684D4@kennard.net> Great, thanks Danny, I?ll check it out and let you know how it goes From: Danny Gonzalez Date: Thursday, 6 February 2020 at 17:27 To: Ed Kennard Cc: "openjfx-dev at openjdk.java.net" Subject: Re: TableView with many columns poor ui performance Hi Ed, I have submitted a pull request and the branch is here: https://github.com/screamingfrog/jfx/tree/listeners_optimisation Danny On 6 Feb 2020, at 09:50, Ed Kennard > wrote: Hi Danny, This is great news, I've previously written about perf issues with TableView, do you have a branch I could try out which is rebased off current jfx master? On 06/02/2020, 10:40, "openjfx-dev on behalf of Danny Gonzalez" on behalf of danny.gonzalez at screamingfrog.co.uk> wrote: Hi, We have been struggling with our migration from Java 8 to Java 11 due to various issues we are having with TableView. The main issue is the general UI lag and slow TableView scroll performance. For context here some links around the issues: TableView has a horrific performance with many columns #409 https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 JDK-8088394 : Huge memory consumption in TableView with too many columns https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088394 JavaFX TreeTableView slow scroll performance https://bugs.openjdk.java.net/browse/JDK-8166956 TableRowSkinBase fails to correctly virtualise cells in horizontal direction https://bugs.openjdk.java.net/browse/JDK-8185887 OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html We have a TableView that is being populated with rows dynamically around the rate of 2 rows per second. The issue we are experiencing is the lagginess of the UI when these rows are being inserted. TableViews with fewer columns don?t seem to exhibit the behaviour quite as badly. I can see that there was an optimisation in Java 8 that would alleviate the TableView performance issue. If you used a fixed cell size in your TableView, a bit of optimisation code in TableRowSkinBase.isColumnPartiallyOrFullyVisible would only render the visible columns. This code, as has been documented in the first link above, used to work in Java 8 but not now in Java 11. It also has a bug where the visible columns calculation is incorrect and instead calculates the visibility on the whole width of the TableView rather than the visible columns. I have tried fixing this up, and even with this code fixed, it brings in other issues where resizing the TableView results in blank columns. I have done some testing and can see that the main issues with the slow down is to do with the thousands of listeners that are being removed in TableView when you add rows or scroll. It is taking up to 60% of the JavaFX Application thread. For whatever reason the amount of listeners registering/unregistering has jumped significantly between Java 8 and Java 11. The following changeset for example (which added an extra listener on the Node class) impacted TableView performance significantly: 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 I can see that the code for removing listeners in ExpressionHelper.Generic is extremely sub optimal and uses a linear search through an array to remove listeners. I have rewritten this class to use a Set instead of an Array and it has fixed our major TableView issues where the performance of the UI seriously deteriorated to the point of not being usable. The CPU usage of com.sun.javafx.binding.ExpressionHelper.removeListener in the JavaFX Application Thread has dropped from 60% to less than 1%. I believe this fix will alleviate the major issues of TableViews detailed in the above links. I have run my fix through the unit test suite and believe it is functionally equivalent to the original code, just much faster. I am happy to submit a pull request. I am new to openJFX contributing so any pointers of what I need to do here would be appreciated. Thanks Danny From kcr at openjdk.java.net Thu Feb 6 19:31:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Feb 2020 19:31:56 GMT Subject: RFR: 8238526: Cherry pick GTK WebKit 2.26.3 changes In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 09:22:56 GMT, Guru Hb wrote: > Fix contains https://webkitgtk.org/2020/01/22/webkitgtk2.26.3-released.html Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/107 From kcr at openjdk.java.net Thu Feb 6 19:35:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Feb 2020 19:35:34 GMT Subject: RFR: 8238526: Cherry pick GTK WebKit 2.26.3 changes In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 19:31:25 GMT, Kevin Rushforth wrote: >> Fix contains https://webkitgtk.org/2020/01/22/webkitgtk2.26.3-released.html > > Marked as reviewed by kcr (Lead). As part of the review, I did a sanity build / test on all three platforms. All looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/107 From jvos at openjdk.java.net Thu Feb 6 21:27:43 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 6 Feb 2020 21:27:43 GMT Subject: RFR: 8238526: Cherry pick GTK WebKit 2.26.3 changes In-Reply-To: References: Message-ID: <3JLzLUYXIK01C-v_NFqyD3N4WJjV-0rEmDs6EMoN41A=.2402959c-132b-4e89-a523-d1da7f259aab@github.com> On Thu, 6 Feb 2020 09:22:56 GMT, Guru Hb wrote: > Fix contains https://webkitgtk.org/2020/01/22/webkitgtk2.26.3-released.html Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/107 From jvos at openjdk.java.net Thu Feb 6 21:27:44 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 6 Feb 2020 21:27:44 GMT Subject: RFR: 8238526: Cherry pick GTK WebKit 2.26.3 changes In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 19:35:18 GMT, Kevin Rushforth wrote: >> Marked as reviewed by kcr (Lead). > > As part of the review, I did a sanity build / test on all three platforms. All looks good. build and basic checks ok on mac/linux/win64. Didn't test on win32. ------------- PR: https://git.openjdk.java.net/jfx/pull/107 From ghb at openjdk.java.net Fri Feb 7 02:13:37 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 7 Feb 2020 02:13:37 GMT Subject: [Integrated] RFR: 8238526: Cherry pick GTK WebKit 2.26.3 changes In-Reply-To: References: Message-ID: <3b8bb3ee-c753-4112-9566-32066424c512@openjdk.org> Changeset: e224e549 Author: Guru Hb Date: 2020-02-07 02:13:15 +0000 URL: https://git.openjdk.java.net/jfx/commit/e224e549 8238526: Cherry pick GTK WebKit 2.26.3 changes Reviewed-by: kcr, jvos ! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp ! modules/javafx.web/src/main/native/Source/JavaScriptCore/dfg/DFGValidate.cpp ! modules/javafx.web/src/main/native/Source/JavaScriptCore/offlineasm/parser.rb ! modules/javafx.web/src/main/native/Source/JavaScriptCore/runtime/NativeErrorConstructor.h ! modules/javafx.web/src/main/native/Source/WTF/wtf/Platform.h ! modules/javafx.web/src/main/native/Source/WTF/wtf/URLHelpers.cpp ! modules/javafx.web/src/main/native/Source/WebCore/dom/Document.cpp ! modules/javafx.web/src/main/native/Source/WebCore/page/FrameView.cpp ! modules/javafx.web/src/main/native/Source/WebCore/page/Page.cpp ! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ComplexTextController.cpp ! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/freetype/FontPlatformDataFreeType.cpp ! modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/harfbuzz/ComplexTextControllerHarfBuzz.cpp ! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderFrameSet.cpp ! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeGtk.cpp ! modules/javafx.web/src/main/native/Source/WebCore/rendering/RenderThemeGtk.h ! modules/javafx.web/src/main/native/Source/WebCore/rendering/SimpleLineLayoutResolver.cpp ! modules/javafx.web/src/main/native/Source/WebCore/svg/properties/SVGAnimatedPropertyPairAccessor.h ! modules/javafx.web/src/main/native/Source/WebCore/testing/InternalSettings.cpp ! modules/javafx.web/src/main/native/Source/cmake/OptionsGTK.cmake From aghaisas at openjdk.java.net Fri Feb 7 05:24:10 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 7 Feb 2020 05:24:10 GMT Subject: RFR: 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering In-Reply-To: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> References: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> Message-ID: <3LdYMDlLJtYra_4DF3xcU1pVbu3zjGQfvp3DJXGn5r4=.55d860bd-5aab-4b80-a3a5-6fc58d366186@github.com> On Wed, 5 Feb 2020 11:07:39 GMT, Ambarish Rapte wrote: > Issue: > Dragging a tab and dropping it back to it's original position causes an incorrect reordering of tabs. Incorrect order of tabs can be observed using arrow key traversal through tabs. > > Cause: > Below mechanism of identifying if tab header is dragged and dropped at same position is not reliable. > When a tab is selected for dragging, the tab's layout X is stored as `dragHeaderStartX`. > When the tab is dropped, the tab's destination layout X is saved as `dragHeaderDestX`. > These two values are used to decide if the reordering of tabs is needed. > This is an unreliable mechanism in two cases, > > 1. When the `TabPane.TabClosingPolicy` is set to `TabPane.TabClosingPolicy.SELECTED_TAB`, the close button icon gets added only to the selected tab. > Each time when the tab selection is changed, the header region needs a re-layout. When a non selected tab is chosen for dragging `dragHeaderStartX` and `dragHeaderDestX` will always differ. > > 2. Calculation of `dragHeaderDestX` involves floating point operation. So the computed `dragHeaderDestX` may sometimes vary by fraction than `dragHeaderStartX`. > > Fix: > Use the index of tab header for identifying the tabs which are reordered. > Save the index when reordering begins. `dragTabHeaderStartIndex` > Save the index when tab is dropped. `dragTabHeaderIndex` > If the index are same then reordering of tabs is NOT needed. > If the index are NOT same then the tabs from `dragTabHeaderStartIndex` to `dragTabHeaderIndex` are reordered. > > Verification: > This fix is specific to TabPane reordering. No other tests/behavior should be affected. > Added a new system test. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/106 From arapte at openjdk.java.net Fri Feb 7 05:59:37 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 Feb 2020 05:59:37 GMT Subject: [Integrated] RFR: 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering In-Reply-To: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> References: <9WVi4p5uxSt6jIO3quMKzTk-qJUbeMZM8LssEMWWyrU=.a0fd8716-8a24-42b9-823c-443005118481@github.com> Message-ID: Changeset: 21d3b7e0 Author: Ambarish Rapte Date: 2020-02-07 05:59:01 +0000 URL: https://git.openjdk.java.net/jfx/commit/21d3b7e0 8237453: [TabPane] Incorrect arrow key traversal through tabs after reordering Reviewed-by: kcr, aghaisas ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java + tests/system/src/test/java/test/robot/javafx/scene/TabPaneReorderTest.java From aghaisas at openjdk.java.net Fri Feb 7 10:54:44 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 7 Feb 2020 10:54:44 GMT Subject: [Rev 02] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: Message-ID: <_pvdEZ5i7PjhmQzYF2BdM5geMnVvJlknK4kq41gaxSw=.6db548cc-d58a-4cf9-b62b-6b15efb9f795@github.com> On Fri, 7 Feb 2020 10:54:44 GMT, Johan Kaving wrote: >> This pull request fixes the sceneProperty listener in `MenuBarSkin` so that we leave the >> current system menubar alone when other menubars are changed. >> >> It also adds a test case that reproduces the problem before the fix. > > Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/86 From arapte at openjdk.java.net Fri Feb 7 12:01:35 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 Feb 2020 12:01:35 GMT Subject: RFR: 8227619: Potential memory leak in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Wed, 5 Feb 2020 23:29:50 GMT, Kevin Rushforth wrote: >> `ListView` does not get GCed because `SelectedItemsReadOnlyObservableList` adds a `ListChangeListener` to the (`ObservableList`) items of `ListView`. >> >> Adding a `WeakListChangeListener` instead of `ListChangeListener` fixes the issue. >> >> Added a unit test and verified that existing tests do not fail due to this change. > > Presuming that using a weak reference causes no other issues, the fix looks fine and will resolve the leak. How confident are you that there are no cases where the listener might be prematurely garbage collected? > > > How confident are you that there are no cases where the listener might be prematurely garbage collected? The listener is added by `ListViewBitSetSelectionModel`. The selection model is set only once for a `ListView` and we do not unset it. So the change looks very safe to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/84 From arapte at openjdk.java.net Fri Feb 7 12:29:53 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 Feb 2020 12:29:53 GMT Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> References: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> Message-ID: <9Ml10hIPAJOE6OWg5ANydZQLL_H-lSvBe_UzjnaHR24=.d9c7d334-5817-4cf9-a011-31c0b59b3830@github.com> On Wed, 5 Feb 2020 22:48:45 GMT, Kevin Rushforth wrote: >> The pull request has been updated with a new target base due to a merge or a rebase. > > modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 189: > >> 188: static void >> 189: disposeNativeImpl(JNIEnv* env, jobject objectHandle) { >> 190: AbstractSurface* surface; > > Since you removed `disposeNativeImpl`, you can also remove the static declaration on [line 40](https://github.com/openjdk/jfx/blob/0591e41f9106e93ae957cb9d80cf2e9e2c6fd805/modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c#L40). I shall do this in next commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From arapte at openjdk.java.net Fri Feb 7 12:29:54 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 Feb 2020 12:29:54 GMT Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> References: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> Message-ID: On Wed, 5 Feb 2020 22:43:13 GMT, Kevin Rushforth wrote: >> The pull request has been updated with a new target base due to a merge or a rebase. > > modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java line 2: > >> 1: /* >> 2: * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > Best to revert this or make it 2020. I will make it 2020 in all files. ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From arapte at openjdk.java.net Fri Feb 7 12:34:46 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 Feb 2020 12:34:46 GMT Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> References: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> Message-ID: On Wed, 5 Feb 2020 22:42:19 GMT, Kevin Rushforth wrote: >> The pull request has been updated with a new target base due to a merge or a rebase. > > modules/javafx.graphics/src/main/java/com/sun/pisces/JavaSurface.java line 46: > >> 45: initialize(dataType, width, height); >> 46: addDisposerRecord(); >> 47: } > > Should this be called from the superclass instead? It works as-is, but if there were ever another subclass added, it would have to be replicated there as well. `AbstractSurface.nativePtr` is needed to create the `AbstractSurfaceDisposerRecord`. It is created and set by the native method `initialize(dataType, width, height);` invoked at line 45 in the `JavaSurface` constructor. It is the reason `addDisposerRecord()` is needed here. ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From github.com+1366654+koppor at openjdk.java.net Fri Feb 7 14:33:52 2020 From: github.com+1366654+koppor at openjdk.java.net (Oliver Kopp) Date: Fri, 7 Feb 2020 14:33:52 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Message-ID: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> This is a WIP PR. Requesting for comments. I could not replicate the test given at https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I nevertheless let my try to replicate the @Test things in here. The fix is just a wild guess without really understanding the side effects of `.addListener`. ------------- Commits: - 492cb6ca: 8176270: Fix TextInputControl String boundaries Changes: https://git.openjdk.java.net/jfx/pull/73/files Webrev: https://webrevs.openjdk.java.net/jfx/73/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8176270 Stats: 108 lines in 2 files changed: 106 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/73.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/73/head:pull/73 PR: https://git.openjdk.java.net/jfx/pull/73 From kcr at openjdk.java.net Fri Feb 7 14:44:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 14:44:46 GMT Subject: [Integrated] RFR: 8236839: System menubar removed when other menubars are created or modified In-Reply-To: References: Message-ID: Changeset: a74137a1 Author: Johan Kaving Committer: Kevin Rushforth Date: 2020-02-07 14:43:29 +0000 URL: https://git.openjdk.java.net/jfx/commit/a74137a1 8236839: System menubar removed when other menubars are created or modified Reviewed-by: kcr, aghaisas ! modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/MenuBarSkinTest.java From abhinay_agarwal at live.com Fri Feb 7 16:33:12 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 7 Feb 2020 16:33:12 +0000 Subject: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side Message-ID: The issue is caused because of a fix which was pushed as a part of https://bugs.openjdk.java.net/browse/JDK-8159044 The root cause of the issue is that ContextMenuSkin#performPopupShifts doesn't consider the cases where shiftX / shiftY can be negative, just as in case of the example provided by Robert in 8228363. Moreover, these shifts are only required for Side.TOP and Side.LEFT. My fix tries to find a solution to this problem using properties map as side, dx, dy passed to ContextMenu#show(Node anchor, Side side, double dx, double dy) are not exposed by the control and cannot be accessed by Skin. I am not sure if it is the best way to do it. Changes: https://github.com/abhinayagarwal/jfx/commit/148b1ba2b0d3c6bc748df24b1b635e964a7b8001 Any feedback on the changes are appreciated. Best regards, Abhinay From kevin.rushforth at oracle.com Fri Feb 7 16:44:53 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 7 Feb 2020 08:44:53 -0800 Subject: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side In-Reply-To: References: Message-ID: <0a52bb5a-e995-5464-f608-256a148b5473@oracle.com> I presume this is a "pre" review before sending out an actual review (which the Skara tooling will do automatically when you generate a pull request)... My concern with this approach is that it leaks what should be an implementation detail into a visible property of the control (and really, using the properties map in this manner is a bit of a workaround). An alternative would be to use package scope methods and a Helper class, which is done in many other places. Worth noting is that if this is information that a custom skin would also need, then some sort of way to make this visible to the Skin will eventually be needed. -- Kevin On 2/7/2020 8:33 AM, Abhinay Agarwal wrote: > The issue is caused because of a fix which was pushed as a part of https://bugs.openjdk.java.net/browse/JDK-8159044 > > The root cause of the issue is that ContextMenuSkin#performPopupShifts doesn't consider the cases where shiftX / shiftY can be negative, just as in case of the example provided by Robert in 8228363. Moreover, these shifts are only required for Side.TOP and Side.LEFT. > > My fix tries to find a solution to this problem using properties map as side, dx, dy passed to ContextMenu#show(Node anchor, Side side, double dx, double dy) are not exposed by the control and cannot be accessed by Skin. I am not sure if it is the best way to do it. > > Changes: https://github.com/abhinayagarwal/jfx/commit/148b1ba2b0d3c6bc748df24b1b635e964a7b8001 > > Any feedback on the changes are appreciated. > > Best regards, > Abhinay From kcr at openjdk.java.net Fri Feb 7 18:26:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 18:26:54 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> Message-ID: <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> On Sat, 21 Dec 2019 15:36:14 GMT, Oliver Kopp wrote: > This is a WIP PR. Requesting for comments. > > I could not replicate the test given at https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I nevertheless let my try to replicate the @Test things in here. > > The fix is just a wild guess without really understanding the side effects of `.addListener`. 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. modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 168: > 167: // Ensure that the last character to get is within the bounds of the txt string > 168: if (end >= start + length) end = length-1; > 169: // In case the start is after the whole txt, nothing valid is selected. Thus, return the default. First, I think the existing test is simply wrong: Why should the `start` value matter when checking whether the `end` value needs to be clamped -- it's an `end` point not a number of characters. I think the entire problem might be the fact that it is comparing against `start + length`. Second, the value to be clamped to was correct before your change. The `substring` method to which `end` is passed is documented as subtracting 1. I think the test should be something like: if (end > length) end = length; modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 170: > 169: // In case the start is after the whole txt, nothing valid is selected. Thus, return the default. > 170: if (start >= length) return ""; > 171: return txt.substring(start, end); This change seems OK, and might be clearer and the existing code, but the existing code is correct, and produces the same effect. modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 2088: > 2087: Semaphore semaphore = new Semaphore(0); > 2088: Platform.runLater(semaphore::release); > 2089: semaphore.acquire(); Since controls tests run using the StubToolkit, `Platform.runLater` does not do what you expect. If you need to run a pulse to get some code to run that normally would run as part of pulse, you can call that method directly. See other controls tests for how this is done. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/73 From kcr at openjdk.java.net Fri Feb 7 18:38:41 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 18:38:41 GMT Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: References: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> Message-ID: On Fri, 7 Feb 2020 12:32:26 GMT, Ambarish Rapte wrote: >> modules/javafx.graphics/src/main/java/com/sun/pisces/JavaSurface.java line 46: >> >>> 45: initialize(dataType, width, height); >>> 46: addDisposerRecord(); >>> 47: } >> >> Should this be called from the superclass instead? It works as-is, but if there were ever another subclass added, it would have to be replicated there as well. > > `AbstractSurface.nativePtr` is needed to create the `AbstractSurfaceDisposerRecord`. > It is created and set by the native method `initialize(dataType, width, height);` invoked at line 45 in the `JavaSurface` constructor. > It is the reason `addDisposerRecord()` is needed here. Oh, I see. The native initialize method in the subclass is writing into a private field in the superclass. Can you add a comment to this effect, since it isn't obvious without reading the native code? ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From github.com+637990+bmwiedemann at openjdk.java.net Fri Feb 7 19:37:33 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Fri, 7 Feb 2020 19:37:33 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Message-ID: 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. ------------- Commits: - e7f71fb9: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Changes: https://git.openjdk.java.net/jfx/pull/99/files Webrev: https://webrevs.openjdk.java.net/jfx/99/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238650 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/99/head:pull/99 PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Fri Feb 7 19:37:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 19:37:33 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann 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. In addition to a signed OCA, we will need a bug filed to track this. Please read the [CONTRIBUTING guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md). ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From github.com+637990+bmwiedemann at openjdk.java.net Fri Feb 7 19:37:34 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Fri, 7 Feb 2020 19:37:34 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 29 Jan 2020 12:33:00 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. > > In addition to a signed OCA, we will need a bug filed to track this. Please read the [CONTRIBUTING guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md). /signed I filed one bug and got review ID : 9063488 ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Fri Feb 7 19:37:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 19:37:34 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 29 Jan 2020 12:40:05 GMT, Bernhard M. Wiedemann wrote: >> In addition to a signed OCA, we will need a bug filed to track this. Please read the [CONTRIBUTING guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md). > > /signed > > I filed one bug and got review ID : 9063488 > I filed one bug and got review ID : 9063488 OK. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From github.com+637990+bmwiedemann at openjdk.java.net Fri Feb 7 19:37:34 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Fri, 7 Feb 2020 19:37:34 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Wed, 29 Jan 2020 12:48:35 GMT, Kevin Rushforth wrote: >> /signed >> >> I filed one bug and got review ID : 9063488 > >> I filed one bug and got review ID : 9063488 > > OK. So the contributor agreement is done. How can I find the bug? ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Fri Feb 7 19:37:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 19:37:35 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: <4Fnn5n-nenb7SYFpn6TCC7NK4M2NeFf_YJU-ijuKFrQ=.7081e17a-6f2f-4bb1-a46b-489b28a6970d@github.com> On Fri, 7 Feb 2020 12:11:24 GMT, Bernhard M. Wiedemann wrote: >>> I filed one bug and got review ID : 9063488 >> >> OK. > > So the contributor agreement is done. How can I find the bug? The OCA needs to be validated and recorded. As for the bug, it has been transferred to the JDK project as [JDK-8238650](https://bugs.openjdk.java.net/browse/JDK-8238650). ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From github.com+637990+bmwiedemann at openjdk.java.net Fri Feb 7 19:38:21 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Fri, 7 Feb 2020 19:38:21 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: <4Fnn5n-nenb7SYFpn6TCC7NK4M2NeFf_YJU-ijuKFrQ=.7081e17a-6f2f-4bb1-a46b-489b28a6970d@github.com> References: <4Fnn5n-nenb7SYFpn6TCC7NK4M2NeFf_YJU-ijuKFrQ=.7081e17a-6f2f-4bb1-a46b-489b28a6970d@github.com> Message-ID: On Fri, 7 Feb 2020 13:43:50 GMT, Kevin Rushforth wrote: >> So the contributor agreement is done. How can I find the bug? > > The OCA needs to be validated and recorded. As for the bug, it has been transferred to the JDK project as [JDK-8238650](https://bugs.openjdk.java.net/browse/JDK-8238650). > The OCA needs to be validated and recorded. https://www.oracle.com/technetwork/community/oca-486395.html#w now has `Bernhard Wiedemann - OpenJDK - bmwiedemann` > As for the bug, it has been transferred to the JDK project as [JDK-8238650](https://bugs.openjdk.java.net/browse/JDK-8238650). Thanks, somehow I had not got an email notification for that. Also worth noting that this PR only fixes one of the sources of non-determinism in openjfx. Do I have to open a separate bug for each of them? ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Fri Feb 7 19:53:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 19:53:27 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: <4Fnn5n-nenb7SYFpn6TCC7NK4M2NeFf_YJU-ijuKFrQ=.7081e17a-6f2f-4bb1-a46b-489b28a6970d@github.com> Message-ID: On Fri, 7 Feb 2020 19:32:39 GMT, Bernhard M. Wiedemann wrote: >> The OCA needs to be validated and recorded. As for the bug, it has been transferred to the JDK project as [JDK-8238650](https://bugs.openjdk.java.net/browse/JDK-8238650). > >> The OCA needs to be validated and recorded. > > https://www.oracle.com/technetwork/community/oca-486395.html#w now has > `Bernhard Wiedemann - OpenJDK - bmwiedemann` > >> As for the bug, it has been transferred to the JDK project as [JDK-8238650](https://bugs.openjdk.java.net/browse/JDK-8238650). > > Thanks, somehow I had not got an email notification for that. > Also worth noting that this PR only fixes one of the sources of non-determinism in openjfx. Do I have to open a separate bug for each of them? > Do I have to open a separate bug for each of them? Every fix (meaning each pull request) needs a unique bug ID. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Fri Feb 7 20:06:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Feb 2020 20:06:43 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: <4Fnn5n-nenb7SYFpn6TCC7NK4M2NeFf_YJU-ijuKFrQ=.7081e17a-6f2f-4bb1-a46b-489b28a6970d@github.com> Message-ID: On Fri, 7 Feb 2020 19:51:07 GMT, Kevin Rushforth wrote: >>> The OCA needs to be validated and recorded. >> >> https://www.oracle.com/technetwork/community/oca-486395.html#w now has >> `Bernhard Wiedemann - OpenJDK - bmwiedemann` >> >>> As for the bug, it has been transferred to the JDK project as [JDK-8238650](https://bugs.openjdk.java.net/browse/JDK-8238650). >> >> Thanks, somehow I had not got an email notification for that. >> Also worth noting that this PR only fixes one of the sources of non-determinism in openjfx. Do I have to open a separate bug for each of them? > >> Do I have to open a separate bug for each of them? > > Every fix (meaning each pull request) needs a unique bug ID. As an optional override, I am OK with the concept of having a way for the build to be reproducible. FWIW, I have scripts that will unpack the modular jar files and diff each class as well as doing the same for a src.zip, and it's pretty easy to tell if only VersionInfo (which is the class that records the time stamps) has changed. I note that in practice, this is useful for a certain class of builds (e.g., CI or nightly test builds), but each released build is necessarily going to be different because you want a unique time stamp and build number associated with it. I will review this (probably some time next week) and would like @johanvos to review as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From abhinay_agarwal at live.com Sat Feb 8 07:45:15 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Sat, 8 Feb 2020 07:45:15 +0000 Subject: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side In-Reply-To: <0a52bb5a-e995-5464-f608-256a148b5473@oracle.com> References: , <0a52bb5a-e995-5464-f608-256a148b5473@oracle.com> Message-ID: Hi Kevin, Yes, this is actually a pre-review mail to know if I am on the right path. Exposing these properties from ContextMenu can confuse users because the control has overloaded show() method. The second show() method doesn't use any of these properties and instead use screenX and screenY to place the ContextMenu. Given the circumstances, using Helper class seems the best solution to me. If someone has a better alternate solution, I am all ears. -- Abhinay ________________________________ From: Kevin Rushforth Sent: Friday, February 7, 2020 10:14 PM To: Abhinay Agarwal ; openjfx-dev at openjdk.java.net Subject: Re: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side I presume this is a "pre" review before sending out an actual review (which the Skara tooling will do automatically when you generate a pull request)... My concern with this approach is that it leaks what should be an implementation detail into a visible property of the control (and really, using the properties map in this manner is a bit of a workaround). An alternative would be to use package scope methods and a Helper class, which is done in many other places. Worth noting is that if this is information that a custom skin would also need, then some sort of way to make this visible to the Skin will eventually be needed. -- Kevin On 2/7/2020 8:33 AM, Abhinay Agarwal wrote: > The issue is caused because of a fix which was pushed as a part of https://bugs.openjdk.java.net/browse/JDK-8159044 > > The root cause of the issue is that ContextMenuSkin#performPopupShifts doesn't consider the cases where shiftX / shiftY can be negative, just as in case of the example provided by Robert in 8228363. Moreover, these shifts are only required for Side.TOP and Side.LEFT. > > My fix tries to find a solution to this problem using properties map as side, dx, dy passed to ContextMenu#show(Node anchor, Side side, double dx, double dy) are not exposed by the control and cannot be accessed by Skin. I am not sure if it is the best way to do it. > > Changes: https://github.com/abhinayagarwal/jfx/commit/148b1ba2b0d3c6bc748df24b1b635e964a7b8001 > > Any feedback on the changes are appreciated. > > Best regards, > Abhinay From github.com+637990+bmwiedemann at openjdk.java.net Sat Feb 8 11:16:47 2020 From: github.com+637990+bmwiedemann at openjdk.java.net (Bernhard M.Wiedemann) Date: Sat, 8 Feb 2020 11:16:47 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: <4Fnn5n-nenb7SYFpn6TCC7NK4M2NeFf_YJU-ijuKFrQ=.7081e17a-6f2f-4bb1-a46b-489b28a6970d@github.com> Message-ID: On Fri, 7 Feb 2020 20:04:21 GMT, Kevin Rushforth wrote: >>> Do I have to open a separate bug for each of them? >> >> Every fix (meaning each pull request) needs a unique bug ID. > > As an optional override, I am OK with the concept of having a way for the build to be reproducible. > > FWIW, I have scripts that will unpack the modular jar files and diff each class as well as doing the same for a src.zip, and it's pretty easy to tell if only VersionInfo (which is the class that records the time stamps) has changed. > > I note that in practice, this is useful for a certain class of builds (e.g., CI or nightly test builds), but each released build is necessarily going to be different because you want a unique time stamp and build number associated with it. > > I will review this (probably some time next week) and would like @johanvos to review as well. > FWIW, I have scripts that will unpack the modular jar files and diff each class I agree that such specialized diff tools have some value, yet, there are also some limitations and downsides to them. E.g. you cannot simply tell another party what the expected sha256sum of a build result is. https://www.suse.com/c/?p=42014 also has a section on problems with "the use of specialized comparison tools like [openSUSE's] ?build-compare? " I probably should write an FAQ entry about that topic... > each released build is necessarily going to be different because you want a unique time stamp and build number associated with it. For release builds, it is important that other people can take the released sources and reproduce the same original binaries with the same release number (and ideally same timestamps) to easily verify that the build was clean (not corrupted by bad CPUs/RAM/HDDs or someone messing with the build machine). I heard, some people even use that to save network bandwidth: add a small patch locally+remotely, build it locally, tell the world the new build hash, but have others upload their binaries with the right hash. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From kcr at openjdk.java.net Sat Feb 8 17:08:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 Feb 2020 17:08:26 GMT Subject: RFR: 8227619: Potential memory leak in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Fri, 10 Jan 2020 08:17:12 GMT, Ambarish Rapte wrote: > `ListView` does not get GCed because `SelectedItemsReadOnlyObservableList` adds a `ListChangeListener` to the (`ObservableList`) items of `ListView`. > > Adding a `WeakListChangeListener` instead of `ListChangeListener` fixes the issue. > > Added a unit test and verified that existing tests do not fail due to this change. OK, this makes sense. Somewhat related to this, I see that `ListViewBitSetSelectionModel` is using a `WeakInvalidationListener` in order to avoid a similar problem. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/84 From lior.yaffe at jelurida.com Sun Feb 9 12:07:25 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Sun, 9 Feb 2020 14:07:25 +0200 Subject: JavaFX 13 Webview hangs Message-ID: My application is a Java application running a Javascript/Html website inside a JavaFX WebView. It was working stable for several years with various versions of Java and JavaFX. As far as I can tell it is following best coding practices such as running all UI code in the JavaFX thread and as such. Since upgrading to JavaFX 13 my application hangs sporadically. When it happens the website running inside the webview becomes unresponsive and displays an hourglass icon. When the app hangs I cannot take a thread dump using jstack or close the application. I have to kill it. The problem is reproduced on multiple Windows workstations. It was never reported or reproduced on Linux or Mac so there is a chance it is Windows specific. When the app hangs the CPU is ideal so this is not a busy loop. Which diagnostic information can I obtain to better understand this problem? From fastegal at openjdk.java.net Sun Feb 9 14:42:44 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 9 Feb 2020 14:42:44 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> Message-ID: On Fri, 7 Feb 2020 18:24:32 GMT, Kevin Rushforth wrote: >> This is a WIP PR. Requesting for comments. >> >> I could not replicate the test given at https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I nevertheless let my try to replicate the @Test things in here. >> >> The fix is just a wild guess without really understanding the side effects of `.addListener`. > > 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. Didn't dig at the reason for the throwing, 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, something like /** * Test for JDK-8176270: register changeListener on selectedText, select at * end of text and replace selection throws. */ @Test public void addingChangeListener() { VBox vBox = new VBox(); TextField textField = new TextField(); textField.setText("1234 5678"); vBox.getChildren().add(textField); textField.selectedTextProperty() .addListener((o, ov, nv) -> {}); Scene scene = new Scene(vBox); Stage stage = new Stage(); stage.setScene(scene); stage.show(); textField.positionCaret(5); // select 2nd word textField.selectNextWord(); 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 .. 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); } ------------- PR: https://git.openjdk.java.net/jfx/pull/73 From fastegal at openjdk.java.net Sun Feb 9 17:12:57 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 9 Feb 2020 17:12:57 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> Message-ID: On Fri, 7 Feb 2020 18:12:23 GMT, Kevin Rushforth wrote: >> This is a WIP PR. Requesting for comments. >> >> I could not replicate the test given at https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I nevertheless let my try to replicate the @Test things in here. >> >> The fix is just a wild guess without really understanding the side effects of `.addListener`. > > modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 170: > >> 169: // In case the start is after the whole txt, nothing valid is selected. Thus, return the default. >> 170: if (start >= length) return ""; >> 171: return txt.substring(start, end); > > This change seems OK, and might be clearer than the existing code, but the existing code is correct, and produces the same effect. yeah, it is correct - but while we are changing the impl, we might go the whole way and clean up :) my pref would be to add the check for start to the short-circuit at the beginning of the method, something like String txt = text.get(); IndexRange sel = selection.get(); if (txt == null || sel == null || sel.getStart() >= text.getLength()) return ""; ------------- PR: https://git.openjdk.java.net/jfx/pull/73 From jvos at openjdk.java.net Mon Feb 10 12:41:02 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 Feb 2020 12:41:02 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux Message-ID: * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) * avoid duplicate symbols with different gst plugins * statically register gst plugins ------------- Commits: - c334ba81: Fix for JDK-8238755 Changes: https://git.openjdk.java.net/jfx/pull/109/files Webrev: https://webrevs.openjdk.java.net/jfx/109/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238755 Stats: 32 lines in 6 files changed: 30 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/109/head:pull/109 PR: https://git.openjdk.java.net/jfx/pull/109 From arapte at openjdk.java.net Mon Feb 10 13:27:27 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 Feb 2020 13:27:27 GMT Subject: [Rev 02] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case In-Reply-To: References: Message-ID: > Memory allocated in initDecompressor() and decompressIndirect() is not freed in error case. > In error case, > 1. Allocated memory should be freed. > 2. Appropriate de-initialization jpeg library calls should be added. > > Verified that, > 1. All unit and systems tests pass on three platforms, and > 2. Memory consumption with and without fix is similar by comparing memory before and after showing 10 jpeg images for 100 times. The pull request has been updated with a new target base due to a merge or a rebase. ------------- Commits: - b91e4236: Merge with master - 8a48080a: correcting use of scanline_ptr - 7af932b7: 8212034: Memory leaks in jpegLoader.c in error case Changes: https://git.openjdk.java.net/jfx/pull/54/files Webrev: https://webrevs.openjdk.java.net/jfx/54/webrev.02 Stats: 59 lines in 1 file changed: 33 ins; 15 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/54/head:pull/54 PR: https://git.openjdk.java.net/jfx/pull/54 From arapte at openjdk.java.net Mon Feb 10 13:27:28 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 Feb 2020 13:27:28 GMT Subject: [Rev 02] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case In-Reply-To: References: Message-ID: On Wed, 27 Nov 2019 21:19:08 GMT, Johan Vos wrote: >> The pull request has been updated with a new target base due to a merge or a rebase. > > In general, this makes sense. I need to look into more detail that the additional calls for freeing resources (in case of errors) don't cause e.g. segmentation violations and lead to a crash -- which would be worse than throwing an Exception. > I expect memory consumption to be similar before and after this patch if you don't run into errors, but did you check memory consumption before/after this patch in case of errors? The PR was outdated. It is now merged with latest master. Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/54 From arapte at openjdk.java.net Mon Feb 10 13:33:41 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 Feb 2020 13:33:41 GMT Subject: [Rev 02] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: References: Message-ID: > The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html). > And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed. > > The change is, > 1. Remove finalize method from PiscesRenderer and AbstractSurface classes. > 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize(). For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java. > 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method. > > Verification: > Verified that the newly added dispose() methods get invoked as required and no OOM occurs. > 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop. > 2. Run the program using -Dprism.order=sw, -Dprism.verbose=true. (optional -Xmx50m) > Expected Behavior: > a. Maximum memory consumption after this change should reduce or remain same as that of before this change. > b. No OOM should occur with this change or without this change. The pull request has been updated with 1 additional commit. ------------- Added commits: - a67c5119: Changes as per review comments Changes: - all: https://git.openjdk.java.net/jfx/pull/66/files - new: https://git.openjdk.java.net/jfx/pull/66/files/0591e41f..a67c5119 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/66/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/66/webrev.01-02 Stats: 11 lines in 5 files changed: 5 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/66.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/66/head:pull/66 PR: https://git.openjdk.java.net/jfx/pull/66 From arapte at openjdk.java.net Mon Feb 10 13:33:41 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 Feb 2020 13:33:41 GMT Subject: [Rev 01] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: References: <227HV6-gDx2KrlmEnCPRnfU3vH3rtgx7T8cBMvq5UsM=.419a2954-9c4d-4cde-a318-1f5d1109a7d0@github.com> <_OGIlE9lC8GNoTka876iy8rAMZMVRB82Okvbz9BBASc=.0214a356-cfb8-4390-baea-8a3ee60fe14b@github.com> Message-ID: On Fri, 7 Feb 2020 18:36:18 GMT, Kevin Rushforth wrote: >> `AbstractSurface.nativePtr` is needed to create the `AbstractSurfaceDisposerRecord`. >> It is created and set by the native method `initialize(dataType, width, height);` invoked at line 45 in the `JavaSurface` constructor. >> It is the reason `addDisposerRecord()` is needed here. > > Oh, I see. The native initialize method in the subclass is writing into a private field in the superclass. Can you add a comment to this effect, since it isn't obvious without reading the native code? The comment would be really helpful for readers. ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From kevin.rushforth at oracle.com Mon Feb 10 14:40:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Feb 2020 06:40:51 -0800 Subject: JavaFX 13 Webview hangs In-Reply-To: References: Message-ID: A thread stack dump using "jstack" might be helpful. Also, what version of the JDK are you running? -- Kevin On 2/9/2020 4:07 AM, Lior Yaffe wrote: > My application is a Java application running a Javascript/Html website > inside a JavaFX WebView. It was working stable for several years with > various versions of Java and JavaFX. > As far as I can tell it is following best coding practices such as running > all UI code in the JavaFX thread and as such. > > Since upgrading to JavaFX 13 my application hangs sporadically. When it > happens the website running inside the webview becomes unresponsive and > displays an hourglass icon. > When the app hangs I cannot take a thread dump using jstack or close the > application. I have to kill it. > > The problem is reproduced on multiple Windows workstations. It was never > reported or reproduced on Linux or Mac so there is a chance it is Windows > specific. > When the app hangs the CPU is ideal so this is not a busy loop. > Which diagnostic information can I obtain to better understand this problem? From abhinay_agarwal at live.com Mon Feb 10 14:43:25 2020 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Mon, 10 Feb 2020 14:43:25 +0000 Subject: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side In-Reply-To: References: , <0a52bb5a-e995-5464-f608-256a148b5473@oracle.com>, Message-ID: Hi, I am trying to add test-cases in ContextMenuTest.java to test ContextMenu positioning, but the test cases fails since it ignores the css padding applied on the ContextMenu's menu/menu-item via css. Test-cases: @Test public void test_position_showOnTop() { // fails ContextMenu cm = createContextMenu(false); cm.show(anchorBtn, Side.TOP, 0, 0); final Bounds anchorBounds = anchorBtn.localToScreen(anchorBtn.getLayoutBounds()); assertEquals(cm.getAnchorX(), anchorBounds.getMinX(), 0.0); assertEquals(cm.getAnchorY() + cm.getHeight(), anchorBounds.getMinY(), 0.0); } @Test public void test_position_showOnRight() { // passes ContextMenu cm = createContextMenu(false); cm.show(anchorBtn, Side.RIGHT, 0, 0); final Bounds anchorBounds = anchorBtn.localToScreen(anchorBtn.getLayoutBounds()); assertEquals(cm.getAnchorX(), anchorBounds.getMaxX(), 0.0); assertEquals(cm.getAnchorY(), anchorBounds.getMinY(), 0.0); } I can do the following to make the tests pass, but it doesn't feel write: @Test public void test_position_showOnTop() { ... cm.setOnShown(e -> { final Bounds anchorBounds = anchorBtn.localToScreen(anchorBtn.getLayoutBounds()); assertEquals(cm.getAnchorX(), anchorBounds.getMinX(), 0.0); assertEquals(cm.getAnchorY() + cm.getHeight(), anchorBounds.getMinY(), 0.0); }); } What would be the correct way to fetch "css applied" height/width of ContextMenu? -- Abhinay ________________________________ From: openjfx-dev on behalf of Abhinay Agarwal Sent: Saturday, February 8, 2020 1:15 PM To: Kevin Rushforth ; openjfx-dev at openjdk.java.net Subject: Re: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side Hi Kevin, Yes, this is actually a pre-review mail to know if I am on the right path. Exposing these properties from ContextMenu can confuse users because the control has overloaded show() method. The second show() method doesn't use any of these properties and instead use screenX and screenY to place the ContextMenu. Given the circumstances, using Helper class seems the best solution to me. If someone has a better alternate solution, I am all ears. -- Abhinay ________________________________ From: Kevin Rushforth Sent: Friday, February 7, 2020 10:14 PM To: Abhinay Agarwal ; openjfx-dev at openjdk.java.net Subject: Re: RFR: 8228363 Fix shifts for ContextMenu shown on TOP/LEFT side I presume this is a "pre" review before sending out an actual review (which the Skara tooling will do automatically when you generate a pull request)... My concern with this approach is that it leaks what should be an implementation detail into a visible property of the control (and really, using the properties map in this manner is a bit of a workaround). An alternative would be to use package scope methods and a Helper class, which is done in many other places. Worth noting is that if this is information that a custom skin would also need, then some sort of way to make this visible to the Skin will eventually be needed. -- Kevin On 2/7/2020 8:33 AM, Abhinay Agarwal wrote: > The issue is caused because of a fix which was pushed as a part of https://bugs.openjdk.java.net/browse/JDK-8159044 > > The root cause of the issue is that ContextMenuSkin#performPopupShifts doesn't consider the cases where shiftX / shiftY can be negative, just as in case of the example provided by Robert in 8228363. Moreover, these shifts are only required for Side.TOP and Side.LEFT. > > My fix tries to find a solution to this problem using properties map as side, dx, dy passed to ContextMenu#show(Node anchor, Side side, double dx, double dy) are not exposed by the control and cannot be accessed by Skin. I am not sure if it is the best way to do it. > > Changes: https://github.com/abhinayagarwal/jfx/commit/148b1ba2b0d3c6bc748df24b1b635e964a7b8001 > > Any feedback on the changes are appreciated. > > Best regards, > Abhinay From kevin.rushforth at oracle.com Mon Feb 10 14:59:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Feb 2020 06:59:49 -0800 Subject: JavaFX 13 Webview hangs In-Reply-To: References: Message-ID: Seems I missed your comment about it being hung to the point you can't run jstack. If you are using JDK 12 or later, you might try with JDK 11 and see if that makes a difference. It will help narrow it down to a change in the JDK versus a change in JavaFX (although I suspect it's a change in JavaFX). -- Kevin On 2/10/2020 6:40 AM, Kevin Rushforth wrote: > A thread stack dump using "jstack" might be helpful. > > Also, what version of the JDK are you running? > > -- Kevin > > > On 2/9/2020 4:07 AM, Lior Yaffe wrote: >> My application is a Java application running a Javascript/Html website >> inside a JavaFX WebView. It was working stable for several years with >> various versions of Java and JavaFX. >> As far as I can tell it is following best coding practices such as >> running >> all UI code in the JavaFX thread and as such. >> >> Since upgrading to JavaFX 13 my application hangs sporadically. When it >> happens the website running inside the webview becomes unresponsive and >> displays an hourglass icon. >> When the app hangs I cannot take a thread dump using jstack or close the >> application. I have to kill it. >> >> The problem is reproduced on multiple Windows workstations. It was never >> reported or reproduced on Linux or Mac so there is a chance it is >> Windows >> specific. >> When the app hangs the CPU is ideal so this is not a busy loop. >> Which diagnostic information can I obtain to better understand this >> problem? > From kevin.rushforth at oracle.com Mon Feb 10 15:00:40 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Feb 2020 07:00:40 -0800 Subject: JavaFX 13 Webview hangs In-Reply-To: References: Message-ID: And one last thing to try: can you run it with the JavaFX 15-ea+1 build and see if that makes a difference? -- Kevin On 2/10/2020 6:59 AM, Kevin Rushforth wrote: > Seems I missed your comment about it being hung to the point you can't > run jstack. > > If you are using JDK 12 or later, you might try with JDK 11 and see if > that makes a difference. It will help narrow it down to a change in > the JDK versus a change in JavaFX (although I suspect it's a change in > JavaFX). > > -- Kevin > > On 2/10/2020 6:40 AM, Kevin Rushforth wrote: >> A thread stack dump using "jstack" might be helpful. >> >> Also, what version of the JDK are you running? >> >> -- Kevin >> >> >> On 2/9/2020 4:07 AM, Lior Yaffe wrote: >>> My application is a Java application running a Javascript/Html website >>> inside a JavaFX WebView. It was working stable for several years with >>> various versions of Java and JavaFX. >>> As far as I can tell it is following best coding practices such as >>> running >>> all UI code in the JavaFX thread and as such. >>> >>> Since upgrading to JavaFX 13 my application hangs sporadically. When it >>> happens the website running inside the webview becomes unresponsive and >>> displays an hourglass icon. >>> When the app hangs I cannot take a thread dump using jstack or close >>> the >>> application. I have to kill it. >>> >>> The problem is reproduced on multiple Windows workstations. It was >>> never >>> reported or reproduced on Linux or Mac so there is a chance it is >>> Windows >>> specific. >>> When the app hangs the CPU is ideal so this is not a busy loop. >>> Which diagnostic information can I obtain to better understand this >>> problem? >> > From kcr at openjdk.java.net Mon Feb 10 15:08:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Feb 2020 15:08:15 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: <7UI9Bac9wiSMuok-6TO7JAQbtk6PKoFkAIZh02KUKOc=.f9b90c94-51a0-41a5-b0e8-61ee5f5c9bb7@github.com> On Mon, 10 Feb 2020 12:26:53 GMT, Johan Vos wrote: > * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) > * avoid duplicate symbols with different gst plugins > * statically register gst plugins I'll review this and also ask @sashamatveev to review. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From dlemmermann at gmail.com Mon Feb 10 16:21:53 2020 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 10 Feb 2020 17:21:53 +0100 Subject: No screen coordinates for DRAG_DONE events Message-ID: Need some help: I noticed that the DRAG_DONE event does not tell me the location of the event. I am working on a docking framework and the fact that I am receiving a DRAG_DONE event but not a DRAG_DROPPED tells me that the user dragged a docking item out of the docking container. If that is the case I would like to show a new stage at the event location but it turns out that the x and y fields are always set to 0 / 0 on the event object. Is this intentional or a bug? Dirk From kcr at openjdk.java.net Mon Feb 10 16:45:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Feb 2020 16:45:52 GMT Subject: [Rev 02] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 16:45:52 GMT, Ambarish Rapte wrote: >> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html). >> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed. >> >> The change is, >> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes. >> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize(). For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java. >> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method. >> >> Verification: >> Verified that the newly added dispose() methods get invoked as required and no OOM occurs. >> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop. >> 2. Run the program using -Dprism.order=sw, -Dprism.verbose=true. (optional -Xmx50m) >> Expected Behavior: >> a. Maximum memory consumption after this change should reduce or remain same as that of before this change. >> b. No OOM should occur with this change or without this change. > > The pull request has been updated with 1 additional commit. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From kcr at openjdk.java.net Mon Feb 10 16:50:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Feb 2020 16:50:14 GMT Subject: [Rev 02] RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 16:45:26 GMT, Kevin Rushforth wrote: >> The pull request has been updated with 1 additional commit. > > Marked as reviewed by kcr (Lead). @johanvos the Skara team enabled the invalidation of stale reviews. Can you re-review this when you get a chance? Btw, tt isn't clear from looking at this that your approval no longer counts; they are working to improve the presentation of this so it will be more clear. ------------- PR: https://git.openjdk.java.net/jfx/pull/66 From kevin.rushforth at oracle.com Mon Feb 10 20:08:09 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Feb 2020 12:08:09 -0800 Subject: No screen coordinates for DRAG_DONE events In-Reply-To: References: Message-ID: My quick take is that this seems like a bug. -- Kevin On 2/10/2020 8:21 AM, Dirk Lemmermann wrote: > Need some help: I noticed that the DRAG_DONE event does not tell me the location of the event. I am working on a docking framework and the fact that I am receiving a DRAG_DONE event but not a DRAG_DROPPED tells me that the user dragged a docking item out of the docking container. If that is the case I would like to show a new stage at the event location but it turns out that the x and y fields are always set to 0 / 0 on the event object. Is this intentional or a bug? > > Dirk > From kcr at openjdk.java.net Mon Feb 10 20:58:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Feb 2020 20:58:32 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 12:26:53 GMT, Johan Vos wrote: > * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) > * avoid duplicate symbols with different gst plugins > * statically register gst plugins I added a comment about using an ifdef for `GSTREAMER_LITE` in one of the modified files (the others are fine, since those files are entirely FX_specific). One other question: do you need any changes in [ConnectionHolder.java](https://github.com/openjdk/jfx/blob/c334ba810293683b7e510a91be3496f7a872c574/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/ConnectionHolder.java)? That class checks for URL scheme to determine whether a URL is seekable. modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst.c line 125: > 124: > 125: #ifdef STATIC_BUILD > 126: gboolean fxplugins_init (GstPlugin * plugin); I think this should also be qualified by `GSTREAMER_LITE` to indicate that it is a JavaFX-specific modification. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From almatvee at openjdk.java.net Mon Feb 10 22:07:10 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 10 Feb 2020 22:07:10 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 12:26:53 GMT, Johan Vos wrote: > * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) > * avoid duplicate symbols with different gst plugins > * statically register gst plugins modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/platform/gstreamer/GSTPlatform.java line 66: > 65: "jrt", > 66: "resource" > 67: }; We do not support "resource" protocol in non-static build, so it is better to only enable it for static build. Not sure how to do this. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From tsayao at openjdk.java.net Tue Feb 11 02:00:14 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2020 02:00:14 GMT Subject: [Rev 19] 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: <18tFJ4ZTlTdmwzberqnAOw8c4rKuMSy-2mOBL4LM7_U=.1c84ed6e-9ca0-4cc7-8030-bb3c412f2c58@github.com> > 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) The pull request has been updated with 21 additional commits. ------------- Added commits: - 7ed26f41: Revert back focus mechanism - 22c38d7f: Merge branch 'jdk_8236651' of https://github.com/tsayao/jfx into jdk_8236651 - 2d10fe8c: Merge branch 'jdk_8236651' of https://github.com/tsayao/jfx into jdk_8236651 - cb2d9fb6: Work on mouse grab - 2bfac077: Mouse pointer grab - 4b555624: Allow undecorated windows to be maximized. - f35fa9b1: Big cleanup - f99aebcf: Maybe fix background - 9850bb71: Fix dialog with owner sizing - 209b7ac7: Better alternative calculation for no _NET_FRAME_EXTENTS WM extension - 0dc70ab3: Use gtk_window_set_default_size for before-map sizing which is the appropriate function - e4d2a1d2: Small fixes - cc7745b4: Pass more tests - 49426b66: Fix flickering and sizing issues - 628d5528: Revert idea files - 8b0cadfc: Fix crash - 1c3df122: Fix crash - 4691800a: Fix crash - 7b48e484: Cleaning + change year to 2020 - 039daa4a: Cleaning - 9f209f1e: JDK-8236651 Simplify and update glass gtk backend Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/14a75ce4..7ed26f41 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.19 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.18-19 Stats: 65 lines in 2 files changed: 17 ins; 24 del; 24 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 Tue Feb 11 02:22:11 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2020 02:22:11 GMT Subject: [Rev 20] 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) The pull request has been updated with 1 additional commit. ------------- Added commits: - 465c9cdd: Fix seat_grab param Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/7ed26f41..465c9cdd Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.20 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.19-20 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 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 Tue Feb 11 02:32:47 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2020 02:32:47 GMT Subject: [Rev 21] 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) The pull request has been updated with 1 additional commit. ------------- Added commits: - 84bfd8b8: Fix POPUP window positioning Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/465c9cdd..84bfd8b8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.21 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.20-21 Stats: 3 lines in 1 file changed: 3 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 arapte at openjdk.java.net Tue Feb 11 06:37:43 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 11 Feb 2020 06:37:43 GMT Subject: [Rev 02] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case In-Reply-To: References: Message-ID: <8Jbnqp0Tj5lzTgCTF5WWO0k6rW5ycA9eawcfQTVrA-g=.8a8c605a-f712-4de0-af8b-81ececdba995@github.com> On Fri, 7 Feb 2020 10:06:59 GMT, Ambarish Rapte wrote: >> In general, this makes sense. I need to look into more detail that the additional calls for freeing resources (in case of errors) don't cause e.g. segmentation violations and lead to a crash -- which would be worse than throwing an Exception. >> I expect memory consumption to be similar before and after this patch if you don't run into errors, but did you check memory consumption before/after this patch in case of errors? > > The PR was outdated. It is now merged with latest master. > Please take a look. @johanvos , @arajkumar Could you please take a re-look at the updated PRs. ------------- PR: https://git.openjdk.java.net/jfx/pull/54 From arapte at openjdk.java.net Tue Feb 11 08:53:19 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 11 Feb 2020 08:53:19 GMT Subject: RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: On Sun, 2 Feb 2020 00:15:02 GMT, Nir Lisker wrote: > Resubmitting from before the transition to this repo. See linked issue for details. Looks good to me at first look. I have not built it yet. Suggested minor typo corrections. modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 1014: > 1013: WCMouseEvent mouseEvent = > 1014: new WCMouseEvent(ID_MAP, button, > 1015: ev.getClickCount(), (int) x, (int) y, Looks like it should remain `id` modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java line 632: > 631: > 632: private static Map predefinedPaperMap; > 633: private static Map preDefinedTrayMap; While this is being changed, can you please rename as, `pre`**D**`efinedPaperMap` modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java line 635: > 634: > 635: private static void initPrefinedMediaMaps() { > 636: if (predefinedPaperMap == null) { There is preexisting typo in method name, `initPre`**De**`finedMediaMaps` ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/104 From aghaisas at openjdk.java.net Tue Feb 11 09:02:49 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 11 Feb 2020 09:02:49 GMT Subject: RFR: 8227619: Potential memory leak in javafx.scene.control.ListView In-Reply-To: References: Message-ID: On Fri, 10 Jan 2020 08:17:12 GMT, Ambarish Rapte wrote: > `ListView` does not get GCed because `SelectedItemsReadOnlyObservableList` adds a `ListChangeListener` to the (`ObservableList`) items of `ListView`. > > Adding a `WeakListChangeListener` instead of `ListChangeListener` fixes the issue. > > Added a unit test and verified that existing tests do not fail due to this change. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/84 From nlisker at openjdk.java.net Tue Feb 11 09:48:49 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 11 Feb 2020 09:48:49 GMT Subject: RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 07:17:43 GMT, Ambarish Rapte wrote: >> Resubmitting from before the transition to this repo. See linked issue for details. > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java line 632: > >> 631: >> 632: private static Map predefinedPaperMap; >> 633: private static Map preDefinedTrayMap; > > While this is being changed, can you please rename as, `pre`**D**`efinedPaperMap` I think that "predefined" is correct as it's one word. I don't mind either way. ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From jvos at openjdk.java.net Tue Feb 11 10:00:18 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 11 Feb 2020 10:00:18 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 22:06:40 GMT, Alexander Matveev wrote: >> * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) >> * avoid duplicate symbols with different gst plugins >> * statically register gst plugins > > modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/platform/gstreamer/GSTPlatform.java line 66: > >> 65: "jrt", >> 66: "resource" >> 67: }; > > We do not support "resource" protocol in non-static build, so it is better to only enable it for static build. Not sure how to do this. As an alternative, the "iPod" strategy can be used. For some reasons, the "ipod-library" protocol is supported in the code (Locator), and if that is found, most connection code is bypassed. That strategy seems to be much more difficult to maintain though. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From arapte at openjdk.java.net Tue Feb 11 10:18:20 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 11 Feb 2020 10:18:20 GMT Subject: [Integrated] RFR: 8227619: Potential memory leak in javafx.scene.control.ListView In-Reply-To: References: Message-ID: Changeset: e9864593 Author: Ambarish Rapte Date: 2020-02-11 10:17:09 +0000 URL: https://git.openjdk.java.net/jfx/commit/e9864593 8227619: Potential memory leak in javafx.scene.control.ListView Reviewed-by: kcr, aghaisas ! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableList.java ! modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java From jvos at openjdk.java.net Tue Feb 11 10:58:09 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 11 Feb 2020 10:58:09 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: <7XG3oLF8ntzF_ajQ1CNbSdZoDG6aZ-Pez2e1khjOBWo=.0552be13-69a3-4c1e-9b5a-cb7059ce8939@github.com> On Mon, 10 Feb 2020 20:47:01 GMT, Kevin Rushforth wrote: >> * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) >> * avoid duplicate symbols with different gst plugins >> * statically register gst plugins > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst.c line 125: > >> 124: >> 125: #ifdef STATIC_BUILD >> 126: gboolean fxplugins_init (GstPlugin * plugin); > > I think this should also be qualified by `GSTREAMER_LITE` to indicate that it is a JavaFX-specific modification. done. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From jvos at openjdk.java.net Tue Feb 11 10:59:54 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 11 Feb 2020 10:59:54 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Mon, 10 Feb 2020 20:57:30 GMT, Kevin Rushforth wrote: >> * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) >> * avoid duplicate symbols with different gst plugins >> * statically register gst plugins > > I added a comment about using an ifdef for `GSTREAMER_LITE` in one of the modified files (the others are fine, since those files are entirely FX_specific). > > One other question: do you need any changes in [ConnectionHolder.java](https://github.com/openjdk/jfx/blob/c334ba810293683b7e510a91be3496f7a872c574/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/ConnectionHolder.java)? That class checks for URL scheme to determine whether a URL is seekable. As for the ConnectionHolder: the URIConnectionHolder will be used. This indeed will by default return false for `isSeekable` hence that functionality will now not be possible using the "resource" protocol. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From kcr at openjdk.java.net Tue Feb 11 13:10:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 11 Feb 2020 13:10:46 GMT Subject: RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: <-wUC9hoyNAd9sb9S_9e-C8U9eToXpqvcHNoDrqVqUTs=.95c585d3-bd2d-44ee-90c1-7a839977510e@github.com> On Tue, 11 Feb 2020 09:48:21 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java line 632: >> >>> 631: >>> 632: private static Map predefinedPaperMap; >>> 633: private static Map preDefinedTrayMap; >> >> While this is being changed, can you please rename as, `pre`**D**`efinedPaperMap` > > I think that "predefined" is correct as it's one word. I don't mind either way. @nlisker is right: `predefined` is one word. ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From kcr at openjdk.java.net Tue Feb 11 13:10:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 11 Feb 2020 13:10:47 GMT Subject: RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 07:20:00 GMT, Ambarish Rapte wrote: >> Resubmitting from before the transition to this repo. See linked issue for details. > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java line 635: > >> 634: >> 635: private static void initPrefinedMediaMaps() { >> 636: if (predefinedPaperMap == null) { > > There is preexisting typo in method name, `initPre`**De**`finedMediaMaps` Yes, this should be fined, but with a lower-case `d`. ------------- PR: https://git.openjdk.java.net/jfx/pull/104 From tsayao at openjdk.java.net Tue Feb 11 14:04:59 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2020 14:04:59 GMT Subject: [Rev 22] 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) The pull request has been updated with 1 additional commit. ------------- Added commits: - 06968c9d: Fix bug on extents calculation Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/84bfd8b8..06968c9d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.22 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.21-22 Stats: 7 lines in 1 file changed: 3 ins; 0 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 Tue Feb 11 15:16:28 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2020 15:16:28 GMT Subject: [Rev 23] 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) The pull request has been updated with 2 additional commits. ------------- Added commits: - 2c51b045: Fix pointer grab bug - 2e3ce44a: Ajustments Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/06968c9d..2c51b045 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.23 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.22-23 Stats: 37 lines in 2 files changed: 17 ins; 1 del; 19 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 lior.yaffe at jelurida.com Tue Feb 11 15:21:25 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Tue, 11 Feb 2020 16:21:25 +0100 (CET) Subject: JavaFX 13 Webview hangs In-Reply-To: References: Message-ID: <1705905098.1280377.1581434485832@ichabod.co-bxl> Test results: OpenJFX 11 never hangs OpenJFX 13 always hangs OpenJFX 15ea the webview frame comes up empty but the runtime never hangs The Java version has no effect. The hang seems to occur in native code since there is no way to take a thread dump using jstack and the only possible action is to kill the process. Is there any other logging or diagnostic you can suggest?? ? February 10, 2020 7:24:54 PM CET Kevin Rushforth wrote: Can you also try JDK 11 with OpenJFX 13? I suspect it will not make a difference (i.e., it will still hang), but it would be good to confirm. And even more interesting will be the results of JavaFX 15-ea. Thanks. -- Kevin On 2/10/2020 10:17 AM, Lior Yaffe wrote: The problem does not reproduce when using JavaFX 11 regardless of the version of Java being used. I will try with Java 15ea On Mon, Feb 10, 2020, 17:01 Kevin Rushforth wrote: And one last thing to try: can you run it with the JavaFX 15-ea+1 build and see if that makes a difference? -- Kevin On 2/10/2020 6:59 AM, Kevin Rushforth wrote: > Seems I missed your comment about it being hung to the point you can't > run jstack. > > If you are using JDK 12 or later, you might try with JDK 11 and see if > that makes a difference. It will help narrow it down to a change in > the JDK versus a change in JavaFX (although I suspect it's a change in > JavaFX). > > -- Kevin > > On 2/10/2020 6:40 AM, Kevin Rushforth wrote: >> A thread stack dump using "jstack" might be helpful. >> >> Also, what version of the JDK are you running? >> >> -- Kevin >> >> >> On 2/9/2020 4:07 AM, Lior Yaffe wrote: >>> My application is a Java application running a Javascript/Html website >>> inside a JavaFX WebView. It was working stable for several years with >>> various versions of Java and JavaFX. >>> As far as I can tell it is following best coding practices such as >>> running >>> all UI code in the JavaFX thread and as such. >>> >>> Since upgrading to JavaFX 13 my application hangs sporadically. When it >>> happens the website running inside the webview becomes unresponsive and >>> displays an hourglass icon. >>> When the app hangs I cannot take a thread dump using jstack or close >>> the >>> application. I have to kill it. >>> >>> The problem is reproduced on multiple Windows workstations. It was >>> never >>> reported or reproduced on Linux or Mac so there is a chance it is >>> Windows >>> specific. >>> When the app hangs the CPU is ideal so this is not a busy loop. >>> Which diagnostic information can I obtain to better understand this >>> problem? >> > From tsayao at openjdk.java.net Tue Feb 11 17:10:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 11 Feb 2020 17:10:02 GMT Subject: [Rev 24] 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) The pull request has been updated with 1 additional commit. ------------- Added commits: - 08caafd9: Remove unused var Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/2c51b045..08caafd9 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.24 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.23-24 Stats: 1 line in 1 file changed: 0 ins; 1 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 nlisker at openjdk.java.net Tue Feb 11 18:10:18 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 11 Feb 2020 18:10:18 GMT Subject: [Rev 01] RFR: 8208761: Update constant collections to use the new immutable collections In-Reply-To: References: Message-ID: <7JHzTXfVEGxv2IT_vmXU099ZCv_qBHElImRP5q_6Feo=.46239464-e16f-4f2d-95f5-1b8aa5d3b039@github.com> > Resubmitting from before the transition to this repo. See linked issue for details. The pull request has been updated with 1 additional commit. ------------- Added commits: - 8bf73ca1: Fixes for review comments Changes: - all: https://git.openjdk.java.net/jfx/pull/104/files - new: https://git.openjdk.java.net/jfx/pull/104/files/440e7a88..8bf73ca1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/104/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/104/webrev.00-01 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/104.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/104/head:pull/104 PR: https://git.openjdk.java.net/jfx/pull/104 From nlisker at openjdk.java.net Tue Feb 11 18:44:26 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 11 Feb 2020 18:44:26 GMT Subject: RFR: 8228867: Fix mistakes in FX API docs Message-ID: Docs fixes for OpenJFX 14. We can wait with integrating this in case there are last minute fixes, but reviews can start. ------------- Commits: - 25c6f63b: Merge remote-tracking branch 'origin/jfx14' into JDK-8228867_Fix_mistakes_in_FX_API_docs - 5425c80a: Fixes for Animation - c067e088: Initial commit of 8228867 Changes: https://git.openjdk.java.net/jfx/pull/110/files Webrev: https://webrevs.openjdk.java.net/jfx/110/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228867 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/110.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/110/head:pull/110 PR: https://git.openjdk.java.net/jfx/pull/110 From kcr at openjdk.java.net Tue Feb 11 18:55:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 11 Feb 2020 18:55:23 GMT Subject: RFR: 8228867: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 18:28:57 GMT, Nir Lisker wrote: > Docs fixes for OpenJFX 14. We can wait with integrating this in case there are last minute fixes, but reviews can start. The changes so far look fine. As you say, we can wait for a bit to finish the review of this. One request: Given that this might be the last fix for `jfx14`, can you update the copyright year to 2020 in the modified files? It will save me having to do one last "Update copyright year to 2020" fix right before GAC of JavaFX 14. ------------- PR: https://git.openjdk.java.net/jfx/pull/110 From nlisker at openjdk.java.net Tue Feb 11 20:25:46 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 11 Feb 2020 20:25:46 GMT Subject: RFR: 8228867: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 18:53:08 GMT, Kevin Rushforth wrote: >> Docs fixes for OpenJFX 14. We can wait with integrating this in case there are last minute fixes, but reviews can start. > > The changes so far look fine. As you say, we can wait for a bit to finish the review of this. > > One request: Given that this might be the last fix for `jfx14`, can you update the copyright year to 2020 in the modified files? It will save me having to do one last "Update copyright year to 2020" fix right before GAC of JavaFX 14. > can you update the copyright year to 2020 in the modified files? Yeah, I'll do it in the last commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/110 From almatvee at openjdk.java.net Tue Feb 11 22:26:18 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 11 Feb 2020 22:26:18 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 09:59:10 GMT, Johan Vos wrote: >> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/platform/gstreamer/GSTPlatform.java line 66: >> >>> 65: "jrt", >>> 66: "resource" >>> 67: }; >> >> We do not support "resource" protocol in non-static build, so it is better to only enable it for static build. Not sure how to do this. > > As an alternative, the "iPod" strategy can be used. > For some reasons, the "ipod-library" protocol is supported in the code (Locator), and if that is found, most connection code is bypassed. > That strategy seems to be much more difficult to maintain though. "ipod-library" is only supported if IOSPlatform is loaded, but it will not be loaded on all platform due to check for HostUtils.isIOS(). Do you know what happens if user tries "resource" protocol on not supported platform? and same for some "unknown" protocol. If error message makes sense we can probably keep it as is. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From almatvee at openjdk.java.net Tue Feb 11 22:34:06 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 11 Feb 2020 22:34:06 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 10:59:32 GMT, Johan Vos wrote: >> I added a comment about using an ifdef for `GSTREAMER_LITE` in one of the modified files (the others are fine, since those files are entirely FX_specific). >> >> One other question: do you need any changes in [ConnectionHolder.java](https://github.com/openjdk/jfx/blob/c334ba810293683b7e510a91be3496f7a872c574/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/ConnectionHolder.java)? That class checks for URL scheme to determine whether a URL is seekable. > > As for the ConnectionHolder: the URIConnectionHolder will be used. This indeed will by default return false for `isSeekable` hence that functionality will now not be possible using the "resource" protocol. Does "resource" protocol allows random access? If yes, we should update isSeekable() to return true for resource protocol. seek() should also be updated. I think same should work as for "if ((urlConnection instanceof JarURLConnection) || isJRT())" ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From jvos at openjdk.java.net Wed Feb 12 07:52:03 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 12 Feb 2020 07:52:03 GMT Subject: RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 22:23:41 GMT, Alexander Matveev wrote: >> As an alternative, the "iPod" strategy can be used. >> For some reasons, the "ipod-library" protocol is supported in the code (Locator), and if that is found, most connection code is bypassed. >> That strategy seems to be much more difficult to maintain though. > > "ipod-library" is only supported if IOSPlatform is loaded, but it will not be loaded on all platform due to check for HostUtils.isIOS(). Do you know what happens if user tries "resource" protocol on not supported platform? and same for some "unknown" protocol. If error message makes sense we can probably keep it as is. That is not 100% correct. ipod-library is supported in case `System.getProperty("os.name")` starts with "ios" (which we do in GraalVM and OpenJDK/mobile) (which does not guarantee at all that we're on ios). We can encapsulate the "resource" protocol using the same approach (with a System.getProperty check). In that case, it might make sense to use a wide property that indicates we're running on a statically linked image. That would then be useful for all Java code, not just javafx.media. But that is a bigger change, so I'd like @kevinrushforth opinion on this. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From jvos at openjdk.java.net Wed Feb 12 08:25:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 12 Feb 2020 08:25:06 GMT Subject: RFR: 8228867: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 18:28:57 GMT, Nir Lisker wrote: > Docs fixes for OpenJFX 14. We can wait with integrating this in case there are last minute fixes, but reviews can start. Those are small but useful fixes. I'm already approving it; in case there is a new commit before the GA number is tagged, the Skara bot should request a new review (hence this is a good testcase). ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/110 From jvos at openjdk.java.net Wed Feb 12 09:41:50 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 12 Feb 2020 09:41:50 GMT Subject: [Rev 01] RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: > * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) > * avoid duplicate symbols with different gst plugins > * statically register gst plugins The pull request has been updated with 1 additional commit. ------------- Added commits: - 1c7a4eb1: Add support for seek when the protocol is "resource" Changes: - all: https://git.openjdk.java.net/jfx/pull/109/files - new: https://git.openjdk.java.net/jfx/pull/109/files/c334ba81..1c7a4eb1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/109/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/109/webrev.00-01 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/109/head:pull/109 PR: https://git.openjdk.java.net/jfx/pull/109 From jvos at openjdk.java.net Wed Feb 12 09:41:51 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 12 Feb 2020 09:41:51 GMT Subject: [Rev 01] RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Tue, 11 Feb 2020 22:31:49 GMT, Alexander Matveev wrote: >> As for the ConnectionHolder: the URIConnectionHolder will be used. This indeed will by default return false for `isSeekable` hence that functionality will now not be possible using the "resource" protocol. > > Does "resource" protocol allows random access? If yes, we should update isSeekable() to return true for resource protocol. seek() should also be updated. I think same should work as for "if ((urlConnection instanceof JarURLConnection) || isJRT())" > Does "resource" protocol allows random access? If yes, we should update isSeekable() to return true for resource protocol. seek() should also be updated. I think same should work as for "if ((urlConnection instanceof JarURLConnection) || isJRT())" Good suggestion, committed. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From jvos at openjdk.java.net Wed Feb 12 10:42:03 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 12 Feb 2020 10:42:03 GMT Subject: [Rev 02] RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: > * add support for the "resource" protocol (which is used in the GraalVM URLs pointing to statically bundled resources) > * avoid duplicate symbols with different gst plugins > * statically register gst plugins The pull request has been updated with 1 additional commit. ------------- Added commits: - d95cf4cd: Only apply JavaFX specific test in case GSTREAMER_LITE is defined Changes: - all: https://git.openjdk.java.net/jfx/pull/109/files - new: https://git.openjdk.java.net/jfx/pull/109/files/1c7a4eb1..d95cf4cd Webrevs: - full: https://webrevs.openjdk.java.net/jfx/109/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/109/webrev.01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/109/head:pull/109 PR: https://git.openjdk.java.net/jfx/pull/109 From fastegal at openjdk.java.net Wed Feb 12 11:13:16 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 12 Feb 2020 11:13:16 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> References: <7-LAewdADbVe96YaZrwt4YZjJTQmeaRLirZkh4V1QOs=.44dc0b69-d9a2-4601-820f-a512bb3aff85@github.com> <1so3r9wM_YpErTvSlRf6yJ9-J4AH6nBkjoKHO7hTBJU=.fd05dd0c-82e1-491f-9071-4918d70c05c8@github.com> Message-ID: On Fri, 7 Feb 2020 18:04:35 GMT, Kevin Rushforth wrote: >> This is a WIP PR. Requesting for comments. >> >> I could not replicate the test given at https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I nevertheless let my try to replicate the @Test things in here. >> >> The fix is just a wild guess without really understanding the side effects of `.addListener`. > > modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 168: > >> 167: // Ensure that the last character to get is within the bounds of the txt string >> 168: if (end >= start + length) end = length-1; >> 169: // In case the start is after the whole txt, nothing valid is selected. Thus, return the default. > > First, I think the existing test is simply wrong: Why should the `start` value matter when checking whether the `end` value needs to be clamped -- it's an `end` point not a number of characters. I think the entire problem might be the fact that it is comparing against `start + length`. Second, the value to be clamped to was correct before your change. The `substring` method to which `end` is passed is documented as subtracting 1. > > I think the test should be something like: > > if (end > length) end = length; on second thought: correct clamping or not, the start/end indices of selection are invalid whenever text was removed/added at an index before the selection - they are in coordinates of the _old_ text, not the new. If they point to an index > new textLength, incorrect clamping will throw. If they are both < new textLength, it'll fire an intermediate changeEvent with incorrect selection, the total sequence beining oldSelectedText -> incorrectly-shifted-selectedText incorrectly-shifted-selectedText -> empty The correct change notification would be, because at the end of the text change, the selection is cleared, oldSelectedText -> empty To me, it looks like using a binding here is not the best of options. ------------- PR: https://git.openjdk.java.net/jfx/pull/73 From fastegal at swingempire.de Wed Feb 12 11:34:00 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 12 Feb 2020 12:34:00 +0100 Subject: TableView with many columns poor ui performance In-Reply-To: <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> References: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> Message-ID: <20200212123400.Horde.4R8XNUQWI7QKiCl9Ix7w0Q7@webmail.df.eu> Zitat von Danny Gonzalez : > Hi Ed, > > I have submitted a pull request and the branch is here: > https://github.com/screamingfrog/jfx/tree/listeners_optimisation > > hmm .. the change seems to be breaking spec of add/remove listeners "If the same listener is added more than once, then it will be notified more than once". or what am I missing? From danny.gonzalez at screamingfrog.co.uk Wed Feb 12 12:03:55 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Wed, 12 Feb 2020 12:03:55 +0000 Subject: TableView with many columns poor ui performance In-Reply-To: <20200212123400.Horde.4R8XNUQWI7QKiCl9Ix7w0Q7@webmail.df.eu> References: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> <20200212123400.Horde.4R8XNUQWI7QKiCl9Ix7w0Q7@webmail.df.eu> Message-ID: Hi Jeanette, True, I hadn't read that spec in ObservableValueBase. Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. I would need to store a registration count for each listener to satisfy this requirement. On 12 Feb 2020, at 11:34, Jeanette Winzenburg > wrote: Zitat von Danny Gonzalez >: Hi Ed, I have submitted a pull request and the branch is here: https://github.com/screamingfrog/jfx/tree/listeners_optimisation hmm .. the change seems to be breaking spec of add/remove listeners "If the same listener is added more than once, then it will be notified more than once". or what am I missing? From kcr at openjdk.java.net Wed Feb 12 16:56:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Feb 2020 16:56:32 GMT Subject: RFR: WIP: 8230231: font-family not updated in HTMLEditor In-Reply-To: <807NKhSRXjlLn18IXMMGrlk72xPhRDvky1Q5t6ctc28=.ee2a0009-ba40-4232-b9ba-0c0fc9e81c46@github.com> References: <5sc2TcVxXD92jtPsDF4L5BvUSDrPDI-_Uwv_DRdonDo=.6ad0a745-e683-4ade-8080-644718a47fca@github.com> <807NKhSRXjlLn18IXMMGrlk72xPhRDvky1Q5t6ctc28=.ee2a0009-ba40-4232-b9ba-0c0fc9e81c46@github.com> Message-ID: On Tue, 5 Nov 2019 11:08:27 GMT, Arun Joseph wrote: >> This bug still exists when the caret is placed on a text with the default font (""). > > Applying this patch creates a new bug: Selecting text with multiple fonts in HTMLEditor sets the text to a single font. > > Steps to reproduce: > Run the same sample program. > Type "Hello world". > Set "Hello" to FontA and "world" to FontB > Select all (or right to left) using keyboard > > Expectation: "Hello world" is selected > Observation: "Hello world" is selected and font changed to FontA @Maxoudela are you interesting in pursuing this? ------------- PR: https://git.openjdk.java.net/jfx/pull/12 From thiago.sayao at clamed.com.br Wed Feb 12 17:05:01 2020 From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao) Date: Wed, 12 Feb 2020 17:05:01 +0000 Subject: No screen coordinates for DRAG_DONE events In-Reply-To: References: Message-ID: Dirk, Which platform are you using? (Windows, Linux, Mac) (Will take a look if Linux) Thanks. ________________________________ De: openjfx-dev em nome de Dirk Lemmermann Enviado: segunda-feira, 10 de fevereiro de 2020 13:21 Para: OpenJFX Assunto: No screen coordinates for DRAG_DONE events Need some help: I noticed that the DRAG_DONE event does not tell me the location of the event. I am working on a docking framework and the fact that I am receiving a DRAG_DONE event but not a DRAG_DROPPED tells me that the user dragged a docking item out of the docking container. If that is the case I would like to show a new stage at the event location but it turns out that the x and y fields are always set to 0 / 0 on the event object. Is this intentional or a bug? Dirk From shadzic at openjdk.java.net Wed Feb 12 20:34:39 2020 From: shadzic at openjdk.java.net (Hadzic Samir) Date: Wed, 12 Feb 2020 20:34:39 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 16:54:08 GMT, Kevin Rushforth wrote: >> Applying this patch creates a new bug: Selecting text with multiple fonts in HTMLEditor sets the text to a single font. >> >> Steps to reproduce: >> Run the same sample program. >> Type "Hello world". >> Set "Hello" to FontA and "world" to FontB >> Select all (or right to left) using keyboard >> >> Expectation: "Hello world" is selected >> Observation: "Hello world" is selected and font changed to FontA > > @Maxoudela are you interesting in pursuing this? 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 ------------- PR: https://git.openjdk.java.net/jfx/pull/12 From kcr at openjdk.java.net Wed Feb 12 20:37:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Feb 2020 20:37:25 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:32:15 GMT, Hadzic Samir wrote: >> @Maxoudela are you interesting in pursuing this? > > 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. ------------- PR: https://git.openjdk.java.net/jfx/pull/12 From guru.hb at oracle.com Thu Feb 13 03:47:52 2020 From: guru.hb at oracle.com (Guru) Date: Thu, 13 Feb 2020 09:17:52 +0530 Subject: JavaFX 13 Webview hangs In-Reply-To: <1705905098.1280377.1581434485832@ichabod.co-bxl> References: <1705905098.1280377.1581434485832@ichabod.co-bxl> Message-ID: Hi Lior, Could you share a simplified test application with the html content or web content which leads to ?webview frame comes up empty? so that I can test and debug at my end. Thanks, Guru > On 11-Feb-2020, at 8:51 PM, Lior Yaffe wrote: > > Test results: > OpenJFX 11 never hangs > OpenJFX 13 always hangs > OpenJFX 15ea the webview frame comes up empty but the runtime never hangs > > The Java version has no effect. > The hang seems to occur in native code since there is no way to take a thread dump using jstack and the only possible action is to kill the process. > Is there any other logging or diagnostic you can suggest? > > > February 10, 2020 7:24:54 PM CET Kevin Rushforth wrote: Can you also try JDK 11 with OpenJFX 13? I suspect it will not make a difference (i.e., it will still hang), but it would be good to confirm. And even more interesting will be the results of JavaFX 15-ea. > > Thanks. > > -- Kevin > > On 2/10/2020 10:17 AM, Lior Yaffe wrote: > > The problem does not reproduce when using JavaFX 11 regardless of the version of Java being used. > I will try with Java 15ea > > On Mon, Feb 10, 2020, 17:01 Kevin Rushforth wrote: > > And one last thing to try: can you run it with the JavaFX 15-ea+1 build > and see if that makes a difference? > > -- Kevin > > On 2/10/2020 6:59 AM, Kevin Rushforth wrote: >> Seems I missed your comment about it being hung to the point you can't >> run jstack. >> >> If you are using JDK 12 or later, you might try with JDK 11 and see if >> that makes a difference. It will help narrow it down to a change in >> the JDK versus a change in JavaFX (although I suspect it's a change in >> JavaFX). >> >> -- Kevin >> >> On 2/10/2020 6:40 AM, Kevin Rushforth wrote: >>> A thread stack dump using "jstack" might be helpful. >>> >>> Also, what version of the JDK are you running? >>> >>> -- Kevin >>> >>> >>> On 2/9/2020 4:07 AM, Lior Yaffe wrote: >>>> My application is a Java application running a Javascript/Html website >>>> inside a JavaFX WebView. It was working stable for several years with >>>> various versions of Java and JavaFX. >>>> As far as I can tell it is following best coding practices such as >>>> running >>>> all UI code in the JavaFX thread and as such. >>>> >>>> Since upgrading to JavaFX 13 my application hangs sporadically. When it >>>> happens the website running inside the webview becomes unresponsive and >>>> displays an hourglass icon. >>>> When the app hangs I cannot take a thread dump using jstack or close >>>> the >>>> application. I have to kill it. >>>> >>>> The problem is reproduced on multiple Windows workstations. It was >>>> never >>>> reported or reproduced on Linux or Mac so there is a chance it is >>>> Windows >>>> specific. >>>> When the app hangs the CPU is ideal so this is not a busy loop. >>>> Which diagnostic information can I obtain to better understand this >>>> problem? >>> >> From B.Peter at gsi.de Thu Feb 13 10:54:22 2020 From: B.Peter at gsi.de (Peter, Benjamin) Date: Thu, 13 Feb 2020 10:54:22 +0000 Subject: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin Message-ID: <2580fc95e8a24c219752b703ddbae0d6@gsi.de> Dear FX devs, please accept my minimal reproduction example for JDK-8217953 "NullPointerException when TableCellSkin gets disposed twice" In the report it says there was no luck reproducing it - I hope this could now be beneficial for a solution to this problem. I could repeatedly trigger the problem after 100 of my update cycles - which interestingly corresponds to the following constant which can be found along the stacktrace. javafx.scene.control.skin.TableRowSkinBase.DEFAULT_FULL_REFRESH_COUNTER = 100 Surely - could be coincidence - but also a hot lead. I can also confirm it is still reproducable in jfx 11 and 13. It is available as public domain gist on github: https://gist.github.com/dedeibel/d02fb51c59942bebcb6e418f23d310fb Thank you for your work and cooperation, with kind regards, Benjamin Peter From lior.yaffe at jelurida.com Thu Feb 13 11:43:25 2020 From: lior.yaffe at jelurida.com (Lior Yaffe) Date: Thu, 13 Feb 2020 12:43:25 +0100 (CET) Subject: JavaFX 13 Webview hangs In-Reply-To: References: <1705905098.1280377.1581434485832@ichabod.co-bxl> Message-ID: <1299887765.1418689.1581594205540@ichabod.co-bxl> I figured that the problem with OpenJFX 15ea was that the webview moved to state FAILED because I was using Https with a self signed SSL certificate for the webview URL. This worked fine in previous versions but fails in 15ea - so maybe a bug if its not intentional. I couldn't find a nice way to print the exception from the code so I'm adding a screen capture from the debugger. If you can show me how to access the exception from inside a StateListener I can print the stack trace nicely for you. So I switched to Http and was able to run webview and so far it seems that 15ea indeed solves my original lockup problem. > ---------------------------------------- > From: Guru > Sent: Thu Feb 13 04:47:52 CET 2020 > To: Lior Yaffe > Cc: > Subject: Re: JavaFX 13 Webview hangs > > > Hi Lior, > > Could you share a simplified test application with the html content or web content which leads to ?webview frame comes up empty? so that I can test and debug at my end. > > Thanks, > Guru > > > On 11-Feb-2020, at 8:51 PM, Lior Yaffe wrote: > > > > Test results: > > OpenJFX 11 never hangs > > OpenJFX 13 always hangs > > OpenJFX 15ea the webview frame comes up empty but the runtime never hangs > > > > The Java version has no effect. > > The hang seems to occur in native code since there is no way to take a thread dump using jstack and the only possible action is to kill the process. > > Is there any other logging or diagnostic you can suggest? > > > > > > February 10, 2020 7:24:54 PM CET Kevin Rushforth wrote: Can you also try JDK 11 with OpenJFX 13? I suspect it will not make a difference (i.e., it will still hang), but it would be good to confirm. And even more interesting will be the results of JavaFX 15-ea. > > > > Thanks. > > > > -- Kevin > > > > On 2/10/2020 10:17 AM, Lior Yaffe wrote: > > > > The problem does not reproduce when using JavaFX 11 regardless of the version of Java being used. > > I will try with Java 15ea > > > > On Mon, Feb 10, 2020, 17:01 Kevin Rushforth wrote: > > > > And one last thing to try: can you run it with the JavaFX 15-ea+1 build > > and see if that makes a difference? > > > > -- Kevin > > > > On 2/10/2020 6:59 AM, Kevin Rushforth wrote: > >> Seems I missed your comment about it being hung to the point you can't > >> run jstack. > >> > >> If you are using JDK 12 or later, you might try with JDK 11 and see if > >> that makes a difference. It will help narrow it down to a change in > >> the JDK versus a change in JavaFX (although I suspect it's a change in > >> JavaFX). > >> > >> -- Kevin > >> > >> On 2/10/2020 6:40 AM, Kevin Rushforth wrote: > >>> A thread stack dump using "jstack" might be helpful. > >>> > >>> Also, what version of the JDK are you running? > >>> > >>> -- Kevin > >>> > >>> > >>> On 2/9/2020 4:07 AM, Lior Yaffe wrote: > >>>> My application is a Java application running a Javascript/Html website > >>>> inside a JavaFX WebView. It was working stable for several years with > >>>> various versions of Java and JavaFX. > >>>> As far as I can tell it is following best coding practices such as > >>>> running > >>>> all UI code in the JavaFX thread and as such. > >>>> > >>>> Since upgrading to JavaFX 13 my application hangs sporadically. When it > >>>> happens the website running inside the webview becomes unresponsive and > >>>> displays an hourglass icon. > >>>> When the app hangs I cannot take a thread dump using jstack or close > >>>> the > >>>> application. I have to kill it. > >>>> > >>>> The problem is reproduced on multiple Windows workstations. It was > >>>> never > >>>> reported or reproduced on Linux or Mac so there is a chance it is > >>>> Windows > >>>> specific. > >>>> When the app hangs the CPU is ideal so this is not a busy loop. > >>>> Which diagnostic information can I obtain to better understand this > >>>> problem? > >>> > >> > From B.Peter at gsi.de Thu Feb 13 14:02:04 2020 From: B.Peter at gsi.de (Peter, Benjamin) Date: Thu, 13 Feb 2020 14:02:04 +0000 Subject: WG: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin In-Reply-To: <2580fc95e8a24c219752b703ddbae0d6@gsi.de> References: <2580fc95e8a24c219752b703ddbae0d6@gsi.de> Message-ID: <7b9f3dacaa904c3c8a645ba013e8b30a@gsi.de> Hello devs, same example but with the file as attachment and without header. regards, Ben -----Urspr?ngliche Nachricht----- Von: openjfx-dev Im Auftrag von Peter, Benjamin Gesendet: Donnerstag, 13. Februar 2020 11:54 An: openjfx-dev at openjdk.java.net Betreff: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin Dear FX devs, please accept my minimal reproduction example for JDK-8217953 "NullPointerException when TableCellSkin gets disposed twice" In the report it says there was no luck reproducing it - I hope this could now be beneficial for a solution to this problem. I could repeatedly trigger the problem after 100 of my update cycles - which interestingly corresponds to the following constant which can be found along the stacktrace. javafx.scene.control.skin.TableRowSkinBase.DEFAULT_FULL_REFRESH_COUNTER = 100 Surely - could be coincidence - but also a hot lead. I can also confirm it is still reproducable in jfx 11 and 13. It is available as public domain gist on github: https://gist.github.com/dedeibel/d02fb51c59942bebcb6e418f23d310fb Thank you for your work and cooperation, with kind regards, Benjamin Peter From kevin.rushforth at oracle.com Thu Feb 13 14:45:54 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Feb 2020 06:45:54 -0800 Subject: WG: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin In-Reply-To: <7b9f3dacaa904c3c8a645ba013e8b30a@gsi.de> References: <2580fc95e8a24c219752b703ddbae0d6@gsi.de> <7b9f3dacaa904c3c8a645ba013e8b30a@gsi.de> Message-ID: <77efb51b-72aa-207e-4efa-00411906f1a6@oracle.com> Unfortunately, attachments don't make it through the openjdk mailing list filters. Can you just paste it inline? Thanks. -- Kevin On 2/13/2020 6:02 AM, Peter, Benjamin wrote: > Hello devs, > > same example but with the file as attachment and without header. > > > regards, > > Ben > > -----Urspr?ngliche Nachricht----- > Von: openjfx-dev Im Auftrag von Peter, Benjamin > Gesendet: Donnerstag, 13. Februar 2020 11:54 > An: openjfx-dev at openjdk.java.net > Betreff: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin > > Dear FX devs, > > please accept my minimal reproduction example for JDK-8217953 "NullPointerException when TableCellSkin gets disposed twice" > > In the report it says there was no luck reproducing it - I hope this could now be beneficial for a solution to this problem. > > I could repeatedly trigger the problem after 100 of my update cycles - which interestingly corresponds to the following constant which can be found along the stacktrace. > javafx.scene.control.skin.TableRowSkinBase.DEFAULT_FULL_REFRESH_COUNTER = 100 Surely - could be coincidence - but also a hot lead. > > > I can also confirm it is still reproducable in jfx 11 and 13. > > It is available as public domain gist on github: > > https://gist.github.com/dedeibel/d02fb51c59942bebcb6e418f23d310fb > > > > Thank you for your work and cooperation, > > with kind regards, > > > Benjamin Peter From kcr at openjdk.java.net Thu Feb 13 23:25:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Feb 2020 23:25:31 GMT Subject: RFR: 8196586: Remove use of deprecated finalize methods from javafx property objects Message-ID: This patch removes the `finalize` methods from the `Property` classes in the `javafx.base` module. The `{Boolean,Double,Float,Int,Long}Property` classes each have a pair of methods -- `asObject` and `xxxxxProperty` -- that create a `Property` object from a primitive `XxxxxProperty` object and vice versa. Each of the methods bidirectionally binds the original property object to the created property object. All of the bidirectional bindings in question use `WeakReference`s to refer to the pair of objects being bound to each other, so that they won't cause a memory leak. The `finalize` methods were added in an attempt to cleanup the bidirectional bindings when the created object goes away. I say attempt, because it is entirely ineffective in doing so. The logic that removes the binding creates a new one from the same pair of objects, but fails to match the original binding because the referent to the created property object has been garbage collected before the `finalize` method is called; the `WeakReference` in the binding is cleared and no longer matches. Fortunately, the only impact of this ineffective logic is that it can delay the removal of the binding (which is a small object that just contains the two weak references) from the original property object until it (the original property) is either garbage collected or modified (the binding logic already looks for a referent that has been GCed and removes the binding). Given that the `finalize` methods don't do anything useful today, and that there is no memory leak in the first place, the proposed fix is to just remove the `finalize` methods entirely with no replacement needed. There will be no changes in behavior as a result of this. Existing tests of the methods in question are sufficient to ensure no functional regressions, although there is no existing test for leaks, so I created new tests to verify that there is no leak. Since there is no existing leak, those tests will pass both with and without this fix. ------------- Commits: - e90abed6: 8196586: Remove use of deprecated finalize methods from javafx property objects Changes: https://git.openjdk.java.net/jfx/pull/113/files Webrev: https://webrevs.openjdk.java.net/jfx/113/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196586 Stats: 433 lines in 6 files changed: 278 ins; 155 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/113/head:pull/113 PR: https://git.openjdk.java.net/jfx/pull/113 From kcr at openjdk.java.net Thu Feb 13 23:25:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Feb 2020 23:25:31 GMT Subject: RFR: 8196586: Remove use of deprecated finalize methods from javafx property objects In-Reply-To: References: Message-ID: On Thu, 13 Feb 2020 23:10:28 GMT, Kevin Rushforth wrote: > This patch removes the `finalize` methods from the `Property` classes in the `javafx.base` module. > > The `{Boolean,Double,Float,Int,Long}Property` classes each have a pair of methods -- `asObject` and `xxxxxProperty` -- that create a `Property` object from a primitive `XxxxxProperty` object and vice versa. Each of the methods bidirectionally binds the original property object to the created property object. All of the bidirectional bindings in question use `WeakReference`s to refer to the pair of objects being bound to each other, so that they won't cause a memory leak. > > The `finalize` methods were added in an attempt to cleanup the bidirectional bindings when the created object goes away. I say attempt, because it is entirely ineffective in doing so. The logic that removes the binding creates a new one from the same pair of objects, but fails to match the original binding because the referent to the created property object has been garbage collected before the `finalize` method is called; the `WeakReference` in the binding is cleared and no longer matches. Fortunately, the only impact of this ineffective logic is that it can delay the removal of the binding (which is a small object that just contains the two weak references) from the original property object until it (the original property) is either garbage collected or modified (the binding logic already looks for a referent that has been GCed and removes the binding). > > Given that the `finalize` methods don't do anything useful today, and that there is no memory leak in the first place, the proposed fix is to just remove the `finalize` methods entirely with no replacement needed. There will be no changes in behavior as a result of this. > > Existing tests of the methods in question are sufficient to ensure no functional regressions, although there is no existing test for leaks, so I created new tests to verify that there is no leak. Since there is no existing leak, those tests will pass both with and without this fix. @arapte I request you to be one of the reviewers of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/113 From kcr at openjdk.java.net Thu Feb 13 23:52:22 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Feb 2020 23:52:22 GMT Subject: [Rev 02] RFR: 8238755: allow to create static lib for javafx.media on linux In-Reply-To: References: Message-ID: On Wed, 12 Feb 2020 07:49:40 GMT, Johan Vos wrote: >> "ipod-library" is only supported if IOSPlatform is loaded, but it will not be loaded on all platform due to check for HostUtils.isIOS(). Do you know what happens if user tries "resource" protocol on not supported platform? and same for some "unknown" protocol. If error message makes sense we can probably keep it as is. > > That is not 100% correct. ipod-library is supported in case `System.getProperty("os.name")` starts with "ios" (which we do in GraalVM and OpenJDK/mobile) (which does not guarantee at all that we're on ios). > > We can encapsulate the "resource" protocol using the same approach (with a System.getProperty check). In that case, it might make sense to use a wide property that indicates we're running on a statically linked image. That would then be useful for all Java code, not just javafx.media. But that is a bigger change, so I'd like @kevinrushforth opinion on this. It might make sense to add an `isStaticallyLinked` method to [PlatformUtil](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java), which is where similar platform methods are kept. ------------- PR: https://git.openjdk.java.net/jfx/pull/109 From kcr at openjdk.java.net Thu Feb 13 23:58:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Feb 2020 23:58:52 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> Message-ID: On Mon, 3 Feb 2020 17:26:32 GMT, Thiago Milczarek Sayao wrote: >> It's ready for an initial look. >> >> If anyone has issues with Linux, I will fix it. > > **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; > * 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 > > > * 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. This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From B.Peter at gsi.de Fri Feb 14 07:22:11 2020 From: B.Peter at gsi.de (Peter, Benjamin) Date: Fri, 14 Feb 2020 07:22:11 +0000 Subject: AW: WG: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin In-Reply-To: <77efb51b-72aa-207e-4efa-00411906f1a6@oracle.com> References: <2580fc95e8a24c219752b703ddbae0d6@gsi.de> <7b9f3dacaa904c3c8a645ba013e8b30a@gsi.de> <77efb51b-72aa-207e-4efa-00411906f1a6@oracle.com> Message-ID: <8cc52d61e1394cfd80a40bdec3df1503@gsi.de> Hello Kevin, sure, will do :-). ==== BEGIN ==== import java.util.List; import java.util.concurrent.atomic.AtomicInteger; import javafx.application.Application; import javafx.application.Platform; import javafx.beans.property.SimpleStringProperty; import javafx.beans.property.StringProperty; import javafx.collections.FXCollections; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.control.cell.PropertyValueFactory; import javafx.stage.Stage; public class TableViewCellDisposeProblem extends Application { public static class Person { private StringProperty firstName; public void setFirstName(String value) { firstNameProperty().set(value); } public String getFirstName() { return firstNameProperty().get(); } public StringProperty firstNameProperty() { if (firstName == null) firstName = new SimpleStringProperty(this, "firstName"); return firstName; } private StringProperty lastName; public void setLastName(String value) { lastNameProperty().set(value); } public String getLastName() { return lastNameProperty().get(); } public StringProperty lastNameProperty() { if (lastName == null) lastName = new SimpleStringProperty(this, "lastName"); return lastName; } public Person(String firstName, String lastName) { setFirstName(firstName); setLastName(lastName); } } private ObservableList teamMembers = FXCollections.observableArrayList( // List.of( // new Person("William", "Reed"), // new Person("James", "Michaelson"), // new Person("Julius", "Dean") // )); TableView table = new TableView<>(); private AtomicInteger updateCount = new AtomicInteger(); public void updateLoop() { Thread thread = new Thread(() -> { while (true) { System.out.println("updating i = "+ updateCount.incrementAndGet()); Platform.runLater(() -> { // Trigger column visibility - Without this, no exception observed! TableColumn secondColumn = table.getColumns().get(1); secondColumn.setVisible(!secondColumn.isVisible()); }); try { Thread.sleep(100); } catch (InterruptedException e) { System.out.println("interrupted"); break; } } }); thread.setDaemon(true); thread.start(); } @Override public void start(Stage primaryStage) throws Exception { primaryStage.setScene(new Scene(table, 800, 600)); table.setItems(teamMembers); TableColumn firstNameCol = new TableColumn<>("First Name"); firstNameCol.setCellValueFactory(new PropertyValueFactory<>("firstName")); TableColumn lastNameCol = new TableColumn<>("Last Name"); lastNameCol.setCellValueFactory(new PropertyValueFactory<>("lastName")); table.getColumns().setAll(firstNameCol, lastNameCol); primaryStage.show(); updateLoop(); } public static void main(String[] args) { Application.launch(args); } } /* * After 100 updates following Exception occurs (of 5 test runs, sleep time varied): * * [WARNING] java.lang.NullPointerException at javafx.scene.control.skin.TableCellSkin.tableColumnProperty (TableCellSkin.java:97) at javafx.scene.control.skin.TableCellSkinBase.getTableColumn (TableCellSkinBase.java:123) at javafx.scene.control.skin.TableCellSkinBase.dispose (TableCellSkinBase.java:136) at javafx.scene.control.skin.TableCellSkin.dispose (TableCellSkin.java:88) at javafx.scene.control.Control$2.invalidated (Control.java:267) at javafx.beans.property.ObjectPropertyBase.markInvalid (ObjectPropertyBase.java:112) at javafx.beans.property.ObjectPropertyBase.set (ObjectPropertyBase.java:147) at javafx.css.StyleableObjectProperty.set (StyleableObjectProperty.java:82) at javafx.scene.control.Control$2.set (Control.java:250) at javafx.scene.control.Control$2.set (Control.java:233) at javafx.scene.control.Control.setSkin (Control.java:230) at javafx.scene.control.skin.TableRowSkinBase.recreateCells (TableRowSkinBase.java:715) at javafx.scene.control.skin.TableRowSkinBase.updateCells (TableRowSkinBase.java:505) at javafx.scene.control.skin.TableRowSkinBase.checkState (TableRowSkinBase.java:649) at javafx.scene.control.skin.TableRowSkinBase.computePrefHeight (TableRowSkinBase.java:588) at javafx.scene.control.Control.computePrefHeight (Control.java:570) at javafx.scene.Parent.prefHeight (Parent.java:1039) at javafx.scene.layout.Region.prefHeight (Region.java:1559) at javafx.scene.control.skin.VirtualFlow.resizeCell (VirtualFlow.java:1923) at javafx.scene.control.skin.VirtualFlow.addLeadingCells (VirtualFlow.java:2030) at javafx.scene.control.skin.VirtualFlow.layoutChildren (VirtualFlow.java:1250) at javafx.scene.Parent.layout (Parent.java:1206) at javafx.scene.Parent.layout (Parent.java:1213) at javafx.scene.Scene.doLayoutPass (Scene.java:576) at javafx.scene.Scene$ScenePulseListener.pulse (Scene.java:2482) at com.sun.javafx.tk.Toolkit.lambda$runPulse$2 (Toolkit.java:412) at java.security.AccessController.doPrivileged (Native Method) at com.sun.javafx.tk.Toolkit.runPulse (Toolkit.java:411) at com.sun.javafx.tk.Toolkit.firePulse (Toolkit.java:438) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:563) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:543) at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue (QuantumToolkit.java:536) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11 (QuantumToolkit.java:342) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run (InvokeLaterDispatcher.java:96) at com.sun.glass.ui.gtk.GtkApplication._runLoop (Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11 (GtkApplication.java:277) at java.lang.Thread.run (Thread.java:834) updating [WARNING] java.lang.NullPointerException at javafx.scene.control.skin.CellSkinBase$StyleableProperties$1.isSettable (CellSkinBase.java:166) at javafx.scene.control.skin.CellSkinBase$StyleableProperties$1.isSettable (CellSkinBase.java:161) at javafx.scene.CssStyleHelper.transitionToState (CssStyleHelper.java:666) at javafx.scene.Node.doProcessCSS (Node.java:9658) at javafx.scene.Node$1.doProcessCSS (Node.java:471) at com.sun.javafx.scene.NodeHelper.processCSSImpl (NodeHelper.java:192) at com.sun.javafx.scene.ParentHelper.superProcessCSSImpl (ParentHelper.java:93) at com.sun.javafx.scene.ParentHelper.superProcessCSS (ParentHelper.java:63) at javafx.scene.Parent.doProcessCSS (Parent.java:1368) at javafx.scene.Parent$1.doProcessCSS (Parent.java:125) at com.sun.javafx.scene.ParentHelper.processCSSImpl (ParentHelper.java:98) at com.sun.javafx.scene.control.ControlHelper.superProcessCSSImpl (ControlHelper.java:63) at com.sun.javafx.scene.control.ControlHelper.superProcessCSS (ControlHelper.java:55) at javafx.scene.control.Control.doProcessCSS (Control.java:886) at javafx.scene.control.Control$1.doProcessCSS (Control.java:89) at com.sun.javafx.scene.control.ControlHelper.processCSSImpl (ControlHelper.java:67) at com.sun.javafx.scene.NodeHelper.processCSS (NodeHelper.java:145) at javafx.scene.Node.processCSS (Node.java:9540) at javafx.scene.Node.processCSS (Node.java:9533) at javafx.scene.Node.processCSS (Node.java:9533) at javafx.scene.Node.processCSS (Node.java:9533) at javafx.scene.Node.processCSS (Node.java:9533) at javafx.scene.Node.processCSS (Node.java:9533) at javafx.scene.Scene.doCSSPass (Scene.java:569) at javafx.scene.Scene$ScenePulseListener.pulse (Scene.java:2477) at com.sun.javafx.tk.Toolkit.lambda$runPulse$2 (Toolkit.java:412) at java.security.AccessController.doPrivileged (Native Method) at com.sun.javafx.tk.Toolkit.runPulse (Toolkit.java:411) at com.sun.javafx.tk.Toolkit.firePulse (Toolkit.java:438) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:563) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:543) at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue (QuantumToolkit.java:536) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11 (QuantumToolkit.java:342) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run (InvokeLaterDispatcher.java:96) at com.sun.glass.ui.gtk.GtkApplication._runLoop (Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11 (GtkApplication.java:277) at java.lang.Thread.run (Thread.java:834) updating */ ===== END ==== best wishes, Ben > -----Urspr?ngliche Nachricht----- > Von: Kevin Rushforth > Gesendet: Donnerstag, 13. Februar 2020 15:46 > An: Peter, Benjamin ; openjfx-dev at openjdk.java.net > Betreff: Re: WG: Minimal reproduction example for JDK-8217953 NPE in > TableCellSkin > > Unfortunately, attachments don't make it through the openjdk mailing list filters. > Can you just paste it inline? > > Thanks. > > -- Kevin > > > On 2/13/2020 6:02 AM, Peter, Benjamin wrote: > > Hello devs, > > > > same example but with the file as attachment and without header. > > > > > > regards, > > > > Ben > > > > -----Urspr?ngliche Nachricht----- > > Von: openjfx-dev Im Auftrag von > > Peter, Benjamin > > Gesendet: Donnerstag, 13. Februar 2020 11:54 > > An: openjfx-dev at openjdk.java.net > > Betreff: Minimal reproduction example for JDK-8217953 NPE in > > TableCellSkin > > > > Dear FX devs, > > > > please accept my minimal reproduction example for JDK-8217953 > "NullPointerException when TableCellSkin gets disposed twice" > > > > In the report it says there was no luck reproducing it - I hope this could now be > beneficial for a solution to this problem. > > > > I could repeatedly trigger the problem after 100 of my update cycles - which > interestingly corresponds to the following constant which can be found along the > stacktrace. > > javafx.scene.control.skin.TableRowSkinBase.DEFAULT_FULL_REFRESH_COUNTER > = 100 Surely - could be coincidence - but also a hot lead. > > > > > > I can also confirm it is still reproducable in jfx 11 and 13. > > > > It is available as public domain gist on github: > > > > https://gist.github.com/dedeibel/d02fb51c59942bebcb6e418f23d310fb > > > > > > > > Thank you for your work and cooperation, > > > > with kind regards, > > > > > > Benjamin Peter From aghaisas at openjdk.java.net Fri Feb 14 09:18:33 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 14 Feb 2020 09:18:33 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation Message-ID: Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) ------------- Commits: - 5f8a925b: Fix for JDK-8235480 Changes: https://git.openjdk.java.net/jfx/pull/114/files Webrev: https://webrevs.openjdk.java.net/jfx/114/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235480 Stats: 675 lines in 2 files changed: 410 ins; 10 del; 255 mod Patch: https://git.openjdk.java.net/jfx/pull/114.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114 PR: https://git.openjdk.java.net/jfx/pull/114 From fastegal at openjdk.java.net Fri Feb 14 11:28:46 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 14 Feb 2020 11:28:46 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 14 Feb 2020 09:09:13 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. > > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java line 152: > 151: > 152: new KeyMapping(LEFT, (rtl? e -> selectRightCell() : e -> selectLeftCell())), > 153: new KeyMapping(KP_LEFT, (rtl? e -> selectRightCell() : e -> selectLeftCell())), ... so a keyMapping based on the initial condition will fail after a change of orientation, or what am I missing? (aside: I really hate this review ui, can't seem to make it take several comments ... argghh) ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From fastegal at openjdk.java.net Fri Feb 14 11:24:10 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 14 Feb 2020 11:24:10 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 14 Feb 2020 09:09:13 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. > > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java line 139: > 138: boolean rtl = isRTL(); > 139: > 140: KeyMapping enterKeyActivateMapping, escapeKeyCancelEditMapping; node orientation can change during the lifetime of a node ... ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From kevin.rushforth at oracle.com Fri Feb 14 13:17:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Feb 2020 05:17:49 -0800 Subject: AW: WG: Minimal reproduction example for JDK-8217953 NPE in TableCellSkin In-Reply-To: <8cc52d61e1394cfd80a40bdec3df1503@gsi.de> References: <2580fc95e8a24c219752b703ddbae0d6@gsi.de> <7b9f3dacaa904c3c8a645ba013e8b30a@gsi.de> <77efb51b-72aa-207e-4efa-00411906f1a6@oracle.com> <8cc52d61e1394cfd80a40bdec3df1503@gsi.de> Message-ID: Hi Ben, Thank you. That does indeed reproduce the problem for me on the 100th iteration. I've attached your test program to the bug report. -- Kevin On 2/13/2020 11:22 PM, Peter, Benjamin wrote: > Hello Kevin, > > sure, will do :-). > > > ==== BEGIN ==== > > import java.util.List; > import java.util.concurrent.atomic.AtomicInteger; > > import javafx.application.Application; > import javafx.application.Platform; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.control.cell.PropertyValueFactory; > import javafx.stage.Stage; > > public class TableViewCellDisposeProblem extends Application { > > public static class Person { > private StringProperty firstName; > > public void setFirstName(String value) { > firstNameProperty().set(value); > } > > public String getFirstName() { > return firstNameProperty().get(); > } > > public StringProperty firstNameProperty() { > if (firstName == null) > firstName = new SimpleStringProperty(this, "firstName"); > return firstName; > } > > private StringProperty lastName; > > public void setLastName(String value) { > lastNameProperty().set(value); > } > > public String getLastName() { > return lastNameProperty().get(); > } > > public StringProperty lastNameProperty() { > if (lastName == null) > lastName = new SimpleStringProperty(this, "lastName"); > return lastName; > } > > public Person(String firstName, String lastName) { > setFirstName(firstName); > setLastName(lastName); > } > } > > private ObservableList teamMembers = FXCollections.observableArrayList( // > List.of( // > new Person("William", "Reed"), // > new Person("James", "Michaelson"), // > new Person("Julius", "Dean") // > )); > > TableView table = new TableView<>(); > > private AtomicInteger updateCount = new AtomicInteger(); > > public void updateLoop() { > Thread thread = new Thread(() -> { > while (true) { > System.out.println("updating i = "+ updateCount.incrementAndGet()); > Platform.runLater(() -> { > // Trigger column visibility - Without this, no exception observed! > TableColumn secondColumn = table.getColumns().get(1); > secondColumn.setVisible(!secondColumn.isVisible()); > }); > try { > Thread.sleep(100); > } catch (InterruptedException e) { > System.out.println("interrupted"); > break; > } > } > }); > thread.setDaemon(true); > thread.start(); > } > > @Override > public void start(Stage primaryStage) throws Exception { > primaryStage.setScene(new Scene(table, 800, 600)); > table.setItems(teamMembers); > > TableColumn firstNameCol = new TableColumn<>("First Name"); > firstNameCol.setCellValueFactory(new PropertyValueFactory<>("firstName")); > TableColumn lastNameCol = new TableColumn<>("Last Name"); > lastNameCol.setCellValueFactory(new PropertyValueFactory<>("lastName")); > > table.getColumns().setAll(firstNameCol, lastNameCol); > primaryStage.show(); > updateLoop(); > } > > public static void main(String[] args) { > Application.launch(args); > } > } > > /* > * After 100 updates following Exception occurs (of 5 test runs, sleep time varied): > * > * [WARNING] > java.lang.NullPointerException > at javafx.scene.control.skin.TableCellSkin.tableColumnProperty (TableCellSkin.java:97) > at javafx.scene.control.skin.TableCellSkinBase.getTableColumn (TableCellSkinBase.java:123) > at javafx.scene.control.skin.TableCellSkinBase.dispose (TableCellSkinBase.java:136) > at javafx.scene.control.skin.TableCellSkin.dispose (TableCellSkin.java:88) > at javafx.scene.control.Control$2.invalidated (Control.java:267) > at javafx.beans.property.ObjectPropertyBase.markInvalid (ObjectPropertyBase.java:112) > at javafx.beans.property.ObjectPropertyBase.set (ObjectPropertyBase.java:147) > at javafx.css.StyleableObjectProperty.set (StyleableObjectProperty.java:82) > at javafx.scene.control.Control$2.set (Control.java:250) > at javafx.scene.control.Control$2.set (Control.java:233) > at javafx.scene.control.Control.setSkin (Control.java:230) > at javafx.scene.control.skin.TableRowSkinBase.recreateCells (TableRowSkinBase.java:715) > at javafx.scene.control.skin.TableRowSkinBase.updateCells (TableRowSkinBase.java:505) > at javafx.scene.control.skin.TableRowSkinBase.checkState (TableRowSkinBase.java:649) > at javafx.scene.control.skin.TableRowSkinBase.computePrefHeight (TableRowSkinBase.java:588) > at javafx.scene.control.Control.computePrefHeight (Control.java:570) > at javafx.scene.Parent.prefHeight (Parent.java:1039) > at javafx.scene.layout.Region.prefHeight (Region.java:1559) > at javafx.scene.control.skin.VirtualFlow.resizeCell (VirtualFlow.java:1923) > at javafx.scene.control.skin.VirtualFlow.addLeadingCells (VirtualFlow.java:2030) > at javafx.scene.control.skin.VirtualFlow.layoutChildren (VirtualFlow.java:1250) > at javafx.scene.Parent.layout (Parent.java:1206) > at javafx.scene.Parent.layout (Parent.java:1213) > at javafx.scene.Scene.doLayoutPass (Scene.java:576) > at javafx.scene.Scene$ScenePulseListener.pulse (Scene.java:2482) > at com.sun.javafx.tk.Toolkit.lambda$runPulse$2 (Toolkit.java:412) > at java.security.AccessController.doPrivileged (Native Method) > at com.sun.javafx.tk.Toolkit.runPulse (Toolkit.java:411) > at com.sun.javafx.tk.Toolkit.firePulse (Toolkit.java:438) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:563) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:543) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue (QuantumToolkit.java:536) > at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11 (QuantumToolkit.java:342) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run (InvokeLaterDispatcher.java:96) > at com.sun.glass.ui.gtk.GtkApplication._runLoop (Native Method) > at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11 (GtkApplication.java:277) > at java.lang.Thread.run (Thread.java:834) > updating > [WARNING] > java.lang.NullPointerException > at javafx.scene.control.skin.CellSkinBase$StyleableProperties$1.isSettable (CellSkinBase.java:166) > at javafx.scene.control.skin.CellSkinBase$StyleableProperties$1.isSettable (CellSkinBase.java:161) > at javafx.scene.CssStyleHelper.transitionToState (CssStyleHelper.java:666) > at javafx.scene.Node.doProcessCSS (Node.java:9658) > at javafx.scene.Node$1.doProcessCSS (Node.java:471) > at com.sun.javafx.scene.NodeHelper.processCSSImpl (NodeHelper.java:192) > at com.sun.javafx.scene.ParentHelper.superProcessCSSImpl (ParentHelper.java:93) > at com.sun.javafx.scene.ParentHelper.superProcessCSS (ParentHelper.java:63) > at javafx.scene.Parent.doProcessCSS (Parent.java:1368) > at javafx.scene.Parent$1.doProcessCSS (Parent.java:125) > at com.sun.javafx.scene.ParentHelper.processCSSImpl (ParentHelper.java:98) > at com.sun.javafx.scene.control.ControlHelper.superProcessCSSImpl (ControlHelper.java:63) > at com.sun.javafx.scene.control.ControlHelper.superProcessCSS (ControlHelper.java:55) > at javafx.scene.control.Control.doProcessCSS (Control.java:886) > at javafx.scene.control.Control$1.doProcessCSS (Control.java:89) > at com.sun.javafx.scene.control.ControlHelper.processCSSImpl (ControlHelper.java:67) > at com.sun.javafx.scene.NodeHelper.processCSS (NodeHelper.java:145) > at javafx.scene.Node.processCSS (Node.java:9540) > at javafx.scene.Node.processCSS (Node.java:9533) > at javafx.scene.Node.processCSS (Node.java:9533) > at javafx.scene.Node.processCSS (Node.java:9533) > at javafx.scene.Node.processCSS (Node.java:9533) > at javafx.scene.Node.processCSS (Node.java:9533) > at javafx.scene.Scene.doCSSPass (Scene.java:569) > at javafx.scene.Scene$ScenePulseListener.pulse (Scene.java:2477) > at com.sun.javafx.tk.Toolkit.lambda$runPulse$2 (Toolkit.java:412) > at java.security.AccessController.doPrivileged (Native Method) > at com.sun.javafx.tk.Toolkit.runPulse (Toolkit.java:411) > at com.sun.javafx.tk.Toolkit.firePulse (Toolkit.java:438) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:563) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse (QuantumToolkit.java:543) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue (QuantumToolkit.java:536) > at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11 (QuantumToolkit.java:342) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run (InvokeLaterDispatcher.java:96) > at com.sun.glass.ui.gtk.GtkApplication._runLoop (Native Method) > at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11 (GtkApplication.java:277) > at java.lang.Thread.run (Thread.java:834) > updating > > */ > > ===== END ==== > > best wishes, > > Ben > >> -----Urspr?ngliche Nachricht----- >> Von: Kevin Rushforth >> Gesendet: Donnerstag, 13. Februar 2020 15:46 >> An: Peter, Benjamin ; openjfx-dev at openjdk.java.net >> Betreff: Re: WG: Minimal reproduction example for JDK-8217953 NPE in >> TableCellSkin >> >> Unfortunately, attachments don't make it through the openjdk mailing list filters. >> Can you just paste it inline? >> >> Thanks. >> >> -- Kevin >> >> >> On 2/13/2020 6:02 AM, Peter, Benjamin wrote: >>> Hello devs, >>> >>> same example but with the file as attachment and without header. >>> >>> >>> regards, >>> >>> Ben >>> >>> -----Urspr?ngliche Nachricht----- >>> Von: openjfx-dev Im Auftrag von >>> Peter, Benjamin >>> Gesendet: Donnerstag, 13. Februar 2020 11:54 >>> An: openjfx-dev at openjdk.java.net >>> Betreff: Minimal reproduction example for JDK-8217953 NPE in >>> TableCellSkin >>> >>> Dear FX devs, >>> >>> please accept my minimal reproduction example for JDK-8217953 >> "NullPointerException when TableCellSkin gets disposed twice" >>> In the report it says there was no luck reproducing it - I hope this could now be >> beneficial for a solution to this problem. >>> I could repeatedly trigger the problem after 100 of my update cycles - which >> interestingly corresponds to the following constant which can be found along the >> stacktrace. >>> javafx.scene.control.skin.TableRowSkinBase.DEFAULT_FULL_REFRESH_COUNTER >> = 100 Surely - could be coincidence - but also a hot lead. >>> >>> I can also confirm it is still reproducable in jfx 11 and 13. >>> >>> It is available as public domain gist on github: >>> >>> https://gist.github.com/dedeibel/d02fb51c59942bebcb6e418f23d310fb >>> >>> >>> >>> Thank you for your work and cooperation, >>> >>> with kind regards, >>> >>> >>> Benjamin Peter From kcr at openjdk.java.net Fri Feb 14 14:08:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 Feb 2020 14:08:36 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 14 Feb 2020 11:26:14 GMT, Jeanette Winzenburg wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 >> >> Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. >> >> Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. >> >> Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java line 152: > >> 151: >> 152: new KeyMapping(LEFT, (rtl? e -> selectRightCell() : e -> selectLeftCell())), >> 153: new KeyMapping(KP_LEFT, (rtl? e -> selectRightCell() : e -> selectLeftCell())), > > ... so a keyMapping based on the initial condition will fail after a change of orientation, or what am I missing? > > (aside: I really hate this review ui, can't seem to make it take several comments ... argghh) To add multiple comments, go to the `Files changed` tab and click on a line of code to add a comment there. Select `Start a review` rather than `Add single comment`. This way you can batch up multiple comments. Then you select `Finish Review` in the upper right. ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From kcr at openjdk.java.net Fri Feb 14 14:23:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 Feb 2020 14:23:45 GMT Subject: [Rev 01] RFR: 8196586: Remove use of deprecated finalize methods from javafx property objects In-Reply-To: References: Message-ID: <9nC2Cr5cjCh_pNCbzg50GWgdYBzC2aeQCENoBOLvHa4=.e0e6f965-8d8d-48a9-951a-6ccec325e41b@github.com> > This patch removes the `finalize` methods from the `Property` classes in the `javafx.base` module. > > The `{Boolean,Double,Float,Int,Long}Property` classes each have a pair of methods -- `asObject` and `xxxxxProperty` -- that create a `Property` object from a primitive `XxxxxProperty` object and vice versa. Each of the methods bidirectionally binds the original property object to the created property object. All of the bidirectional bindings in question use `WeakReference`s to refer to the pair of objects being bound to each other, so that they won't cause a memory leak. > > The `finalize` methods were added in an attempt to cleanup the bidirectional bindings when the created object goes away. I say attempt, because it is entirely ineffective in doing so. The logic that removes the binding creates a new one from the same pair of objects, but fails to match the original binding because the referent to the created property object has been garbage collected before the `finalize` method is called; the `WeakReference` in the binding is cleared and no longer matches. Fortunately, the only impact of this ineffective logic is that it can delay the removal of the binding (which is a small object that just contains the two weak references) from the original property object until it (the original property) is either garbage collected or modified (the binding logic already looks for a referent that has been GCed and removes the binding). > > Given that the `finalize` methods don't do anything useful today, and that there is no memory leak in the first place, the proposed fix is to just remove the `finalize` methods entirely with no replacement needed. There will be no changes in behavior as a result of this. > > Existing tests of the methods in question are sufficient to ensure no functional regressions, although there is no existing test for leaks, so I created new tests to verify that there is no leak. Since there is no existing leak, those tests will pass both with and without this fix. The pull request has been updated with 1 additional commit. ------------- Added commits: - 1097ace6: Add final in a few missing places in the test for symmetry Changes: - all: https://git.openjdk.java.net/jfx/pull/113/files - new: https://git.openjdk.java.net/jfx/pull/113/files/e90abed6..1097ace6 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/113/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/113/webrev.00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/113/head:pull/113 PR: https://git.openjdk.java.net/jfx/pull/113 From fastegal at openjdk.java.net Fri Feb 14 14:29:24 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 14 Feb 2020 14:29:24 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 14 Feb 2020 14:06:28 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java line 152: >> >>> 151: >>> 152: new KeyMapping(LEFT, (rtl? e -> selectRightCell() : e -> selectLeftCell())), >>> 153: new KeyMapping(KP_LEFT, (rtl? e -> selectRightCell() : e -> selectLeftCell())), >> >> ... so a keyMapping based on the initial condition will fail after a change of orientation, or what am I missing? >> >> (aside: I really hate this review ui, can't seem to make it take several comments ... argghh) > > To add multiple comments, go to the `Files changed` tab and click on a line of code to add a comment there. Select `Start a review` rather than `Add single comment`. This way you can batch up multiple comments. Then you select `Finish Review` in the upper right. thanks, Kevin - that's what I tried, but it refused to accept the second .. so sticking with single comments until I feel like digging into this weirdness. ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From kevin.rushforth at oracle.com Fri Feb 14 14:32:20 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Feb 2020 06:32:20 -0800 Subject: TableView with many columns poor ui performance In-Reply-To: References: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> <20200212123400.Horde.4R8XNUQWI7QKiCl9Ix7w0Q7@webmail.df.eu> Message-ID: <2ec41574-1ad1-8ef0-07b0-84b59d7b3177@oracle.com> Whether or not the specification of notifying a listener multiple times was intentional or driven by the implementation, it is part of the spec, and some applications could be relying on it. I do agree that there is no guarantee as to the order, which might simplify things. I can think of two possible implementations: 1. Use a counter as you mentioned below as a possibility. If you did this, you would need to add an additional LinkedHashSet of objects containing the Listener and a count. You could initialize that set to null and only constructing it in the (rather unlikely) case that a listener is added when it is already in the set of listeners. You could then test for "if (countSet == null)" in the various operations and do the simple thing if it is. 2. Since adding a listener more than once is unlikely, you could switch from a LinkedHashSet to an ArrayList the first time that a listener is added more than once. You would keep a Collection of listeners, initialize it to a LinkedHashSet, and dynamically switch from a LinkedHashSet to an ArrayList (copying existing entries) in addListener if the collection contains the listener already. This would be simpler logic than keeping track of the count for each object. I would lean towards the second optoin. It gives the desired speed up for the common case where we don't add a listener more than once, and in the worst case, switches back to what we have today. -- Kevin On 2/12/2020 4:03 AM, Danny Gonzalez wrote: > Hi Jeanette, > > > True, I hadn't read that spec in ObservableValueBase. > Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. > > Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. > > I would need to store a registration count for each listener to satisfy this requirement. > > > > On 12 Feb 2020, at 11:34, Jeanette Winzenburg > wrote: > > > Zitat von Danny Gonzalez >: > > Hi Ed, > > I have submitted a pull request and the branch is here: > https://github.com/screamingfrog/jfx/tree/listeners_optimisation > > > > hmm .. the change seems to be breaking spec of add/remove listeners > > "If the same listener is added more than once, then it will be notified more than once". > > or what am I missing? > > From danny.gonzalez at screamingfrog.co.uk Fri Feb 14 14:47:52 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Fri, 14 Feb 2020 14:47:52 +0000 Subject: TableView with many columns poor ui performance In-Reply-To: <2ec41574-1ad1-8ef0-07b0-84b59d7b3177@oracle.com> References: <3E1FB678-12A5-4A4F-A9D0-3BC459F1F4D3@kennard.net> <3D79C178-F78B-405E-8BB4-0527C7F13ECE@screamingfrog.co.uk> <20200212123400.Horde.4R8XNUQWI7QKiCl9Ix7w0Q7@webmail.df.eu> <2ec41574-1ad1-8ef0-07b0-84b59d7b3177@oracle.com> Message-ID: <4074ABA5-5F37-45E4-876B-655EFC1BED8B@screamingfrog.co.uk> Hi Kevin, Thanks for your comments. I am about to push some code for this. I have used a linkedHashMap which stores the listener and a count. I have also updated the unit tests to test for the addListener and removeListener behaviour in the case you register the same listener more than once. Would be interested in any comments or suggestions you may have. This fix has allowed us to move forward to using Java 11 as otherwise the number of listeners unregistering when using a TableView was killing our application. Thanks for your time. Danny > On 14 Feb 2020, at 14:32, Kevin Rushforth wrote: > > Whether or not the specification of notifying a listener multiple times was intentional or driven by the implementation, it is part of the spec, and some applications could be relying on it. I do agree that there is no guarantee as to the order, which might simplify things. I can think of two possible implementations: > > 1. Use a counter as you mentioned below as a possibility. If you did this, you would need to add an additional LinkedHashSet of objects containing the Listener and a count. You could initialize that set to null and only constructing it in the (rather unlikely) case that a listener is added when it is already in the set of listeners. You could then test for "if (countSet == null)" in the various operations and do the simple thing if it is. > > 2. Since adding a listener more than once is unlikely, you could switch from a LinkedHashSet to an ArrayList the first time that a listener is added more than once. You would keep a Collection of listeners, initialize it to a LinkedHashSet, and dynamically switch from a LinkedHashSet to an ArrayList (copying existing entries) in addListener if the collection contains the listener already. This would be simpler logic than keeping track of the count for each object. > > I would lean towards the second optoin. It gives the desired speed up for the common case where we don't add a listener more than once, and in the worst case, switches back to what we have today. > > -- Kevin > > > On 2/12/2020 4:03 AM, Danny Gonzalez wrote: >> Hi Jeanette, >> >> >> True, I hadn't read that spec in ObservableValueBase. >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> >> I would need to store a registration count for each listener to satisfy this requirement. >> >> >> >> On 12 Feb 2020, at 11:34, Jeanette Winzenburg > wrote: >> >> >> Zitat von Danny Gonzalez >: >> >> Hi Ed, >> >> I have submitted a pull request and the branch is here: >> https://github.com/screamingfrog/jfx/tree/listeners_optimisation >> >> >> >> hmm .. the change seems to be breaking spec of add/remove listeners >> >> "If the same listener is added more than once, then it will be notified more than once". >> >> or what am I missing? >> >> > From tsayao at openjdk.java.net Fri Feb 14 17:20:59 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 14 Feb 2020 17:20:59 GMT Subject: [Rev 25] 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) The pull request has been updated with a new target base due to a merge or a rebase. ------------- Commits: - f772c2e7: Merge branch 'master' into jdk_8236651 - 37519d74: Merge pull request #5 from openjdk/master - 08caafd9: Remove unused var - 2c51b045: Fix pointer grab bug - 2e3ce44a: Ajustments - 06968c9d: Fix bug on extents calculation - 84bfd8b8: Fix POPUP window positioning - 465c9cdd: Fix seat_grab param - 7ed26f41: Revert back focus mechanism - 22c38d7f: Merge branch 'jdk_8236651' of https://github.com/tsayao/jfx into jdk_8236651 - 14a75ce4: Merge branch 'master' into jdk_8236651 - e829b8e9: Better fix for initial size - 058a0992: Revert "Fix Initial Size" - 0c982d60: Fix Initial Size - 2d10fe8c: Merge branch 'jdk_8236651' of https://github.com/tsayao/jfx into jdk_8236651 - 694641f6: JDK-8236651 Simplify and update glass gtk backend - 9397a748: Merge pull request #4 from openjdk/master - cb2d9fb6: Work on mouse grab - 2bfac077: Mouse pointer grab - 4b555624: Allow undecorated windows to be maximized. - f35fa9b1: Big cleanup - f99aebcf: Maybe fix background - 9850bb71: Fix dialog with owner sizing - 209b7ac7: Better alternative calculation for no _NET_FRAME_EXTENTS WM extension - 0dc70ab3: Use gtk_window_set_default_size for before-map sizing which is the appropriate function - e4d2a1d2: Small fixes - cc7745b4: Pass more tests - 49426b66: Fix flickering and sizing issues - 628d5528: Revert idea files - 8b0cadfc: Fix crash - 1c3df122: Fix crash - 4691800a: Fix crash - 7b48e484: Cleaning + change year to 2020 - 039daa4a: Cleaning - 9f209f1e: JDK-8236651 Simplify and update glass gtk backend Changes: https://git.openjdk.java.net/jfx/pull/77/files Webrev: https://webrevs.openjdk.java.net/jfx/77/webrev.25 Stats: 3343 lines in 12 files changed: 773 ins; 1774 del; 796 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 nlisker at openjdk.java.net Fri Feb 14 20:49:19 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 14 Feb 2020 20:49:19 GMT Subject: RFR: 8196586: Remove use of deprecated finalize methods from javafx property objects In-Reply-To: References: Message-ID: <_H9gYq8VYI54d7g6z36szJKXtdOiFa7mJl9_LRb1jjY=.7b57c9de-afd5-41ec-83ef-07f1bd7ef81a@github.com> On Thu, 13 Feb 2020 23:13:06 GMT, Kevin Rushforth wrote: >> This patch removes the `finalize` methods from the `Property` classes in the `javafx.base` module. >> >> The `{Boolean,Double,Float,Int,Long}Property` classes each have a pair of methods -- `asObject` and `xxxxxProperty` -- that create a `Property` object from a primitive `XxxxxProperty` object and vice versa. Each of the methods bidirectionally binds the original property object to the created property object. All of the bidirectional bindings in question use `WeakReference`s to refer to the pair of objects being bound to each other, so that they won't cause a memory leak. >> >> The `finalize` methods were added in an attempt to cleanup the bidirectional bindings when the created object goes away. I say attempt, because it is entirely ineffective in doing so. The logic that removes the binding creates a new one from the same pair of objects, but fails to match the original binding because the referent to the created property object has been garbage collected before the `finalize` method is called; the `WeakReference` in the binding is cleared and no longer matches. Fortunately, the only impact of this ineffective logic is that it can delay the removal of the binding (which is a small object that just contains the two weak references) from the original property object until it (the original property) is either garbage collected or modified (the binding logic already looks for a referent that has been GCed and removes the binding). >> >> Given that the `finalize` methods don't do anything useful today, and that there is no memory leak in the first place, the proposed fix is to just remove the `finalize` methods entirely with no replacement needed. There will be no changes in behavior as a result of this. >> >> Existing tests of the methods in question are sufficient to ensure no functional regressions, although there is no existing test for leaks, so I created new tests to verify that there is no leak. Since there is no existing leak, those tests will pass both with and without this fix. > > @arapte I request you to be one of the reviewers of this PR. I'll be the 2nd reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/113 From kcr at openjdk.java.net Sat Feb 15 15:03:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 15 Feb 2020 15:03:59 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 14 Feb 2020 09:09:13 GMT, Ajit Ghaisas wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8235480 > > Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class. > > Testing : Modified unit tests in TableViewKeyInputTest to take orientation as a parameter. The Left/Right key press tests have been modified to address LTR and RTL orientations. > > Note : If this test modification is acceptable, I would like to address other similar tests separately. (I will create a test JBS issue and address later) @kleopatra is right about the need to handle the case where the orientation of a node changes. As for the test, I think the idea of parameterizing it with LTR, RTL is good. I haven't reviewed it in detail, but added one minor suggestion for you to consider. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewKeyInputTest.java line 102: > 101: > 102: private NodeOrientation orientation; > 103: I might recommend also adding a `private boolean ltr` instance variable to make the check less verbose, but that's up to you. ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From kcr at openjdk.java.net Sat Feb 15 15:04:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 15 Feb 2020 15:04:00 GMT Subject: RFR: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation In-Reply-To: References: Message-ID: On Fri, 14 Feb 2020 14:27:15 GMT, Jeanette Winzenburg wrote: >> To add multiple comments, go to the `Files changed` tab and click on a line of code to add a comment there. Select `Start a review` rather than `Add single comment`. This way you can batch up multiple comments. Then you select `Finish Review` in the upper right. > > thanks, Kevin - that's what I tried, but it refused to accept the second .. so sticking with single comments until I feel like digging into this weirdness. Regarding the fix, it seems that you need to eliminate the `rtl` variable you added earlier, and move the test into the listener, like this: new KeyMapping(LEFT, e -> isRtl() ? selectRightCell() : selectLeftCell()), ------------- PR: https://git.openjdk.java.net/jfx/pull/114 From ebresie at gmail.com Sat Feb 15 18:23:31 2020 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 15 Feb 2020 12:23:31 -0600 Subject: "Using an IDE" Page outdated (Openjfx) In-Reply-To: <939010e4-7425-475c-9b54-b612a4cf6e24@Erics-iPhone-X> References: <939010e4-7425-475c-9b54-b612a4cf6e24@Erics-iPhone-X> Message-ID: Wanted to ping the netbeans mailing list to see if there is any input that could be provided to help on the open jfx as it relates to recent netbeans.. See https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingNetBeans(JDK-8) I seem to recall sometime back that there was some discussion on usage of the newer OpenJFX libraries, examples, and additional configuration of new ones but not an expert on that really. Eric Bresie ebresie at gmail.com On Wed, Jan 15, 2020 at 2:44 PM Eric Bresie wrote: > Anyone on the Netbeans community want to provide any updates on the > openjfx IDE page listed below? > > Eric Bresie > Ebresie at gmail.com > > On January 10, 2020 at 10:52:26 AM CST, Nir Lisker > wrote: > > Hi Robert, > > > > I've brought this up in the past. > > > > I think that the best solution is for someone from the community to take > > that task. I try to keep the Eclipse section updated, we will need > someone > > for the other IDE's. > > > > - Nir > > > > On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger < > > r.lichtenberger at gmail.com> wrote: > > > > > I've noticed that > > > https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE > > > seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no > > > longer exists, etc.). > > > > > > Could someone please update this page so that it is easier for > newcomers to > > > dive into the development of OpenJFX. > > > > > > Thanks, > > > Robert > > > > From tsayao at openjdk.java.net Sun Feb 16 01:11:56 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 16 Feb 2020 01:11:56 GMT Subject: [Rev 26] 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) The pull request has been updated with 2 additional commits. ------------- Added commits: - bc3711ed: Adjust comment - eab00230: Adjust comment Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/f772c2e7..bc3711ed Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.26 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.25-26 Stats: 3 lines in 1 file changed: 0 ins; 0 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 nlisker at openjdk.java.net Sun Feb 16 01:26:50 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 16 Feb 2020 01:26:50 GMT Subject: RFR: 8196586: Remove use of deprecated finalize methods from javafx property objects In-Reply-To: <_H9gYq8VYI54d7g6z36szJKXtdOiFa7mJl9_LRb1jjY=.7b57c9de-afd5-41ec-83ef-07f1bd7ef81a@github.com> References: <_H9gYq8VYI54d7g6z36szJKXtdOiFa7mJl9_LRb1jjY=.7b57c9de-afd5-41ec-83ef-07f1bd7ef81a@github.com> Message-ID: On Fri, 14 Feb 2020 20:47:04 GMT, Nir Lisker wrote: >> @arapte I request you to be one of the reviewers of this PR. > > I'll be the 2nd reviewer. > the referent to the created property object has been garbage collected before the `finalize` method is called I'm confused. What is that referent exactly and why is it guaranteed to have been GC'd before finalization? ------------- PR: https://git.openjdk.java.net/jfx/pull/113 From tsayao at openjdk.java.net Sun Feb 16 01:49:44 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 16 Feb 2020 01:49:44 GMT Subject: [Rev 27] 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) Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR. ------------- Added commits: - f7a84fdb: JDK-8236651 Simplify and update glass gtk backend Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/bc3711ed..f7a84fdb Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.27 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.26-27 Stats: 5 lines in 1 file changed: 1 ins; 2 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 nlisker at openjdk.java.net Mon Feb 17 01:55:33 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 17 Feb 2020 01:55:33 GMT Subject: [Rev 03] RFR: 8217472: Add attenuation for PointLight In-Reply-To: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> References: <2brNoXfoHkcDhP8MQYg1Z9OKKGXsD6o37OP13VkpQCM=.eba6cd21-8fdb-41de-a2b2-8840bffbacc3@github.com> Message-ID: On Wed, 5 Feb 2020 13:48:45 GMT, Kevin Rushforth wrote: >> We have a few performance tests in apps/performance, but I don't know how up to date they are. They might give you a starting point on how to measure FPS, but really the harder part is going to be coming up with a workload -- a scene with a number of Shape3Ds with large triangles (so that they are fill-rate limited) and 1-3 lights, etc -- that you can use to measure rendering performance without measuring overhead. Typically you want a scene that is rendering continuously in the < 30 fps range, and more like 10 fps to minimize the overhead even more. >> >> Before we figure out whether we need to double the number of shaders (which was one of the ideas that I had as well), we need to know how much of a problem it is. Is it < 2% performance drop on typical cases on a variety of machines or it is a 25% drop (or more likely somewhere in between). If the perf drop is negligible, then it isn't worth doubling the shaders. If it is significant, then we probably need to. >> >> If we do need to double the shaders, I wouldn't do it based on the maxRange being infinite, rather I would do it based on whether attenuation is being used. That way the existing shaders would be unchanged, while the new shader would deal with both attenuation and the maxRange test. >> >> Hopefully, there won't be enough of a perf hit to require doubling the shaders, but we need to be able to measure it. >> >> For functional testing, in addition to the simple API tests, we want to make sure that the basic rendering is working with and without attenuation. Some sort of visual test where you verify that attenuation is / isn't happening as well as testing the cutoff. I wouldn't get too fancy with these...just a sanity test. > > Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't complete. An incomplete CSR should be treated the same way as an insufficient number of reviewers. I filed [SKARA-262](https://bugs.openjdk.java.net/browse/SKARA-262) to track this. I've taken the sample app and enlarged the box to fill the whole range of the lights in an attempt to have many pixels rendered for few vertices. I measured 90-115 fps during continuous animation with this patch, and 100-120 before it. I measured the fps using an external app called BandiCam. Will do more tests this week. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From aghaisas at openjdk.java.net Mon Feb 17 09:15:13 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 17 Feb 2020 09:15:13 GMT Subject: [Rev 01] RFR: 8238434: Ensemble: Update version of Lucene to 7.7.2 In-Reply-To: References: Message-ID: On Tue, 4 Feb 2020 22:47:18 GMT, Kevin Rushforth wrote: >> Update the version of Lucene used by Ensemble to the latest release of Lucene 7 which is version 7.7.2. >> >> Per the instructions in [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt), I made the following changes: >> >> 1. Bumped the version numbers from 7.7.1 to 7.7.2 in all needed places >> >> I did not regenerate the index files, since only the `bugfix` number (the third digit) changed. It is the same `major.minor` release as before. >> >> To test this: apply the patch, run `gradle apps`, launch Ensemble8, and search for a sample or JavaFX component in the upper-right search box. > > The pull request has been updated with 1 additional commit. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/105 From aghaisas at openjdk.java.net Mon Feb 17 09:15:14 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 17 Feb 2020 09:15:14 GMT Subject: RFR: 8238434: Ensemble: Update version of Lucene to 7.7.2 In-Reply-To: References: <8T6X-06auMFtKLUUHmu1S0_W6s_iOdjmJu3dAeVm5hA=.5ac97090-fe6a-4f27-b68e-b7c8f6af4f6a@github.com> Message-ID: On Tue, 4 Feb 2020 22:41:37 GMT, Kevin Rushforth wrote: >> @aghaisas can you review this? > > I pushed a new commit that reverts the changes to the stored binary index files. There is no need to regenerate them when upgrading to a new version where only the `bugfix` number (the third digit) changes. This minimizes the churn and avoids modifying the binary index files needlessly. I added a note to this effect in the updated [`UPDATING-lucene.txt`](https://github.com/openjdk/jfx/blob/6facff5d7b7a9160939a5b4231a8355a617377a6/apps/samples/Ensemble8/UPDATING-lucene.txt) file. I applied this patch, built the apps and verified with Ensemble8 app. Also, verified that it downloads lucene 7.7.2 during build. ------------- PR: https://git.openjdk.java.net/jfx/pull/105 From Rony.Flatscher at wu.ac.at Mon Feb 17 15:40:20 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 17 Feb 2020 16:40:20 +0100 Subject: Question ad creating a testcase that needs a jar on class- or module path In-Reply-To: References: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at> <40571aa5-a667-d279-c410-ecb4648a9629@oracle.com> Message-ID: Over the weekend I was finally able to finalize the test unit in form of a module. Kept it as simple as possible (but it includes a pseudo script engine). May I just ask a few questions, before proceeding with submitting one or two PRs: * Every new program needs the Oracle license header at the top? * Would it be o.k. to dual license (AL 2.0 for the pseudo scripting engine)? o If not (it probably would introduce noise and problems) it would not be a real problem as I always can create a separate package using only the code that was authored by myself. * Where shall I explain/document how the test unit works, here in the mailing list or with the PR? o If the latter, then it would probably be a good idea to submit the test unit separately from the PR for fixing the bug as that will have its own set of explanations/documentations (briefly discussing the three scenarious how a script controller may define scripts and why the filenames were picked the way they are). * Maybe the explanations/documentations for the bug fix should be posted here upfront for discussion? ---rony On 03.02.2020 15:04, Rony G. Flatscher wrote: > Hi Kevin, > > On 31.01.2020 16:38, Kevin Rushforth wrote: >> And if you need a modular jar, you might look at ModuleLauncherTest instead. > thank you very much for this important hint as well! > > Having no knowledge about gradle it will take me a while to research and digest, but this definitely > helps me to jump start to the section where tests get carried out with separately configured JVMs. > > Would it be o.k. to first submit a pull request for JDK-8234959 > and later, when an appropriate test unit using > the SPI dependent pseudo script engine is available submitting the test app with different pull > request? Or would it be better to submit both with the same pull request? > > ---rony From kevin.rushforth at oracle.com Mon Feb 17 17:07:12 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Feb 2020 09:07:12 -0800 Subject: Question ad creating a testcase that needs a jar on class- or module path In-Reply-To: References: <7785bd7b-f9ca-dc98-bbad-b7d835232fed@wu.ac.at> <40571aa5-a667-d279-c410-ecb4648a9629@oracle.com> Message-ID: <1420801f-5915-4465-c7bd-5845047e49bd@oracle.com> Replies inline. On 2/17/2020 7:40 AM, Rony G. Flatscher wrote: > Over the weekend I was finally able to finalize the test unit in form of a module. Kept it as simple > as possible (but it includes a pseudo script engine). > > May I just ask a few questions, before proceeding with submitting one or two PRs: > > * Every new program needs the Oracle license header at the top? Yes. > * Would it be o.k. to dual license (AL 2.0 for the pseudo scripting engine)? > > o If not (it probably would introduce noise and problems) it would not be a real problem as I > always can create a separate package using only the code that was authored by myself. Not for code you commit into the openjfx repo, no. However, since you retain the copyright for anything you contribute to OpenJDK, you can ship it separately under whatever license you choose. > * Where shall I explain/document how the test unit works, here in the mailing list or with the PR? > > o If the latter, then it would probably be a good idea to submit the test unit separately from > the PR for fixing the bug as that will have its own set of explanations/documentations > (briefly discussing the three scenarious how a script controller may define scripts and why > the filenames were picked the way they are). > > * Maybe the explanations/documentations for the bug fix should be posted here upfront for discussion? I think a mailing list discussion would be a good place to start. -- Kevin > > ---rony > > > On 03.02.2020 15:04, Rony G. Flatscher wrote: > >> Hi Kevin, >> >> On 31.01.2020 16:38, Kevin Rushforth wrote: >>> And if you need a modular jar, you might look at ModuleLauncherTest instead. >> thank you very much for this important hint as well! >> >> Having no knowledge about gradle it will take me a while to research and digest, but this definitely >> helps me to jump start to the section where tests get carried out with separately configured JVMs. >> >> Would it be o.k. to first submit a pull request for JDK-8234959 >> and later, when an appropriate test unit using >> the SPI dependent pseudo script engine is available submitting the test app with different pull >> request? Or would it be better to submit both with the same pull request? >> >> ---rony From sebastian.stenzel at gmail.com Mon Feb 17 18:42:57 2020 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 17 Feb 2020 19:42:57 +0100 Subject: AssertionError in ScheduledService.executeTask Message-ID: <16C6DE33-EFA2-4890-A018-7794F53839AD@gmail.com> When restart()ing a ScheduledService while having assertions enabled, the assertions in [1] or [2] fail. Without assertions the code seems to run fine, though. According to the inline comments, "resetting things should have cleared the delayTask". Therefore I wonder, if resetting the delayTask is missing in reset(). At the moment this field is only set to null during cancel() [3] as well as after exception-free execution of a previous TimerTask [4]. A workaround would be to call cancel() first, but one has to make sure to be in a valid state. I wonder if there is some documentation about the state transitions and how to start, stop and restart a service correctly. [1]: https://github.com/openjdk/jfx/blob/e98645932d0d7765988f21b09d6d121202281e02/modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java#L357 [2]: https://github.com/openjdk/jfx/blob/e98645932d0d7765988f21b09d6d121202281e02/modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java#L379 [3]: https://github.com/openjdk/jfx/blob/e98645932d0d7765988f21b09d6d121202281e02/modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java#L469 [4]: https://github.com/openjdk/jfx/blob/e98645932d0d7765988f21b09d6d121202281e02/modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java#L524 From tres.finocchiaro at gmail.com Mon Feb 17 19:12:32 2020 From: tres.finocchiaro at gmail.com (Tres Finocchiaro) Date: Mon, 17 Feb 2020 14:12:32 -0500 Subject: Monocle as a replacement Message-ID: 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 nlisker at openjdk.java.net Tue Feb 18 02:21:38 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 18 Feb 2020 02:21:38 GMT Subject: [jfx14] [Rev 01] RFR: 8228867: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <5mSxMSdJNjXjH0FWX0r0Kalu3Je7r_po08i1q_CZg_U=.78332923-35a7-4820-ae76-90e06156a12b@github.com> > Docs fixes for OpenJFX 14. We can wait with integrating this in case there are last minute fixes, but reviews can start. The pull request has been updated with 2 additional commits. ------------- Added commits: - 75d34b85: Update copyright year - 131850d2: Fix extra } Changes: - all: https://git.openjdk.java.net/jfx/pull/110/files - new: https://git.openjdk.java.net/jfx/pull/110/files/25c6f63b..75d34b85 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/110/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/110/webrev.00-01 Stats: 9 lines in 5 files changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/110.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/110/head:pull/110 PR: https://git.openjdk.java.net/jfx/pull/110 From github.com+6702882+dannygonzalez at openjdk.java.net Tue Feb 18 09:06:31 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Tue, 18 Feb 2020 09:06:31 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView Message-ID: https://bugs.openjdk.java.net/browse/JDK-8185886 Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. This may alleviate some of the issues seen here: TableView has a horrific performance with many columns #409 https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 JDK-8088394 : Huge memory consumption in TableView with too many columns JDK-8166956: JavaFX TreeTableView slow scroll performance JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html ------------- Commits: - 05c37196: JDK-8185886 Changes: https://git.openjdk.java.net/jfx/pull/108/files Webrev: https://webrevs.openjdk.java.net/jfx/108/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8185886 Stats: 240 lines in 4 files changed: 105 ins; 76 del; 59 mod Patch: https://git.openjdk.java.net/jfx/pull/108.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/108/head:pull/108 PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Tue Feb 18 09:06:32 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Tue, 18 Feb 2020 09:06:32 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 16:13:33 GMT, dannygonzalez wrote: > https://bugs.openjdk.java.net/browse/JDK-8185886 > > Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. > > This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. > > This may alleviate some of the issues seen here: > > TableView has a horrific performance with many columns #409 > https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 > > JDK-8088394 : Huge memory consumption in TableView with too many columns > JDK-8166956: JavaFX TreeTableView slow scroll performance > JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction > > OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns > https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html /signed I have signed the Oracle Contributor Agreement today. Have not received back any confirmation yet though. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Tue Feb 18 09:06:32 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 18 Feb 2020 09:06:32 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: Message-ID: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> On Thu, 6 Feb 2020 16:22:28 GMT, dannygonzalez wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185886 >> >> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. >> >> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. >> >> This may alleviate some of the issues seen here: >> >> TableView has a horrific performance with many columns #409 >> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 >> >> JDK-8088394 : Huge memory consumption in TableView with too many columns >> JDK-8166956: JavaFX TreeTableView slow scroll performance >> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction >> >> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html > > /signed > > I have signed the Oracle Contributor Agreement today. Have not received back any confirmation yet though. hmm ... wouldn't the change violate spec of adding listeners: > If the same listener is added more than once, then it will be notified more than once. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Tue Feb 18 09:06:32 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Tue, 18 Feb 2020 09:06:32 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> Message-ID: <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> On Wed, 12 Feb 2020 11:29:24 GMT, Jeanette Winzenburg wrote: >> /signed >> >> I have signed the Oracle Contributor Agreement today. Have not received back any confirmation yet though. > > hmm ... wouldn't the change violate spec of adding listeners: > >> If the same listener is added more than once, then it will be notified more than once. > hmm ... wouldn't the change violate spec of adding listeners: > > > If the same listener is added more than once, then it will be notified more than once. True, I hadn't read that spec in ObservableValueBase. Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. I would need to store a registration count for each listener to satisfy this requirement. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Tue Feb 18 09:06:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 18 Feb 2020 09:06:33 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> Message-ID: On Wed, 12 Feb 2020 12:01:03 GMT, dannygonzalez wrote: >> hmm ... wouldn't the change violate spec of adding listeners: >> >>> If the same listener is added more than once, then it will be notified more than once. > >> hmm ... wouldn't the change violate spec of adding listeners: >> >> > If the same listener is added more than once, then it will be notified more than once. > > True, I hadn't read that spec in ObservableValueBase. > Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. > > Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. > > I would need to store a registration count for each listener to satisfy this requirement. > > Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. > whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? > Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. > yeah, the test coverage is ... not optimal :) > I would need to store a registration count for each listener to satisfy this requirement. a count plus some marker as to where it was added: addListener(firstL) addListener(secondL) addListener(firstL) must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Tue Feb 18 09:06:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 18 Feb 2020 09:06:33 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> Message-ID: <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> On Wed, 12 Feb 2020 12:43:58 GMT, dannygonzalez wrote: >>> >>> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >>> >> >> whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? >> >>> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >>> >> >> yeah, the test coverage is ... not optimal :) >> >>> I would need to store a registration count for each listener to satisfy this requirement. >> >> a count plus some marker as to where it was added: >> >> addListener(firstL) >> addListener(secondL) >> addListener(firstL) >> >> must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? > > The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. > > The performance unregistering thousands of listeners by TableView from the array is killing the performance of our JavaFX application. It takes up to 60% of JavaFX Application thread CPU and there are various bug reports around this same TableView performance issue. > The set implementation has lowered this to below 1%. > > This pull request may be too fundamental a change to go into mainline. We however have to build our local OpenJFX with this fix or our application is unusable. > > I?m happy to receive any suggestions. > > Danny > > > On 12 Feb 2020, at 12:22, Jeanette Winzenburg > wrote: > > > Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. > > whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? > > Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. > > yeah, the test coverage is ... not optimal :) > > I would need to store a registration count for each listener to satisfy this requirement. > > a count plus some marker as to where it was added: > > addListener(firstL) > addListener(secondL) > addListener(firstL) > > must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or unsubscribe. > > The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. yeah, you are right can't find that spec on sequence right now - maybe I dreamed it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Tue Feb 18 09:06:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Feb 2020 09:06:34 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@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> Message-ID: On Wed, 12 Feb 2020 13:06:00 GMT, Jeanette Winzenburg wrote: >> The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. >> >> The performance unregistering thousands of listeners by TableView from the array is killing the performance of our JavaFX application. It takes up to 60% of JavaFX Application thread CPU and there are various bug reports around this same TableView performance issue. >> The set implementation has lowered this to below 1%. >> >> This pull request may be too fundamental a change to go into mainline. We however have to build our local OpenJFX with this fix or our application is unusable. >> >> I?m happy to receive any suggestions. >> >> Danny >> >> >> On 12 Feb 2020, at 12:22, Jeanette Winzenburg > wrote: >> >> >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> >> whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? >> >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> >> yeah, the test coverage is ... not optimal :) >> >> I would need to store a registration count for each listener to satisfy this requirement. >> >> a count plus some marker as to where it was added: >> >> addListener(firstL) >> addListener(secondL) >> addListener(firstL) >> >> must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub, or unsubscribe. > >> >> The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. > > yeah, you are right can't find that spec on sequence right now - maybe I dreamed it :) @dannygonzalez the reason for the `jcheck` failure is that you have commits with two different email addresses in your branch. At this point, it's probably best to squash the commits into a single commit with `git rebase -i master` (presuming that your local `master` is up to date), and then do a force-push. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Tue Feb 18 09:06:33 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Tue, 18 Feb 2020 09:06:33 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> Message-ID: On Wed, 12 Feb 2020 12:22:15 GMT, Jeanette Winzenburg wrote: >>> hmm ... wouldn't the change violate spec of adding listeners: >>> >>> > If the same listener is added more than once, then it will be notified more than once. >> >> True, I hadn't read that spec in ObservableValueBase. >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> >> I would need to store a registration count for each listener to satisfy this requirement. > >> >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> > > whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? > >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> > > yeah, the test coverage is ... not optimal :) > >> I would need to store a registration count for each listener to satisfy this requirement. > > a count plus some marker as to where it was added: > > addListener(firstL) > addListener(secondL) > addListener(firstL) > > must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. The performance unregistering thousands of listeners by TableView from the array is killing the performance of our JavaFX application. It takes up to 60% of JavaFX Application thread CPU and there are various bug reports around this same TableView performance issue. The set implementation has lowered this to below 1%. This pull request may be too fundamental a change to go into mainline. We however have to build our local OpenJFX with this fix or our application is unusable. I?m happy to receive any suggestions. Danny On 12 Feb 2020, at 12:22, Jeanette Winzenburg > wrote: Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. yeah, the test coverage is ... not optimal :) I would need to store a registration count for each listener to satisfy this requirement. a count plus some marker as to where it was added: addListener(firstL) addListener(secondL) addListener(firstL) must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? ? You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Tue Feb 18 09:07:26 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Tue, 18 Feb 2020 09:07: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> Message-ID: On Mon, 17 Feb 2020 13:51:49 GMT, Kevin Rushforth wrote: >>> >>> The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. >> >> yeah, you are right can't find that spec on sequence right now - maybe I dreamed it :) > > @dannygonzalez the reason for the `jcheck` failure is that you have commits with two different email addresses in your branch. At this point, it's probably best to squash the commits into a single commit with `git rebase -i master` (presuming that your local `master` is up to date), and then do a force-push. @kevinrushforth just a note to say there are other ExpressionHelper classes (i.e. MapExpressionHelper, SetExpressionHelper and ListExpressionHelper) that also use arrays and suffer from the linear search issue when removing listeners. These however didn't appear in the critical path of the JavaFXThread and didn't come up in my profiling of TableView. If this pull request is accepted, my opinion is that they should probably all move to using the same pattern as here, which is to use Maps instead of Arrays for their listener lists so that all these classes are uniform. Thanks ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From Rony.Flatscher at wu.ac.at Tue Feb 18 12:36:26 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 18 Feb 2020 13:36:26 +0100 Subject: Ad suggested fix for "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV" Message-ID: [1] reports a bug related to FXMLLoader for FXML controllers being implemented in any one of the javax.script languages: the invoked scripts are not supplied the standardized entries "javax.script.filename" (a string denoting the filename that hosts the script) and "javax.script.argv" (an Object[] of positional arguments in the case of event scripts) in their engine scope Bindings. The FXML file below demonstrates how scripts can be defined (using some hypothetical Java script language named "rpsl"). In the case of a runtime error (or for debugging purposes) the script engines therefore cannot supply the filename that hosts the script that caused a runtime error (or which gets currently debugged). I have prepared a fix for [1], but would like to communicate what it does and its reasonings first (making it easy for script programmers to locate erroneous scripts and to fetch the event argument as a script argument in event scripts). --- To illustrate the problem at hand the file "demo_01.fxml" below has been created, which among other things defines: * line # 6: process instruction defines some Java script language named "rpsl" to be used for executing the scripts of the fxml file * line # 11: defines an empty "fx:script" element, denoting in its "source" attribute the external script file named "demo_01_topscript.rpsl" (note: the Button element with the fx:id "idButton" is not yet defined at that point in time) * line # 15: defines a Button element with the fx:id "idButton" * line # 17: defines a script (PCDATA) for the "onMouseClicked" event attribute for the Button element (fx:id "idButton") * line # 18 : defines a script (PCDATA) for the "onButton" event attribute for the Button element (fx:id "idButton") * line # 21: defines an empty "fx:script" element, denoting in its "source" attribute the external script file named "demo_01_middlescript.rpsl" * line # 27: defines an empty "fx:script" element, denoting in its "source" attribute the external script file named "demo_01_bottomscript.rpsl" * line # 29: defines an? "fx:script" element with contained PCDATA script code (note: ends in line # 32) * line # 32: defines an? "fx:script" element with contained CDATA script code Currently, * whatever script gets run (lines # 11, #17, #18, #21, #27, #29, #32), the name of the file hosting the script is unknown, because of the missing entry "javax.script.filename" in the engine scope Bindings, * the event scripts (lines # 17, #18) cannot fetch the "event" argument as an argument, because of the missing entry "javax.script.argv" The proposed fix does the following: * scripts stored in external files (lines #11, #21, # 27): the value of the "source" attribute gets stored with the key "javax.script.filename" in the engine scope Bindings, yielding e.g.: o line # 11:? ...path-to..."demo_01_topscript.rpsl" o line # 21: ...path-to..."demo_01_middlescript.rpsl" o line #27: ...path-to..."demo_01_bottomscript.rpsl" * scripts contained in "fx:script" elements (lines #29, # 32): the FXML location path is used as the hosting filename with the string "-script_starting_at_line_#" appended and stored with the key "javax.script.filename" in the engine scope Bindings, yielding e.g.: o line # 29: ...path-to... "demo_01.fxml-script_starting_at_line_29" o line # 32: ...path-to... "demo_01.fxml-script_starting_at_line_32" o notes: + the dash ('-') following the FXML filename is meant to make spotting/parsing easier + the appended text should be self-describing, allowing the programmer to immediately spot the position of the script in question * event scripts (lines #17, #18):? o the single "event" argument is stored in the local scope Bindings, and now in addition gets supplied as the single argument in the single-element Object array stored with "javax.script.argv" in the engine scope Bindings o the FXML location path is used as the hosting filename with the string "-${eventAttributeName}_attribute_in_element_ending_at_line_#" and stored with the key "javax.script.filename" in the engine scope Bindings, yielding e.g.: + line #17: ...path-to... "demo_01.fxml-onAction_attribute_in_element_ending_at_line_19" + line #19: ...path-to... "demo_01.fxml-onMouseClicked_attribute_in_element_ending_at_line_19" o notes: + the dash ('-') following the FXML filename is meant to make spotting/parsing easier + the appended text should be self-describing, allowing the programmer to closely spot the position of the event script in question + using a minimal edit approach, it is not possible for the suggested fix to fetch the starting line (and column) number of the element for which the event attributes get processed (nor the exact position of the event attributes for that matter) in FXMLLoader therefore hinting the programmer at "_xxx_attribute_in_element_ending_at_line_#". This is regarded to be sufficient and will allow the programmer to immediately locate the position in the FXML file of the script that may have caused a runtime exception. "demo_01.fxml": ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ???? ??????? ?????????????????????????????? ??????? ??????? ????????