From youngty1997 at gmail.com Wed Jul 1 01:31:31 2020 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 30 Jun 2020 20:31:31 -0500 Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: On 6/25/20 10:56 PM, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). > > ------------- > > Commit messages: > - 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread > > Changes: https://git.openjdk.java.net/jfx/pull/255/files > Webrev: https://webrevs.openjdk.java.net/jfx/255/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8201567 > Stats: 35 lines in 5 files changed: 29 ins; 0 del; 6 mod > Patch: https://git.openjdk.java.net/jfx/pull/255.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/255/head:pull/255 > > PR: https://git.openjdk.java.net/jfx/pull/255 Does this fix the years old Linux JavaFX buffer reset bug? From github.com+1413266+jgneff at openjdk.java.net Wed Jul 1 05:45:49 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Wed, 1 Jul 2020 05:45:49 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 06:05:08 GMT, John Neffenger wrote: >> At first glance the fix looks fine (aside from the `assert` statements that need to be removed). It will also need to >> be tested using the SW pipeline on all platforms. > >> It will also need to be tested using the SW pipeline on all platforms. > > Thanks for the reminder. I managed to build JavaFX on Windows and macOS today, so I'll test this pull request on those > platforms in addition to Linux desktop and embedded. I tested this pull request on all of the following platforms: * JavaFX desktop platforms (*amd64* architecture) * Windows SDK on Windows 10 Pro Version 2004 * Mac OS X SDK on macOS 10.15.5 (Catalina) * Linux SDK on Ubuntu 16.04.6 LTS (Xenial Xerus) * JavaFX embedded platforms (*armhf* architecture) * armv6hf SDK (Monocle EPD) on Ubuntu 14.04.6 LTS (Trusty Tahr) * armv6hf SDK (Monocle VNC) on Ubuntu 20.04 LTS (Focal Fossa) This is a tricky timing problem on most platforms, so I used rather intrusive techniques to catch the error and verify it was fixed. The bug is easily visible only on the Monocle VNC platform. ### Desktop I tested the desktop platforms as follows: 1. I added `assert` statements and calls to `Thread.sleep` as shown by [this commit](https://github.com/jgneff/javafx-graphics/commit/ffc639e4) to catch the error. It looks like a lot of changes, but they simply call `sleep` to change the timing of the threads so that the JavaFX Application Thread is unable to keep up with the QuantumRenderer. The `assert` statements catch the error when the rendering thread starts looking for an unused buffer. All platforms printed many `InvalidMarkException` errors as the buffer position was modified while in use on the JavaFX application thread. The Linux and Windows platforms printed, "Exception in thread 'JavaFX Application Thread' java.nio.InvalidMarkException," while the macOS platform printed, "Exception in thread 'AppKit Thread' java.nio.InvalidMarkException." 2. I applied the fix to call `getBuffer` instead of `getPixels` in `QueuedPixelSource`. 3. After the fix, no errors were detected by the assertions on any of the platforms. ### Embedded I tested the embedded platforms as follows: 1. I added only `assert` statements to the `HeadlessScreen` and `EPDScreen` classes, as shown below. Both platforms printed many `InvalidMarkException` errors as the buffer position was modified while in use on the JavaFX application thread. 2. I applied the fix to call `getBuffer` instead of `getPixels` in `QueuedPixelSource`. 3. After the fix, no errors were detected by the assertions on either platform. #### `HeadlessScreen` and `EPDScreen` @Override public synchronized void uploadPixels(Buffer b, int x, int y, int width, int height, float alpha) { + assert b.mark() == b; pixels.composePixels(b, x, y, width, height, alpha); + assert b.reset() == b; } For the Monocle VNC platform, you can also simply connect and watch the bug corrupt the frames sent to the VNC client, as shown in my prior comment on this pull request. ### Other results I found some unexpected results, listed below. * JavaFX on Linux does not limit its frame rate to 60 Hz when using the hardware pipeline, reaching over 350 frames per second. * JavaFX on macOS ignores the system property `-Djavafx.animation.pulse=8` and runs at 60 Hz, even though it prints the message "Setting PULSE_DURATION to 8 hz." * JavaFX on macOS prints the error shown below when `Platform.exit` is called to end the application. The error also occurs on JavaFX 14.0.1 and 15-ea+6. The error does not occur when the window is closed manually using the mouse. Java has been detached already, but someone is still trying to use it at -[GlassViewDelegate dealloc]: /Users/john/src/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m:204 0 libglass.dylib 0x000000010eb6c05d -[GlassViewDelegate dealloc] + 221 1 libglass.dylib 0x000000010eb71af6 -[GlassView3D dealloc] + 246 2 libobjc.A.dylib 0x00007fff66937054 _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 134 3 libobjc.A.dylib 0x00007fff6691bdba objc_autoreleasePoolPop + 175 4 CoreFoundation 0x00007fff2dad23c5 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 5 CoreFoundation 0x00007fff2dad22f7 __CFRunLoopDoObservers + 457 6 CoreFoundation 0x00007fff2dad1895 __CFRunLoopRun + 874 7 CoreFoundation 0x00007fff2dad0ece CFRunLoopRunSpecific + 462 8 libjli.dylib 0x000000010be945c1 CreateExecutionEnvironment + 399 9 libjli.dylib 0x000000010be90752 JLI_Launch + 1354 10 java 0x000000010be83ca1 main + 375 11 libdyld.dylib 0x00007fff67acdcc9 start + 1 12 ??? 0x000000000000000b 0x0 + 11 ### Test scripts Below are the scripts I used to run the tests. The scripts include the system property `-Djavafx.animation.pulse=8`, but I removed it when trying to recreate the bug with the added `assert` and `sleep` statements. #### Linux #!/bin/bash # Linux desktop $HOME/opt/jdk-14.0.1/bin/java -ea --show-version \ --module-path=$HOME/lib/javafx-sdk-dev/lib \ --add-modules=javafx.graphics \ -Dprism.order=sw -Djavafx.animation.pulse=8 \ -jar dist/epd-javafx.jar \ --width=800 --height=600 --pattern=3 --loops=0 #### macOS #!/bin/bash # macOS desktop $HOME/opt/jdk-14.0.1.jdk/Contents/Home/bin/java -ea --show-version \ --module-path=$HOME/lib/javafx-sdk-dev/lib \ --add-modules=javafx.graphics \ -Dprism.order=sw -Djavafx.animation.pulse=8 \ -jar dist/epd-javafx.jar \ --width=800 --height=600 --pattern=3 --loops=0 #### Windows #!/bin/bash # Windows desktop under Cygwin $HOME/opt/jdk-14.0.1/bin/java -ea --show-version \ --module-path=$(cygpath -m $HOME/lib/javafx-sdk-dev/lib) \ --add-modules=javafx.graphics \ -Dprism.order=sw -Djavafx.animation.pulse=8 \ -jar dist/epd-javafx.jar \ --width=800 --height=600 --pattern=3 --loops=0 REM Windows desktop under Command Prompt C:\cygwin64\home\john\opt\jdk-14.0.1\bin\java -ea --show-version^ --module-path=C:/cygwin64/home/john/lib/javafx-sdk-dev/lib^ --add-modules=javafx.graphics^ -Dprism.order=sw -Djavafx.animation.pulse=8^ -jar dist\epd-javafx.jar^ --width=800 --height=600 --pattern=3 --loops=0 #### Monocle EPD Run with `sudo`. #!/bin/bash # Monocle EPD platform on Linux armhf $HOME/opt/jdk-14.0.1+7/bin/java -ea --show-version \ --module-path=$HOME/lib/armv6hf-sdk/lib \ --add-modules=javafx.graphics \ -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ -Dmonocle.epd.waveformMode=4 -jar dist/epd-javafx.jar \ --width=800 --height=600 --pattern=3 --loops=0 #### Monocle VNC #!/bin/bash # Monocle VNC platform on Linux armhf /usr/lib/jvm/java-14-openjdk-armhf/bin/java -ea --show-version \ --module-path=$HOME/lib/armv6hf-sdk/lib \ --add-modules=javafx.graphics \ -Dprism.order=sw -Djavafx.animation.pulse=8 \ -Dglass.platform=Monocle -Dmonocle.platform=VNC \ -jar dist/epd-javafx.jar \ --width=1024 --height=600 --pattern=3 --loops=0 ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From nlisker at openjdk.java.net Wed Jul 1 06:33:32 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 1 Jul 2020 06:33:32 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com> Message-ID: On Wed, 13 May 2020 23:50:37 GMT, Kevin Rushforth wrote: >>> We should make sure that we aren't seeing any significant performance drop when rendering spheres (at a couple >>> different tessellation levels) or boxes. >> >> I missed this. Do you mean that the test should create a mesh of a sphere instead of a flat surface? > > I would say in addition to rather than instead of, since both are useful. > > What might help is to add the sphere test plus the pathological test I put together into your test program so we can > select between them. And then get a few of us to run that updated program and post results. I've added sphere with 10, 64 (default) and 200 divisions. Note that this number is approximate because the sphere mesh corrects the division number with `newDivisions = ((oldDivisions + 3) / 4) * 4`. [attenTest.zip](https://github.com/openjdk/jfx/files/4855989/attenTest.zip) Using AMD RX 470 4GB on Win 10, all 3 spheres averaged 120 fps both before and after the patch. (It takes a couple of measurements to hit the consistent fps, so I discarded them.) ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From github.com+7450507+fthevenet at openjdk.java.net Wed Jul 1 09:19:26 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 1 Jul 2020 09:19:26 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v14] In-Reply-To: References: Message-ID: <0KyRvcTaO9taJc6c_lyFercAoFdx_2IQmnSRNbPFz3M=.36750b2a-a902-4968-9aa8-a969caa83e51@github.com> On Tue, 30 Jun 2020 21:22:14 GMT, Ambarish Rapte wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Prevent attempt to render tiles with a 0 sized dimension. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1638: > >> 1637: renderWholeImage(x, y, w, h, rf, pImage); >> 1638: } >> 1639: params.platformImage = pImage; > > I tried to write this code using for loop to make it little easy for reader to understand. This is just a suggestion, I > leave it to you to whether replace it or not, > int mTileWidth = computeTileSize(w, maxTextureSize); > int mTileHeight = computeTileSize(h, maxTextureSize); > IntBuffer buffer = IntBuffer.allocate(mTileWidth * mTileHeight); > > int mTileXOffset = 0; > int mTileYOffset = 0; > for (mTileXOffset = 0; (mTileXOffset + mTileWidth) <= w; mTileXOffset += mTileWidth) { > for (mTileYOffset = 0; (mTileYOffset + mTileHeight) <= h; mTileYOffset += mTileHeight) { > renderTile(x, mTileXOffset, y, mTileYOffset, mTileWidth, mTileHeight, > buffer, rf, tileRttCache, pImage); > } > } > > int rTileXOffset = mTileXOffset; > int rTileWidth = w - rTileXOffset; > if (rTileWidth > 0) { > for (int rTileYOffset = 0; (rTileYOffset + mTileHeight) <= h; rTileYOffset += mTileHeight) { > renderTile(x, rTileXOffset, y, rTileYOffset, rTileWidth, mTileHeight, > buffer, rf, tileRttCache, pImage); > } > } > > int bTileYOffset = mTileYOffset; > int bTileHeight = h - bTileYOffset; > if (bTileHeight > 0) { > for (int bTileXOffset = 0; (bTileXOffset + mTileWidth) <= w; bTileXOffset += mTileWidth) { > renderTile(x, bTileXOffset, y, bTileYOffset, mTileWidth, bTileHeight, > buffer, rf, tileRttCache, pImage); > } > } > > if (rTileWidth > 0 && bTileHeight > 0) { > renderTile(x, rTileXOffset, y, bTileYOffset, rTileWidth, bTileHeight, > buffer, rf, tileRttCache, pImage); > } Thanks for you suggestion. The original code is still too fresh in my mind for me to really be able to say which version is easier to understand, so I'll let others with a fresh pair of eyes be the judge of that. However I think your code is arguably more concise - and overall more elegant - so I'd be happy to swap my version for yours, provided it is considered at least as readable as the original. WDYT? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Wed Jul 1 09:44:05 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 1 Jul 2020 09:44:05 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v15] In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: - Removed unused imports in Snapshot2Test - Fixed comments in QuantumToolkit - Only initialize RTT cache if needed ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/c0f7d14f..d8083075 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.14 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.13-14 Stats: 10 lines in 2 files changed: 3 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From jvos at openjdk.java.net Wed Jul 1 12:11:05 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 1 Jul 2020 12:11:05 GMT Subject: RFR: 8248317: Change JavaFX release version to 16 In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 15:30:31 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 16. I will integrate this immediately after forking the `jfx15` stabilization > branch. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/260 From jvos at openjdk.java.net Wed Jul 1 12:12:37 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 1 Jul 2020 12:12:37 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> Message-ID: <6o8qSlwswav0zA97KO1AcFkc9S9N10m5T4O1WiGs5Fk=.28d3812f-a8cd-4c80-990b-af07aaf1c084@github.com> On Mon, 29 Jun 2020 18:49:33 GMT, John Neffenger wrote: >> The rationale makes sense (open/open/close) instead of (open/close/open) > > Based on my notes below, I believe this change is safe for any Linux input device driver because the driver shouldn't > receive the intermediate *open* and *close* calls at all. > Nonetheless, it would be reassuring if someone could try [this change](https://github.com/openjdk/jfx/pull/258/files) > just once on a mainstream device, such as the Raspberry Pi with a touchscreen LCD panel. I only have six obscure ARM > devices and a headless QEMU ARM virtual machine for testing. @johanvos or @dellgreen - Is that something you could > test? If you think it's overkill and not worth it, that's fine, too. #### Notes > The Linux kernel documentation about [opening and > closing](https://www.kernel.org/doc/html/latest/input/input-programming.html#dev-open-and-dev-close) input devices > states: >> Note that input core keeps track of number of users for the device and makes sure that dev->open() is called only when >> the first user connects to the device and that dev->close() is called when the very last user disconnects. Calls to >> both callbacks are serialized. > > Also, the Linux Programmer's Manual for the *close* system call (`man 2 close`) states: > >> If *fd* is the last file descriptor referring to the underlying open file description (see **open**(2)), the resources >> associated with the open file description are freed. > > Running a JavaFX program with `strace -f -e trace=open,close -o strace.log` shows the one *open* for the *event0* > keyboard, and the *open, open, close* for the *event1* touchscreen: > 5847 open("/dev/input/event0", O_RDONLY) = 11 > ... > 5847 open("/dev/input/event1", O_RDONLY) = 12 > 5847 open("/dev/input/event1", O_RDONLY) = 13 > 5847 close(13) = 0 > > Both devices are actually closed by the kernel when the JavaFX program ends. I don't have access to a Pi right now, so I can't test this (I'll be able to test in about 10 days from now though) ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From kcr at openjdk.java.net Wed Jul 1 12:25:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 12:25:56 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v14] In-Reply-To: <0KyRvcTaO9taJc6c_lyFercAoFdx_2IQmnSRNbPFz3M=.36750b2a-a902-4968-9aa8-a969caa83e51@github.com> References: <0KyRvcTaO9taJc6c_lyFercAoFdx_2IQmnSRNbPFz3M=.36750b2a-a902-4968-9aa8-a969caa83e51@github.com> Message-ID: <80X5fauiatDQTwUytQH_D8rHzep2YHB35OE_-WhfNLY=.936b6099-783e-47b5-b20a-82a6e941f278@github.com> On Wed, 1 Jul 2020 09:17:16 GMT, Frederic Thevenet wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1638: >> >>> 1637: renderWholeImage(x, y, w, h, rf, pImage); >>> 1638: } >>> 1639: params.platformImage = pImage; >> >> I tried to write this code using for loop to make it little easy for reader to understand. This is just a suggestion, I >> leave it to you to whether replace it or not, >> int mTileWidth = computeTileSize(w, maxTextureSize); >> int mTileHeight = computeTileSize(h, maxTextureSize); >> IntBuffer buffer = IntBuffer.allocate(mTileWidth * mTileHeight); >> >> int mTileXOffset = 0; >> int mTileYOffset = 0; >> for (mTileXOffset = 0; (mTileXOffset + mTileWidth) <= w; mTileXOffset += mTileWidth) { >> for (mTileYOffset = 0; (mTileYOffset + mTileHeight) <= h; mTileYOffset += mTileHeight) { >> renderTile(x, mTileXOffset, y, mTileYOffset, mTileWidth, mTileHeight, >> buffer, rf, tileRttCache, pImage); >> } >> } >> >> int rTileXOffset = mTileXOffset; >> int rTileWidth = w - rTileXOffset; >> if (rTileWidth > 0) { >> for (int rTileYOffset = 0; (rTileYOffset + mTileHeight) <= h; rTileYOffset += mTileHeight) { >> renderTile(x, rTileXOffset, y, rTileYOffset, rTileWidth, mTileHeight, >> buffer, rf, tileRttCache, pImage); >> } >> } >> >> int bTileYOffset = mTileYOffset; >> int bTileHeight = h - bTileYOffset; >> if (bTileHeight > 0) { >> for (int bTileXOffset = 0; (bTileXOffset + mTileWidth) <= w; bTileXOffset += mTileWidth) { >> renderTile(x, bTileXOffset, y, bTileYOffset, mTileWidth, bTileHeight, >> buffer, rf, tileRttCache, pImage); >> } >> } >> >> if (rTileWidth > 0 && bTileHeight > 0) { >> renderTile(x, rTileXOffset, y, bTileYOffset, rTileWidth, bTileHeight, >> buffer, rf, tileRttCache, pImage); >> } > > Thanks for you suggestion. > > The original code is still too fresh in my mind for me to really be able to say which version is easier to understand, > so I'll let others with a fresh pair of eyes be the judge of that. However I think your code is arguably more concise - > and overall more elegant - so I'd be happy to swap my version for yours, provided it is considered at least as readable > as the original. WDYT? We'll leave it up to you, but I note that it will require retesting if you adopt the suggested change. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+2720909+jskov at openjdk.java.net Wed Jul 1 12:15:05 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Wed, 1 Jul 2020 12:15:05 GMT Subject: Integrated: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: <6spcDi6gClMnP0siTkbDNNxVHP9jYKom78t4HOByepE=.29f5d165-a74f-44f6-abde-8b964b545354@github.com> On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov wrote: > I have tested on Linux (Fedora 31) only. > It works as intended (with one test failure due to 15-ea+4 being too old now). > > UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. > But as I could not find anything about it, that section in the documentation may need some love. This pull request has now been integrated. Changeset: 869ea404 Author: Jesper Skov Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/869ea404 Stats: 106 lines in 2 files changed: 3 ins; 97 del; 6 mod 8244212: Optionally download media and webkit libraries from latest openjfx EA build Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From jvos at openjdk.java.net Wed Jul 1 12:13:36 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 1 Jul 2020 12:13:36 GMT Subject: RFR: 8201570: Get two bytes for the Linux input event type, not four In-Reply-To: References: Message-ID: <6i8gYO6SuN204NQ_4Tn9hdlAwtxbsfWjfb9k6shm_2U=.1cccd914-d9a5-45c9-a762-d954217730d2@github.com> On Mon, 29 Jun 2020 11:31:41 GMT, Johan Vos wrote: >> Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). > > This fixes a bug that currently didn't cause any harm > (https://bugs.openjdk.java.net/browse/JDK-8201570?focusedCommentId=14172176) , but it's better to fix it now. @jgneff you can proceed with this and integrate it. Once you do that, I'll sponsor the commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/257 From kcr at openjdk.java.net Wed Jul 1 13:21:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 13:21:31 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v15] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 09:44:05 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > - Removed unused imports in Snapshot2Test > - Fixed comments in QuantumToolkit > - Only initialize RTT cache if needed Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kevin.rushforth at oracle.com Wed Jul 1 13:29:18 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Jul 2020 06:29:18 -0700 Subject: FINAL REMINDER: JavaFX 15 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 15] In-Reply-To: <94814ae6-dd2c-ee3f-5d5f-bc0007901172@oracle.com> References: <94814ae6-dd2c-ee3f-5d5f-bc0007901172@oracle.com> Message-ID: As a reminder, RDP1 starts tomorrow. I will fork the 'jfx15' branch at 16:00 UTC. -- Kevin On 6/18/2020 9:38 AM, Kevin Rushforth wrote: > As a reminder, RDP1 for JavaFX 15 starts on July 2, 2020 at 16:00 UTC > (09:00 Pacific time), which is two weeks from today. > > Please allow sufficient time for any feature that needs a CSR. New > features should be far enough along in the review process that you can > finalize the CSR before Thursday, June 25, or it is likely to miss the > window for this release, in which case it can be targeted for JavaFX 16. > > During rampdown of JavaFX 15, the "master" branch of the jfx repo will > be open for JavaFX 16 fixes. > > We will follow the same process as previous releases for getting fixes > into JavaFX 15 during rampdown. I'll send a message with detailed > information later, but candidates for fixing during RDP1 are P1-P3 > bugs (as long as they are not risky) and test or doc bugs of any > priority. Some small enhancements might be considered during RDP1, but > they require explicit approval; the bar will be high for such requests. > > -- Kevin > > > On 3/12/2020 10:11 AM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 15. >> >> RDP1: Jul 2, 2020 (aka ?feature freeze?) >> RDP2: Jul 30, 2020 >> Freeze: Aug 20, 2020 >> GA: September 8, 2020 >> >> We plan to fork a jfx15 stabilization branch at RDP1. The GA date is >> expected to be one week ahead of JDK 15, matching what we did for 14. >> >> As a slight change from previous releases, the start of RDP1, the >> start of RDP2, and the code freeze will be 16:00 UTC on the >> respective dates. >> >> Please let Johan or me know if you have any questions. >> >> -- Kevin >> > From arapte at openjdk.java.net Wed Jul 1 13:44:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 1 Jul 2020 13:44:45 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v15] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 09:44:05 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > - Removed unused imports in Snapshot2Test > - Fixed comments in QuantumToolkit > - Only initialize RTT cache if needed Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Wed Jul 1 14:32:14 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 1 Jul 2020 14:32:14 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v15] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 13:42:12 GMT, Ambarish Rapte wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> - Removed unused imports in Snapshot2Test >> - Fixed comments in QuantumToolkit >> - Only initialize RTT cache if needed > > Marked as reviewed by arapte (Reviewer). I have read Ambarish's code more closely and I am now convinced it is indeed easier to understand; beyond the change from "while" to "for" loops, it introduces an extra set of variables which avoids the same "m/b/rTileWidth/Height" vars to have to designate different things depending in which loop they're used (M, B, or R). In hindsight, this is why I had such a hard time naming them. I have run the automated tests on Windows and Ubuntu (w/ forceGPU=true) and it passes. The benchmark I made also produces similar results. Someone will still need to run the tests on macOS, I'm afraid. If it's not too much of a problem now that the PR's been approved, I think it would beneficial to make the change, especially considering that this bit of code might be used as a starting point for other issues requiring tiling. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Wed Jul 1 15:13:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 15:13:21 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v15] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 14:29:55 GMT, Frederic Thevenet wrote: >> Marked as reviewed by arapte (Reviewer). > > I have read Ambarish's code more closely and I am now convinced it is indeed easier to understand; beyond the change > from "while" to "for" loops, it introduces an extra set of variables which avoids the same "m/b/rTileWidth/Height" vars > to have to designate different things depending in which loop they're used (M, B, or R). In hindsight, this is why I > had such a hard time naming them. I have run the automated tests on Windows and Ubuntu (w/ forceGPU=true) and it > passes. The benchmark I made also produces similar results. Someone will still need to run the tests on macOS, I'm > afraid. If it's not too much of a problem now that the PR's been approved, I think it would beneficial to make the > change, especially considering that this bit of code might be used as a starting point for other issues requiring > tiling. That would be fine with me. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From danny.gonzalez at screamingfrog.co.uk Wed Jul 1 12:50:41 2020 From: danny.gonzalez at screamingfrog.co.uk (Danny Gonzalez) Date: Wed, 1 Jul 2020 12:50:41 +0000 Subject: MacOS Big Sur and OpenJFX on Arm Macs Message-ID: Hi All, Not sure if this is the correct place to direct this conversation but here goes. With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, what are the plans to ensure that OpenJFX and Java will run on this platform? Are there plans to get the Developer Transition Kit to test on real hardware prior to the release of consumer hardware? Are there testers testing on MacOs beta? Will OpenJFX and Java be able to run natively in this new Arm Mac environment? Will OpenJFX and Java be able to run in the Rosetta emulator? We have many MacOS customers, many of whom will be early adopters and upgrade to the new Arm Macs so this could be a big issue for us. Thanks Danny From kcr at openjdk.java.net Wed Jul 1 17:46:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 17:46:18 GMT Subject: RFR: 8247963: Update SQLite to version 3.32.3 In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html @guruhb @bhaweshkc can one of you review this as well? ------------- PR: https://git.openjdk.java.net/jfx/pull/261 From ajoseph at openjdk.java.net Wed Jul 1 17:46:18 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 1 Jul 2020 17:46:18 GMT Subject: RFR: 8247963: Update SQLite to version 3.32.3 Message-ID: We currently use SQLite version 3.31.1. We should update to the latest stable release version 3.32.3 released on 2020-06-18. https://www.sqlite.org/index.html ------------- Commit messages: - 8247963: Update SQLite to version 3.32.3 Changes: https://git.openjdk.java.net/jfx/pull/261/files Webrev: https://webrevs.openjdk.java.net/jfx/261/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247963 Stats: 4409 lines in 4 files changed: 2488 ins; 1057 del; 864 mod Patch: https://git.openjdk.java.net/jfx/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/261/head:pull/261 PR: https://git.openjdk.java.net/jfx/pull/261 From kcr at openjdk.java.net Wed Jul 1 17:54:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 17:54:31 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v16] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 16:20:53 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with two additional commits since the last revision: > > - Mark variables as final > - Using for loops instead of while Looks good. Sanity tested on all three platforms. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1589: > 1588: int mTileWidth = computeTileSize(w, maxTextureSize); > 1589: int mTileHeight = computeTileSize(h, maxTextureSize); > 1590: IntBuffer buffer = IntBuffer.allocate(mTileWidth * mTileHeight); I'll test it soon. Since these variables no longer change, maybe you could make them `final`? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Wed Jul 1 17:54:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 17:54:31 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v15] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 14:29:55 GMT, Frederic Thevenet wrote: > Someone will still need to run the tests on macOS, I'm afraid. I'll do a quick sanity test on all three platforms. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Wed Jul 1 17:54:29 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 1 Jul 2020 17:54:29 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v16] In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with two additional commits since the last revision: - Mark variables as final - Using for loops instead of while ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/d8083075..58cc2000 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.15 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.14-15 Stats: 37 lines in 1 file changed: 3 ins; 14 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From nlisker at openjdk.java.net Wed Jul 1 18:00:24 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 1 Jul 2020 18:00:24 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 11:23:01 GMT, Johan Vos wrote: >> I have tested on Linux (Fedora 31) only. >> It works as intended (with one test failure due to 15-ea+4 being too old now). >> >> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. >> But as I could not find anything about it, that section in the documentation may need some love. > > Marked as reviewed by jvos (Reviewer). Do the build instructions need to be updated? ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From arapte at openjdk.java.net Wed Jul 1 18:08:25 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 1 Jul 2020 18:08:25 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v16] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 17:54:29 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with two additional commits since the last revision: > > - Mark variables as final > - Using for loops instead of while Verified On Mac and Windows10, looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/112 From jvos at openjdk.java.net Wed Jul 1 18:29:20 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 1 Jul 2020 18:29:20 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 17:58:10 GMT, Nir Lisker wrote: >> Marked as reviewed by jvos (Reviewer). > > Do the build instructions need to be updated? The build instruction can indeed refer to WEBKIT-MEDIA-STUBS.md now. ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From github.com+7450507+fthevenet at openjdk.java.net Wed Jul 1 18:53:30 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 1 Jul 2020 18:53:30 GMT Subject: Integrated: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Wed, 12 Feb 2020 13:21:03 GMT, Frederic Thevenet wrote: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. This pull request has now been integrated. Changeset: 32584dba Author: Frederic Thevenet Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/32584dba Stats: 395 lines in 3 files changed: 64 ins; 313 del; 18 mod 8238954: Improve performance of tiled snapshot rendering Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Wed Jul 1 20:11:28 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Jul 2020 20:11:28 GMT Subject: RFR: 8247963: Update SQLite to version 3.32.3 In-Reply-To: References: Message-ID: <3ezupyDPuswDi0nJIgyijF_5x4XiLRQvk4kRkj3jsK4=.68ec28d9-5671-42a8-8f21-24c80c1ec763@github.com> On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html Looks good. Tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/261 From swpalmer at gmail.com Thu Jul 2 00:46:14 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 1 Jul 2020 20:46:14 -0400 Subject: MacOS Big Sur and OpenJFX on Arm Macs In-Reply-To: References: Message-ID: JavaFX already runs on some Arm-based devices like the Raspberry Pi, so I expect an Arm-based port for new Macs won?t be that big of a job (relatively speaking) Hopefully by that time there will be a Metal-base rendering pipeline as well. The Metal-based pipeline for Swing seems to be coming along nicely. I don?t know if Oracle has access to one of the early developer boxes that runs macOS on arm or not. If they don?t, then a Java/Java FX port may not be available on day 1. That being said, perhaps Rosetta 2 will run the JDK/JRE until a proper port is available. I don?t know if the JIT compiler will work with Rosetta though. If it doesn?t then that certainly makes a proper port more urgent. Scott > On Jul 1, 2020, at 2:13 PM, Danny Gonzalez wrote: > > ?Hi All, > > Not sure if this is the correct place to direct this conversation but here goes. > > With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, what are the plans to ensure that OpenJFX and Java will run on this platform? > > Are there plans to get the Developer Transition Kit to test on real hardware prior to the release of consumer hardware? > Are there testers testing on MacOs beta? > > Will OpenJFX and Java be able to run natively in this new Arm Mac environment? > Will OpenJFX and Java be able to run in the Rosetta emulator? > > We have many MacOS customers, many of whom will be early adopters and upgrade to the new Arm Macs so this could be a big issue for us. > > Thanks > > Danny > > From rlichten at openjdk.java.net Thu Jul 2 05:29:05 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 2 Jul 2020 05:29:05 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v7] In-Reply-To: References: Message-ID: > This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Clamping is no longer needed, removed it. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/138/files - new: https://git.openjdk.java.net/jfx/pull/138/files/660335bf..bf9e08d7 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/138/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.05-06 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138 PR: https://git.openjdk.java.net/jfx/pull/138 From rlichten at openjdk.java.net Thu Jul 2 05:29:16 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 2 Jul 2020 05:29:16 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v6] In-Reply-To: References: <5dDCIGDVd43vo4JtxBVmSlPpZAhMjMKV5es8BZ6nj6c=.90895611-47ba-4f08-8232-3d2edd95dcf5@github.com> Message-ID: On Tue, 30 Jun 2020 23:05:40 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException >> >> Move replaceSelectionAtEndWithListener test to general test class. >> Add a more general test for selection/text properties and replace/undo/redo operations. > > modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 186: > >> 185: int length = txt.length(); >> 186: if (end > start + length) end = length; >> 187: if (start > length-1) start = end = 0; > > As I mentioned in [this comment in PR #73](https://github.com/openjdk/jfx/pull/73#discussion_r376528686), I think this > test is wrong. The value of `start` has no impact on whether `end` is out of range. So... shouldn't this simply be `if > (end > length) end = length;` ? You're right. The whole point of the fix was to remove the need for any clamping by preventing the "in-between" updates of the selected text property. I've checked that the condition in line 186 is never fulfilled now anymore and removed it. I've also removed the clamping in the line below, because the only case where start > length-1 is now that start == length in which case also end == length and txt.substring(length, length) will be just as empty as txt.substring(0, 0). ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Thu Jul 2 12:43:50 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Jul 2020 12:43:50 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 05:43:29 GMT, John Neffenger wrote: >>> It will also need to be tested using the SW pipeline on all platforms. >> >> Thanks for the reminder. I managed to build JavaFX on Windows and macOS today, so I'll test this pull request on those >> platforms in addition to Linux desktop and embedded. > > I tested this pull request on all of the following platforms: > > * JavaFX desktop platforms (*amd64* architecture) > * Windows SDK on Windows 10 Pro Version 2004 > * Mac OS X SDK on macOS 10.15.5 (Catalina) > * Linux SDK on Ubuntu 16.04.6 LTS (Xenial Xerus) > > * JavaFX embedded platforms (*armhf* architecture) > * armv6hf SDK (Monocle EPD) on Ubuntu 14.04.6 LTS (Trusty Tahr) > * armv6hf SDK (Monocle VNC) on Ubuntu 20.04 LTS (Focal Fossa) > > This is a tricky timing problem on most platforms, so I used rather intrusive techniques to catch the error and verify > it was fixed. The bug is easily visible only on the Monocle VNC platform. > ### Desktop > > I tested the desktop platforms as follows: > > 1. I added `assert` statements and calls to `Thread.sleep` as shown by [this > commit](https://github.com/jgneff/javafx-graphics/commit/ffc639e4) to catch the error. It looks like a lot of changes, > but they simply call `sleep` to change the timing of the threads so that the JavaFX Application Thread is unable to > keep up with the QuantumRenderer. The `assert` statements catch the error when the rendering thread starts looking for > an unused buffer. > All platforms printed many `InvalidMarkException` errors as the buffer position was modified while in use on the JavaFX > application thread. The Linux and Windows platforms printed, "Exception in thread 'JavaFX Application Thread' > java.nio.InvalidMarkException," while the macOS platform printed, "Exception in thread 'AppKit Thread' > java.nio.InvalidMarkException." > > 2. I applied the fix to call `getBuffer` instead of `getPixels` in `QueuedPixelSource`. > > 3. After the fix, no errors were detected by the assertions on any of the platforms. > > ### Embedded > > I tested the embedded platforms as follows: > > 1. I added only `assert` statements to the `HeadlessScreen` and `EPDScreen` classes, as shown below. Both platforms > printed many `InvalidMarkException` errors as the buffer position was modified while in use on the JavaFX application > thread. 2. I applied the fix to call `getBuffer` instead of `getPixels` in `QueuedPixelSource`. > > 3. After the fix, no errors were detected by the assertions on either platform. > > #### `HeadlessScreen` and `EPDScreen` > > @Override > public synchronized void uploadPixels(Buffer b, int x, int y, > int width, int height, float alpha) { > + assert b.mark() == b; > pixels.composePixels(b, x, y, width, height, alpha); > + assert b.reset() == b; > } > > For the Monocle VNC platform, you can also simply connect and watch the bug corrupt the frames sent to the VNC client, > as shown in my prior comment on this pull request. > ### Other results > > I found some unexpected results, listed below. > > * JavaFX on Linux does not limit its frame rate to 60 Hz when using the hardware pipeline, reaching over 350 frames per > second. > > * JavaFX on macOS ignores the system property `-Djavafx.animation.pulse=8` and runs at 60 Hz, even though it prints the > message "Setting PULSE_DURATION to 8 hz." > > * JavaFX on macOS prints the error shown below when `Platform.exit` is called to end the application. The error also > occurs on JavaFX 14.0.1 and 15-ea+6. The error does not occur when the window is closed manually using the mouse. > > Java has been detached already, but someone is still trying to use it at > -[GlassViewDelegate dealloc]: > /Users/john/src/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m:204 > 0 libglass.dylib 0x000000010eb6c05d -[GlassViewDelegate dealloc] + 221 > 1 libglass.dylib 0x000000010eb71af6 -[GlassView3D dealloc] + 246 > 2 libobjc.A.dylib 0x00007fff66937054 _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 134 > 3 libobjc.A.dylib 0x00007fff6691bdba objc_autoreleasePoolPop + 175 > 4 CoreFoundation 0x00007fff2dad23c5 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 > 5 CoreFoundation 0x00007fff2dad22f7 __CFRunLoopDoObservers + 457 > 6 CoreFoundation 0x00007fff2dad1895 __CFRunLoopRun + 874 > 7 CoreFoundation 0x00007fff2dad0ece CFRunLoopRunSpecific + 462 > 8 libjli.dylib 0x000000010be945c1 CreateExecutionEnvironment + 399 > 9 libjli.dylib 0x000000010be90752 JLI_Launch + 1354 > 10 java 0x000000010be83ca1 main + 375 > 11 libdyld.dylib 0x00007fff67acdcc9 start + 1 > 12 ??? 0x000000000000000b 0x0 + 11 > > ### Test scripts > > Below are the scripts I used to run the tests. The scripts include the system property `-Djavafx.animation.pulse=8`, > but I removed it when trying to recreate the bug with the added `assert` and `sleep` statements. > #### Linux > > #!/bin/bash > # Linux desktop > $HOME/opt/jdk-14.0.1/bin/java -ea --show-version \ > --module-path=$HOME/lib/javafx-sdk-dev/lib \ > --add-modules=javafx.graphics \ > -Dprism.order=sw -Djavafx.animation.pulse=8 \ > -jar dist/epd-javafx.jar \ > --width=800 --height=600 --pattern=3 --loops=0 > > #### macOS > > #!/bin/bash > # macOS desktop > $HOME/opt/jdk-14.0.1.jdk/Contents/Home/bin/java -ea --show-version \ > --module-path=$HOME/lib/javafx-sdk-dev/lib \ > --add-modules=javafx.graphics \ > -Dprism.order=sw -Djavafx.animation.pulse=8 \ > -jar dist/epd-javafx.jar \ > --width=800 --height=600 --pattern=3 --loops=0 > > #### Windows > > #!/bin/bash > # Windows desktop under Cygwin > $HOME/opt/jdk-14.0.1/bin/java -ea --show-version \ > --module-path=$(cygpath -m $HOME/lib/javafx-sdk-dev/lib) \ > --add-modules=javafx.graphics \ > -Dprism.order=sw -Djavafx.animation.pulse=8 \ > -jar dist/epd-javafx.jar \ > --width=800 --height=600 --pattern=3 --loops=0 > > REM Windows desktop under Command Prompt > C:\cygwin64\home\john\opt\jdk-14.0.1\bin\java -ea --show-version^ > --module-path=C:/cygwin64/home/john/lib/javafx-sdk-dev/lib^ > --add-modules=javafx.graphics^ > -Dprism.order=sw -Djavafx.animation.pulse=8^ > -jar dist\epd-javafx.jar^ > --width=800 --height=600 --pattern=3 --loops=0 > > #### Monocle EPD > > Run with `sudo`. > > #!/bin/bash > # Monocle EPD platform on Linux armhf > $HOME/opt/jdk-14.0.1+7/bin/java -ea --show-version \ > --module-path=$HOME/lib/armv6hf-sdk/lib \ > --add-modules=javafx.graphics \ > -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ > -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ > -Dmonocle.epd.waveformMode=4 -jar dist/epd-javafx.jar \ > --width=800 --height=600 --pattern=3 --loops=0 > > #### Monocle VNC > > #!/bin/bash > # Monocle VNC platform on Linux armhf > /usr/lib/jvm/java-14-openjdk-armhf/bin/java -ea --show-version \ > --module-path=$HOME/lib/armv6hf-sdk/lib \ > --add-modules=javafx.graphics \ > -Dprism.order=sw -Djavafx.animation.pulse=8 \ > -Dglass.platform=Monocle -Dmonocle.platform=VNC \ > -jar dist/epd-javafx.jar \ > --width=1024 --height=600 --pattern=3 --loops=0 > Does this fix the years old Linux JavaFX buffer reset bug? Possibly. This is a race condition that can affect the use of `UploadingPainter`, which is used by the SW pipeline. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kevin.rushforth at oracle.com Thu Jul 2 12:48:59 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Jul 2020 05:48:59 -0700 Subject: MacOS Big Sur and OpenJFX on Arm Macs In-Reply-To: References: Message-ID: <02ef668c-1ccc-8f6a-3430-006f731e0318@oracle.com> At WWDC, Apple indicated that they have run the JDK on prototype Arm HW using Rosetta2. Once we get our hands on some HW we'll test JavaFX as well. I expect that it will run reasonably well. I think that an ARM port for JavaFX won't be too difficult, although I doubt the existence of Linux ARM for embedded platforms will help much with the Mac. Most of the work will be upgrading to Xcode 12 and producing universal (fat) binaries again, which we did back in the very early days for ppc and intel. As for a Metal port, we do plan to get started on that soon (we've done some very preliminary looking). -- Kevin On 7/1/2020 5:46 PM, Scott Palmer wrote: > JavaFX already runs on some Arm-based devices like the Raspberry Pi, so I expect an Arm-based port for new Macs won?t be that big of a job (relatively speaking) > > Hopefully by that time there will be a Metal-base rendering pipeline as well. The Metal-based pipeline for Swing seems to be coming along nicely. > > I don?t know if Oracle has access to one of the early developer boxes that runs macOS on arm or not. If they don?t, then a Java/Java FX port may not be available on day 1. That being said, perhaps Rosetta 2 will run the JDK/JRE until a proper port is available. I don?t know if the JIT compiler will work with Rosetta though. If it doesn?t then that certainly makes a proper port more urgent. > > > Scott > >> On Jul 1, 2020, at 2:13 PM, Danny Gonzalez wrote: >> >> ?Hi All, >> >> Not sure if this is the correct place to direct this conversation but here goes. >> >> With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, what are the plans to ensure that OpenJFX and Java will run on this platform? >> >> Are there plans to get the Developer Transition Kit to test on real hardware prior to the release of consumer hardware? >> Are there testers testing on MacOs beta? >> >> Will OpenJFX and Java be able to run natively in this new Arm Mac environment? >> Will OpenJFX and Java be able to run in the Rosetta emulator? >> >> We have many MacOS customers, many of whom will be early adopters and upgrade to the new Arm Macs so this could be a big issue for us. >> >> Thanks >> >> Danny >> >> From johan.vos at gluonhq.com Thu Jul 2 13:17:22 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 2 Jul 2020 15:17:22 +0200 Subject: MacOS Big Sur and OpenJFX on Arm Macs In-Reply-To: <02ef668c-1ccc-8f6a-3430-006f731e0318@oracle.com> References: <02ef668c-1ccc-8f6a-3430-006f731e0318@oracle.com> Message-ID: This is probably a toolchain issue indeed. There shouldn't be a real difference between OpenJFX and other Mac applications. It's probably (hopefully) just compiling/linking with a few specific flags to set the CPU. - Johan On Thu, Jul 2, 2020 at 2:51 PM Kevin Rushforth wrote: > At WWDC, Apple indicated that they have run the JDK on prototype Arm HW > using Rosetta2. Once we get our hands on some HW we'll test JavaFX as > well. I expect that it will run reasonably well. > > I think that an ARM port for JavaFX won't be too difficult, although I > doubt the existence of Linux ARM for embedded platforms will help much > with the Mac. Most of the work will be upgrading to Xcode 12 and > producing universal (fat) binaries again, which we did back in the very > early days for ppc and intel. > > As for a Metal port, we do plan to get started on that soon (we've done > some very preliminary looking). > > -- Kevin > > > On 7/1/2020 5:46 PM, Scott Palmer wrote: > > JavaFX already runs on some Arm-based devices like the Raspberry Pi, so > I expect an Arm-based port for new Macs won?t be that big of a job > (relatively speaking) > > > > Hopefully by that time there will be a Metal-base rendering pipeline as > well. The Metal-based pipeline for Swing seems to be coming along nicely. > > > > I don?t know if Oracle has access to one of the early developer boxes > that runs macOS on arm or not. If they don?t, then a Java/Java FX port may > not be available on day 1. That being said, perhaps Rosetta 2 will run the > JDK/JRE until a proper port is available. I don?t know if the JIT compiler > will work with Rosetta though. If it doesn?t then that certainly makes a > proper port more urgent. > > > > > > Scott > > > >> On Jul 1, 2020, at 2:13 PM, Danny Gonzalez < > danny.gonzalez at screamingfrog.co.uk> wrote: > >> > >> ?Hi All, > >> > >> Not sure if this is the correct place to direct this conversation but > here goes. > >> > >> With the imminent arrival of Arm Macs in late 2020 running MacOS Big > Sur, what are the plans to ensure that OpenJFX and Java will run on this > platform? > >> > >> Are there plans to get the Developer Transition Kit to test on real > hardware prior to the release of consumer hardware? > >> Are there testers testing on MacOs beta? > >> > >> Will OpenJFX and Java be able to run natively in this new Arm Mac > environment? > >> Will OpenJFX and Java be able to run in the Rosetta emulator? > >> > >> We have many MacOS customers, many of whom will be early adopters and > upgrade to the new Arm Macs so this could be a big issue for us. > >> > >> Thanks > >> > >> Danny > >> > >> > > From ghb at openjdk.java.net Thu Jul 2 13:24:30 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 2 Jul 2020 13:24:30 GMT Subject: RFR: 8247963: Update SQLite to version 3.32.3 In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html Looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/261 From ajoseph at openjdk.java.net Thu Jul 2 13:32:57 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 2 Jul 2020 13:32:57 GMT Subject: Integrated: 8247963: Update SQLite to version 3.32.3 In-Reply-To: References: Message-ID: <5ro8jkkr1tgJn3-ik405frbzOXRBNcIUYFZAxN05gtA=.db331513-ccf1-459e-9b27-5672dce7b5c6@github.com> On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html This pull request has now been integrated. Changeset: f3a04465 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/f3a04465 Stats: 4413 lines in 4 files changed: 1061 ins; 2492 del; 860 mod 8247963: Update SQLite to version 3.32.3 Reviewed-by: kcr, ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/261 From github.com+1413266+jgneff at openjdk.java.net Thu Jul 2 15:32:20 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 2 Jul 2020 15:32:20 GMT Subject: Integrated: 8201570: Get two bytes for the Linux input event type, not four In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 00:12:41 GMT, John Neffenger wrote: > Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). This pull request has now been integrated. Changeset: 126637f5 Author: John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/126637f5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8201570: Get two bytes for the Linux input event type, not four Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/257 From kcr at openjdk.java.net Thu Jul 2 16:09:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Jul 2020 16:09:32 GMT Subject: Integrated: 8248317: Change JavaFX release version to 16 In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 15:30:31 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 16. I will integrate this immediately after forking the `jfx15` stabilization > branch. This pull request has now been integrated. Changeset: a4f31505 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a4f31505 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8248317: Change JavaFX release version to 16 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/260 From kevin.rushforth at oracle.com Thu Jul 2 16:13:42 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Jul 2020 09:13:42 -0700 Subject: JavaFX 15 is in Rampdown Phase One (RDP1) Message-ID: JavaFX 15 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx15 branch [2] for stabilizing the JavaFX 15 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for openjfx16. Most fixes will be integrated to master for 16. - The jfx15 branch of the jfx repo is now open for integrating fixes for openjfx15 that meet the RDP1 criteria as outlined below. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. - I will periodically sync jfx15 --> master, meaning that developers should integrate fixes to one or the other, not both DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx15 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx15. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx15 branch. The master branch is open for all openjfx16 fixes, including enhancements. As a reminder, we are using a single openjdk/jfx GitHub repo with stabilization branches [3] rather than creating separate stabilization repos. The jfx15 branch is used to stabilize the upcoming openjfx15 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx15 to ensure that it doesn't contain any commits from master after the jfx15 fork date. What that means is that if you intend a PR to be for jfx15, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 16 as of today). This is usually what we want. A PR should be targeted to `jfx15` if, and only if, it is intended for OpenJFX 15 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx15`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 16. Reviewers also need to be extra careful when reviewing PRs targeted to jfx15 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. We will use the same rules for RDP1 that the JDK uses [4], with the same three modifications we did for the previous release: 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 15 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx15-enhancement-request", "openjfx15-enhancement-yes", "openjfx15-enhancement-no" and "openjfx15-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx15 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should now go into master for openjfx16, since we do not want to risk anything that would destabilize the openjfx15 release without a compelling reason. Also, we have only 4 weeks until RDP2 of openjfx15 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for openjfx15 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-March/025410.html [2] https://github.com/openjdk/jfx/tree/jfx15 [3] https://github.com/openjdk/jfx/branches/all [4] http://openjdk.java.net/jeps/3 From kevin.rushforth at oracle.com Thu Jul 2 17:49:07 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Jul 2020 10:49:07 -0700 Subject: JBS bugs and enhancements still targeted to openjfx15 Message-ID: To: OpenJFX Authors, Committers, and Reviewers Now that we are in the rampdown for openjfx15, I ask everyone who is an Author, Committer, or Reviewer in the OpenJFX project, and who has a JBS issue targeted to openjfx15 (that is, "fixversion==openjfx15"), to look at their JBS issues and move them to a future release, unless they are among the few candidates for getting into 15 during rampdown. 1. Here is a JBS query for bugs still targeted to openjfx15: https://bugs.openjdk.java.net/issues/?filter=39194 At the time of sending this email, there are 28 bugs on that list. Many (probably most) of these should be retargeted to openjfx16, or to "tbd" if you don't intend to fix them within the next 6 months. 2. Here is a JBS query for enhancements and other tasks still targeted to openjfx15: https://bugs.openjdk.java.net/issues/?filter=39195 At the time of sending this email, there are 15 issues on that list. None of these seem like candidates to consider for openjfx15, so they should be retargeted to either "openjfx16", if they are planned for the next 6 months, or "tbd", otherwise. Let me know if you have any questions. Thank you. -- Kevin From kcr at openjdk.java.net Thu Jul 2 23:42:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Jul 2020 23:42:13 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v6] In-Reply-To: References: <5dDCIGDVd43vo4JtxBVmSlPpZAhMjMKV5es8BZ6nj6c=.90895611-47ba-4f08-8232-3d2edd95dcf5@github.com> Message-ID: On Tue, 30 Jun 2020 23:14:52 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException >> >> Move replaceSelectionAtEndWithListener test to general test class. >> Add a more general test for selection/text properties and replace/undo/redo operations. > > Changing from using bindings to using listeners seems reasonable as long as there can't be a memory leak as a result > (it should be fine). > As I note inline below, I think the clamping is still wrong. Maybe you can't ever hit a case where it matters now, but > it should still be fixed. I need to do some more testing, but this looks like the right approach. This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. If I don't spot anything of concern during the review, then I will ask you to retarget your PR to the `jfx15` branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Thu Jul 2 23:48:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Jul 2020 23:48:52 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: <0P3rBw0Lkt5oFlgcSWPBaw8JQ_545NxYEinvuPMJAYI=.37ab6b83-9938-418d-a0f6-459fc5a7771b@github.com> References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> <0P3rBw0Lkt5oFlgcSWPBaw8JQ_545NxYEinvuPMJAYI=.37ab6b83-9938-418d-a0f6-459fc5a7771b@github.com> Message-ID: On Mon, 29 Jun 2020 11:33:24 GMT, Johan Vos wrote: >> I think the code in the `_stop` method is correct after all. >> >> The `MonocleTimer` class is written to allow for multiple calls to the pair of `_start` and `_stop` methods (even >> though I don't think that ever happens), and the static `ScheduledThreadPoolExecutor`, named `scheduler`, is created >> only once and reused on subsequent calls. Changing the `_stop` method to call `task.cancel(true)` still leaves the >> timer thread running, which prevents the JavaFX application from exiting when the timer thread is a user thread. >> Furthermore, whether it's a user or daemon thread, if the call to `task.cancel(true)` happens to run exactly when the >> periodic task is *in progress*, the `timerRunnable` lambda in `QuantumToolkit` prints the stack trace when it catches >> the `InterruptedException`. java.lang.InterruptedException: >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit >> .lambda$runToolkit$12(QuantumToolkit.java:345) >> at java.base/java.util.concurrent.Executors$RunnableAdapter >> .call(Executors.java:515) >> at java.base/java.util.concurrent.FutureTask >> .runAndReset(FutureTask.java:305) >> at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask >> .run(ScheduledThreadPoolExecutor.java:305) >> at java.base/java.util.concurrent.ThreadPoolExecutor >> .runWorker(ThreadPoolExecutor.java:1130) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker >> .run(ThreadPoolExecutor.java:630) >> at java.base/java.lang.Thread >> .run(Thread.java:832) >> >> So the call to `task.cancel(false)` is correct. >> >> Changing the `_stop` method to shut down the `scheduler` will terminate the associated thread, regardless of its daemon >> status, but a subsequent call to `_start` will throw a `RejectedExecutionException` when trying to schedule the timer >> task: java.util.concurrent.RejectedExecutionException: >> Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at b1fe89 >> [Not completed, task = java.util.concurrent.Executors$RunnableAdapter at 1f85c96 >> [Wrapped task = com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$111/0x34563828 at 141859b]] >> rejected from java.util.concurrent.ScheduledThreadPoolExecutor at 55f462 >> [Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> at java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy >> .rejectedExecution(ThreadPoolExecutor.java:2057) >> at java.base/java.util.concurrent.ThreadPoolExecutor >> .reject(ThreadPoolExecutor.java:827) >> at java.base/java.util.concurrent.ScheduledThreadPoolExecutor >> .delayedExecute(ScheduledThreadPoolExecutor.java:340) >> at java.base/java.util.concurrent.ScheduledThreadPoolExecutor >> .scheduleAtFixedRate(ScheduledThreadPoolExecutor.java:632) >> at javafx.graphics/com.sun.glass.ui.monocle.MonocleTimer >> ._start(MonocleTimer.java:64) >> at javafx.graphics/com.sun.glass.ui.Timer >> .start(Timer.java:96) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit >> .runToolkit(QuantumToolkit.java:384) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit >> .lambda$startup$10(QuantumToolkit.java:280) >> at javafx.graphics/com.sun.glass.ui.Application >> .lambda$run$1(Application.java:153) >> at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor >> .runLoop(RunnableProcessor.java:92) >> at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor >> .run(RunnableProcessor.java:51) >> at java.base/java.lang.Thread >> .run(Thread.java:832) >> >> So if we want `MonocleTimer` to reuse a single `ScheduledThreadPoolExecutor` object, I think the only way to make sure >> that its timer thread exits when the application exits is to set its daemon status to `true`. > > While the PR should indeed fix the original issue, I'm unsure about the behavior of multiple invocations of start/stop > rather than using the (nop) pause method. However, it seems this behavior is similar on other platforms, so I assume it > is by design. Given that this is a regression introduced in JavaFX 14, this fix seems like a good candidate for JavaFX 15, so I recommend to _not_ merge the master branch. Go ahead and retarget your PR to the `jfx15` branch (you should not need to merge anything), although we will need to satisfy ourselves that the risk of further regression is low. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From kcr at openjdk.java.net Thu Jul 2 23:50:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Jul 2020 23:50:17 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Thu, 2 Jul 2020 12:41:34 GMT, Kevin Rushforth wrote: >> I tested this pull request on all of the following platforms: >> >> * JavaFX desktop platforms (*amd64* architecture) >> * Windows SDK on Windows 10 Pro Version 2004 >> * Mac OS X SDK on macOS 10.15.5 (Catalina) >> * Linux SDK on Ubuntu 16.04.6 LTS (Xenial Xerus) >> * JavaFX embedded platforms (*armhf* architecture) >> * armv6hf SDK (Monocle EPD) on Ubuntu 14.04.6 LTS (Trusty Tahr) >> * armv6hf SDK (Monocle VNC) on Ubuntu 20.04 LTS (Focal Fossa) >> >> This is a tricky timing problem on most platforms, so I used rather intrusive techniques to catch the error and verify >> it was fixed. The bug is easily visible only on the Monocle VNC platform. >> ### Desktop >> >> I tested the desktop platforms as follows: >> >> 1. I added `assert` statements and calls to `Thread.sleep` as shown by [this >> commit](https://github.com/jgneff/javafx-graphics/commit/ffc639e4) to catch the error. It looks like a lot of changes, >> but they simply call `sleep` to change the timing of the threads so that the JavaFX Application Thread is unable to >> keep up with the QuantumRenderer. The `assert` statements catch the error when the rendering thread starts looking for >> an unused buffer. >> All platforms printed many `InvalidMarkException` errors as the buffer position was modified while in use on the JavaFX >> application thread. The Linux and Windows platforms printed, "Exception in thread 'JavaFX Application Thread' >> java.nio.InvalidMarkException," while the macOS platform printed, "Exception in thread 'AppKit Thread' >> java.nio.InvalidMarkException." >> >> 2. I applied the fix to call `getBuffer` instead of `getPixels` in `QueuedPixelSource`. >> >> 3. After the fix, no errors were detected by the assertions on any of the platforms. >> >> ### Embedded >> >> I tested the embedded platforms as follows: >> >> 1. I added only `assert` statements to the `HeadlessScreen` and `EPDScreen` classes, as shown below. Both platforms >> printed many `InvalidMarkException` errors as the buffer position was modified while in use on the JavaFX application >> thread. 2. I applied the fix to call `getBuffer` instead of `getPixels` in `QueuedPixelSource`. >> >> 3. After the fix, no errors were detected by the assertions on either platform. >> >> #### `HeadlessScreen` and `EPDScreen` >> >> @Override >> public synchronized void uploadPixels(Buffer b, int x, int y, >> int width, int height, float alpha) { >> + assert b.mark() == b; >> pixels.composePixels(b, x, y, width, height, alpha); >> + assert b.reset() == b; >> } >> >> For the Monocle VNC platform, you can also simply connect and watch the bug corrupt the frames sent to the VNC client, >> as shown in my prior comment on this pull request. >> ### Other results >> >> I found some unexpected results, listed below. >> >> * JavaFX on Linux does not limit its frame rate to 60 Hz when using the hardware pipeline, reaching over 350 frames per >> second. >> >> * JavaFX on macOS ignores the system property `-Djavafx.animation.pulse=8` and runs at 60 Hz, even though it prints the >> message "Setting PULSE_DURATION to 8 hz." >> >> * JavaFX on macOS prints the error shown below when `Platform.exit` is called to end the application. The error also >> occurs on JavaFX 14.0.1 and 15-ea+6. The error does not occur when the window is closed manually using the mouse. >> >> Java has been detached already, but someone is still trying to use it at >> -[GlassViewDelegate dealloc]: >> /Users/john/src/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m:204 >> 0 libglass.dylib 0x000000010eb6c05d -[GlassViewDelegate dealloc] + 221 >> 1 libglass.dylib 0x000000010eb71af6 -[GlassView3D dealloc] + 246 >> 2 libobjc.A.dylib 0x00007fff66937054 _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 134 >> 3 libobjc.A.dylib 0x00007fff6691bdba objc_autoreleasePoolPop + 175 >> 4 CoreFoundation 0x00007fff2dad23c5 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 >> 5 CoreFoundation 0x00007fff2dad22f7 __CFRunLoopDoObservers + 457 >> 6 CoreFoundation 0x00007fff2dad1895 __CFRunLoopRun + 874 >> 7 CoreFoundation 0x00007fff2dad0ece CFRunLoopRunSpecific + 462 >> 8 libjli.dylib 0x000000010be945c1 CreateExecutionEnvironment + 399 >> 9 libjli.dylib 0x000000010be90752 JLI_Launch + 1354 >> 10 java 0x000000010be83ca1 main + 375 >> 11 libdyld.dylib 0x00007fff67acdcc9 start + 1 >> 12 ??? 0x000000000000000b 0x0 + 11 >> >> ### Test scripts >> >> Below are the scripts I used to run the tests. The scripts include the system property `-Djavafx.animation.pulse=8`, >> but I removed it when trying to recreate the bug with the added `assert` and `sleep` statements. >> #### linux.sh >> >> #!/bin/bash >> # Linux desktop >> $HOME/opt/jdk-14.0.1/bin/java -ea --show-version \ >> --module-path=$HOME/lib/javafx-sdk-dev/lib \ >> --add-modules=javafx.graphics \ >> -Dprism.order=sw -Djavafx.animation.pulse=8 \ >> -jar dist/epd-javafx.jar \ >> --width=800 --height=600 --pattern=3 --loops=0 >> >> #### macos.sh >> >> #!/bin/bash >> # macOS desktop >> $HOME/opt/jdk-14.0.1.jdk/Contents/Home/bin/java -ea --show-version \ >> --module-path=$HOME/lib/javafx-sdk-dev/lib \ >> --add-modules=javafx.graphics \ >> -Dprism.order=sw -Djavafx.animation.pulse=8 \ >> -jar dist/epd-javafx.jar \ >> --width=800 --height=600 --pattern=3 --loops=0 >> >> #### windows.sh >> >> #!/bin/bash >> # Windows desktop under Cygwin >> $HOME/opt/jdk-14.0.1/bin/java -ea --show-version \ >> --module-path=$(cygpath -m $HOME/lib/javafx-sdk-dev/lib) \ >> --add-modules=javafx.graphics \ >> -Dprism.order=sw -Djavafx.animation.pulse=8 \ >> -jar dist/epd-javafx.jar \ >> --width=800 --height=600 --pattern=3 --loops=0 >> >> #### windows.bat >> >> REM Windows desktop under Command Prompt >> C:\cygwin64\home\john\opt\jdk-14.0.1\bin\java -ea --show-version^ >> --module-path=C:/cygwin64/home/john/lib/javafx-sdk-dev/lib^ >> --add-modules=javafx.graphics^ >> -Dprism.order=sw -Djavafx.animation.pulse=8^ >> -jar dist\epd-javafx.jar^ >> --width=800 --height=600 --pattern=3 --loops=0 >> >> #### monocle-epd.sh >> >> Run with `sudo`. >> >> #!/bin/bash >> # Monocle EPD platform on Linux armhf >> $HOME/opt/jdk-14.0.1+7/bin/java -ea --show-version \ >> --module-path=$HOME/lib/armv6hf-sdk/lib \ >> --add-modules=javafx.graphics \ >> -Dglass.platform=Monocle -Dmonocle.platform=EPD -Dprism.order=sw \ >> -Dmonocle.input.18/0/0/0.maxX=800 -Dmonocle.input.18/0/0/0.maxY=600 \ >> -Dmonocle.epd.waveformMode=4 -jar dist/epd-javafx.jar \ >> --width=800 --height=600 --pattern=3 --loops=0 >> >> #### monocle-vnc.sh >> >> #!/bin/bash >> # Monocle VNC platform on Linux armhf >> /usr/lib/jvm/java-14-openjdk-armhf/bin/java -ea --show-version \ >> --module-path=$HOME/lib/armv6hf-sdk/lib \ >> --add-modules=javafx.graphics \ >> -Dprism.order=sw -Djavafx.animation.pulse=8 \ >> -Dglass.platform=Monocle -Dmonocle.platform=VNC \ >> -jar dist/epd-javafx.jar \ >> --width=1024 --height=600 --pattern=3 --loops=0 > >> Does this fix the years old Linux JavaFX buffer reset bug? > > Possibly. This is a race condition that can affect the use of `UploadingPainter`, which is used by the SW pipeline. This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. If we don't spot anything of concern during the review, then we might ask you to retarget your PR to the `jfx15` branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Thu Jul 2 23:50:41 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Jul 2020 23:50:41 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Tue, 30 Jun 2020 18:21:52 GMT, Oliver Schmidtmer wrote: >> In 2D, we normally use sun.java2d.pipe.Region.clipRound as it also checks for -ve/+ve max INTEGER but I guess that is >> internal class to FX so it's ok to use Math.round. Approval pending test creation. > > While both might work, as long as there is no mixed usage of round and ceil, Math.ceil seems to be better. > > I'm not sure if the timed waiting for the resizes is the best way for ensuring that the buffer is resized to the new > bounds, so I'm open for suggestions. To me at least it seems to create a reproducible sheared output after the second > resize in the test case and not anymore after changing the calculations to Math.ceil. This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. If we don't spot anything of concern during the review, then we might ask you to retarget your PR to the `jfx15` branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From nlisker at openjdk.java.net Fri Jul 3 00:05:47 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 3 Jul 2020 00:05:47 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: On Wed, 1 Jul 2020 18:27:01 GMT, Johan Vos wrote: >> Do the build instructions need to be updated? > > The build instruction can indeed refer to WEBKIT-MEDIA-STUBS.md now. I updated https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-PlatformPrerequisites. ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From kcr at openjdk.java.net Fri Jul 3 00:54:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Jul 2020 00:54:01 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2] In-Reply-To: <7iy75Q1BwFgHwqiVTAEcTH8_M6qnI3mqCC1ITvp8cE8=.bef5eac2-92e7-4cf2-a4ba-bb51fc33ceb3@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <7iy75Q1BwFgHwqiVTAEcTH8_M6qnI3mqCC1ITvp8cE8=.bef5eac2-92e7-4cf2-a4ba-bb51fc33ceb3@github.com> Message-ID: On Tue, 30 Jun 2020 18:28:11 GMT, Oliver Schmidtmer wrote: >> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and >> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared >> rendering. The changes were already proposed by the submitter in JBS-8220484. >> >> OCA is signed and send. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > Change to Math.ceil and add test I left specific feedback, mostly on the test, but also one question on the fix. For the test, make sure you can run it as follows: gradle --info -PFULL_TEST=true -PUSE_ROBOT=true cleanTest :systemTests:test --tests JFXPanelScaledTest (presuming you rename it to `JFXPanelScaledTest`) It should fail without your fix and pass with your fix. Currently, it will fail because of the call to `setAccessible` (see inline comments). tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 2: > 1: /* > 2: * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. This should be `Copyright (c) 2020, Oracle` ... tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 39: > 38: import javax.swing.*; > 39: import java.awt.*; > 40: import java.awt.image.BufferedImage; We generally avoid wildcard imports. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 49: > 48: > 49: public class JDK8220484Test { > 50: static CountDownLatch launchLatch; We no longer use the pattern of naming our test classes after the bug ID. I recommend a descriptive name for the test class. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 71: > 70: try { > 71: if (!launchLatch.await(5 * TIMEOUT, TimeUnit.MILLISECONDS)) { > 72: throw new AssertionFailedError("Timeout waiting for Application to launch (" + (5 * TIMEOUT) + " > seconds)"); If you add `throws Exception` to the this setup method, then you can replace the entire try / catch block with simply: assertTrue("Timeout waiting for Application to launch", launchLatch.await(5 * TIMEOUT, TimeUnit.MILLISECONDS)); This is the pattern we use for our newer system tests. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 90: > 89: Field fpixelsIm = JFXPanel.class.getDeclaredField("pixelsIm"); > 90: fpixelsIm.setAccessible(true); > 91: BufferedImage pixelsIm = (BufferedImage) fpixelsIm.get(myApp.jfxPanel); This isn't the pattern we use to access internal fields of a JavaFX class, and won't work. We typically use the "shim" pattern for such white-box testing. Can you look into adding shims to the `javafx.swing` module? Many of the other modules already have shims, so you can use that as a pattern. It will require adding a package-scope `test_getPixelsIm` method to `JFXPanel`. Alternatively, you can use AWT `Robot` to read the JFXPanel pixels. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 93: > 92: > 93: > 94: assertEquals(127, pixelsIm.getWidth()); Minor: a single blank line is sufficient. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 103: > 102: for (int y = 90; y < 115; y++) { > 103: if(colorOfDiagonal == pixelsIm.getRGB( x, y )) { > 104: fail( "image is skewed" ); Are you sure that an equality test will work on all platforms and configurations? We usually use a tolerance when comparing colors whose components are other than 0 or 255. Somewhat related to this, is the expected value of `181` coming from the default value of the button border? It might be more robust to fill the Scene with a stroked rectangle whose color you control (e.g. set to black). Either that or set the color of the button border using an inline CSS style so you aren't dependent on the default inherited from the `modena.css` style sheet. Minor: add a space after the `if` and remove the extra spaces surrounding the function arguments `x, y`. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 104: > 103: if(colorOfDiagonal == pixelsIm.getRGB( x, y )) { > 104: fail( "image is skewed" ); > 105: } Minor: remove the extra spaces surrounding the function argument. tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 26: > 25: > 26: package test.javafx.embed.swing; > 27: This test will need to move to the `test.robot.javafx.embed.swing` package since it relies on reading the actual rendered pixels. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java line 235: > 234: scaledWidth = (int) Math.ceil(scaledWidth * texScaleFactorX); > 235: scaledHeight = (int) Math.ceil(scaledHeight * texScaleFactorY); > 236: Since this is in code that is shared by all embedded scenes, have you verified that FXCanvas (SWT interop) doesn't need similar changes? tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 114: > 113: * > 114: */ > 115: private static final long serialVersionUID = 1L; Minor: you can remove this empty comment block. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+1413266+jgneff at openjdk.java.net Fri Jul 3 02:40:25 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 3 Jul 2020 02:40:25 GMT Subject: [jfx15] RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> <0P3rBw0Lkt5oFlgcSWPBaw8JQ_545NxYEinvuPMJAYI=.37ab6b83-9938-418d-a0f6-459fc5a7771b@github.com> Message-ID: On Thu, 2 Jul 2020 23:46:40 GMT, Kevin Rushforth wrote: > Given that this is a regression introduced in JavaFX 14, this fix seems like a good candidate for JavaFX 15 ... Actually, this is a regression introduced in JavaFX 15, so we have the chance to fix it before it's ever released. > Go ahead and retarget your PR to the `jfx15` branch (you should not need to merge anything) ... Like [this](https://github.blog/2016-08-15-change-the-base-branch-of-a-pull-request/)? I'll try that now. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From kcr at openjdk.java.net Fri Jul 3 13:52:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Jul 2020 13:52:18 GMT Subject: RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com> Message-ID: On Wed, 1 Jul 2020 06:31:22 GMT, Nir Lisker wrote: >> I would say in addition to rather than instead of, since both are useful. >> >> What might help is to add the sphere test plus the pathological test I put together into your test program so we can >> select between them. And then get a few of us to run that updated program and post results. > > I've added sphere with 10, 64 (default) and 200 divisions. Note that this number is approximate because the sphere mesh > corrects the division number with `newDivisions = ((oldDivisions + 3) / 4) * 4`. > [attenTest.zip](https://github.com/openjdk/jfx/files/4855989/attenTest.zip) Using AMD RX 470 4GB on Win 10, all 3 > spheres averaged 120 fps both before and after the patch. (It takes a couple of measurements to hit the consistent fps, > so I discarded them.) > If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. > I've added sphere with 10, 64 (default) and 200 divisions. Thanks, I'll take a look at it. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Jul 3 13:53:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Jul 2020 13:53:23 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Sun, 14 Jun 2020 23:59:17 GMT, Thiago Milczarek Sayao wrote: >> This is the result on OL 82 with latest commit >> OL82> src="https://user-images.githubusercontent.com/6153953/84592508-d82c5200-ae63-11ea-87d3-7f55671ed302.png"> > > @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. > If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+10960818+Schmidor at openjdk.java.net Fri Jul 3 17:39:40 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Fri, 3 Jul 2020 17:39:40 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v3] In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: <76fFlf7IKBfwOkG94hK4IWlMBuVr0F7BoTBKENR953c=.88f659f3-d839-49de-a172-c036a19c9fd6@github.com> > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: more solid test with shim and style independent color ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/246/files - new: https://git.openjdk.java.net/jfx/pull/246/files/994ca03c..555c5f30 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/246/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/246/webrev.01-02 Stats: 358 lines in 5 files changed: 201 ins; 155 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/246/head:pull/246 PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Fri Jul 3 17:39:55 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Fri, 3 Jul 2020 17:39:55 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <7iy75Q1BwFgHwqiVTAEcTH8_M6qnI3mqCC1ITvp8cE8=.bef5eac2-92e7-4cf2-a4ba-bb51fc33ceb3@github.com> Message-ID: On Fri, 3 Jul 2020 00:01:10 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: >> >> Change to Math.ceil and add test > > tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 90: > >> 89: Field fpixelsIm = JFXPanel.class.getDeclaredField("pixelsIm"); >> 90: fpixelsIm.setAccessible(true); >> 91: BufferedImage pixelsIm = (BufferedImage) fpixelsIm.get(myApp.jfxPanel); > > This isn't the pattern we use to access internal fields of a JavaFX class, and won't work. > > We typically use the "shim" pattern for such white-box testing. Can you look into adding shims to the `javafx.swing` > module? Many of the other modules already have shims, so you can use that as a pattern. It will require adding a > package-scope `test_getPixelsIm` method to `JFXPanel`. Alternatively, you can use AWT `Robot` to read the JFXPanel > pixels. I've added a shim. I would like to check the backing image directly. > tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 103: > >> 102: for (int y = 90; y < 115; y++) { >> 103: if(colorOfDiagonal == pixelsIm.getRGB( x, y )) { >> 104: fail( "image is skewed" ); > > Are you sure that an equality test will work on all platforms and configurations? We usually use a tolerance when > comparing colors whose components are other than 0 or 255. > Somewhat related to this, is the expected value of `181` coming from the default value of the button border? It might > be more robust to fill the Scene with a stroked rectangle whose color you control (e.g. set to black). Either that or > set the color of the button border using an inline CSS style so you aren't dependent on the default inherited from the > `modena.css` style sheet. Minor: add a space after the `if` and remove the extra spaces surrounding the function > arguments `x, y`. done, a rectangle with a defined background & border color. That is definitely more stable. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Mon Jul 6 18:27:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Jul 2020 18:27:32 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Mon, 6 Jul 2020 18:22:56 GMT, Oliver Schmidtmer wrote: >> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and >> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared >> rendering. The changes were already proposed by the submitter in JBS-8220484. >> >> OCA is signed and send. > > Oliver Schmidtmer has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains two new > commits since the last revision: > - Similar changes and test for FXCanvas > - more solid test with shim and style independent color The test is looking better now. And the fix to `FXPanel` looks correct as well, although needs to be tested. I left a few comments relating to the tests. I haven't looked at the SWT test in detail, but will do that later. I also still need to test this on multiple platforms (I have a concern about platforms other than Windows due to assumptions the test is making). build.gradle line 3611: > 3610: testCompile project(":swt") > 3611: testCompile name: SWT_FILE_NAME > 3612: } We can't have a dependency on `swt` from any other project. SWT tests need to be confined to `modules/javafx.swt/src/test/java/` build.gradle line 3614: > 3613: > 3614: def dependentProjects = [ 'base', 'graphics', 'controls', 'media', 'web', 'swing', 'fxml', 'swt' ] > 3615: commonModuleSetup(project, dependentProjects) Similarly, this needs to be reverted. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 934: > 933: // Package scope method for testing > 934: final BufferedImage test_getPixelsIm(){ > 935: return pixelsIm; Minor: add a space before the `{` tests/system/src/test/java/test/robot/javafx/embed/swt/FXCanvasScaledTest.java line 26: > 25: > 26: package test.robot.javafx.embed.swt; > 27: This should move to `test.javafx.embed.swt` underneath `modules/javafx.swt/src/test/java`. Note that the tests in the `javafx.swt` module are not currently enabled (I haven't looked recently into what it would take to do so), so you might need to verify it manually. tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelScaledTest.java line 74: > 73: if (!launchLatch.await(5 * TIMEOUT, TimeUnit.MILLISECONDS)) { > 74: throw new AssertionFailedError("Timeout waiting for Application to launch (" + (5 * TIMEOUT) + " > seconds)"); 75: } As a suggestion, this can further be simplified to: assertTrue("Timeout waiting for Application to launch", launchLatch.await(5 * TIMEOUT, TimeUnit.MILLISECONDS)) { tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelScaledTest.java line 90: > 89: assertEquals(127, pixelsIm.getWidth()); > 90: assertEquals(127, pixelsIm.getHeight()); > 91: Where does the `127` come from? If this is derived from the size of the JFXPanel * scale, it isn't likely to work on platforms other than Windows (it certainly won't work on Mac, and I suspect not on Linux, but it needs to be tested). Also, unless there is a padding of 1 pixel (in user space coordinates), wouldn't it be 125? ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Mon Jul 6 18:27:30 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Mon, 6 Jul 2020 18:27:30 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. Oliver Schmidtmer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Similar changes and test for FXCanvas - more solid test with shim and style independent color ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/246/files - new: https://git.openjdk.java.net/jfx/pull/246/files/555c5f30..882f95c1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/246/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/246/webrev.02-03 Stats: 268 lines in 6 files changed: 130 ins; 0 del; 138 mod Patch: https://git.openjdk.java.net/jfx/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/246/head:pull/246 PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Mon Jul 6 18:27:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Jul 2020 18:27:32 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Mon, 6 Jul 2020 18:19:53 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains two new >> commits since the last revision: >> - Similar changes and test for FXCanvas >> - more solid test with shim and style independent color > > The test is looking better now. And the fix to `FXPanel` looks correct as well, although needs to be tested. > > I left a few comments relating to the tests. I haven't looked at the SWT test in detail, but will do that later. I also > still need to test this on multiple platforms (I have a concern about platforms other than Windows due to assumptions > the test is making). Also, in general we recommend not to force-push to your branch after the review has started, unless there is some compelling reason to do so. It makes it harder for reviewers to look at incremental diffs. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Mon Jul 6 23:34:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Jul 2020 23:34:39 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: <9jiUO9RraTZfFbRzK8hyghAXM5MsE2_NVyDBI6pq87I=.18510f52-9822-4ba7-aa34-10cb36a5918c@github.com> On Mon, 6 Jul 2020 17:52:16 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains two new >> commits since the last revision: >> - Similar changes and test for FXCanvas >> - more solid test with shim and style independent color > > build.gradle line 3611: > >> 3610: testCompile project(":swt") >> 3611: testCompile name: SWT_FILE_NAME >> 3612: } > > We can't have a dependency on `swt` from any other project. SWT tests need to be confined to > `modules/javafx.swt/src/test/java/` I note that this does work for me. So copying the pattern used by `systemTests` into the `swt` project might be all that is needed to get it to work there. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Tue Jul 7 10:55:57 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 7 Jul 2020 10:55:57 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Mon, 6 Jul 2020 18:18:20 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelScaledTest.java line 90: > >> 89: assertEquals(127, pixelsIm.getWidth()); >> 90: assertEquals(127, pixelsIm.getHeight()); >> 91: > > Where does the `127` come from? If this is derived from the size of the JFXPanel * scale, it isn't likely to work on > platforms other than Windows (it certainly won't work on Mac, and I suspect not on Linux, but it needs to be tested). > Also, unless there is a padding of 1 pixel (in user space coordinates), wouldn't it be 125? I'm using a base size of 101, so that there is a difference between Math.ceil and Math.round for width*1.25. 100 is only the initial size. The Timer changes the bounds first to 201 and then to 101. Without resizing the issue does not appear. I believe somewhere in the Pulse-Thread? there is also a creation/resizing of the Buffer using Math.ceil. I'm trying to clarify that now using constants. My main concern is that the conversion vom JFX to Swing (and SWT, as you mentioned) is consistent, so there are no wrong line offsets when reading the buffer outside of JFX. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Tue Jul 7 12:34:17 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 7 Jul 2020 12:34:17 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v5] In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: move swt test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/246/files - new: https://git.openjdk.java.net/jfx/pull/246/files/882f95c1..6b0d58a0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/246/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/246/webrev.03-04 Stats: 275 lines in 5 files changed: 137 ins; 131 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/246/head:pull/246 PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Tue Jul 7 12:34:18 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 7 Jul 2020 12:34:18 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: <9jiUO9RraTZfFbRzK8hyghAXM5MsE2_NVyDBI6pq87I=.18510f52-9822-4ba7-aa34-10cb36a5918c@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <9jiUO9RraTZfFbRzK8hyghAXM5MsE2_NVyDBI6pq87I=.18510f52-9822-4ba7-aa34-10cb36a5918c@github.com> Message-ID: On Mon, 6 Jul 2020 23:31:28 GMT, Kevin Rushforth wrote: >> build.gradle line 3611: >> >>> 3610: testCompile project(":swt") >>> 3611: testCompile name: SWT_FILE_NAME >>> 3612: } >> >> We can't have a dependency on `swt` from any other project. SWT tests need to be confined to >> `modules/javafx.swt/src/test/java/` > > I note that this does work for me. So copying the pattern used by `systemTests` into the `swt` project might be all > that is needed to get it to work there. I assumed I should add it to the robot package, as it is also a visual test. I've moved it to the swt module ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Tue Jul 7 12:34:18 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 7 Jul 2020 12:34:18 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Mon, 6 Jul 2020 18:00:08 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > tests/system/src/test/java/test/robot/javafx/embed/swt/FXCanvasScaledTest.java line 26: > >> 25: >> 26: package test.robot.javafx.embed.swt; >> 27: > > This should move to `test.javafx.embed.swt` underneath `modules/javafx.swt/src/test/java`. > > Note that the tests in the `javafx.swt` module are not currently enabled (I haven't looked recently into what it would > take to do so), so you might need to verify it manually. The swt tests are hard disabled by `enabled = false // FIXME: JIGSAW -- support this with modules` in the gradle.build If I manually change that for running the single test now in the swt module, the test is working fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From arapte at openjdk.java.net Wed Jul 8 17:47:43 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 8 Jul 2020 17:47:43 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 23:11:56 GMT, John Neffenger wrote: >> Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Remove assert statements Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From arapte at openjdk.java.net Wed Jul 8 17:47:43 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 8 Jul 2020 17:47:43 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: <9N-ikjenv4sV7_1im5rs-b691ISCsPTZYjvpvpRxftM=.17365c8a-2b1d-46d5-944f-2e9a647a215e@github.com> On Thu, 2 Jul 2020 23:48:08 GMT, Kevin Rushforth wrote: >>> Does this fix the years old Linux JavaFX buffer reset bug? >> >> Possibly. This is a race condition that can affect the use of `UploadingPainter`, which is used by the SW pipeline. > > This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. > > If we don't spot anything of concern during the review, then we might ask you to retarget your PR to the `jfx15` branch. This seems to be a safe fix to me. As mentioned in `Pixels.java`, the class is not thread safe but most of the other methods have the check `Application.checkEventThread()`, so those methods seem safe. But the the method `getPixels()` does not have this check, as it is at least accessed by two threads. The new method `getBuffer()` is a true get method and more correct for comparing the buffers. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Wed Jul 8 21:53:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Jul 2020 21:53:15 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jul 2020 17:45:25 GMT, Ambarish Rapte wrote: >> John Neffenger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove assert statements > > Marked as reviewed by arapte (Reviewer). @jgneff this looks safe enough to get into 15. Go ahead an retarget it to the `jfx15` branch. @arapte this will invalidate your review, so you will need to re-review it once retargeted. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Wed Jul 8 22:04:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Jul 2020 22:04:36 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jul 2020 21:51:00 GMT, Kevin Rushforth wrote: >> Marked as reviewed by arapte (Reviewer). > > @jgneff this looks safe enough to get into 15. Go ahead an retarget it to the `jfx15` branch. > > @arapte this will invalidate your review, so you will need to re-review it once retargeted. Oh, and regarding the following: > JavaFX on macOS prints the error shown below when Platform.exit is called to end the application. That's a known issue on macOS 10.15: [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558): [macos 10.15] Platform.exit causes assertion error on macOS Catalina ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Wed Jul 8 22:11:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Jul 2020 22:11:19 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <9jiUO9RraTZfFbRzK8hyghAXM5MsE2_NVyDBI6pq87I=.18510f52-9822-4ba7-aa34-10cb36a5918c@github.com> Message-ID: <_bL6TO_TEdaSBk7ld633agoBL8hbQMrkfy_HuSSDX8k=.014e89b7-4f4c-477c-a307-835ea279b5f7@github.com> On Tue, 7 Jul 2020 12:15:11 GMT, Oliver Schmidtmer wrote: >> I note that this does work for me. So copying the pattern used by `systemTests` into the `swt` project might be all >> that is needed to get it to work there. > > I assumed I should add it to the robot package, as it is also a visual test. I've moved it to the swt module I verified that the SWT test works well, when manually enabled in build.gradle and if it runs in isolation. As for putting it in a `robot` sub-package, that seems helpful, but since it won't be enabled anyway, is optional. We can file a follow-up issue to enable SWT tests again (as long as they aren't enabled by default. My thought is to change the default value of `SWT_TEST` to false, and then enable the tests on platforms other than macOS when the `SWT_TEST` is set to `true` along with `FULL_TEST`). ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Wed Jul 8 22:13:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Jul 2020 22:13:42 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v4] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Tue, 7 Jul 2020 10:53:18 GMT, Oliver Schmidtmer wrote: >> tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelScaledTest.java line 90: >> >>> 89: assertEquals(127, pixelsIm.getWidth()); >>> 90: assertEquals(127, pixelsIm.getHeight()); >>> 91: >> >> Where does the `127` come from? If this is derived from the size of the JFXPanel * scale, it isn't likely to work on >> platforms other than Windows (it certainly won't work on Mac, and I suspect not on Linux, but it needs to be tested). >> Also, unless there is a padding of 1 pixel (in user space coordinates), wouldn't it be 125? > > I'm using a base size of 101, so that there is a difference between Math.ceil and Math.round for width*1.25. > 100 is only the initial size. The Timer changes the bounds first to 201 and then to 101. Without resizing the issue > does not appear. I believe somewhere in the Pulse-Thread? there is also a creation/resizing of the Buffer using > Math.ceil. I'm trying to clarify that now using constants. > My main concern is that the conversion vom JFX to Swing (and SWT, as you mentioned) is consistent, so there are no > wrong line offsets when reading the buffer outside of JFX. OK. You can update the PR with your findings. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Wed Jul 8 22:20:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Jul 2020 22:20:51 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v5] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Tue, 7 Jul 2020 12:34:17 GMT, Oliver Schmidtmer wrote: >> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and >> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared >> rendering. The changes were already proposed by the submitter in JBS-8220484. >> >> OCA is signed and send. > > Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: > > move swt test The test looks good with one minor typo in the constant field name (see below). I verified that it fails on Linux and Mac (as I suspected), so you will need to limit the test to running on Windows. modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasScaledTest.java line 56: > 55: /* Base size, so that with a scaling of 125% there are different results for Math.round and Math.ceil */ > 56: final static int TAGET_BASE_SIZE = 101; > 57: Spelling error: `TAGET` --> `TARGET` tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelScaledTest.java line 63: > 62: /* Base size, so that with a scaling of 125% there are different results for Math.round and Math.ceil */ > 63: final static int TAGET_BASE_SIZE = 101; > 64: Spelling error: `TAGET` --> `TARGET` tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelScaledTest.java line 68: > 67: @BeforeClass > 68: public static void setupOnce() throws Exception { > 69: System.setProperty("sun.java2d.uiScale.enabled", "true"); You can add an `assumeTrue(PlatformUtil.isWindows());` here to ensure that the test only runs on Windows. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Thu Jul 9 20:41:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Jul 2020 20:41:52 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v7] In-Reply-To: References: Message-ID: On Thu, 2 Jul 2020 05:29:05 GMT, Robert Lichtenberger wrote: >> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException > > Clamping is no longer needed, removed it. The fix looks good. I left one question and one comment on the tests. I believe this is safe enough and desired for 15, so can you please retarget this PR to the `jfx15` branch? modules/javafx.controls/src/test/java/test/javafx/scene/control/TextFieldTest.java line 475: > 474: assertEquals(4, txtField.getSelection().getStart()); > 475: assertEquals(4, txtField.getSelection().getStart()); > 476: } Did you mean to check `getStart()` twice? modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 1924: > 1923: textInput.selectionProperty().addListener((__, ___, selection) -> selectionLog.append("|" + > selection.getStart() + "," + selection.getEnd())); 1924: textInput.textProperty().addListener((__, ___, > text) -> textLog.append("|" + text)); 1925: The pattern of using multiple underscores for unused variables isn't one we use. I recommend using something more common like `obs` and `o` (or similar). ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Thu Jul 9 21:02:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Jul 2020 21:02:17 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jul 2020 22:02:17 GMT, Kevin Rushforth wrote: >> @jgneff this looks safe enough to get into 15. Go ahead an retarget it to the `jfx15` branch. >> >> @arapte this will invalidate your review, so you will need to re-review it once retargeted. > > Oh, and regarding the following: > >> JavaFX on macOS prints the error shown below when Platform.exit is called to end the application. > > That's a known issue on macOS 10.15: > > [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558): [macos 10.15] Platform.exit causes assertion error on > macOS Catalina I am done with my testing. All looks good. Once this PR is retargeted to `jfx15` I will approve it. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Thu Jul 9 21:41:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Jul 2020 21:41:43 GMT Subject: [jfx15] RFR: 8248381: Create a daemon thread for MonocleTimer [v2] In-Reply-To: References: Message-ID: <9k5gR4fjfuj1IoBAFP_H3lnw4904UM_He6JZ3-u295I=.f52865a1-3cda-4b60-9f42-2ee2dca7b9fd@github.com> On Sun, 28 Jun 2020 02:28:35 GMT, John Neffenger wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Remove POOL_SIZE constant Looks good to me. I verified that it does, in fact, fix the regression. As long as @johanvos also approves, then this is fine to go in for `jfx15` I think we can address any issues relating to Timer start / stop / pause / resume in a subsequent release. There was some work done to support pause / resume as part of [JDK-8189926](https://bugs.openjdk.java.net/browse/JDK-8189926), but it was only implemented on macOS (with follow-up issues filed to implement it on Windows and Linux). It didn't address any issues with start / stop. In particular we have never supported restarting the JavaFX runtime, so unless there are other uses of stop besides shutting down the runtime, I don't know that it matters if the timer can be restarted. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/256 From kcr at openjdk.java.net Thu Jul 9 21:44:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Jul 2020 21:44:12 GMT Subject: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 23:11:56 GMT, John Neffenger wrote: >> Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Remove assert statements Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From github.com+1413266+jgneff at openjdk.java.net Thu Jul 9 22:37:20 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Thu, 9 Jul 2020 22:37:20 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: <6o8qSlwswav0zA97KO1AcFkc9S9N10m5T4O1WiGs5Fk=.28d3812f-a8cd-4c80-990b-af07aaf1c084@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> <6o8qSlwswav0zA97KO1AcFkc9S9N10m5T4O1WiGs5Fk=.28d3812f-a8cd-4c80-990b-af07aaf1c084@github.com> Message-ID: On Wed, 1 Jul 2020 12:10:23 GMT, Johan Vos wrote: > I don't have access to a Pi right now, so I can't test this (I'll be able to test in about 10 days from now though) Thank you, Johan. If you have the time, that would be great. Otherwise, merging this for early-access builds of JavaFX 16 should provide enough time to find any regression errors on other devices. By the way, do you know whether I would be able to use a [PinePhone](https://www.pine64.org/pinephone/) instead of a Raspberry Pi for testing the Monocle Linux platform (`monocle.platform=Linux`)? The PinePhone has a quad-core ARM Cortex A53 processor instead of the quad-core ARM Cortex-A72 on the Raspberry Pi 4, but it also has the advantage of a built-in LCD touchscreen. ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From electricalh at gmail.com Fri Jul 10 04:13:56 2020 From: electricalh at gmail.com (Guruprasad Kulkarni) Date: Fri, 10 Jul 2020 09:43:56 +0530 Subject: JavaFx application with Windows 10 operating systems Message-ID: I have a application on JavaFX 12 , open jdk 11 . It runs on other operating systems successfully . But on windows 10 certain editions it fails to load the Java Fx components . My application runs on Windows 7 , Windows 10 2017 edition . It shows no exception or error while running . I have tried using Liberica Bellsoft jdk but still my application fails . Please if anyone is using JavaFx 11 on Windows 10 and encountered the same problem please help me . Regards , Guruprasad Kulkarni From arapte at openjdk.java.net Fri Jul 10 05:22:12 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 10 Jul 2020 05:22:12 GMT Subject: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 23:11:56 GMT, John Neffenger wrote: >> Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Remove assert statements Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From ajoseph at openjdk.java.net Fri Jul 10 05:51:43 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 10 Jul 2020 05:51:43 GMT Subject: RFR: 8245284: Update to 610.1 version of WebKit Message-ID: Update JavaFX WebKit to GTK WebKit 2.28 (610.1) ------------- Commit messages: - Fix exec files - 8245284: Update to 610.1 version of WebKit Changes: https://git.openjdk.java.net/jfx/pull/263/files Webrev: https://webrevs.openjdk.java.net/jfx/263/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245284 Stats: 301003 lines in 5370 files changed: 146627 ins; 94168 del; 60208 mod Patch: https://git.openjdk.java.net/jfx/pull/263.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/263/head:pull/263 PR: https://git.openjdk.java.net/jfx/pull/263 From rlichten at openjdk.java.net Fri Jul 10 06:14:15 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 10 Jul 2020 06:14:15 GMT Subject: [jfx15] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v8] In-Reply-To: References: Message-ID: > This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Fix check condition in RTest. Replace underscore based variable names. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/138/files - new: https://git.openjdk.java.net/jfx/pull/138/files/bf9e08d7..3dd80c78 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/138/webrev.07 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.06-07 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138 PR: https://git.openjdk.java.net/jfx/pull/138 From rlichten at openjdk.java.net Fri Jul 10 06:14:17 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 10 Jul 2020 06:14:17 GMT Subject: [jfx15] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v7] In-Reply-To: References: Message-ID: On Thu, 9 Jul 2020 20:29:51 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException >> >> Clamping is no longer needed, removed it. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TextFieldTest.java line 475: > >> 474: assertEquals(4, txtField.getSelection().getStart()); >> 475: assertEquals(4, txtField.getSelection().getStart()); >> 476: } > > Did you mean to check `getStart()` twice? No I didn't. Good catch. Fixed in next commit. > modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 1924: > >> 1923: textInput.selectionProperty().addListener((__, ___, selection) -> selectionLog.append("|" + >> selection.getStart() + "," + selection.getEnd())); 1924: textInput.textProperty().addListener((__, ___, >> text) -> textLog.append("|" + text)); 1925: > > The pattern of using multiple underscores for unused variables isn't one we use. I recommend using something more > common like `obs` and `o` (or similar). Replaced the variable names in next commit. It looks like "observable" / "oldValue" / "newValue" are almost exclusively used in the current code base so I changed them to that. ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From rlichten at openjdk.java.net Fri Jul 10 06:14:32 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 10 Jul 2020 06:14:32 GMT Subject: [jfx15] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: <5dDCIGDVd43vo4JtxBVmSlPpZAhMjMKV5es8BZ6nj6c=.90895611-47ba-4f08-8232-3d2edd95dcf5@github.com> Message-ID: On Thu, 2 Jul 2020 23:39:58 GMT, Kevin Rushforth wrote: >> seeing that you are working at it (and still without too close a look, sry ;) - we need more tests about the >> notifications of all properties involved: text, selectedText, indexRange (anything else?). The things to test are >> count and old/new value. F.i. something like: >> List values = new ArrayList(); >> textField.selectedTextProperty().addListener((src, ov, nv) -> { >> list.addAll(ov, nv); >> } >> // do stuff >> assertEquals(2, values.size()); >> assertEquals(expectedOldValue, values.get(0)); >> assertEquals(expectedNewValue, values.get(1)); > > I need to do some more testing, but this looks like the right approach. > > This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. If I don't spot anything > of concern during the review, then I will ask you to retarget your PR to the `jfx15` branch. I changed the base branch of this PR by editing it in the github GUI. Is this all I need to do to retarget it for jfx15? ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From fastegal at swingempire.de Fri Jul 10 09:12:53 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 10 Jul 2020 11:12:53 +0200 Subject: JavaFx application with Windows 10 operating systems In-Reply-To: References: Message-ID: <20200710111253.Horde.Nru_DDC88jGKfAjYkq-drA5@webmail.df.eu> this mailing list is for fx developers - not for application devs :) And certainly not the place after to go after your question on SO https://stackoverflow.com/q/62807394/203657 was closed due to being too vague .. instead, edit that question to make it answerable (there's something wrong in your setup somewhere) Zitat von Guruprasad Kulkarni : > I have a application on JavaFX 12 , open jdk 11 . It runs on other > operating systems successfully . But on windows 10 certain editions it > fails to load the Java Fx components . > My application runs on Windows 7 , Windows 10 2017 edition . > It shows no exception or error while running . I have tried using Liberica > Bellsoft jdk but still my application fails . > Please if anyone is using JavaFx 11 on Windows 10 and encountered the same > problem please help me . > > Regards , > Guruprasad Kulkarni From aghaisas at openjdk.java.net Fri Jul 10 11:54:55 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 10 Jul 2020 11:54:55 GMT Subject: [jfx15] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v8] In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 06:14:15 GMT, Robert Lichtenberger wrote: >> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException > > Fix check condition in RTest. > Replace underscore based variable names. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Fri Jul 10 12:47:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Jul 2020 12:47:58 GMT Subject: RFR: 8245284: Update to 610.1 version of WebKit In-Reply-To: References: Message-ID: <_dUcA8V_BqBv-WbX8pA7u7TsZZ3f3jPGNrH3eRCialU=.6429c07d-6786-4ced-98b7-b92db06bda49@github.com> On Fri, 10 Jul 2020 05:26:39 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.28 (610.1) @bhaweshkc @johanvos can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/263 From kcr at openjdk.java.net Fri Jul 10 12:59:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Jul 2020 12:59:12 GMT Subject: [jfx15] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v8] In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 11:52:41 GMT, Ajit Ghaisas wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException >> >> Fix check condition in RTest. >> Replace underscore based variable names. > > Marked as reviewed by aghaisas (Reviewer). Yes, that's all you need to do to retarget the PR to `jfx15`. ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Fri Jul 10 13:20:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Jul 2020 13:20:20 GMT Subject: [jfx15] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v8] In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 06:14:15 GMT, Robert Lichtenberger wrote: >> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException > > Fix check condition in RTest. > Replace underscore based variable names. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From github.com+1413266+jgneff at openjdk.java.net Fri Jul 10 15:49:26 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 10 Jul 2020 15:49:26 GMT Subject: [jfx15] Integrated: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 03:47:55 GMT, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). This pull request has now been integrated. Changeset: d67c47fd Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d67c47fd Stats: 26 lines in 3 files changed: 0 ins; 20 del; 6 mod 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Fri Jul 10 21:33:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Jul 2020 21:33:07 GMT Subject: [jfx15] RFR: 8248490: [macOS] Undecorated stage does not minimize Message-ID: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> When running a JavaFX application on macOS using a JDK compiled with the MacOSX 10.13 SDK or later, an undecorated or transparent stage cannot be programmatically minimized (iconified). The reason for this failure is that JavaFX only sets the `NSMiniaturizableWindowMask` bit in the `styleMask` of the `NSWindow` for decorated windows. Previous versions of the MacOSX SDK would minimize and restore a windows regardless of the setting of this flag. When the application is compiled against a newer SDK, Apple honors that flag and prevents the window from being minimized. Note that it is the version of the SDK used to compile the JDK and not the version that is used to compile JavaFX that exposes this bug. The fix is to temporarily set the `NSMiniaturizableWindowMask` prior to calling `miniaturize` or `deminiaturize`, and restore it afterwards. This seems safer than setting the bit unconditionally when the NSWindow is created, which would have been another approach. A similar fix was done for AWT. See [JDK-8214046](https://bugs.openjdk.java.net/browse/JDK-8214046). I propose to fix this in JavaFX 15, so it it targeted to the `jfx15` branch. ------------- Commit messages: - 8248490: [macOS] Undecorated stage does not minimize Changes: https://git.openjdk.java.net/jfx/pull/264/files Webrev: https://webrevs.openjdk.java.net/jfx/264/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248490 Stats: 135 lines in 2 files changed: 134 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/264.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/264/head:pull/264 PR: https://git.openjdk.java.net/jfx/pull/264 From kcr at openjdk.java.net Fri Jul 10 21:33:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Jul 2020 21:33:17 GMT Subject: [jfx15] RFR: 8248490: [macOS] Undecorated stage does not minimize In-Reply-To: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> References: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> Message-ID: On Fri, 10 Jul 2020 18:23:58 GMT, Kevin Rushforth wrote: > When running a JavaFX application on macOS using a JDK compiled with the MacOSX 10.13 SDK or later, an undecorated or > transparent stage cannot be programmatically minimized (iconified). The reason for this failure is that JavaFX only > sets the `NSMiniaturizableWindowMask` bit in the `styleMask` of the `NSWindow` for decorated windows. Previous versions > of the MacOSX SDK would minimize and restore a windows regardless of the setting of this flag. When the application is > compiled against a newer SDK, Apple honors that flag and prevents the window from being minimized. Note that it is the > version of the SDK used to compile the JDK and not the version that is used to compile JavaFX that exposes this bug. > The fix is to temporarily set the `NSMiniaturizableWindowMask` prior to calling `miniaturize` or `deminiaturize`, and > restore it afterwards. This seems safer than setting the bit unconditionally when the NSWindow is created, which would > have been another approach. A similar fix was done for AWT. See > [JDK-8214046](https://bugs.openjdk.java.net/browse/JDK-8214046). I propose to fix this in JavaFX 15, so it it targeted > to the `jfx15` branch. On a related note, even after this fix, an undecorated window cannot be restored (deminiaturized) programmatically. This is not related and is not a regression. I filed [JDK-8249202](https://bugs.openjdk.java.net/browse/JDK-8249202) to track this as a follow-up issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/264 From kcr at openjdk.java.net Fri Jul 10 22:05:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Jul 2020 22:05:31 GMT Subject: RFR: 8245284: Update to 610.1 version of WebKit In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 05:26:39 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.28 (610.1) Looks good. Tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/263 From almatvee at openjdk.java.net Sat Jul 11 03:16:50 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 11 Jul 2020 03:16:50 GMT Subject: RFR: 8248365: Debug build crashes on Windows when playing media file Message-ID: <-qxH-QDfOuLEsF4J-AvqzmVPfZSrUAGQJ_qPsCEKMzE=.6ed63a38-9119-48b8-9915-d44a648e5084@github.com> According to information found for similar bugs filed against libffi, this is known issue with libffi. libffi modifies stack frames and it triggers stack frame run-time error checking. Fixed by disabling stack frame error checking in debug build. It was already off in release build. ------------- Commit messages: - 8248365: Debug build crashes on Windows when playing media file Changes: https://git.openjdk.java.net/jfx/pull/265/files Webrev: https://webrevs.openjdk.java.net/jfx/265/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248365 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/265.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/265/head:pull/265 PR: https://git.openjdk.java.net/jfx/pull/265 From kcr at openjdk.java.net Sat Jul 11 13:48:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 11 Jul 2020 13:48:58 GMT Subject: RFR: 8248365: Debug build crashes on Windows when playing media file In-Reply-To: <-qxH-QDfOuLEsF4J-AvqzmVPfZSrUAGQJ_qPsCEKMzE=.6ed63a38-9119-48b8-9915-d44a648e5084@github.com> References: <-qxH-QDfOuLEsF4J-AvqzmVPfZSrUAGQJ_qPsCEKMzE=.6ed63a38-9119-48b8-9915-d44a648e5084@github.com> Message-ID: On Sat, 11 Jul 2020 03:04:16 GMT, Alexander Matveev wrote: > According to information found for similar bugs filed against libffi, this is known issue with libffi. libffi modifies > stack frames and it triggers stack frame run-time error checking. Fixed by disabling stack frame error checking in > debug build. It was already off in release build. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/265 From rlichten at openjdk.java.net Mon Jul 13 13:00:07 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 13 Jul 2020 13:00:07 GMT Subject: [jfx15] Integrated: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: <9GlRrERx8ClLASU3TBPZSszIzO4F9V3iekSY1tEPWKs=.829ee748-12e2-408d-bfb2-42c4417e9559@github.com> On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger wrote: > This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. This pull request has now been integrated. Changeset: e2d1c021 Author: Robert Lichtenberger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e2d1c021 Stats: 219 lines in 4 files changed: 18 ins; 172 del; 29 mod 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From bchoudhary at openjdk.java.net Mon Jul 13 14:03:11 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 13 Jul 2020 14:03:11 GMT Subject: RFR: 8245284: Update to 610.1 version of WebKit In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 22:03:22 GMT, Kevin Rushforth wrote: >> Update JavaFX WebKit to GTK WebKit 2.28 (610.1) > > Looks good. Tested on all three platforms. Checked with various websites on all three platform. Looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/263 From bchoudhary at openjdk.java.net Mon Jul 13 17:15:07 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 13 Jul 2020 17:15:07 GMT Subject: RFR: 8245284: Update to 610.1 version of WebKit In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 05:26:39 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.28 (610.1) Marked as reviewed by bchoudhary (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/263 From almatvee at openjdk.java.net Mon Jul 13 20:45:27 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 13 Jul 2020 20:45:27 GMT Subject: Integrated: 8248365: Debug build crashes on Windows when playing media file In-Reply-To: <-qxH-QDfOuLEsF4J-AvqzmVPfZSrUAGQJ_qPsCEKMzE=.6ed63a38-9119-48b8-9915-d44a648e5084@github.com> References: <-qxH-QDfOuLEsF4J-AvqzmVPfZSrUAGQJ_qPsCEKMzE=.6ed63a38-9119-48b8-9915-d44a648e5084@github.com> Message-ID: On Sat, 11 Jul 2020 03:04:16 GMT, Alexander Matveev wrote: > According to information found for similar bugs filed against libffi, this is known issue with libffi. libffi modifies > stack frames and it triggers stack frame run-time error checking. Fixed by disabling stack frame error checking in > debug build. It was already off in release build. This pull request has now been integrated. Changeset: 946590e6 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/946590e6 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8248365: Debug build crashes on Windows when playing media file Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/265 From kevin.rushforth at oracle.com Tue Jul 14 16:10:48 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Jul 2020 09:10:48 -0700 Subject: [jfx15] RFR: Request to sync July 2020 CPU changes into jfx Message-ID: <73851f38-6ee5-996b-de35-7cec69fc98b0@oracle.com> Johan and Phil, I request approval to sync changes from to the just-released July 2020 CPU release into the 'jfx15' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/e2d1c02...cpu-2007-sync NOTE: Since this is an integration of already-reviewed fixes into the jfx15 branch of the jfx repo, I will push it directly rather than via a pull request. -- Kevin From kevin.rushforth at oracle.com Tue Jul 14 16:11:21 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 14 Jul 2020 09:11:21 -0700 Subject: [11][14] RFR: Request to backport July 2020 CPU changes Message-ID: Hi Johan, I request approval to backport the changes from the just-released July 2020 CPU to 11-dev (for 11.0.8) and the jfx14 branch of jfx (for 14.0.2). https://cr.openjdk.java.net/~kcr/cpu-2007-sync/11-dev/webrev/ https://github.com/kevinrushforth/jfx/compare/5f9ba88...14-cpu-2007-sync Each is a straight backport (patch applies cleanly) of the two FX fixes that went into the July CPU. NOTE: For the 14.0.2 backport, since this is an integration of already-reviewed fixes into the jfx repo, I will push it directly into the jfx14 branch rather than via a pull request. The 11.0.8 backport will be pushed to the HG 11-dev repo. Thanks. -- Kevin From johan.vos at gluonhq.com Tue Jul 14 17:10:35 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Jul 2020 19:10:35 +0200 Subject: [jfx15] RFR: Request to sync July 2020 CPU changes into jfx In-Reply-To: <73851f38-6ee5-996b-de35-7cec69fc98b0@oracle.com> References: <73851f38-6ee5-996b-de35-7cec69fc98b0@oracle.com> Message-ID: Approved. On Tue, Jul 14, 2020 at 6:12 PM Kevin Rushforth wrote: > Johan and Phil, > > I request approval to sync changes from to the just-released July 2020 > CPU release into the 'jfx15' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/e2d1c02...cpu-2007-sync > > NOTE: Since this is an integration of already-reviewed fixes into the > jfx15 branch of the jfx repo, I will push it directly rather than via a > pull request. > > -- Kevin > > From johan.vos at gluonhq.com Tue Jul 14 17:10:56 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 14 Jul 2020 19:10:56 +0200 Subject: [11][14] RFR: Request to backport July 2020 CPU changes In-Reply-To: References: Message-ID: Approved. On Tue, Jul 14, 2020 at 6:11 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released July > 2020 CPU to 11-dev (for 11.0.8) and the jfx14 branch of jfx (for 14.0.2). > > https://cr.openjdk.java.net/~kcr/cpu-2007-sync/11-dev/webrev/ > https://github.com/kevinrushforth/jfx/compare/5f9ba88...14-cpu-2007-sync > > Each is a straight backport (patch applies cleanly) of the two FX fixes > that went into the July CPU. > > NOTE: For the 14.0.2 backport, since this is an integration of > already-reviewed fixes into the jfx repo, I will push it directly into > the jfx14 branch rather than via a pull request. The 11.0.8 backport > will be pushed to the HG 11-dev repo. > > Thanks. > > -- Kevin > > From philip.race at oracle.com Tue Jul 14 17:26:40 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 14 Jul 2020 10:26:40 -0700 Subject: [jfx15] RFR: Request to sync July 2020 CPU changes into jfx In-Reply-To: References: <73851f38-6ee5-996b-de35-7cec69fc98b0@oracle.com> Message-ID: <5F0DEAD0.4050300@oracle.com> +1 -phil On 7/14/20, 10:10 AM, Johan Vos wrote: > Approved. > > On Tue, Jul 14, 2020 at 6:12 PM Kevin Rushforth > > wrote: > > Johan and Phil, > > I request approval to sync changes from to the just-released July > 2020 > CPU release into the 'jfx15' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/e2d1c02...cpu-2007-sync > > NOTE: Since this is an integration of already-reviewed fixes into the > jfx15 branch of the jfx repo, I will push it directly rather than > via a > pull request. > > -- Kevin > From nlisker at openjdk.java.net Wed Jul 15 00:18:20 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 15 Jul 2020 00:18:20 GMT Subject: RFR: 8217472: Add attenuation for PointLight In-Reply-To: References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com> Message-ID: <4uhrEVJ-wHYPHLQ0AJfr-UmITcWmTFwYwJb8jUFEXfc=.ef638d75-6f4b-4a61-8f41-4ee4e0943c17@github.com> On Fri, 3 Jul 2020 13:49:20 GMT, Kevin Rushforth wrote: >> I've added sphere with 10, 64 (default) and 200 divisions. Note that this number is approximate because the sphere mesh >> corrects the division number with `newDivisions = ((oldDivisions + 3) / 4) * 4`. >> [attenTest.zip](https://github.com/openjdk/jfx/files/4855989/attenTest.zip) Using AMD RX 470 4GB on Win 10, all 3 >> spheres averaged 120 fps both before and after the patch. (It takes a couple of measurements to hit the consistent fps, >> so I discarded them.) > >> I've added sphere with 10, 64 (default) and 200 divisions. > > Thanks, I'll take a look at it. Using AMD RX 470 4GB on Ubuntu 18, all 3 spheres averaged 60 fps both before and after the patch. I wonder why the number is half what it is on Windows. Is it capped? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Wed Jul 15 11:04:02 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Jul 2020 11:04:02 GMT Subject: [jfx15] RFR: 8248490: [macOS] Undecorated stage does not minimize In-Reply-To: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> References: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> Message-ID: On Fri, 10 Jul 2020 18:23:58 GMT, Kevin Rushforth wrote: > When running a JavaFX application on macOS using a JDK compiled with the MacOSX 10.13 SDK or later, an undecorated or > transparent stage cannot be programmatically minimized (iconified). The reason for this failure is that JavaFX only > sets the `NSMiniaturizableWindowMask` bit in the `styleMask` of the `NSWindow` for decorated windows. Previous versions > of the MacOSX SDK would minimize and restore a windows regardless of the setting of this flag. When the application is > compiled against a newer SDK, Apple honors that flag and prevents the window from being minimized. Note that it is the > version of the SDK used to compile the JDK and not the version that is used to compile JavaFX that exposes this bug. > The fix is to temporarily set the `NSMiniaturizableWindowMask` prior to calling `miniaturize` or `deminiaturize`, and > restore it afterwards. This seems safer than setting the bit unconditionally when the NSWindow is created, which would > have been another approach. A similar fix was done for AWT. See > [JDK-8214046](https://bugs.openjdk.java.net/browse/JDK-8214046). I propose to fix this in JavaFX 15, so it it targeted > to the `jfx15` branch. Fix and test both look good to me. Confirmed that test fails before and passes after the fix. At current stage of jfx15, approach of safe fix seems preferable over always setting the the style. Just a small query, will we fix this differently in main line ? ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/264 From aghaisas at openjdk.java.net Wed Jul 15 11:42:53 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 15 Jul 2020 11:42:53 GMT Subject: [jfx15] RFR: 8248490: [macOS] Undecorated stage does not minimize In-Reply-To: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> References: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> Message-ID: On Fri, 10 Jul 2020 18:23:58 GMT, Kevin Rushforth wrote: > When running a JavaFX application on macOS using a JDK compiled with the MacOSX 10.13 SDK or later, an undecorated or > transparent stage cannot be programmatically minimized (iconified). The reason for this failure is that JavaFX only > sets the `NSMiniaturizableWindowMask` bit in the `styleMask` of the `NSWindow` for decorated windows. Previous versions > of the MacOSX SDK would minimize and restore a windows regardless of the setting of this flag. When the application is > compiled against a newer SDK, Apple honors that flag and prevents the window from being minimized. Note that it is the > version of the SDK used to compile the JDK and not the version that is used to compile JavaFX that exposes this bug. > The fix is to temporarily set the `NSMiniaturizableWindowMask` prior to calling `miniaturize` or `deminiaturize`, and > restore it afterwards. This seems safer than setting the bit unconditionally when the NSWindow is created, which would > have been another approach. A similar fix was done for AWT. See > [JDK-8214046](https://bugs.openjdk.java.net/browse/JDK-8214046). I propose to fix this in JavaFX 15, so it it targeted > to the `jfx15` branch. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/264 From kcr at openjdk.java.net Wed Jul 15 13:08:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Jul 2020 13:08:38 GMT Subject: [jfx15] RFR: 8248490: [macOS] Undecorated stage does not minimize In-Reply-To: References: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> Message-ID: On Wed, 15 Jul 2020 11:01:43 GMT, Ambarish Rapte wrote: > Just a small query, will we fix this differently in main line ? No, I wasn't planning to revisit this. At least not until looking at the (P4) follow-up issue, [JDK-8249202](https://bugs.openjdk.java.net/browse/JDK-8249202). ------------- PR: https://git.openjdk.java.net/jfx/pull/264 From kcr at openjdk.java.net Wed Jul 15 13:11:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Jul 2020 13:11:51 GMT Subject: RFR: 8217472: Add attenuation for PointLight In-Reply-To: <4uhrEVJ-wHYPHLQ0AJfr-UmITcWmTFwYwJb8jUFEXfc=.ef638d75-6f4b-4a61-8f41-4ee4e0943c17@github.com> References: <-Wfh_fffU1Owa9UGpp7bn7-lvtyKrKcLPAHeorPg2nk=.49c4dfe8-c8c3-4494-88f2-a90e2c12fbe9@github.com> <89ZguUrld7xsjkqAQnIdMQZIPnF6AZGMjAuqDYnzb-E=.6ccbc0f7-8887-430b-978b-992020640247@github.com> <_HwDxHR7B4Rl6smz5yCeY_I9429IJkxqPnWA5qRA_4E=.9b6bf318-2a74-4c06-ab9f-a7a9f0d09a0d@github.com> <2Yjn1Udbz91bkTcY9nawqbsii7J08Utb4es ypGtttZU=.6685d2fd-1a14-478e-8fa3-6e0adaa224f7@github.com> <91gZ9ZTgmrN9sF8kZ9HoXVlPsSuGI-kjoQiTWK2tucw=.5fa95f24-bd57-49c3-9a5d-42cc689bf91f@github.com> <4uhrEVJ-wHYPHLQ0AJfr-UmITcWmTFwYwJb8jUFEXfc=.ef638d75-6f4b-4a61-8f41-4ee4e0943c17@github.com> Message-ID: On Wed, 15 Jul 2020 00:16:03 GMT, Nir Lisker wrote: >>> I've added sphere with 10, 64 (default) and 200 divisions. >> >> Thanks, I'll take a look at it. > > Using AMD RX 470 4GB on Ubuntu 18, all 3 spheres averaged 60 fps both before and after the patch. > > I wonder why the number is half what it is on Windows. Is it capped? Yes, in general frame rate should be limited to the refresh rate of the monitor, although it isn't in all cases. I would not count on running faster than 60 fps. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Wed Jul 15 13:23:53 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Jul 2020 13:23:53 GMT Subject: [jfx15] RFR: 8248490: [macOS] Undecorated stage does not minimize In-Reply-To: References: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> Message-ID: <2onDhHS_1eI2STrxeQexyIGmv8Jm_81tUHuvUoTRLCg=.877d823c-b939-4fb0-b046-7902008e266d@github.com> On Wed, 15 Jul 2020 13:06:27 GMT, Kevin Rushforth wrote: > At least not until looking at the (P4) follow-up issue, [JDK-8249202](https://bugs.openjdk.java.net/browse/JDK-8249202). Sounds good to me, we can address these together. ------------- PR: https://git.openjdk.java.net/jfx/pull/264 From kcr at openjdk.java.net Wed Jul 15 13:33:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Jul 2020 13:33:14 GMT Subject: [jfx15] Integrated: 8248490: [macOS] Undecorated stage does not minimize In-Reply-To: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> References: <1sTH8z9ioB_SRK_yUT6iVrnVkJp_GKtabLz8n6UT_K4=.8a14c8d4-6bd9-4ecf-a231-099a6570eb4e@github.com> Message-ID: On Fri, 10 Jul 2020 18:23:58 GMT, Kevin Rushforth wrote: > When running a JavaFX application on macOS using a JDK compiled with the MacOSX 10.13 SDK or later, an undecorated or > transparent stage cannot be programmatically minimized (iconified). The reason for this failure is that JavaFX only > sets the `NSMiniaturizableWindowMask` bit in the `styleMask` of the `NSWindow` for decorated windows. Previous versions > of the MacOSX SDK would minimize and restore a windows regardless of the setting of this flag. When the application is > compiled against a newer SDK, Apple honors that flag and prevents the window from being minimized. Note that it is the > version of the SDK used to compile the JDK and not the version that is used to compile JavaFX that exposes this bug. > The fix is to temporarily set the `NSMiniaturizableWindowMask` prior to calling `miniaturize` or `deminiaturize`, and > restore it afterwards. This seems safer than setting the bit unconditionally when the NSWindow is created, which would > have been another approach. A similar fix was done for AWT. See > [JDK-8214046](https://bugs.openjdk.java.net/browse/JDK-8214046). I propose to fix this in JavaFX 15, so it it targeted > to the `jfx15` branch. This pull request has now been integrated. Changeset: 2f4666a7 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2f4666a7 Stats: 135 lines in 2 files changed: 0 ins; 134 del; 1 mod 8248490: [macOS] Undecorated stage does not minimize Reviewed-by: arapte, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/264 From prr at openjdk.java.net Thu Jul 16 00:11:56 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 16 Jul 2020 00:11:56 GMT Subject: RFR: 8248908: Printer.createPageLayout() returns 0.75"margins instead of hardware margins Message-ID: For a Media that had no defined size - eg a "custom" paper - the code was creating a mapping that over-rode the NA_LETTER size. This might cause multiple problems but definitely meant that we ended up with default margins. ------------- Commit messages: - 8248908: Printer.createPageLayout() returns 0.75"margins instead of hardware margins Changes: https://git.openjdk.java.net/jfx/pull/266/files Webrev: https://webrevs.openjdk.java.net/jfx/266/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248908 Stats: 129 lines in 2 files changed: 117 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/266.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/266/head:pull/266 PR: https://git.openjdk.java.net/jfx/pull/266 From sproket at videotron.ca Thu Jul 16 12:51:33 2020 From: sproket at videotron.ca (Dan Howard) Date: Thu, 16 Jul 2020 08:51:33 -0400 Subject: RFR: 8248908: Printer.createPageLayout() returns 0.75"margins instead of hardware margins In-Reply-To: References: Message-ID: I don't think the private method needs to be final. Does? it? On 7/15/2020 8:11 PM, Phil Race wrote: > For a Media that had no defined size - eg a "custom" paper - the code was creating a mapping > that over-rode the NA_LETTER size. This might cause multiple problems but definitely meant that > we ended up with default margins. > > ------------- > > Commit messages: > - 8248908: Printer.createPageLayout() returns 0.75"margins instead of hardware margins > > Changes: https://git.openjdk.java.net/jfx/pull/266/files > Webrev: https://webrevs.openjdk.java.net/jfx/266/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8248908 > Stats: 129 lines in 2 files changed: 117 ins; 8 del; 4 mod > Patch: https://git.openjdk.java.net/jfx/pull/266.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/266/head:pull/266 > > PR: https://git.openjdk.java.net/jfx/pull/266 From kcr at openjdk.java.net Thu Jul 16 17:11:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Jul 2020 17:11:03 GMT Subject: RFR: 8248908: Printer.createPageLayout() returns 0.75"margins instead of hardware margins In-Reply-To: References: Message-ID: On Wed, 15 Jul 2020 23:54:59 GMT, Phil Race wrote: > For a Media that had no defined size - eg a "custom" paper - the code was creating a mapping > that over-rode the NA_LETTER size. This might cause multiple problems but definitely meant that > we ended up with default margins. Fix looks good. I left one minor comment on the test. Btw, it looks like you are missing a space between `0.75"` and `margins` in the PR title, which is why Skara is saying: `Title mismatch between PR and JBS.` modules/javafx.graphics/src/test/java/test/javafx/print/MarginsTest.java line 54: > 53: if (printer == null) { > 54: return; > 55: } Minor: Normally we would use `assumeNotNull` so the test is marked as skipped rather than passed. ------------- PR: https://git.openjdk.java.net/jfx/pull/266 From johan.vos at gluonhq.com Thu Jul 16 18:10:16 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 16 Jul 2020 20:10:16 +0200 Subject: Request for permission to backport to 14 Message-ID: Hi Kevin, I request permission to backport the following fixes to the jfx14 branch: JDK-8244579: Windows "User Objects" leakage with WebView JDK-8237889: Update libxml2 to version 2.9.10 JDK-8239107: Update libjpeg to version 9d JDK-8236832: [macos 10.15] JavaFX Application hangs on video play on Catalina JDK-8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina JDK-8241629: [macos10.15] Long startup delay playing media over https on Catalina JDK-8234474: [macos 10.15] Crash in file dialog in sandbox mode Thanks, - Johan From kevin.rushforth at oracle.com Thu Jul 16 18:23:45 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 16 Jul 2020 11:23:45 -0700 Subject: Request for permission to backport to 14 In-Reply-To: References: Message-ID: <90332d9d-29ee-5cd7-80e1-8545fac3d04d@oracle.com> +1 -- Kevin On 7/16/2020 11:10 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following fixes to the jfx14 branch: > > JDK-8244579:?Windows "User Objects" leakage with WebView > JDK-8237889: Update libxml2 to version 2.9.10 > JDK-8239107: Update libjpeg to version 9d > JDK-8236832: [macos 10.15] JavaFX Application hangs on video play on > Catalina > JDK-8240694: [macos 10.15] JavaFX Media hangs on some video files on > Catalina > JDK-8241629: [macos10.15] Long startup delay playing media over https > on Catalina > JDK-8234474: [macos 10.15] Crash in file dialog in sandbox mode > > Thanks, > > - Johan From sykora at openjdk.java.net Thu Jul 16 18:38:50 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Thu, 16 Jul 2020 18:38:50 GMT Subject: RFR: 8245284: Update to 610.1 version of WebKit In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 05:26:39 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.28 (610.1) Successfully tested building on all three platforms. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/263 From prr at openjdk.java.net Thu Jul 16 18:39:46 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 16 Jul 2020 18:39:46 GMT Subject: RFR: 8248908: Printer.createPageLayout() returns 0.75" margins instead of hardware margins [v2] In-Reply-To: References: Message-ID: <_bUemcAphLyatGwz8j7Rx6I02-SkBnJLh2M6l-DImv4=.6e1a9f8d-e40c-4620-82eb-af637d04e0fb@github.com> > For a Media that had no defined size - eg a "custom" paper - the code was creating a mapping > that over-rode the NA_LETTER size. This might cause multiple problems but definitely meant that > we ended up with default margins. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8248908: Printer.createPageLayout() returns 0.75" instead of hardware margins ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/266/files - new: https://git.openjdk.java.net/jfx/pull/266/files/d54cd40d..e517ca55 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/266/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/266/webrev.00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/266.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/266/head:pull/266 PR: https://git.openjdk.java.net/jfx/pull/266 From kcr at openjdk.java.net Thu Jul 16 18:39:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Jul 2020 18:39:59 GMT Subject: RFR: 8248908: Printer.createPageLayout() returns 0.75" margins instead of hardware margins [v2] In-Reply-To: <_bUemcAphLyatGwz8j7Rx6I02-SkBnJLh2M6l-DImv4=.6e1a9f8d-e40c-4620-82eb-af637d04e0fb@github.com> References: <_bUemcAphLyatGwz8j7Rx6I02-SkBnJLh2M6l-DImv4=.6e1a9f8d-e40c-4620-82eb-af637d04e0fb@github.com> Message-ID: On Thu, 16 Jul 2020 18:39:46 GMT, Phil Race wrote: >> For a Media that had no defined size - eg a "custom" paper - the code was creating a mapping >> that over-rode the NA_LETTER size. This might cause multiple problems but definitely meant that >> we ended up with default margins. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8248908: Printer.createPageLayout() returns 0.75" instead of hardware margins Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/266 From ajoseph at openjdk.java.net Thu Jul 16 18:55:59 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 16 Jul 2020 18:55:59 GMT Subject: Integrated: 8245284: Update to 610.1 version of WebKit In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 05:26:39 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.28 (610.1) This pull request has now been integrated. Changeset: 5e7e452c Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/5e7e452c Stats: 300855 lines in 5370 files changed: 94021 ins; 146480 del; 60354 mod 8245284: Update to 610.1 version of WebKit Co-authored-by: Guru Hb Co-authored-by: Bhawesh Choudhary Reviewed-by: kcr, bchoudhary, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/263 From prr at openjdk.java.net Thu Jul 16 19:03:46 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 16 Jul 2020 19:03:46 GMT Subject: Integrated: 8248908: Printer.createPageLayout() returns 0.75" margins instead of hardware margins In-Reply-To: References: Message-ID: <5j-fvxKkkWRzjCr2eYxKwl1fVV5LcJPpdaKcY79r6H4=.de3aeef0-144d-4d2d-8048-b7f735aa1091@github.com> On Wed, 15 Jul 2020 23:54:59 GMT, Phil Race wrote: > For a Media that had no defined size - eg a "custom" paper - the code was creating a mapping > that over-rode the NA_LETTER size. This might cause multiple problems but definitely meant that > we ended up with default margins. This pull request has now been integrated. Changeset: f056d24b Author: Phil Race URL: https://git.openjdk.java.net/jfx/commit/f056d24b Stats: 123 lines in 2 files changed: 2 ins; 111 del; 10 mod 8248908: Printer.createPageLayout() returns 0.75" margins instead of hardware margins Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/266 From jvos at openjdk.java.net Thu Jul 16 20:34:18 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Jul 2020 20:34:18 GMT Subject: [jfx14] RFR: 8249635: Change JavaFX release version in jfx14 branch to 14.0.2.1 Message-ID: Set the patch version for JavaFX 14.0.2.1 Fix for JDK-8249635 ------------- Commit messages: - set patch version to 1 for the upcoming 14.0.2.1 release Changes: https://git.openjdk.java.net/jfx/pull/267/files Webrev: https://webrevs.openjdk.java.net/jfx/267/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249635 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/267.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/267/head:pull/267 PR: https://git.openjdk.java.net/jfx/pull/267 From kcr at openjdk.java.net Thu Jul 16 20:34:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Jul 2020 20:34:29 GMT Subject: [jfx14] RFR: 8249635: Change JavaFX release version in jfx14 branch to 14.0.2.1 In-Reply-To: References: Message-ID: On Thu, 16 Jul 2020 20:16:54 GMT, Johan Vos wrote: > Set the patch version for JavaFX 14.0.2.1 > Fix for JDK-8249635 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/267 From jvos at openjdk.java.net Thu Jul 16 20:34:29 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Jul 2020 20:34:29 GMT Subject: [jfx14] Integrated: 8249635: Change JavaFX release version in jfx14 branch to 14.0.2.1 In-Reply-To: References: Message-ID: On Thu, 16 Jul 2020 20:16:54 GMT, Johan Vos wrote: > Set the patch version for JavaFX 14.0.2.1 > Fix for JDK-8249635 This pull request has now been integrated. Changeset: dac82880 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/dac82880 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8249635: Change JavaFX release version in jfx14 branch to 14.0.2.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/267 From kevin.rushforth at oracle.com Fri Jul 17 22:40:41 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Jul 2020 15:40:41 -0700 Subject: Removing obsolete NetBeans IDE files from jfx source repo (JDK-8223375) Message-ID: <0165b7a5-fcc7-ea23-b061-a9641805ac78@oracle.com> I propose to remove the obsolete NetBeans IDE files from the JavaFX source repo. See JDK-8223375 [1]. Those files were written to run with NetBeans 8. We sort of limped along with FX 9 using JDK 8 to browse and navigate the sources, but it really doesn't work at all now. I just downloaded NetBeans 12, which has added support for gradle 6.3, to see if I could load and run JavaFX using their gradle plugin (I had some mixed success with NetBeans 11.x). Using JDK 14, and Netbeans' default gradle plugin, I can load the "jfx" project, which uses build.gradle to configure the projects> I get no warnings or errors now. The only minor problem I had is that if I close NetBeans with the project open, it seems to misplace the subprojects (base, graphics, etc.) when I open it back up. I then have to close and reopen the main 'jfx' project. Then all seems happy again. If there are no concerns, I will send a out a pull request next week to remove the old NB project files. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8223375 From kevin.rushforth at oracle.com Fri Jul 17 23:31:56 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Jul 2020 16:31:56 -0700 Subject: Using NetBeans to develop JavaFX [was: Removing obsolete NetBeans IDE files from jfx source repo (JDK-8223375)] In-Reply-To: <0165b7a5-fcc7-ea23-b061-a9641805ac78@oracle.com> References: <0165b7a5-fcc7-ea23-b061-a9641805ac78@oracle.com> Message-ID: I spoke too soon about NB 12 working well for me, although I still think we should remove the obsolete nbproject files, (unless someone is inexplicably using them). I can open and navigate javafx.base just fine, since it doesn't depend on any other modules. When I open any file in javafx.graphics that relies on javafx.base, it can't resolve it, so it shows a whole pile of errors in the file, and you can't navigate to any class in the javafx.base module. Same problem with javafx.controls not recognizing the javafx.base or javafx.graphics modules. I'm reasonably sure I had this working with NB 11.x with a previous incarnation of JavaFX (before the recent gradle / JDK upgrades), but now I'm not so sure. Is anyone else using NetBeans for developing JavaFX itself (as opposed to developing an app that uses JavaFX)? Or has everyone switched to IntelliJ? I'd like to stick with NetBeans, but will need a solution (or viable workaround) to this problem. -- Kevin On 7/17/2020 3:40 PM, Kevin Rushforth wrote: > I propose to remove the obsolete NetBeans IDE files from the JavaFX > source repo. See JDK-8223375 [1]. Those files were written to run with > NetBeans 8. We sort of limped along with FX 9 using JDK 8 to browse > and navigate the sources, but it really doesn't work at all now. > > I just downloaded NetBeans 12, which has added support for gradle 6.3, > to see if I could load and run JavaFX using their gradle plugin (I had > some mixed success with NetBeans 11.x). > > Using JDK 14, and Netbeans' default gradle plugin, I can load the > "jfx" project, which uses build.gradle to configure the projects> I > get no warnings or errors now. > > The only minor problem I had is that if I close NetBeans with the > project open, it seems to misplace the subprojects (base, graphics, > etc.) when I open it back up. I then have to close and reopen the main > 'jfx' project. Then all seems happy again. > > If there are no concerns, I will send a out a pull request next week > to remove the old NB project files. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8223375 > From neil at codelerity.com Sat Jul 18 11:02:48 2020 From: neil at codelerity.com (Neil C Smith) Date: Sat, 18 Jul 2020 12:02:48 +0100 Subject: Using NetBeans to develop JavaFX [was: Removing obsolete NetBeans IDE files from jfx source repo (JDK-8223375)] In-Reply-To: References: <0165b7a5-fcc7-ea23-b061-a9641805ac78@oracle.com> Message-ID: On Sat, 18 Jul 2020 at 00:34, Kevin Rushforth wrote: > I can open and navigate javafx.base just fine, since it doesn't depend > on any other modules. When I open any file in javafx.graphics that > relies on javafx.base, it can't resolve it, so it shows a whole pile of > errors in the file, ... > Is anyone else using NetBeans for developing JavaFX itself (as opposed > to developing an app that uses JavaFX)? Or has everyone switched to > IntelliJ? I'd like to stick with NetBeans, but will need a solution (or > viable workaround) to this problem. If you haven't already, please also cross-post this on our (NetBeans) dev@ list at Apache. Be good to see if we can get this looked at for 12.1 over next few weeks. Best wishes, Neil -- Neil C Smith Codelerity Ltd. www.codelerity.com Codelerity Ltd. is a company registered in England and Wales Registered company number : 12063669 Registered office address : Office 4 219 Kensington High Street, Kensington, London, England, W8 6BD From kcr at openjdk.java.net Sat Jul 18 15:10:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Jul 2020 15:10:05 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer Message-ID: This removes the obsolete OpenPiscesRasterizer (Java-based) and NativePiscesRasterizer implementations. The Marlin rasterizer was added in FX 9 and was made the default in FX 10. Marlin both outperforms Pisces and is more robust. There is no reason to keep the Pisces rasterizer(s) any more. Note that the SW pipeline still has a Pisces-based renderer for the actual rendering of primitives. This is separate from the rasterizer and is not affected by this proposed fix. I have tested this on Mac, Windows, and Linux. ------------- Commit messages: - 8196079: Remove obsolete Pisces rasterizer Changes: https://git.openjdk.java.net/jfx/pull/268/files Webrev: https://webrevs.openjdk.java.net/jfx/268/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196079 Stats: 10224 lines in 30 files changed: 1 ins; 10217 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/268/head:pull/268 PR: https://git.openjdk.java.net/jfx/pull/268 From mp at jugs.org Sat Jul 18 15:50:09 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Jul 2020 17:50:09 +0200 Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: Message-ID: <0e929e1a-764d-fe3f-bb3f-70cfbc44265e@jugs.org> Am 18.07.20 um 17:10 schrieb Kevin Rushforth: > Note that the SW pipeline still has a Pisces-based renderer for the actual rendering of primitives. This is separate > from the rasterizer and is not affected by this proposed fix. Just out of curiosity - why is this still needed? Wouldn't it be nice to remove Pisces completely? Michael From kevin.rushforth at oracle.com Sat Jul 18 15:57:07 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 18 Jul 2020 08:57:07 -0700 Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: <0e929e1a-764d-fe3f-bb3f-70cfbc44265e@jugs.org> References: <0e929e1a-764d-fe3f-bb3f-70cfbc44265e@jugs.org> Message-ID: <281613a9-497a-d812-604e-a7127b2a9ab2@oracle.com> On 7/18/2020 8:50 AM, Michael Paus wrote: > Am 18.07.20 um 17:10 schrieb Kevin Rushforth: >> Note that the SW pipeline still has a Pisces-based renderer for the >> actual rendering of primitives. This is separate >> from the rasterizer and is not affected by this proposed fix. > > Just out of curiosity - why is this still needed? Wouldn't it be nice > to remove Pisces completely? We still fall back to the SW pipeline for a few cases, such as virtual environments without HW graphics support (Windows Remote Desktop, VMWare, VirtualBox), systems with insufficient graphics HW or drivers (mainly on Linux, but also on some Windows servers). -- Kevin From prr at openjdk.java.net Sat Jul 18 16:13:48 2020 From: prr at openjdk.java.net (Phil Race) Date: Sat, 18 Jul 2020 16:13:48 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: Message-ID: On Sat, 18 Jul 2020 14:57:08 GMT, Kevin Rushforth wrote: > This removes the obsolete OpenPiscesRasterizer (Java-based) and NativePiscesRasterizer implementations. The Marlin > rasterizer was added in FX 9 and was made the default in FX 10. Marlin both outperforms Pisces and is more robust. > There is no reason to keep the Pisces rasterizer(s) any more. Note that the SW pipeline still has a Pisces-based > renderer for the actual rendering of primitives. This is separate from the rasterizer and is not affected by this > proposed fix. I have tested this on Mac, Windows, and Linux. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/268 From mp at jugs.org Sat Jul 18 17:20:41 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 18 Jul 2020 19:20:41 +0200 Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: <281613a9-497a-d812-604e-a7127b2a9ab2@oracle.com> References: <0e929e1a-764d-fe3f-bb3f-70cfbc44265e@jugs.org> <281613a9-497a-d812-604e-a7127b2a9ab2@oracle.com> Message-ID: Am 18.07.20 um 17:57 schrieb Kevin Rushforth: > > On 7/18/2020 8:50 AM, Michael Paus wrote: >> Am 18.07.20 um 17:10 schrieb Kevin Rushforth: >>> Note that the SW pipeline still has a Pisces-based renderer for the >>> actual rendering of primitives. This is separate >>> from the rasterizer and is not affected by this proposed fix. >> >> Just out of curiosity - why is this still needed? Wouldn't it be nice >> to remove Pisces completely? > > We still fall back to the SW pipeline for a few cases, such as virtual > environments without HW graphics support (Windows Remote Desktop, > VMWare, VirtualBox), systems with insufficient graphics HW or drivers > (mainly on Linux, but also on some Windows servers). I think you misunderstood my question. Of course I know that JavaFX has a SW pipeline which is used under certain conditions. My question was why this SW pipeline still uses Pisces. The Marlin renderer has replaced Pisces in all other areas, as far as I know. Why not also in the SW pipeline. In how far are the requirements of the SW pipeline different from the ones in AWT for example? Michael From kcr at openjdk.java.net Sat Jul 18 22:10:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Jul 2020 22:10:11 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: Message-ID: <86uysTW0QF8oStyO-RKixXqyca_HkneV2TC5nffHK0Y=.03950a76-b06c-45be-9b93-1583f305fce4@github.com> On Sat, 18 Jul 2020 16:11:38 GMT, Phil Race wrote: >> This removes the obsolete OpenPiscesRasterizer (Java-based) and NativePiscesRasterizer implementations. The Marlin >> rasterizer was added in FX 9 and was made the default in FX 10. Marlin both outperforms Pisces and is more robust. >> There is no reason to keep the Pisces rasterizer(s) any more. Note that the SW pipeline still has a Pisces-based >> renderer for the actual rendering of primitives. This is separate from the rasterizer and is not affected by this >> proposed fix. I have tested this on Mac, Windows, and Linux. > > Marked as reviewed by prr (Reviewer). I think you are conflating the rasterization step with the rendering step. In Prism the rasterization mainly includes clipping the shape and generating the mask data for the filled and/or stroked shape (the latter possibly being a wide and/or dashed stroke). The rasterized shape is then sent to the Prism GraphicsPipeline for drawing into the render target. This latter step is either done using shaders + D3D or OpenGL, or via the SW pipeline (or the J2D pipeline for printing). In the case of the SW pipeline, the renderer is based on code that was originally derived from Pisces, but it is distinct from the rasterization step that OpenPisces used to perform and Marlin now does perform. Take a look at the [SW pipeline](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/prism/sw) classes, the [Java PiscesRendering](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/pisces) classes, and the [prism-sw](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/native-prism-sw) native code. ------------- PR: https://git.openjdk.java.net/jfx/pull/268 From usfirepilot123 at gmail.com Sun Jul 19 07:21:26 2020 From: usfirepilot123 at gmail.com (FireController#1847) Date: Sun, 19 Jul 2020 01:21:26 -0600 Subject: Hello! Message-ID: Hello, I have never used a mailing list before, and I have no clue how this works at all. I'm more of a Discord type of person, and am also very young haha. Would anyone be willing to give me a quick summary of what I can expect now that I'm subscribed to this, and how I can use it to help me implement a feature? Thanks, Fire From github.com+5607073+bourgesl at openjdk.java.net Sun Jul 19 09:33:45 2020 From: github.com+5607073+bourgesl at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 19 Jul 2020 09:33:45 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: Message-ID: <3QlULqD8tPOp3G0hHw7SZFZ9guctE5ltzu0P2cwLyiw=.08004601-4f0b-48e5-90a0-31a9ba559ef6@github.com> On Sat, 18 Jul 2020 16:11:38 GMT, Phil Race wrote: >> This removes the obsolete OpenPiscesRasterizer (Java-based) and NativePiscesRasterizer implementations. The Marlin >> rasterizer was added in FX 9 and was made the default in FX 10. Marlin both outperforms Pisces and is more robust. >> There is no reason to keep the Pisces rasterizer(s) any more. Note that the SW pipeline still has a Pisces-based >> renderer for the actual rendering of primitives. This is separate from the rasterizer and is not affected by this >> proposed fix. I have tested this on Mac, Windows, and Linux. > > Marked as reviewed by prr (Reviewer). That's the case, michael. In SWContext, the Marlin renderer is called to rasterize any shape. See https://github.com/openjdk/jfx/pull/268/files#diff-28f93b00dc9cba7197f0a6c2fef022ed ------------- PR: https://git.openjdk.java.net/jfx/pull/268 From github.com+5607073+bourgesl at openjdk.java.net Sun Jul 19 09:37:33 2020 From: github.com+5607073+bourgesl at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 19 Jul 2020 09:37:33 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: <86uysTW0QF8oStyO-RKixXqyca_HkneV2TC5nffHK0Y=.03950a76-b06c-45be-9b93-1583f305fce4@github.com> References: <86uysTW0QF8oStyO-RKixXqyca_HkneV2TC5nffHK0Y=.03950a76-b06c-45be-9b93-1583f305fce4@github.com> Message-ID: On Sat, 18 Jul 2020 22:07:59 GMT, Kevin Rushforth wrote: >> That's the case, michael. >> In SWContext, the Marlin renderer is called to rasterize any shape. >> >> See https://github.com/openjdk/jfx/pull/268/files#diff-28f93b00dc9cba7197f0a6c2fef022ed > > I think you are conflating the rasterization step with the rendering step. In Prism the rasterization mainly includes > clipping the shape and generating the mask data for the filled and/or stroked shape (the latter possibly being a wide > and/or dashed stroke). The rasterized shape is then sent to the Prism GraphicsPipeline for drawing into the render > target. This latter step is either done using shaders + D3D or OpenGL, or via the SW pipeline (or the J2D pipeline for > printing). In the case of the SW pipeline, the renderer is based on code that was originally derived from Pisces, but > it is distinct from the rasterization step that OpenPisces used to perform and Marlin now does perform. Take a look at > the [SW pipeline](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/prism/sw) > classes, the [Java > PiscesRendering](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/pisces) > classes, and the > [prism-sw](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/native-prism-sw) native code. @kevinrushforth I asked skara JBS to associate my github account with my openjdk role... I will approve your PR once I have proper credentials. Good job, 10k LOC removed. I wonder if I should also deprecate the Float-precision Marlin renderer to remove 10k lines too. The Double-precision Marlin renderer was enabled as the default renderer since JDK10, so it is doing the job properly, no reason to have 2 variants anymore and it will ease the maintenance. Laurent ------------- PR: https://git.openjdk.java.net/jfx/pull/268 From perini.davide at dpsoftware.org Sun Jul 19 21:31:13 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 19 Jul 2020 23:31:13 +0200 Subject: How to create a fat jar for my JavaFX program? Message-ID: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> Hi all, thanks for the great project, I love JavaFX. I always used the maven plugin to crete fat jars with all my deps. The resulting jar is an executable one and ready to use. This is my pom that create the fat jar. but when I try to exceute the jar I get this error: Error: JavaFX runtime components are missing, and are required to run this appli cation if I explode the fat jar I can see that there are the javafx class in it. what am I doing wrong? Thanks Davide org.openjfx javafx-maven-plugin ${javafx.maven.plugin.version} org.dpsoftware.FastScreenCapture org.apache.maven.plugins maven-assembly-plugin ${project.build.directory}/ JavaFastScreenCapture make-executable-jar-with-dependencies package single true org.dpsoftware.FastScreenCapture jar-with-dependencies From swpalmer at gmail.com Mon Jul 20 00:50:35 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 19 Jul 2020 20:50:35 -0400 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> Message-ID: <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> The JavaFX classes are there, but what about the native libraries? A fat jar isn?t a good way to distribute a Java application these days. Now you should probably be using jpackage and/or jlink to bundle your application classes with a runtime suitable for running the application. Scott > On Jul 19, 2020, at 5:32 PM, Davide Perini wrote: > > ?Hi all, > thanks for the great project, I love JavaFX. > > I always used the maven plugin to crete fat jars with all my deps. The resulting jar is an executable one and ready to use. > > This is my pom that create the fat jar. > > but when I try to exceute the jar I get this error: > > Error: JavaFX runtime components are missing, and are required to run this appli > cation > > > if I explode the fat jar I can see that there are the javafx class in it. what am I doing wrong? > > Thanks > Davide > > org.openjfx javafx-maven-plugin ${javafx.maven.plugin.version} org.dpsoftware.FastScreenCapture org.apache.maven.plugins maven-assembly-plugin ${project.build.directory}/ JavaFastScreenCapture make-executable-jar-with-dependencies package single true org.dpsoftware.FastScreenCapture jar-with-dependencies > From julianjupiter.io at gmail.com Mon Jul 20 04:52:44 2020 From: julianjupiter.io at gmail.com (Julian Jupiter) Date: Mon, 20 Jul 2020 12:52:44 +0800 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> Message-ID: I'm using maven-shade-plugin: org.apache.maven.plugins maven-shade-plugin 3.2.4 true *:* META-INF/*.SF META-INF/*.DSA META-INF/*.RSA package shade false package.to.Main On Mon, Jul 20, 2020, 5:32 AM Davide Perini, wrote: > Hi all, > thanks for the great project, I love JavaFX. > > I always used the maven plugin to crete fat jars with all my deps. The > resulting jar is an executable one and ready to use. > > This is my pom that create the fat jar. > > but when I try to exceute the jar I get this error: > > Error: JavaFX runtime components are missing, and are required to run > this appli > cation > > > if I explode the fat jar I can see that there are the javafx class in > it. what am I doing wrong? > > Thanks > Davide > > org.openjfx > javafx-maven-plugin > ${javafx.maven.plugin.version} > org.dpsoftware.FastScreenCapture > org.apache.maven.plugins > maven-assembly-plugin > ${project.build.directory}/ > JavaFastScreenCapture > make-executable-jar-with-dependencies > package single > true > org.dpsoftware.FastScreenCapture > > jar-with-dependencies > > > > From kcr at openjdk.java.net Mon Jul 20 13:14:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Jul 2020 13:14:58 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: <86uysTW0QF8oStyO-RKixXqyca_HkneV2TC5nffHK0Y=.03950a76-b06c-45be-9b93-1583f305fce4@github.com> Message-ID: On Sun, 19 Jul 2020 09:35:15 GMT, Laurent Bourg?s wrote: >> I think you are conflating the rasterization step with the rendering step. In Prism the rasterization mainly includes >> clipping the shape and generating the mask data for the filled and/or stroked shape (the latter possibly being a wide >> and/or dashed stroke). The rasterized shape is then sent to the Prism GraphicsPipeline for drawing into the render >> target. This latter step is either done using shaders + D3D or OpenGL, or via the SW pipeline (or the J2D pipeline for >> printing). In the case of the SW pipeline, the renderer is based on code that was originally derived from Pisces, but >> it is distinct from the rasterization step that OpenPisces used to perform and Marlin now does perform. Take a look at >> the [SW pipeline](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/prism/sw) >> classes, the [Java >> PiscesRendering](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/java/com/sun/pisces) >> classes, and the >> [prism-sw](https://github.com/openjdk/jfx/tree/master/modules/javafx.graphics/src/main/native-prism-sw) native code. > > @kevinrushforth I asked skara JBS to associate my github account with my openjdk role... > I will approve your PR once I have proper credentials. > > Good job, 10k LOC removed. > > I wonder if I should also deprecate the Float-precision Marlin renderer to remove 10k lines too. > The Double-precision Marlin renderer was enabled as the default renderer since JDK10, so it is doing the job properly, > no reason to have 2 variants anymore and it will ease the maintenance. > Laurent That's a good question about removing the single-precision float Marlin rasterizer. For desktop platforms, I see no reason to keep it. Perhaps Johan could weigh in as to whether their might be value in keeping it for some embedded platforms. ------------- PR: https://git.openjdk.java.net/jfx/pull/268 From jvos at openjdk.java.net Mon Jul 20 14:23:53 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 20 Jul 2020 14:23:53 GMT Subject: [jfx15] RFR: 8248381: Create a daemon thread for MonocleTimer [v2] In-Reply-To: References: Message-ID: On Sun, 28 Jun 2020 02:28:35 GMT, John Neffenger wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Remove POOL_SIZE constant I'm ok with this, as it fixes regression. A longer-term requirement could be the addition of platform-independent start/stop and pause/resume methods, similar to http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/4e1e2f56c7af (https://bugs.openjdk.java.net/browse/JDK-8189926) ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/256 From perini.davide at dpsoftware.org Mon Jul 20 17:25:13 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 20 Jul 2020 19:25:13 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> Message-ID: <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> Unfortunantly so few dependencies supports Java Modules this day, so fat JAR is the only way I can do it. Thanks Il 20/07/2020 02.50, Scott Palmer ha scritto: > The JavaFX classes are there, but what about the native libraries? > > A fat jar isn?t a good way to distribute a Java application these days. Now you should probably be using jpackage and/or jlink to bundle your application classes with a runtime suitable for running the application. > > Scott > >> On Jul 19, 2020, at 5:32 PM, Davide Perini wrote: >> >> ?Hi all, >> thanks for the great project, I love JavaFX. >> >> I always used the maven plugin to crete fat jars with all my deps. The resulting jar is an executable one and ready to use. >> >> This is my pom that create the fat jar. >> >> but when I try to exceute the jar I get this error: >> >> Error: JavaFX runtime components are missing, and are required to run this appli >> cation >> >> >> if I explode the fat jar I can see that there are the javafx class in it. what am I doing wrong? >> >> Thanks >> Davide >> >> org.openjfx javafx-maven-plugin ${javafx.maven.plugin.version} org.dpsoftware.FastScreenCapture org.apache.maven.plugins maven-assembly-plugin ${project.build.directory}/ JavaFastScreenCapture make-executable-jar-with-dependencies package single true org.dpsoftware.FastScreenCapture jar-with-dependencies >> From mblaesing at doppel-helix.eu Mon Jul 20 17:30:53 2020 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Mon, 20 Jul 2020 19:30:53 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> Message-ID: <0ed3b4c8bad4aacd6cffeae801c048b39bbda069.camel@doppel-helix.eu> Hi, Am Montag, den 20.07.2020, 19:25 +0200 schrieb Davide Perini: > Unfortunantly so few dependencies supports Java Modules this day, so > fat JAR is the only way I can do it. no it is not. There are seveal ways how to bundle native libraries. jpackage is one way, fat jars are another. And for fat jars of course you can extract native libraries at runtime (JNA does exactly that). What is difficult is the handling of native dependencies. If you know what you are doing you can manually load native libraries in the right order. The alternative is to distribute a ZIP file and setup the paths prior to loading libraries. Changing the java.library.path takes some reflection, but it is possible to do at runtime. The javafx jars from maven central hold the native libraries. Matthias From perini.davide at dpsoftware.org Mon Jul 20 17:37:18 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 20 Jul 2020 19:37:18 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <0ed3b4c8bad4aacd6cffeae801c048b39bbda069.camel@doppel-helix.eu> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> <0ed3b4c8bad4aacd6cffeae801c048b39bbda069.camel@doppel-helix.eu> Message-ID: <9963361e-cf61-c2eb-973c-3d3363dd5f22@dpsoftware.org> Hi, thanks for the answer, I appreciate it. I am trying with jpackage (that bundles my fat jar with some more dlls), but when I try to run my app I get this error: Error: JavaFX runtime components are missing, and are required to run this application Any idea? Thanks Il 20/07/2020 19.30, Matthias Bl?sing ha scritto: > Hi, > > Am Montag, den 20.07.2020, 19:25 +0200 schrieb Davide Perini: >> Unfortunantly so few dependencies supports Java Modules this day, so >> fat JAR is the only way I can do it. > no it is not. There are seveal ways how to bundle native libraries. > jpackage is one way, fat jars are another. And for fat jars of course > you can extract native libraries at runtime (JNA does exactly that). > What is difficult is the handling of native dependencies. If you know > what you are doing you can manually load native libraries in the right > order. > > The alternative is to distribute a ZIP file and setup the paths prior > to loading libraries. Changing the java.library.path takes some > reflection, but it is possible to do at runtime. > > The javafx jars from maven central hold the native libraries. > > Matthias > From mp at jugs.org Mon Jul 20 17:39:21 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Jul 2020 19:39:21 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> Message-ID: <74f95a27-de53-a791-76b1-426522141504@jugs.org> In order to create a real platform installer with jpackage and jlink/jdeps you don't have to use the java module system at all. Have a look at this tutorial which I co-autored together with Dirk Lemmermann: Michael Am 20.07.20 um 19:25 schrieb Davide Perini: > Unfortunantly so few dependencies supports Java Modules this day, so > fat JAR is the only way I can do it. > > Thanks > > Il 20/07/2020 02.50, Scott Palmer ha scritto: >> The JavaFX classes are there, but what about the native libraries? >> >> A fat jar isn?t a good way to distribute a Java application these >> days. Now you should probably be using jpackage and/or jlink to >> bundle your application classes with a runtime suitable for running >> the application. >> >> Scott >> >>> On Jul 19, 2020, at 5:32 PM, Davide Perini >>> wrote: >>> >>> ?Hi all, >>> thanks for the great project, I love JavaFX. >>> >>> I always used the maven plugin to crete fat jars with all my deps. >>> The resulting jar is an executable one and ready to use. >>> >>> This is my pom that create the fat jar. >>> >>> but when I try to exceute the jar I get this error: >>> >>> Error: JavaFX runtime components are missing, and are required to >>> run this appli >>> cation >>> >>> >>> if I explode the fat jar I can see that there are the javafx class >>> in it. what am I doing wrong? >>> >>> Thanks >>> Davide >>> >>> org.openjfx >>> javafx-maven-plugin >>> ${javafx.maven.plugin.version} >>> org.dpsoftware.FastScreenCapture >>> >>> org.apache.maven.plugins >>> maven-assembly-plugin >>> ${project.build.directory}/ >>> JavaFastScreenCapture >>> >>> make-executable-jar-with-dependencies >>> package single >>> >>> true >>> org.dpsoftware.FastScreenCapture >>> >>> jar-with-dependencies >>> >>> > From nlisker at gmail.com Mon Jul 20 17:40:34 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 20 Jul 2020 20:40:34 +0300 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> Message-ID: Hi, Unfortunantly so few dependencies supports Java Modules this day All the ones I know of do. Here's a list of modules on Maven Central: https://github.com/sormuras/modules so fat JAR is the only way I can do it. > In addition to the other answers, you can look into GraalVM's native image: https://www.graalvm.org/docs/reference-manual/native-image/ On Mon, Jul 20, 2020 at 8:25 PM Davide Perini wrote: > Unfortunantly so few dependencies supports Java Modules this day, so fat > JAR is the only way I can do it. > > Thanks > > Il 20/07/2020 02.50, Scott Palmer ha scritto: > > The JavaFX classes are there, but what about the native libraries? > > > > A fat jar isn?t a good way to distribute a Java application these days. > Now you should probably be using jpackage and/or jlink to bundle your > application classes with a runtime suitable for running the application. > > > > Scott > > > >> On Jul 19, 2020, at 5:32 PM, Davide Perini < > perini.davide at dpsoftware.org> wrote: > >> > >> ?Hi all, > >> thanks for the great project, I love JavaFX. > >> > >> I always used the maven plugin to crete fat jars with all my deps. The > resulting jar is an executable one and ready to use. > >> > >> This is my pom that create the fat jar. > >> > >> but when I try to exceute the jar I get this error: > >> > >> Error: JavaFX runtime components are missing, and are required to run > this appli > >> cation > >> > >> > >> if I explode the fat jar I can see that there are the javafx class in > it. what am I doing wrong? > >> > >> Thanks > >> Davide > >> > >> org.openjfx > javafx-maven-plugin > ${javafx.maven.plugin.version} > org.dpsoftware.FastScreenCapture > org.apache.maven.plugins > maven-assembly-plugin > ${project.build.directory}/ > JavaFastScreenCapture > make-executable-jar-with-dependencies > package single > true > org.dpsoftware.FastScreenCapture > > jar-with-dependencies > > >> > > From nlisker at gmail.com Mon Jul 20 17:46:43 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 20 Jul 2020 20:46:43 +0300 Subject: Hello! In-Reply-To: References: Message-ID: Hi, As the mailing list page [1] says, this list is for technical discussion related to the OpenJFX project. To implement a feature, see [2]. - Nir [1] https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev [2] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md On Sun, Jul 19, 2020 at 10:22 AM FireController#1847 < usfirepilot123 at gmail.com> wrote: > Hello, > > I have never used a mailing list before, and I have no clue how this works > at all. I'm more of a Discord type of person, and am also very young haha. > > Would anyone be willing to give me a quick summary of what I can expect now > that I'm subscribed to this, and how I can use it to help me implement a > feature? > > Thanks, > Fire > From mp at jugs.org Mon Jul 20 17:47:54 2020 From: mp at jugs.org (Michael Paus) Date: Mon, 20 Jul 2020 19:47:54 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> Message-ID: <8a9b84ec-8e9c-06ea-9138-dd8051d379c9@jugs.org> Am 20.07.20 um 19:40 schrieb Nir Lisker: > In addition to the other answers, you can look into GraalVM's native image: > https://www.graalvm.org/docs/reference-manual/native-image/ GraalVM native-image does not work directly with JavaFX. You would have to use the Gluon client-maven-plugin to get that going but I would not recommend that as a first try because it is just too difficult. You can try that step later. > > On Mon, Jul 20, 2020 at 8:25 PM Davide Perini > wrote: > >> Unfortunantly so few dependencies supports Java Modules this day, so fat >> JAR is the only way I can do it. >> >> Thanks >> >> Il 20/07/2020 02.50, Scott Palmer ha scritto: >>> The JavaFX classes are there, but what about the native libraries? >>> >>> A fat jar isn?t a good way to distribute a Java application these days. >> Now you should probably be using jpackage and/or jlink to bundle your >> application classes with a runtime suitable for running the application. >>> Scott >>> >>>> On Jul 19, 2020, at 5:32 PM, Davide Perini < >> perini.davide at dpsoftware.org> wrote: >>>> ?Hi all, >>>> thanks for the great project, I love JavaFX. >>>> >>>> I always used the maven plugin to crete fat jars with all my deps. The >> resulting jar is an executable one and ready to use. >>>> This is my pom that create the fat jar. >>>> >>>> but when I try to exceute the jar I get this error: >>>> >>>> Error: JavaFX runtime components are missing, and are required to run >> this appli >>>> cation >>>> >>>> >>>> if I explode the fat jar I can see that there are the javafx class in >> it. what am I doing wrong? >>>> Thanks >>>> Davide >>>> >>>> org.openjfx >> javafx-maven-plugin >> ${javafx.maven.plugin.version} >> org.dpsoftware.FastScreenCapture >> org.apache.maven.plugins >> maven-assembly-plugin >> ${project.build.directory}/ >> JavaFastScreenCapture >> make-executable-jar-with-dependencies >> package single >> true >> org.dpsoftware.FastScreenCapture >> >> jar-with-dependencies >> >> From github.com+10960818+Schmidor at openjdk.java.net Mon Jul 20 18:11:34 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Mon, 20 Jul 2020 18:11:34 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v6] In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: <1Ol0_qeX5QlgmxG8AgW0bIxrlqbZn6EXauyDODWaIvE=.9b198ee0-0896-4bf3-a8ec-9679eb685fbf@github.com> > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. Oliver Schmidtmer has updated the pull request incrementally with two additional commits since the last revision: - run test only on windows - Typo ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/246/files - new: https://git.openjdk.java.net/jfx/pull/246/files/6b0d58a0..ea1ff37d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/246/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/246/webrev.04-05 Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/246/head:pull/246 PR: https://git.openjdk.java.net/jfx/pull/246 From swpalmer at gmail.com Mon Jul 20 18:26:25 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 20 Jul 2020 14:26:25 -0400 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <74f95a27-de53-a791-76b1-426522141504@jugs.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> <74f95a27-de53-a791-76b1-426522141504@jugs.org> Message-ID: <334F0A64-1CDC-456D-8334-794BA84F7CD5@gmail.com> jlink and jdeps are module-based, so you do have to be careful. Neither will work properly when you try to run it against a non-modular project (found that out the hard way when Java 11 broke the world by removing the EE modules from Java SE and no modules were available to replace them), but you can use them to make a JRE image from a set of modules, such as those supplied by OpenJFX. I still think the .jmod files should be hosted by artifact repositories to make this work smoothly. Downloading an SDK, seems so old-school when we have good dependency-management tools. Once you have a JRE image that includes JavaFX, then your application Jar files (all of them, no need to make anything 'fat') can easily be bundled with that JRE using jpackage. I have done Gradle scripts to do all that and it wasn?t difficult. Scott > On Jul 20, 2020, at 1:39 PM, Michael Paus wrote: > > In order to create a real platform installer with jpackage and jlink/jdeps you don't have to use the java > module system at all. Have a look at this tutorial which I co-autored together with Dirk Lemmermann: > > Michael > > Am 20.07.20 um 19:25 schrieb Davide Perini: >> Unfortunantly so few dependencies supports Java Modules this day, so fat JAR is the only way I can do it. >> >> Thanks >> >> Il 20/07/2020 02.50, Scott Palmer ha scritto: >>> The JavaFX classes are there, but what about the native libraries? >>> >>> A fat jar isn?t a good way to distribute a Java application these days. Now you should probably be using jpackage and/or jlink to bundle your application classes with a runtime suitable for running the application. >>> >>> Scott >>> >>>> On Jul 19, 2020, at 5:32 PM, Davide Perini wrote: >>>> >>>> ?Hi all, >>>> thanks for the great project, I love JavaFX. >>>> >>>> I always used the maven plugin to crete fat jars with all my deps. The resulting jar is an executable one and ready to use. >>>> >>>> This is my pom that create the fat jar. >>>> >>>> but when I try to exceute the jar I get this error: >>>> >>>> Error: JavaFX runtime components are missing, and are required to run this appli >>>> cation >>>> >>>> >>>> if I explode the fat jar I can see that there are the javafx class in it. what am I doing wrong? >>>> >>>> Thanks >>>> Davide >>>> >>>> org.openjfx javafx-maven-plugin ${javafx.maven.plugin.version} org.dpsoftware.FastScreenCapture org.apache.maven.plugins maven-assembly-plugin ${project.build.directory}/ JavaFastScreenCapture make-executable-jar-with-dependencies package single true org.dpsoftware.FastScreenCapture jar-with-dependencies >>>> From perini.davide at dpsoftware.org Mon Jul 20 18:55:02 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 20 Jul 2020 20:55:02 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <334F0A64-1CDC-456D-8334-794BA84F7CD5@gmail.com> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> <74f95a27-de53-a791-76b1-426522141504@jugs.org> <334F0A64-1CDC-456D-8334-794BA84F7CD5@gmail.com> Message-ID: <983bad79-4e2b-5aae-7758-050cb00e70cc@dpsoftware.org> I agree, don't want to download a JDK. Is there a way to simply to it the old but good way using maven assembly plugin or shade plugin? I am following this guide here: https://openjfx.io/openjfx-docs/#modular I have done what they suggest in my pom file: org.openjfx javafx-controls ${javafx.version} org.openjfx javafx-fxml ${javafx.version} org.openjfx javafx-graphics 14 win org.openjfx javafx-maven-plugin ${javafx.maven.plugin.version} org.dpsoftware.FastScreenCapture org.apache.maven.plugins maven-assembly-plugin ${project.build.directory}/ JavaFastScreenCapture make-executable-jar-with-dependencies package single true org.dpsoftware.FastScreenCapture jar-with-dependencies jar with dependencies says Error: JavaFX runtime components are missing, and are required to run this application still don't understand how to do it the right way. I would like to do it with maven, is this possible? Thanks, Davide Il 20/07/2020 20.26, Scott Palmer ha scritto: > jlink and jdeps are module-based, so you do have to be careful. Neither will work properly when you try to run it against a non-modular project (found that out the hard way when Java 11 broke the world by removing the EE modules from Java SE and no modules were available to replace them), but you can use them to make a JRE image from a set of modules, such as those supplied by OpenJFX. > > I still think the .jmod files should be hosted by artifact repositories to make this work smoothly. Downloading an SDK, seems so old-school when we have good dependency-management tools. > > Once you have a JRE image that includes JavaFX, then your application Jar files (all of them, no need to make anything 'fat') can easily be bundled with that JRE using jpackage. > > I have done Gradle scripts to do all that and it wasn?t difficult. > > Scott > >> On Jul 20, 2020, at 1:39 PM, Michael Paus wrote: >> >> In order to create a real platform installer with jpackage and jlink/jdeps you don't have to use the java >> module system at all. Have a look at this tutorial which I co-autored together with Dirk Lemmermann: >> >> Michael >> >> Am 20.07.20 um 19:25 schrieb Davide Perini: >>> Unfortunantly so few dependencies supports Java Modules this day, so fat JAR is the only way I can do it. >>> >>> Thanks >>> >>> Il 20/07/2020 02.50, Scott Palmer ha scritto: >>>> The JavaFX classes are there, but what about the native libraries? >>>> >>>> A fat jar isn?t a good way to distribute a Java application these days. Now you should probably be using jpackage and/or jlink to bundle your application classes with a runtime suitable for running the application. >>>> >>>> Scott >>>> >>>>> On Jul 19, 2020, at 5:32 PM, Davide Perini wrote: >>>>> >>>>> ?Hi all, >>>>> thanks for the great project, I love JavaFX. >>>>> >>>>> I always used the maven plugin to crete fat jars with all my deps. The resulting jar is an executable one and ready to use. >>>>> >>>>> This is my pom that create the fat jar. >>>>> >>>>> but when I try to exceute the jar I get this error: >>>>> >>>>> Error: JavaFX runtime components are missing, and are required to run this appli >>>>> cation >>>>> >>>>> >>>>> if I explode the fat jar I can see that there are the javafx class in it. what am I doing wrong? >>>>> >>>>> Thanks >>>>> Davide >>>>> >>>>> org.openjfx javafx-maven-plugin ${javafx.maven.plugin.version} org.dpsoftware.FastScreenCapture org.apache.maven.plugins maven-assembly-plugin ${project.build.directory}/ JavaFastScreenCapture make-executable-jar-with-dependencies package single true org.dpsoftware.FastScreenCapture jar-with-dependencies >>>>> From perini.davide at dpsoftware.org Mon Jul 20 19:15:21 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 20 Jul 2020 21:15:21 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <983bad79-4e2b-5aae-7758-050cb00e70cc@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> <74f95a27-de53-a791-76b1-426522141504@jugs.org> <334F0A64-1CDC-456D-8334-794BA84F7CD5@gmail.com> <983bad79-4e2b-5aae-7758-050cb00e70cc@dpsoftware.org> Message-ID: Ok solved it reading this stackoverflow: https://stackoverflow.com/questions/52653836/maven-shade-javafx-runtime-components-are-missing thanks to all Il 20/07/2020 20.55, Davide Perini ha scritto: > I agree, don't want to download a JDK. > Is there a way to simply to it the old but good way using maven > assembly plugin or shade plugin? > > I am following this guide here: > https://openjfx.io/openjfx-docs/#modular > > I have done what they suggest in my pom file: > > org.openjfx > javafx-controls > ${javafx.version} > org.openjfx javafx-fxml > ${javafx.version} > org.openjfx > javafx-graphics 14 > win > > > org.openjfx > javafx-maven-plugin > ${javafx.maven.plugin.version} > org.dpsoftware.FastScreenCapture > > org.apache.maven.plugins > maven-assembly-plugin > ${project.build.directory}/ > JavaFastScreenCapture > > make-executable-jar-with-dependencies package > single > true > org.dpsoftware.FastScreenCapture > > jar-with-dependencies > > > > jar with dependencies says > > Error: JavaFX runtime components are missing, and are required to run > this application > > > still don't understand how to do it the right way. > I would like to do it with maven, is this possible? > > Thanks, > Davide > > Il 20/07/2020 20.26, Scott Palmer ha scritto: >> jlink and jdeps are module-based, so you do have to be careful.? >> Neither will work properly when you try to run it against a >> non-modular project (found that out the hard way when Java 11 broke >> the world by removing the EE modules from Java SE and no modules were >> available to replace them), but you can use them to make a JRE image >> from a set of modules, such as those supplied by OpenJFX. >> >> I still think the .jmod files should be hosted by artifact >> repositories to make this work smoothly.? Downloading an SDK, seems >> so old-school when we have good dependency-management tools. >> >> Once you have a JRE image that includes JavaFX, then your application >> Jar files (all of them, no need to make anything 'fat') can easily be >> bundled with that JRE using jpackage. >> >> I have done Gradle scripts to do all that and it wasn?t difficult. >> >> Scott >> >>> On Jul 20, 2020, at 1:39 PM, Michael Paus wrote: >>> >>> In order to create a real platform installer with jpackage and >>> jlink/jdeps you don't have to use the java >>> module system at all. Have a look at this tutorial which I >>> co-autored together with Dirk Lemmermann: >>> >>> Michael >>> >>> Am 20.07.20 um 19:25 schrieb Davide Perini: >>>> Unfortunantly so few dependencies supports Java Modules this day, >>>> so fat JAR is the only way I can do it. >>>> >>>> Thanks >>>> >>>> Il 20/07/2020 02.50, Scott Palmer ha scritto: >>>>> The JavaFX classes are there, but what about the native libraries? >>>>> >>>>> A fat jar isn?t a good way to distribute a Java application these >>>>> days. Now you should probably be using jpackage and/or jlink to >>>>> bundle your application classes with a runtime suitable for >>>>> running the application. >>>>> >>>>> Scott >>>>> >>>>>> On Jul 19, 2020, at 5:32 PM, Davide Perini >>>>>> wrote: >>>>>> >>>>>> ?Hi all, >>>>>> thanks for the great project, I love JavaFX. >>>>>> >>>>>> I always used the maven plugin to crete fat jars with all my >>>>>> deps. The resulting jar is an executable one and ready to use. >>>>>> >>>>>> This is my pom that create the fat jar. >>>>>> >>>>>> but when I try to exceute the jar I get this error: >>>>>> >>>>>> Error: JavaFX runtime components are missing, and are required to >>>>>> run this appli >>>>>> cation >>>>>> >>>>>> >>>>>> if I explode the fat jar I can see that there are the javafx >>>>>> class in it. what am I doing wrong? >>>>>> >>>>>> Thanks >>>>>> Davide >>>>>> >>>>>> org.openjfx >>>>>> javafx-maven-plugin >>>>>> ${javafx.maven.plugin.version} >>>>>> org.dpsoftware.FastScreenCapture >>>>>> >>>>>> org.apache.maven.plugins >>>>>> maven-assembly-plugin >>>>>> ${project.build.directory}/ >>>>>> JavaFastScreenCapture >>>>>> >>>>>> make-executable-jar-with-dependencies >>>>>> package single >>>>>> >>>>>> true >>>>>> org.dpsoftware.FastScreenCapture >>>>>> >>>>>> jar-with-dependencies >>>>>> >>>>>> >>>>>> > From youngty1997 at gmail.com Mon Jul 20 19:19:17 2020 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 20 Jul 2020 14:19:17 -0500 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> Message-ID: <9ff2ff9a-7748-5455-b98d-ad15963a458d@gmail.com> Don't know anything about fat jars, but you could try this jlink plugin: https://tentackle.org/static-content/sitedocs/tentackle/latest/tentackle-jlink-maven-plugin/jlink-mojo.html It works with non-modular projects as well - everything just gets dumped into a folder and put onto the module path. Just follow the standard Maven jlink guide: https://maven.apache.org/plugins/maven-jlink-plugin/usage.html but use the above plugin instead. I've been using it and it works great. Hope this helps. From laszlo.kishalmi at gmail.com Mon Jul 20 19:21:18 2020 From: laszlo.kishalmi at gmail.com (Laszlo Kishalmi) Date: Mon, 20 Jul 2020 12:21:18 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX Message-ID: <042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com> Dear OpenJFX devs, As a quick introduction, I'm the main developer behind the Gradle support in Apache NetBeans. Well, I must say they OpenJFX is using Gradle in a very original way. In order to make NetBeans to be able to be used for OpenJFX development, I need to understand some aspects on that build system you have. According to my inspections, NetBeans has struggle to discover the dependencies between the sub-projects in JavaFX. At first I see two reason for that: 1. For some reason version calculation is built in the script adding a second precision suffix to the output jar names. This breaks the dependency chain in NetBeans as it evaluates sub-projects individually (which could change somewhere down the road.). So expressing javafx:gracphics dependency would look like: javafx:graphics sources -> -/-> -> javafx:base sources That could be prevented by removing line 1547: project.version = MAVEN_VERSION from the build script. It is a recommendation to handle version as an external property to the standard build process and specify it with -Pversion= on release time only. 2. Unfortunately even removing the version out of the picture won't help as the generated classes of javafx:base goes into /build/classes/java/main/javafx.base/ instead of /build/classes/java/main/ So far I couldn't figure it out how that happens. I'm not really experienced in modular java builds, just tested a simple modular app with Gradle and it did not generate the classes under a folder /build/classes/java/main// just inside /build/classes/java/main/. So I might miss something here which could make NetBeans be aware of this situation and check. My theory is that these classes are somehow moved during the build, then the dependency is set externally by specifying --module-source-path in the compiler command line arguments. As of the later NetBeans is not aware of at the moment. So in order to understand the build more, my questions would be: 1. What is the reason behind generating the version during build time (with seconds precision)? 2. How the javafx base classes are ending up one folder down the path? 3. Is it the --module-source-path on the java compiler which actually keep the the dependencies together? Thank you, in advance! -- ? Laszlo Kishalmi From perini.davide at dpsoftware.org Mon Jul 20 19:06:57 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 20 Jul 2020 21:06:57 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: <983bad79-4e2b-5aae-7758-050cb00e70cc@dpsoftware.org> References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> <74f95a27-de53-a791-76b1-426522141504@jugs.org> <334F0A64-1CDC-456D-8334-794BA84F7CD5@gmail.com> <983bad79-4e2b-5aae-7758-050cb00e70cc@dpsoftware.org> Message-ID: PS: I add that I'm not new to maven, before java fx, I had a fat jar with gstreamer library, jna, and so on. the only problem I have is that it seems that I'm not able to bundle javafx with my fat jar. Il 20/07/2020 20.55, Davide Perini ha scritto: > I agree, don't want to download a JDK. > Is there a way to simply to it the old but good way using maven > assembly plugin or shade plugin? > > I am following this guide here: > https://openjfx.io/openjfx-docs/#modular > > I have done what they suggest in my pom file: > > org.openjfx > javafx-controls > ${javafx.version} > org.openjfx javafx-fxml > ${javafx.version} > org.openjfx > javafx-graphics 14 > win > > > org.openjfx > javafx-maven-plugin > ${javafx.maven.plugin.version} > org.dpsoftware.FastScreenCapture > > org.apache.maven.plugins > maven-assembly-plugin > ${project.build.directory}/ > JavaFastScreenCapture > > make-executable-jar-with-dependencies package > single > true > org.dpsoftware.FastScreenCapture > > jar-with-dependencies > > > > jar with dependencies says > > Error: JavaFX runtime components are missing, and are required to run > this application > > > still don't understand how to do it the right way. > I would like to do it with maven, is this possible? > > Thanks, > Davide > > Il 20/07/2020 20.26, Scott Palmer ha scritto: >> jlink and jdeps are module-based, so you do have to be careful.? >> Neither will work properly when you try to run it against a >> non-modular project (found that out the hard way when Java 11 broke >> the world by removing the EE modules from Java SE and no modules were >> available to replace them), but you can use them to make a JRE image >> from a set of modules, such as those supplied by OpenJFX. >> >> I still think the .jmod files should be hosted by artifact >> repositories to make this work smoothly.? Downloading an SDK, seems >> so old-school when we have good dependency-management tools. >> >> Once you have a JRE image that includes JavaFX, then your application >> Jar files (all of them, no need to make anything 'fat') can easily be >> bundled with that JRE using jpackage. >> >> I have done Gradle scripts to do all that and it wasn?t difficult. >> >> Scott >> >>> On Jul 20, 2020, at 1:39 PM, Michael Paus wrote: >>> >>> In order to create a real platform installer with jpackage and >>> jlink/jdeps you don't have to use the java >>> module system at all. Have a look at this tutorial which I >>> co-autored together with Dirk Lemmermann: >>> >>> Michael >>> >>> Am 20.07.20 um 19:25 schrieb Davide Perini: >>>> Unfortunantly so few dependencies supports Java Modules this day, >>>> so fat JAR is the only way I can do it. >>>> >>>> Thanks >>>> >>>> Il 20/07/2020 02.50, Scott Palmer ha scritto: >>>>> The JavaFX classes are there, but what about the native libraries? >>>>> >>>>> A fat jar isn?t a good way to distribute a Java application these >>>>> days. Now you should probably be using jpackage and/or jlink to >>>>> bundle your application classes with a runtime suitable for >>>>> running the application. >>>>> >>>>> Scott >>>>> >>>>>> On Jul 19, 2020, at 5:32 PM, Davide Perini >>>>>> wrote: >>>>>> >>>>>> ?Hi all, >>>>>> thanks for the great project, I love JavaFX. >>>>>> >>>>>> I always used the maven plugin to crete fat jars with all my >>>>>> deps. The resulting jar is an executable one and ready to use. >>>>>> >>>>>> This is my pom that create the fat jar. >>>>>> >>>>>> but when I try to exceute the jar I get this error: >>>>>> >>>>>> Error: JavaFX runtime components are missing, and are required to >>>>>> run this appli >>>>>> cation >>>>>> >>>>>> >>>>>> if I explode the fat jar I can see that there are the javafx >>>>>> class in it. what am I doing wrong? >>>>>> >>>>>> Thanks >>>>>> Davide >>>>>> >>>>>> org.openjfx >>>>>> javafx-maven-plugin >>>>>> ${javafx.maven.plugin.version} >>>>>> org.dpsoftware.FastScreenCapture >>>>>> >>>>>> org.apache.maven.plugins >>>>>> maven-assembly-plugin >>>>>> ${project.build.directory}/ >>>>>> JavaFastScreenCapture >>>>>> >>>>>> make-executable-jar-with-dependencies >>>>>> package single >>>>>> >>>>>> true >>>>>> org.dpsoftware.FastScreenCapture >>>>>> >>>>>> jar-with-dependencies >>>>>> >>>>>> >>>>>> > From usfirepilot123 at gmail.com Mon Jul 20 19:24:37 2020 From: usfirepilot123 at gmail.com (FireController#1847) Date: Mon, 20 Jul 2020 13:24:37 -0600 Subject: Hello! In-Reply-To: References: Message-ID: Hey, Thanks for the response. I've read all of the contributing data and signed the OCA (otherwise I wouldn't be here haha). I've already got a build of JavaFX up and running, but I am completely lost on where to get started. I'd like to work on implementing this feature: JDK-8238733 (sparked from JDK-8238729 ), but I'm not entirely sure of how complicated it could possibly be. I was looking into how insets work on borders, but it appears to be a vastly different system that is being used for effects. I also noticed that a lot of the border inset logic is on the "Region" class, whereas the effect logic is on the "Node" class. Similarly, I'm not entirely sure I understand this disconnect between "JavaFX's" code and "sun's" code? Is there a document explaining what this means and/or a document showing a summary of how the code is laid out? - Fire On Mon, Jul 20, 2020 at 11:47 AM Nir Lisker wrote: > Hi, > > As the mailing list page [1] says, this list is for technical discussion > related to the OpenJFX project. > > To implement a feature, see [2]. > > - Nir > > [1] https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > [2] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md > > On Sun, Jul 19, 2020 at 10:22 AM FireController#1847 < > usfirepilot123 at gmail.com> wrote: > >> Hello, >> >> I have never used a mailing list before, and I have no clue how this works >> at all. I'm more of a Discord type of person, and am also very young haha. >> >> Would anyone be willing to give me a quick summary of what I can expect >> now >> that I'm subscribed to this, and how I can use it to help me implement a >> feature? >> >> Thanks, >> Fire >> > From kevin.rushforth at oracle.com Mon Jul 20 20:15:20 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Jul 2020 13:15:20 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com> References: <042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com> Message-ID: <79a8eda0-4d9b-7d01-3c70-6497fa14541a@oracle.com> Hi Laszlo, Thanks for reaching out to us. Neil Smith suggested that I report this on netbeans-dev, which I haven't done yet, but can do today if you still need me to. To answer some of your specific questions: > 1. For some reason version calculation is built in the script adding a > ?? second precision suffix to the output jar names. This breaks the > ?? dependency chain in NetBeans as it evaluates sub-projects > ?? individually (which could change somewhere down the road.). So > ?? expressing javafx:gracphics dependency would look like: > ?? javafx:graphics sources -> > ?? -/-> -> javafx:base sources > > ?? That could be prevented by removing line 1547: project.version = > ?? MAVEN_VERSION from the build script. Interesting. That is only used for the maven "publishing" tasks, and shouldn't affect the main build artifacts. I don't see the generated version number showing up anywhere in the build output. It would be easy enough to suppress this for non-production builds, but I'd want to understand how it is causing problems. Does gradle (and thus the NetBeans gradle plugin), assign some semantic meaning to the project.version attribute? > 2. Unfortunately even removing the version out of the picture won't > ?? help as the generated classes of javafx:base goes into > ?? /build/classes/java/main/javafx.base/ instead of > ?? /build/classes/java/main/ > ?? So far I couldn't figure it out how that happens. Yes, that is expected for modules that are compiled as modules, by specifying "--module-source-path" to javac. > I'm not really > ?? experienced in modular java builds, just tested a simple modular app > ?? with Gradle and it did not generate the classes under a folder > ?? /build/classes/java/main// just inside > ?? /build/classes/java/main/. So I might miss something here which > ?? could make NetBeans be aware of this situation and check. When compiling using the --module-source-path option, all classes for a module are placed under / by javac. > ?? My theory is that these classes are somehow moved during the build, > ?? then the dependency is set externally by specifying > ?? --module-source-path in the compiler command line arguments. As of > ?? the later NetBeans is not aware of at the moment. No, we aren't moving them. > So in order to understand the build more, my questions would be: > > 1. What is the reason behind generating the version during build time > ?? (with seconds precision)? This seems unintentional, and in any case could be suppressed for non-release builds without too much trouble. > 2. How the javafx base classes are ending up one folder down the path? Because we are compiling with "--module-source-path". > 3. Is it the --module-source-path on the java compiler which actually > ?? keep the the dependencies together? If I understand what you are asking, then yes. -- Kevin On 7/20/2020 12:21 PM, Laszlo Kishalmi wrote: > Dear OpenJFX devs, > > As a quick introduction, I'm the main developer behind the Gradle > support in Apache NetBeans. > > Well, I must say they OpenJFX is using Gradle in a very original way. > In order to make NetBeans to be able to be used for OpenJFX > development, I need to understand some aspects on that build system > you have. > > According to my inspections, NetBeans has struggle to discover the > dependencies between the sub-projects in JavaFX. At first I see two > reason for that: > > 1. For some reason version calculation is built in the script adding a > ?? second precision suffix to the output jar names. This breaks the > ?? dependency chain in NetBeans as it evaluates sub-projects > ?? individually (which could change somewhere down the road.). So > ?? expressing javafx:gracphics dependency would look like: > ?? javafx:graphics sources -> > ?? -/-> -> javafx:base sources > > ?? That could be prevented by removing line 1547: project.version = > ?? MAVEN_VERSION from the build script. > > ?? It is a recommendation to handle version as an external property to > ?? the standard build process and specify it with -Pversion= ?? version> on release time only. > 2. Unfortunately even removing the version out of the picture won't > ?? help as the generated classes of javafx:base goes into > ?? /build/classes/java/main/javafx.base/ instead of > ?? /build/classes/java/main/ > ?? So far I couldn't figure it out how that happens. I'm not really > ?? experienced in modular java builds, just tested a simple modular app > ?? with Gradle and it did not generate the classes under a folder > ?? /build/classes/java/main// just inside > ?? /build/classes/java/main/. So I might miss something here which > ?? could make NetBeans be aware of this situation and check. > ?? My theory is that these classes are somehow moved during the build, > ?? then the dependency is set externally by specifying > ?? --module-source-path in the compiler command line arguments. As of > ?? the later NetBeans is not aware of at the moment. > > So in order to understand the build more, my questions would be: > > 1. What is the reason behind generating the version during build time > ?? (with seconds precision)? > 2. How the javafx base classes are ending up one folder down the path? > 3. Is it the --module-source-path on the java compiler which actually > ?? keep the the dependencies together? > > Thank you, in advance! > > -- > > ? Laszlo Kishalmi > > From laszlo.kishalmi at gmail.com Mon Jul 20 21:05:32 2020 From: laszlo.kishalmi at gmail.com (Laszlo Kishalmi) Date: Mon, 20 Jul 2020 14:05:32 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <79a8eda0-4d9b-7d01-3c70-6497fa14541a@oracle.com> References: <042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com> <79a8eda0-4d9b-7d01-3c70-6497fa14541a@oracle.com> Message-ID: <5aee1ec3-cd9f-ff45-a4fe-b9fe4cd2f97c@gmail.com> On 7/20/20 1:15 PM, Kevin Rushforth wrote: > Hi Laszlo, > > Thanks for reaching out to us. Neil Smith suggested that I report this > on netbeans-dev, which I haven't done yet, but can do today if you > still need me to. > > To answer some of your specific questions: > >> 1. For some reason version calculation is built in the script adding a >> ?? second precision suffix to the output jar names. This breaks the >> ?? dependency chain in NetBeans as it evaluates sub-projects >> ?? individually (which could change somewhere down the road.). So >> ?? expressing javafx:gracphics dependency would look like: >> ?? javafx:graphics sources -> >> ?? -/-> -> javafx:base sources >> >> ?? That could be prevented by removing line 1547: project.version = >> ?? MAVEN_VERSION from the build script. > > Interesting. That is only used for the maven "publishing" tasks, and > shouldn't affect the main build artifacts. I don't see the generated > version number showing up anywhere in the build output. It would be > easy enough to suppress this for non-production builds, but I'd want > to understand how it is causing problems. Does gradle (and thus the > NetBeans gradle plugin), assign some semantic meaning to the > project.version attribute? There is no semantic association. It is just the binding of the sub-projects together. Recent Gradle doesn't generate the jar files of the sub-projects if not asked for that specifically. Though if javafx:base project is asked of it's main output it would be a jar file with a second precision suffix in it's name. Also if you ask for the dependencies of javafx:graphics it will list a dependency on a javafx:base base jar with the second precision suffix in its name. The jar file does not have to be exist, NetBeans still would able to find out the dependency between the two sub-projects, but these jar names shall be the same. So if these two queries happen in different times the jar name would not match. > >> 2. Unfortunately even removing the version out of the picture won't >> ?? help as the generated classes of javafx:base goes into >> ?? /build/classes/java/main/javafx.base/ instead of >> ?? /build/classes/java/main/ >> ?? So far I couldn't figure it out how that happens. > > Yes, that is expected for modules that are compiled as modules, by > specifying "--module-source-path" to javac. > >> I'm not really >> ?? experienced in modular java builds, just tested a simple modular app >> ?? with Gradle and it did not generate the classes under a folder >> ?? /build/classes/java/main// just inside >> ?? /build/classes/java/main/. So I might miss something here which >> ?? could make NetBeans be aware of this situation and check. > > When compiling using the --module-source-path option, all classes for > a module are placed under / by javac. Thank you! I did not know that! That's something I can work on! > >> ?? My theory is that these classes are somehow moved during the build, >> ?? then the dependency is set externally by specifying >> ?? --module-source-path in the compiler command line arguments. As of >> ?? the later NetBeans is not aware of at the moment. > > No, we aren't moving them. > >> So in order to understand the build more, my questions would be: >> >> 1. What is the reason behind generating the version during build time >> ?? (with seconds precision)? > > This seems unintentional, and in any case could be suppressed for > non-release builds without too much trouble. > >> 2. How the javafx base classes are ending up one folder down the path? > > Because we are compiling with "--module-source-path". > >> 3. Is it the --module-source-path on the java compiler which actually >> ?? keep the the dependencies together? > > If I understand what you are asking, then yes. > > -- Kevin > > > On 7/20/2020 12:21 PM, Laszlo Kishalmi wrote: >> Dear OpenJFX devs, >> >> As a quick introduction, I'm the main developer behind the Gradle >> support in Apache NetBeans. >> >> Well, I must say they OpenJFX is using Gradle in a very original way. >> In order to make NetBeans to be able to be used for OpenJFX >> development, I need to understand some aspects on that build system >> you have. >> >> According to my inspections, NetBeans has struggle to discover the >> dependencies between the sub-projects in JavaFX. At first I see two >> reason for that: >> >> 1. For some reason version calculation is built in the script adding a >> ?? second precision suffix to the output jar names. This breaks the >> ?? dependency chain in NetBeans as it evaluates sub-projects >> ?? individually (which could change somewhere down the road.). So >> ?? expressing javafx:gracphics dependency would look like: >> ?? javafx:graphics sources -> >> ?? -/-> -> javafx:base sources >> >> ?? That could be prevented by removing line 1547: project.version = >> ?? MAVEN_VERSION from the build script. >> >> ?? It is a recommendation to handle version as an external property to >> ?? the standard build process and specify it with -Pversion=> ?? version> on release time only. >> 2. Unfortunately even removing the version out of the picture won't >> ?? help as the generated classes of javafx:base goes into >> ?? /build/classes/java/main/javafx.base/ instead of >> ?? /build/classes/java/main/ >> ?? So far I couldn't figure it out how that happens. I'm not really >> ?? experienced in modular java builds, just tested a simple modular app >> ?? with Gradle and it did not generate the classes under a folder >> ?? /build/classes/java/main// just inside >> ?? /build/classes/java/main/. So I might miss something here which >> ?? could make NetBeans be aware of this situation and check. >> ?? My theory is that these classes are somehow moved during the build, >> ?? then the dependency is set externally by specifying >> ?? --module-source-path in the compiler command line arguments. As of >> ?? the later NetBeans is not aware of at the moment. >> >> So in order to understand the build more, my questions would be: >> >> 1. What is the reason behind generating the version during build time >> ?? (with seconds precision)? >> 2. How the javafx base classes are ending up one folder down the path? >> 3. Is it the --module-source-path on the java compiler which actually >> ?? keep the the dependencies together? >> >> Thank you, in advance! >> >> -- >> >> ? Laszlo Kishalmi >> >> > From kevin.rushforth at oracle.com Mon Jul 20 22:16:43 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Jul 2020 15:16:43 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <5aee1ec3-cd9f-ff45-a4fe-b9fe4cd2f97c@gmail.com> References: <042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com> <79a8eda0-4d9b-7d01-3c70-6497fa14541a@oracle.com> <5aee1ec3-cd9f-ff45-a4fe-b9fe4cd2f97c@gmail.com> Message-ID: <5f672b71-77c8-4e83-e5fe-8de1bbb89315@oracle.com> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > On 7/20/20 1:15 PM, Kevin Rushforth wrote: >>> ?? That could be prevented by removing line 1547: project.version = >>> ?? MAVEN_VERSION from the build script. >> >> Interesting. That is only used for the maven "publishing" tasks, and >> shouldn't affect the main build artifacts. I don't see the generated >> version number showing up anywhere in the build output. It would be >> easy enough to suppress this for non-production builds, but I'd want >> to understand how it is causing problems. Does gradle (and thus the >> NetBeans gradle plugin), assign some semantic meaning to the >> project.version attribute? > There is no semantic association. It is just the binding of the > sub-projects together. Recent Gradle doesn't generate the jar files of > the sub-projects if not asked for that specifically. Though if > javafx:base project is asked of it's main output it would be a jar > file with a second precision suffix in it's name. Also if you ask for > the dependencies of javafx:graphics it will list a dependency on a > javafx:base base jar with the second precision suffix in its name. The > jar file does not have to be exist, NetBeans still would able to find > out the dependency between the two sub-projects, but these jar names > shall be the same. So if these two queries happen in different times > the jar name would not match. Got it. We explicitly disable the jar task for each modular project, since we don't need them, so we never would have noticed this. If I enable them, I can see the jar files with the full version number, including the date string. I'll file a bug to fix it. I'll need to do it in such a way that won't disrupt generating maven artifacts for testing (actual maven artifacts for uploading won't be affected anyway), but it should be easy to do. -- Kevin From kevin.rushforth at oracle.com Mon Jul 20 22:42:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 20 Jul 2020 15:42:30 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <5f672b71-77c8-4e83-e5fe-8de1bbb89315@oracle.com> References: <042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com> <79a8eda0-4d9b-7d01-3c70-6497fa14541a@oracle.com> <5aee1ec3-cd9f-ff45-a4fe-b9fe4cd2f97c@gmail.com> <5f672b71-77c8-4e83-e5fe-8de1bbb89315@oracle.com> Message-ID: I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing the build.gradle to not include the time stamp, at least by default. -- Kevin On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > > On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: >> On 7/20/20 1:15 PM, Kevin Rushforth wrote: >>>> ?? That could be prevented by removing line 1547: project.version = >>>> ?? MAVEN_VERSION from the build script. >>> >>> Interesting. That is only used for the maven "publishing" tasks, and >>> shouldn't affect the main build artifacts. I don't see the generated >>> version number showing up anywhere in the build output. It would be >>> easy enough to suppress this for non-production builds, but I'd want >>> to understand how it is causing problems. Does gradle (and thus the >>> NetBeans gradle plugin), assign some semantic meaning to the >>> project.version attribute? >> There is no semantic association. It is just the binding of the >> sub-projects together. Recent Gradle doesn't generate the jar files >> of the sub-projects if not asked for that specifically. Though if >> javafx:base project is asked of it's main output it would be a jar >> file with a second precision suffix in it's name. Also if you ask for >> the dependencies of javafx:graphics it will list a dependency on a >> javafx:base base jar with the second precision suffix in its name. >> The jar file does not have to be exist, NetBeans still would able to >> find out the dependency between the two sub-projects, but these jar >> names shall be the same. So if these two queries happen in different >> times the jar name would not match. > > Got it. We explicitly disable the jar task for each modular project, > since we don't need them, so we never would have noticed this. If I > enable them, I can see the jar files with the full version number, > including the date string. > > I'll file a bug to fix it. I'll need to do it in such a way that won't > disrupt generating maven artifacts for testing (actual maven artifacts > for uploading won't be affected anyway), but it should be easy to do. > > -- Kevin > From perini.davide at dpsoftware.org Mon Jul 20 22:56:09 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 21 Jul 2020 00:56:09 +0200 Subject: How to create a fat jar for my JavaFX program? In-Reply-To: References: <64fdf68e-3a33-ccae-322e-4dfc7afd3815@dpsoftware.org> <8C45B8EF-BE3D-4572-BBD3-EF784FCF16FC@gmail.com> <12777a09-daea-c848-08a7-41750be95af3@dpsoftware.org> <74f95a27-de53-a791-76b1-426522141504@jugs.org> <334F0A64-1CDC-456D-8334-794BA84F7CD5@gmail.com> <983bad79-4e2b-5aae-7758-050cb00e70cc@dpsoftware.org> Message-ID: <1736e710b28.2820.3c8a1e3a2388806d058c6e4a23c6ecab@dpsoftware.org> Done it here. https://github.com/sblantipodi/JavaFastScreenCapture/blob/JavaFXJavaModule/pom.xml If you read my sources there is how to configure the maven pom. You need then create a simple class with a main that doesn't extends application that simply call the main in the class that extends application. Hope it helped In data 20 luglio 2020 21:25:23 Davide Perini ha scritto: > PS: I add that I'm not new to maven, > before java fx, I had a fat jar with gstreamer library, jna, and so on. > > the only problem I have is that it seems that I'm not able to bundle > javafx with my fat jar. > > > > Il 20/07/2020 20.55, Davide Perini ha scritto: >> I agree, don't want to download a JDK. >> Is there a way to simply to it the old but good way using maven >> assembly plugin or shade plugin? >> >> I am following this guide here: >> https://openjfx.io/openjfx-docs/#modular >> >> I have done what they suggest in my pom file: >> >> org.openjfx >> javafx-controls >> ${javafx.version} >> org.openjfx javafx-fxml >> ${javafx.version} >> org.openjfx >> javafx-graphics 14 >> win >> >> >> org.openjfx >> javafx-maven-plugin >> ${javafx.maven.plugin.version} >> org.dpsoftware.FastScreenCapture >> >> org.apache.maven.plugins >> maven-assembly-plugin >> ${project.build.directory}/ >> JavaFastScreenCapture >> >> make-executable-jar-with-dependencies package >> single >> true >> org.dpsoftware.FastScreenCapture >> >> jar-with-dependencies >> >> >> >> jar with dependencies says >> >> Error: JavaFX runtime components are missing, and are required to run >> this application >> >> >> still don't understand how to do it the right way. >> I would like to do it with maven, is this possible? >> >> Thanks, >> Davide >> >> Il 20/07/2020 20.26, Scott Palmer ha scritto: >>> jlink and jdeps are module-based, so you do have to be careful. >>> Neither will work properly when you try to run it against a >>> non-modular project (found that out the hard way when Java 11 broke >>> the world by removing the EE modules from Java SE and no modules were >>> available to replace them), but you can use them to make a JRE image >>> from a set of modules, such as those supplied by OpenJFX. >>> >>> I still think the .jmod files should be hosted by artifact >>> repositories to make this work smoothly. Downloading an SDK, seems >>> so old-school when we have good dependency-management tools. >>> >>> Once you have a JRE image that includes JavaFX, then your application >>> Jar files (all of them, no need to make anything 'fat') can easily be >>> bundled with that JRE using jpackage. >>> >>> I have done Gradle scripts to do all that and it wasn?t difficult. >>> >>> Scott >>> >>>> On Jul 20, 2020, at 1:39 PM, Michael Paus wrote: >>>> >>>> In order to create a real platform installer with jpackage and >>>> jlink/jdeps you don't have to use the java >>>> module system at all. Have a look at this tutorial which I >>>> co-autored together with Dirk Lemmermann: >>>> >>>> Michael >>>> >>>> Am 20.07.20 um 19:25 schrieb Davide Perini: >>>>> Unfortunantly so few dependencies supports Java Modules this day, >>>>> so fat JAR is the only way I can do it. >>>>> >>>>> Thanks >>>>> >>>>> Il 20/07/2020 02.50, Scott Palmer ha scritto: >>>>>> The JavaFX classes are there, but what about the native libraries? >>>>>> >>>>>> A fat jar isn?t a good way to distribute a Java application these >>>>>> days. Now you should probably be using jpackage and/or jlink to >>>>>> bundle your application classes with a runtime suitable for >>>>>> running the application. >>>>>> >>>>>> Scott >>>>>> >>>>>>> On Jul 19, 2020, at 5:32 PM, Davide Perini >>>>>>> wrote: >>>>>>> >>>>>>> ?Hi all, >>>>>>> thanks for the great project, I love JavaFX. >>>>>>> >>>>>>> I always used the maven plugin to crete fat jars with all my >>>>>>> deps. The resulting jar is an executable one and ready to use. >>>>>>> >>>>>>> This is my pom that create the fat jar. >>>>>>> >>>>>>> but when I try to exceute the jar I get this error: >>>>>>> >>>>>>> Error: JavaFX runtime components are missing, and are required to >>>>>>> run this appli >>>>>>> cation >>>>>>> >>>>>>> >>>>>>> if I explode the fat jar I can see that there are the javafx >>>>>>> class in it. what am I doing wrong? >>>>>>> >>>>>>> Thanks >>>>>>> Davide >>>>>>> >>>>>>> org.openjfx >>>>>>> javafx-maven-plugin >>>>>>> ${javafx.maven.plugin.version} >>>>>>> org.dpsoftware.FastScreenCapture >>>>>>> >>>>>>> org.apache.maven.plugins >>>>>>> maven-assembly-plugin >>>>>>> ${project.build.directory}/ >>>>>>> JavaFastScreenCapture >>>>>>> >>>>>>> make-executable-jar-with-dependencies >>>>>>> package single >>>>>>> >>>>>>> true >>>>>>> org.dpsoftware.FastScreenCapture >>>>>>> >>>>>>> jar-with-dependencies >>>>>>> >>>>>>> >>>>>>> >> From kcr at openjdk.java.net Mon Jul 20 23:37:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Jul 2020 23:37:35 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v5] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Wed, 8 Jul 2020 22:18:39 GMT, Kevin Rushforth wrote: >> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: >> >> move swt test > > The test looks good with one minor typo in the constant field name (see below). I verified that it fails on Linux and > Mac (as I suspected), so you will need to limit the test to running on Windows. I think this is ready to target to `jfx15`, so go ahead and do that. I'll finish my review after that. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From ajoseph at openjdk.java.net Tue Jul 21 04:21:39 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 21 Jul 2020 04:21:39 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v3] In-Reply-To: References: Message-ID: <4NbvmYgJfY73K-aNBd3Lc3m2EcibT_ybMd-cbGO7U3k=.529cfcd5-b69a-4735-a5b4-64ded0edc1cc@github.com> > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Modify SW pipeline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/76e4745d..2e2b5cd1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.01-02 Stats: 91 lines in 3 files changed: 33 ins; 58 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From github.com+1413266+jgneff at openjdk.java.net Tue Jul 21 12:28:35 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 21 Jul 2020 12:28:35 GMT Subject: [jfx15] Integrated: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 03:50:02 GMT, John Neffenger wrote: > Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). This pull request has now been integrated. Changeset: 5f60ea5d Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5f60ea5d Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod 8248381: Create a daemon thread for MonocleTimer Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From fkirmaier at openjdk.java.net Tue Jul 21 12:29:29 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 21 Jul 2020 12:29:29 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v2] In-Reply-To: References: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> Message-ID: On Wed, 22 Apr 2020 12:00:03 GMT, Florian Kirmaier wrote: >> Changes requested by arapte (Reviewer). > > I don't think the class MeshManagerCacheLeakTest is a good base to write monocle + native tests. > It required input/output parsing which would be a bit too much. > > In my latest commit, I've added a simple solution to how the test can be reused. > On my side, both tests are always green, but I'm using a mac. > > > If one of the tests is unstable on windows, then it would be great if we could consider it as 2 bugs, so this PR can be > finished. > Afterwards it would be great if someone else could continue the windows-bug because I don't have a very productive > setup to work on it and I also don't really understand the native windows code. Any news about this PR? It's a bit annoying to explain everyone - who is checking for memory leaks - this bug. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Tue Jul 21 12:29:47 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 21 Jul 2020 12:29:47 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: References: Message-ID: <02hKtV2O8WDJUuXZZ-5dtlawHafSm91QcElR_PvuddQ=.a5528377-2c8e-41df-9873-b052e9b564b6@github.com> On Thu, 7 May 2020 18:16:22 GMT, Florian Kirmaier wrote: >> What I tried asking from my work account is: what is the purpose of createGarbage? > > The createGarbage method stimulates the GC. All unit tests are green without it, but according to my memory some tests > in an earlier version of this library were unstable without this. I can also change the configuration to create 0 > garbage. Any news about this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From fkirmaier at openjdk.java.net Tue Jul 21 12:37:53 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 21 Jul 2020 12:37:53 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v2] In-Reply-To: References: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> Message-ID: On Wed, 22 Apr 2020 12:00:03 GMT, Florian Kirmaier wrote: >> Changes requested by arapte (Reviewer). > > I don't think the class MeshManagerCacheLeakTest is a good base to write monocle + native tests. > It required input/output parsing which would be a bit too much. > > In my latest commit, I've added a simple solution to how the test can be reused. > On my side, both tests are always green, but I'm using a mac. > > > If one of the tests is unstable on windows, then it would be great if we could consider it as 2 bugs, so this PR can be > finished. > Afterwards it would be great if someone else could continue the windows-bug because I don't have a very productive > setup to work on it and I also don't really understand the native windows code. Any updates about this PR? I run into this bug basically every time I check something for a memory leak, which is quite annoying. Edit: The rerequest review button seems to be not working ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Tue Jul 21 12:37:53 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 21 Jul 2020 12:37:53 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Fri, 17 Apr 2020 12:57:28 GMT, Ambarish Rapte wrote: >> The previous version of test failed on my Windows 10 machine with below exception, but the updated version does not >> fail, >> test.javafx.stage.FocusedWindowTest > testLeak FAILED >> junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 5fe60662 >> at junit.framework.Assert.fail(Assert.java:47) >> at junit.framework.Assert.assertTrue(Assert.java:20) >> at junit.framework.Assert.assertNull(Assert.java:233) >> at junit.framework.Assert.assertNull(Assert.java:226) >> at test.javafx.stage.FocusedWindowTest.assertCollectable(FocusedWindowTest.java:133) >> at test.javafx.stage.FocusedWindowTest.testLeakOnce(FocusedWindowTest.java:116) >> at test.javafx.stage.FocusedWindowTest.testLeak(FocusedWindowTest.java:84) > >> Do you have a good recommendation on how to add it? > > May be a test like `MeshManagerCacheLeakTest` should be able to solve the problem. I have not tried it myself, please > check if it can help here. See below command ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Tue Jul 21 17:59:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Jul 2020 17:59:02 GMT Subject: [jfx15] RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v6] In-Reply-To: <1Ol0_qeX5QlgmxG8AgW0bIxrlqbZn6EXauyDODWaIvE=.9b198ee0-0896-4bf3-a8ec-9679eb685fbf@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <1Ol0_qeX5QlgmxG8AgW0bIxrlqbZn6EXauyDODWaIvE=.9b198ee0-0896-4bf3-a8ec-9679eb685fbf@github.com> Message-ID: On Mon, 20 Jul 2020 18:11:34 GMT, Oliver Schmidtmer wrote: >> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and >> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared >> rendering. The changes were already proposed by the submitter in JBS-8220484. >> >> OCA is signed and send. > > Oliver Schmidtmer has updated the pull request incrementally with two additional commits since the last revision: > > - run test only on windows > - Typo Looks good. @prsadhuk can you also review this? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Tue Jul 21 20:24:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Jul 2020 20:24:09 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v2] In-Reply-To: References: <0Z3vMAZZibSDTmmAp4OY2Vg0spa8YE-7kdWuXrAFqvk=.ec7a4bdf-3b97-4a9c-802b-d221f9782784@github.com> Message-ID: On Tue, 21 Jul 2020 12:33:28 GMT, Florian Kirmaier wrote: >> I don't think the class MeshManagerCacheLeakTest is a good base to write monocle + native tests. >> It required input/output parsing which would be a bit too much. >> >> In my latest commit, I've added a simple solution to how the test can be reused. >> On my side, both tests are always green, but I'm using a mac. >> >> >> If one of the tests is unstable on windows, then it would be great if we could consider it as 2 bugs, so this PR can be >> finished. >> Afterwards it would be great if someone else could continue the windows-bug because I don't have a very productive >> setup to work on it and I also don't really understand the native windows code. > > Any updates about this PR? > I run into this bug basically every time I check something for a memory leak, which is quite annoying. > Edit: The rerequest review button seems to be not working Once the last of the `jfx15` reviews and other critical reviews are out of the way, we'll get back to this for JavaFX 16. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From bchoudhary at openjdk.java.net Tue Jul 21 21:50:39 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 21 Jul 2020 21:50:39 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v6] In-Reply-To: References: Message-ID: <5ZvCdQhLSzUf-gpbfBj3Cx5ZtJgVZ3xqaL-mgkwnV9k=.ecb8559f-611b-4238-ac0b-f8c42dcb746e@github.com> > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: HiDPI printing and Rendering fix ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/f0c217ec..312d068a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/213/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.04-05 Stats: 34 lines in 2 files changed: 5 ins; 9 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Tue Jul 21 22:05:36 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 21 Jul 2020 22:05:36 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v5] In-Reply-To: References: Message-ID: <7R7bW7JKwPd1cRCZwjmKgE4yGC7JSJosZGqftMrWT_E=.e5480c6d-2ce1-4322-8ef0-a4b419d96e52@github.com> On Fri, 12 Jun 2020 22:01:47 GMT, Kevin Rushforth wrote: >> The code looks good (with a couple minor formatting issues). >> >> All of the onscreen testing I did looks good on Windows. I'd like to test it on Mac as well. >> >> There is an issue with printing in the case of Hi-DPI scaling, which is what I run by default on Windows. The gradient >> texture appears to be scaled incorrectly (as if the scale was applied more than once). If I force scaling to 1 with >> `-Dglass.win.uiScale=1` then it prints correctly. > > It behaves the same on Mac with a Retina display as it does on Windows with Hi-DPI scaling. The gradient doesn't appear > to be scaled correctly when printing. It's fine with on-screen rendering (with both HW and SW pipeline). Issue related to hidpi rendering was caused due to correct pixel scale factor not being set to the context in which mask texture was getting rendered. setting correct device scale factor in `RenderSVGResourceMasker.cpp` fixed the issue. Below images shows the rendered mask texture in both case (HiDpi and Normal respectively) ![HiDpi_Mask_1](https://user-images.githubusercontent.com/4208131/88110579-125ae300-cbca-11ea-9c02-ceec2ccdf7d1.png) ![Normal_Mask_1](https://user-images.githubusercontent.com/4208131/88110582-138c1000-cbca-11ea-88ce-5e15ccccd124.png) Another issue was in Hi DPI printing. PrintGraphics draws with different resolution than the mask texture. Before the fix mask was not drawn correctly to RTTexture, due to which only top left portion which comes inside current draw bounds was taken to draw the whole image. After fix, entire mask texture is always considered while doing final drawing. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From jvos at openjdk.java.net Wed Jul 22 12:49:34 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Jul 2020 12:49:34 GMT Subject: [jfx14] RFR: 8249799: Create release notes for JavaFX 14.0.2.1 Message-ID: Add release notes for 14.0.2.1 Fix for JDK-8249799 ------------- Commit messages: - Add release notes for 14.0.2.1 Changes: https://git.openjdk.java.net/jfx/pull/269/files Webrev: https://webrevs.openjdk.java.net/jfx/269/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249799 Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/269/head:pull/269 PR: https://git.openjdk.java.net/jfx/pull/269 From psadhukhan at openjdk.java.net Wed Jul 22 12:59:48 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 22 Jul 2020 12:59:48 GMT Subject: [jfx15] RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v6] In-Reply-To: <1Ol0_qeX5QlgmxG8AgW0bIxrlqbZn6EXauyDODWaIvE=.9b198ee0-0896-4bf3-a8ec-9679eb685fbf@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <1Ol0_qeX5QlgmxG8AgW0bIxrlqbZn6EXauyDODWaIvE=.9b198ee0-0896-4bf3-a8ec-9679eb685fbf@github.com> Message-ID: On Mon, 20 Jul 2020 18:11:34 GMT, Oliver Schmidtmer wrote: >> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and >> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared >> rendering. The changes were already proposed by the submitter in JBS-8220484. >> >> OCA is signed and send. > > Oliver Schmidtmer has updated the pull request incrementally with two additional commits since the last revision: > > - run test only on windows > - Typo Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Wed Jul 22 13:05:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Jul 2020 13:05:21 GMT Subject: [jfx14] RFR: 8249799: Create release notes for JavaFX 14.0.2.1 In-Reply-To: References: Message-ID: On Wed, 22 Jul 2020 12:07:06 GMT, Johan Vos wrote: > Add release notes for 14.0.2.1 > Fix for JDK-8249799 It looks like you used the JBS bug IDs of the backport records rather than the main bug. The rest looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/269 From github.com+10960818+Schmidor at openjdk.java.net Wed Jul 22 14:40:38 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Wed, 22 Jul 2020 14:40:38 GMT Subject: [jfx15] Integrated: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Wed, 3 Jun 2020 15:46:36 GMT, Oliver Schmidtmer wrote: > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. This pull request has now been integrated. Changeset: 3cc29e38 Author: Oliver Schmidtmer Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3cc29e38 Stats: 351 lines in 7 files changed: 0 ins; 341 del; 10 mod 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% Reviewed-by: kcr, psadhukhan ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From perini.davide at dpsoftware.org Wed Jul 22 12:29:30 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 22 Jul 2020 14:29:30 +0200 Subject: Is scene builder abandoned? And what about JavaFX? Message-ID: <8a05269b5edff5f7be14dc859d834eab@dpsoftware.org> Hi all, love JavaFX and I think that it is very productive, super awesome. It is pretty sad that scene builder seems so old and unsupported, scene builder still not support spinner and many "newer" elements. Why? Is JavaFX dead or is still active? Since Oracle "abandon" I see no documentation of the new features implemented. Is there an official documentation for JavaFX now? Thanks Davide From kevin.rushforth at oracle.com Wed Jul 22 15:09:34 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 Jul 2020 08:09:34 -0700 Subject: Is scene builder abandoned? And what about JavaFX? In-Reply-To: <8a05269b5edff5f7be14dc859d834eab@dpsoftware.org> References: <8a05269b5edff5f7be14dc859d834eab@dpsoftware.org> Message-ID: <0134c200-8e8c-57d5-56c7-755553e3309d@oracle.com> JavaFX is quite active, and has not been abandoned. You can find the documentation and download the latest releases at openjfx.io [1]. The source repository for JavaFX is on GitHub [2]. SceneBuilder is maintained by Gluon. Releases are available for download at [3]. The source repository is on GitHub [4]. -- Kevin [1] https://openjfx.io/ [2] https://github.com/openjdk/jfx [3] https://gluonhq.com/products/scene-builder/ [4] https://github.com/gluonhq/scenebuilder On 7/22/2020 5:29 AM, Davide Perini wrote: > Hi all, > love JavaFX and I think that it is very productive, super awesome. > It is pretty sad that scene builder seems so old and unsupported, scene > builder still not support spinner and many "newer" elements. Why? > > Is JavaFX dead or is still active? > Since Oracle "abandon" I see no documentation of the new features > implemented. > Is there an official documentation for JavaFX now? > Thanks > Davide From jvos at openjdk.java.net Wed Jul 22 17:21:59 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Jul 2020 17:21:59 GMT Subject: [jfx14] RFR: 8249799: Create release notes for JavaFX 14.0.2.1 [v2] In-Reply-To: References: Message-ID: > Add release notes for 14.0.2.1 > Fix for JDK-8249799 Johan Vos has updated the pull request incrementally with two additional commits since the last revision: - and also change the links, pointing to the original bug - Use the bug id of the original issue instead of the backport issue ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/269/files - new: https://git.openjdk.java.net/jfx/pull/269/files/f0adf179..fe873a8d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/269/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/269/webrev.00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/269/head:pull/269 PR: https://git.openjdk.java.net/jfx/pull/269 From kcr at openjdk.java.net Wed Jul 22 17:21:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Jul 2020 17:21:59 GMT Subject: [jfx14] RFR: 8249799: Create release notes for JavaFX 14.0.2.1 [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jul 2020 14:54:38 GMT, Johan Vos wrote: >> Add release notes for 14.0.2.1 >> Fix for JDK-8249799 > > Johan Vos has updated the pull request incrementally with two additional commits since the last revision: > > - and also change the links, pointing to the original bug > - Use the bug id of the original issue instead of the backport issue Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/269 From jvos at openjdk.java.net Wed Jul 22 17:22:00 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Jul 2020 17:22:00 GMT Subject: [jfx14] Integrated: 8249799: Create release notes for JavaFX 14.0.2.1 In-Reply-To: References: Message-ID: On Wed, 22 Jul 2020 12:07:06 GMT, Johan Vos wrote: > Add release notes for 14.0.2.1 > Fix for JDK-8249799 This pull request has now been integrated. Changeset: c8ee1b7f Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/c8ee1b7f Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod 8249799: Create release notes for JavaFX 14.0.2.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/269 From kcr at openjdk.java.net Wed Jul 22 17:34:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Jul 2020 17:34:53 GMT Subject: RFR: 8249777: build.gradle: project.version should not contain time stamps Message-ID: The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we were creating them, we would have the problem that each time we ran gradle, it would generate a new `project-$version.jar` file with a different time stamp each time the build was run. The setting of `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the maven publishing tasks. ------------- Commit messages: - 8249777: build.gradle: project.version should not contain time stamps Changes: https://git.openjdk.java.net/jfx/pull/270/files Webrev: https://webrevs.openjdk.java.net/jfx/270/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249777 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/270.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/270/head:pull/270 PR: https://git.openjdk.java.net/jfx/pull/270 From kcr at openjdk.java.net Wed Jul 22 17:34:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Jul 2020 17:34:53 GMT Subject: RFR: 8249777: build.gradle: project.version should not contain time stamps In-Reply-To: References: Message-ID: On Wed, 22 Jul 2020 17:22:25 GMT, Kevin Rushforth wrote: > The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, > controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing > problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). > We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we > were creating them, we would have the problem that each time we ran gradle, it would generate a new > `project-$version.jar` file with a different time stamp each time the build was run. The setting of > `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor > for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to > `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven > publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the > maven publishing tasks. @tiainen can you also review this? build.gradle line 2063: > 2062: project.ext.moduleName = "javafx.graphics" > 2063: project.ext.mavenPublish = IS_MAVEN_PUBLISH > 2064: Is this property needed? None of the other projects define it, and I don't see any usage of it. ------------- PR: https://git.openjdk.java.net/jfx/pull/270 From nlisker at gmail.com Thu Jul 23 01:59:26 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 23 Jul 2020 04:59:26 +0300 Subject: Hello! In-Reply-To: References: Message-ID: > > I'd like to work on implementing this feature: JDK-8238733 > I suggest you sent a new email specifically discussing this issue then. You will need approval from Kevin of Johan to implement it anyway. Someone might be able to help you technically, but in general you would need to learn the code yourself. Similarly, I'm not entirely sure I understand this disconnect between > "JavaFX's" code and "sun's" code? Generally, code inside com.sun packages is internal; code inside javafx packages is for the public API. On Mon, Jul 20, 2020 at 10:25 PM FireController#1847 < usfirepilot123 at gmail.com> wrote: > Hey, > > Thanks for the response. I've read all of the contributing data and signed > the OCA (otherwise I wouldn't be here haha). > > I've already got a build of JavaFX up and running, but I am completely > lost on where to get started. I'd like to work on implementing this > feature: JDK-8238733 (sparked > from JDK-8238729 ), but > I'm not entirely sure of how complicated it could possibly be. I was > looking into how insets work on borders, but it appears to be a vastly > different system that is being used for effects. I also noticed that a lot > of the border inset logic is on the "Region" class, whereas the effect > logic is on the "Node" class. > > Similarly, I'm not entirely sure I understand this disconnect between > "JavaFX's" code and "sun's" code? Is there a document explaining what this > means and/or a document showing a summary of how the code is laid out? > > - Fire > > On Mon, Jul 20, 2020 at 11:47 AM Nir Lisker wrote: > >> Hi, >> >> As the mailing list page [1] says, this list is for technical discussion >> related to the OpenJFX project. >> >> To implement a feature, see [2]. >> >> - Nir >> >> [1] https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev >> [2] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md >> >> On Sun, Jul 19, 2020 at 10:22 AM FireController#1847 < >> usfirepilot123 at gmail.com> wrote: >> >>> Hello, >>> >>> I have never used a mailing list before, and I have no clue how this >>> works >>> at all. I'm more of a Discord type of person, and am also very young >>> haha. >>> >>> Would anyone be willing to give me a quick summary of what I can expect >>> now >>> that I'm subscribed to this, and how I can use it to help me implement a >>> feature? >>> >>> Thanks, >>> Fire >>> >> From bchoudhary at openjdk.java.net Thu Jul 23 04:43:56 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Thu, 23 Jul 2020 04:43:56 GMT Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v3] In-Reply-To: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> Message-ID: > root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four > corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while > rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it > otherwise construct a path from given rounded rect and draw it. Bhawesh Choudhary has updated the pull request incrementally with 54 additional commits since the last revision: - 8181775: JavaFX WebView does not calculate border-radius properly - 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% Reviewed-by: kcr, psadhukhan - 8248381: Create a daemon thread for MonocleTimer Reviewed-by: kcr, jvos - 8248490: [macOS] Undecorated stage does not minimize Reviewed-by: arapte, aghaisas - 8248908: Printer.createPageLayout() returns 0.75" margins instead of hardware margins Reviewed-by: kcr - 8245284: Update to 610.1 version of WebKit Co-authored-by: Guru Hb Co-authored-by: Bhawesh Choudhary Reviewed-by: kcr, bchoudhary, sykora - 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Reviewed-by: aghaisas, kcr - 8245422: Better Pisces rasterizing Reviewed-by: prr, rhalade, arapte, mschoene - 8241108: Glib improvements Reviewed-by: kcr, ahgross, rhalade - 8248365: Debug build crashes on Windows when playing media file Reviewed-by: kcr - ... and 44 more: https://git.openjdk.java.net/jfx/compare/e7cb98fe...586af326 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/218/files - new: https://git.openjdk.java.net/jfx/pull/218/files/e7cb98fe..586af326 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/218/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/218/webrev.01-02 Stats: 393560 lines in 5665 files changed: 200813 ins; 130033 del; 62714 mod Patch: https://git.openjdk.java.net/jfx/pull/218.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/218/head:pull/218 PR: https://git.openjdk.java.net/jfx/pull/218 From ajoseph at openjdk.java.net Thu Jul 23 05:48:25 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 23 Jul 2020 05:48:25 GMT Subject: RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes Message-ID: Update to GTK WebKit 2.28.3 https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html ------------- Commit messages: - Cherry pick GTK WebKit 2.28.3 changes Changes: https://git.openjdk.java.net/jfx/pull/271/files Webrev: https://webrevs.openjdk.java.net/jfx/271/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249839 Stats: 533 lines in 36 files changed: 381 ins; 66 del; 86 mod Patch: https://git.openjdk.java.net/jfx/pull/271.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/271/head:pull/271 PR: https://git.openjdk.java.net/jfx/pull/271 From bchoudhary at openjdk.java.net Thu Jul 23 09:43:36 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Thu, 23 Jul 2020 09:43:36 GMT Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4] In-Reply-To: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> Message-ID: > root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four > corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while > rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it > otherwise construct a path from given rounded rect and draw it. Bhawesh Choudhary has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into 8181775 - Removed wildcard import statement - Formatting (File Mode Attribute change) - 8181775: JavaFX WebView does not calculate border-radius properly ------------- Changes: https://git.openjdk.java.net/jfx/pull/218/files Webrev: https://webrevs.openjdk.java.net/jfx/218/webrev.03 Stats: 104 lines in 2 files changed: 95 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/218.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/218/head:pull/218 PR: https://git.openjdk.java.net/jfx/pull/218 From kcr at openjdk.java.net Thu Jul 23 12:03:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 12:03:47 GMT Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4] In-Reply-To: References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> Message-ID: <9rGsXcTYcPajPMgFz9tyfTRtJrh86bVijc55ND-wkT0=.3610307b-7def-4a22-b11a-8b32ea713179@github.com> On Fri, 15 May 2020 17:33:10 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains four commits: >> - Merge branch 'master' into 8181775 >> - Removed wildcard import statement >> - Formatting (File Mode Attribute change) >> - 8181775: JavaFX WebView does not calculate border-radius properly > > The fix looks correct, but I want to test it. I left one minor comment on the test. In general, we recommend not to rebase your branch once you have opened the PR. Occasionally there might be a need, but the usual way to do it is to merge in the latest upstream `master` branch without rebasing. ------------- PR: https://git.openjdk.java.net/jfx/pull/218 From github.com+370894+ebresie at openjdk.java.net Thu Jul 23 12:37:04 2020 From: github.com+370894+ebresie at openjdk.java.net (Eric Bresie) Date: Thu, 23 Jul 2020 12:37:04 GMT Subject: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jul 2020 05:20:03 GMT, Ambarish Rapte wrote: >> John Neffenger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove assert statements > > Marked as reviewed by arapte (Reviewer). Just curious and this may be OBE by now but... I see the check thread but when accessing the buffer itself, should it have some sort of synchronization of some type to make it more thread safe? ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Thu Jul 23 13:04:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 13:04:25 GMT Subject: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: <2GB6Z-u7PRK40K2zDFYbyLxuBjHBUuzMt8Hl_l1oaGo=.c1b5d4c7-9b6e-402b-aaf9-af339c8877aa@github.com> On Thu, 23 Jul 2020 12:34:43 GMT, Eric Bresie wrote: >> Marked as reviewed by arapte (Reviewer). > > Just curious and this may be OBE by now but... I see the check thread but when accessing the buffer itself, should it > have some sort of synchronization of some type to make it more thread safe? There is no need to synchronize the `getBuffer` method, since all it does is return the immutable buffer field. In any case, this PR has been integrated, so if an additional issue is discovered, a new bug would need to be filed. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From sykora at openjdk.java.net Thu Jul 23 13:05:20 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Thu, 23 Jul 2020 13:05:20 GMT Subject: RFR: 8249777: build.gradle: project.version should not contain time stamps In-Reply-To: References: Message-ID: <7jxJLIO4b2LsMT-WCoiGDGV7KxDq-UpnyfqbqjC3dSY=.f1c06f5b-31a4-4fa4-a9d7-ba080f68a9d3@github.com> On Wed, 22 Jul 2020 17:24:24 GMT, Kevin Rushforth wrote: >> The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, >> controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing >> problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). >> We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we >> were creating them, we would have the problem that each time we ran gradle, it would generate a new >> `project-$version.jar` file with a different time stamp each time the build was run. The setting of >> `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor >> for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to >> `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven >> publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the >> maven publishing tasks. > > build.gradle line 2063: > >> 2062: project.ext.moduleName = "javafx.graphics" >> 2063: project.ext.mavenPublish = IS_MAVEN_PUBLISH >> 2064: > > Is this property needed? None of the other projects define it, and I don't see any usage of it. No, it indeed doesn't seem to be used anywhere. I would remove it. ------------- PR: https://git.openjdk.java.net/jfx/pull/270 From ebresie at gmail.com Thu Jul 23 12:55:32 2020 From: ebresie at gmail.com (Eric Bresie) Date: Thu, 23 Jul 2020 07:55:32 -0500 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: bde4aa58-3e39-43b6-1e03-3f1eee3a280f@oracle.com References: 042e06b9-be71-2608-e0e2-0a6b546c0ec5@gmail.com 79a8eda0-4d9b-7d01-3c70-6497fa14541a@oracle.com 5aee1ec3-cd9f-ff45-a4fe-b9fe4cd2f97c@gmail.com 5f672b71-77c8-4e83-e5fe-8de1bbb89315@oracle.com 5f672b71-77c8-4e83-e5fe-8de1bbb89315@oracle.com Message-ID: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> Is there a need for some further cleanup dependency between builds maybe to remove duplicate jars / modules with different time stamps? Rather than time stamp in these cases should it just use a SNAPSHOT designation instead? Eric Bresie Ebresie at gmail.com > On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth wrote: > I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing > the build.gradle to not include the time stamp, at least by default. > > -- Kevin > > > On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > > > > On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > > > On 7/20/20 1:15 PM, Kevin Rushforth wrote: > > > > > That could be prevented by removing line 1547: project.version = > > > > > MAVEN_VERSION from the build script. > > > > > > > > Interesting. That is only used for the maven "publishing" tasks, and > > > > shouldn't affect the main build artifacts. I don't see the generated > > > > version number showing up anywhere in the build output. It would be > > > > easy enough to suppress this for non-production builds, but I'd want > > > > to understand how it is causing problems. Does gradle (and thus the > > > > NetBeans gradle plugin), assign some semantic meaning to the > > > > project.version attribute? > > > There is no semantic association. It is just the binding of the > > > sub-projects together. Recent Gradle doesn't generate the jar files > > > of the sub-projects if not asked for that specifically. Though if > > > javafx:base project is asked of it's main output it would be a jar > > > file with a second precision suffix in it's name. Also if you ask for > > > the dependencies of javafx:graphics it will list a dependency on a > > > javafx:base base jar with the second precision suffix in its name. > > > The jar file does not have to be exist, NetBeans still would able to > > > find out the dependency between the two sub-projects, but these jar > > > names shall be the same. So if these two queries happen in different > > > times the jar name would not match. > > > > Got it. We explicitly disable the jar task for each modular project, > > since we don't need them, so we never would have noticed this. If I > > enable them, I can see the jar files with the full version number, > > including the date string. > > > > I'll file a bug to fix it. I'll need to do it in such a way that won't > > disrupt generating maven artifacts for testing (actual maven artifacts > > for uploading won't be affected anyway), but it should be easy to do. > > > > -- Kevin > > > From kcr at openjdk.java.net Thu Jul 23 13:45:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 13:45:33 GMT Subject: RFR: 8249777: build.gradle: project.version should not contain time stamps [v2] In-Reply-To: References: Message-ID: <9RmAkJXr0lOHwc6IwZIlEXpEnyGonm34_lyUmhsPLH0=.12f1660f-eac7-4475-ab9a-873a7bc137a9@github.com> > The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, > controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing > problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). > We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we > were creating them, we would have the problem that each time we ran gradle, it would generate a new > `project-$version.jar` file with a different time stamp each time the build was run. The setting of > `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor > for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to > `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven > publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the > maven publishing tasks. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Remove unised mavenPublish property from graphics project ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/270/files - new: https://git.openjdk.java.net/jfx/pull/270/files/592ad650..1c077ec5 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/270/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/270/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/270.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/270/head:pull/270 PR: https://git.openjdk.java.net/jfx/pull/270 From perini.davide at dpsoftware.org Thu Jul 23 14:42:09 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Thu, 23 Jul 2020 16:42:09 +0200 Subject: Fullscreen canvas Message-ID: Hi all, is it possible to create a fullscreen canvas? I don't find a good doc for JavaFX and canvas. Thanks Davide From kcr at openjdk.java.net Thu Jul 23 16:38:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 16:38:18 GMT Subject: RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 05:34:50 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.3 > https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/271 From kevin.rushforth at oracle.com Thu Jul 23 16:39:15 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Jul 2020 09:39:15 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> References: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> Message-ID: <12316cfd-1509-a355-9efa-c128ec6e5ffd@oracle.com> The proposed fix will be to disable the maven publishing tasks by default, and to not set the project.version at all. So this will decouple the maven publishing tasks, and they won't interfere with normal developer or production builds. Joeri or Johan can confirm, but if they ever do upload a bundle for testing, I'm pretty sure they would use a SNAPSHOT designation (set manually). -- Kevin On 7/23/2020 5:55 AM, Eric Bresie wrote: > Is there a need for some further cleanup dependency between builds maybe to remove duplicate jars / modules with different time stamps? > > Rather than time stamp in these cases should it just use a SNAPSHOT designation instead? > > Eric Bresie > Ebresie at gmail.com >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth wrote: >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing >> the build.gradle to not include the time stamp, at least by default. >> >> -- Kevin >> >> >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: >>>>>> That could be prevented by removing line 1547: project.version = >>>>>> MAVEN_VERSION from the build script. >>>>> Interesting. That is only used for the maven "publishing" tasks, and >>>>> shouldn't affect the main build artifacts. I don't see the generated >>>>> version number showing up anywhere in the build output. It would be >>>>> easy enough to suppress this for non-production builds, but I'd want >>>>> to understand how it is causing problems. Does gradle (and thus the >>>>> NetBeans gradle plugin), assign some semantic meaning to the >>>>> project.version attribute? >>>> There is no semantic association. It is just the binding of the >>>> sub-projects together. Recent Gradle doesn't generate the jar files >>>> of the sub-projects if not asked for that specifically. Though if >>>> javafx:base project is asked of it's main output it would be a jar >>>> file with a second precision suffix in it's name. Also if you ask for >>>> the dependencies of javafx:graphics it will list a dependency on a >>>> javafx:base base jar with the second precision suffix in its name. >>>> The jar file does not have to be exist, NetBeans still would able to >>>> find out the dependency between the two sub-projects, but these jar >>>> names shall be the same. So if these two queries happen in different >>>> times the jar name would not match. >>> Got it. We explicitly disable the jar task for each modular project, >>> since we don't need them, so we never would have noticed this. If I >>> enable them, I can see the jar files with the full version number, >>> including the date string. >>> >>> I'll file a bug to fix it. I'll need to do it in such a way that won't >>> disrupt generating maven artifacts for testing (actual maven artifacts >>> for uploading won't be affected anyway), but it should be easy to do. >>> >>> -- Kevin >>> From sykora at openjdk.java.net Thu Jul 23 17:18:41 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Thu, 23 Jul 2020 17:18:41 GMT Subject: RFR: 8249777: build.gradle: project.version should not contain time stamps [v2] In-Reply-To: <9RmAkJXr0lOHwc6IwZIlEXpEnyGonm34_lyUmhsPLH0=.12f1660f-eac7-4475-ab9a-873a7bc137a9@github.com> References: <9RmAkJXr0lOHwc6IwZIlEXpEnyGonm34_lyUmhsPLH0=.12f1660f-eac7-4475-ab9a-873a7bc137a9@github.com> Message-ID: On Thu, 23 Jul 2020 13:45:33 GMT, Kevin Rushforth wrote: >> The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, >> controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing >> problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). >> We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we >> were creating them, we would have the problem that each time we ran gradle, it would generate a new >> `project-$version.jar` file with a different time stamp each time the build was run. The setting of >> `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor >> for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to >> `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven >> publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the >> maven publishing tasks. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unised mavenPublish property from graphics project Marked as reviewed by sykora (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/270 From joeri at lodgon.com Thu Jul 23 17:26:49 2020 From: joeri at lodgon.com (Joeri Sykora) Date: Thu, 23 Jul 2020 19:26:49 +0200 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <12316cfd-1509-a355-9efa-c128ec6e5ffd@oracle.com> References: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> <12316cfd-1509-a355-9efa-c128ec6e5ffd@oracle.com> Message-ID: We have never had the need to publish snapshot versions. We do however publish early access builds quite regularly (e.g. 15-ea+6) for the versions that are in development. Op do 23 jul. 2020 18:44 schreef Kevin Rushforth : > The proposed fix will be to disable the maven publishing tasks by > default, and to not set the project.version at all. So this will > decouple the maven publishing tasks, and they won't interfere with > normal developer or production builds. > > Joeri or Johan can confirm, but if they ever do upload a bundle for > testing, I'm pretty sure they would use a SNAPSHOT designation (set > manually). > > -- Kevin > > > On 7/23/2020 5:55 AM, Eric Bresie wrote: > > Is there a need for some further cleanup dependency between builds maybe > to remove duplicate jars / modules with different time stamps? > > > > Rather than time stamp in these cases should it just use a SNAPSHOT > designation instead? > > > > Eric Bresie > > Ebresie at gmail.com > >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track > fixing > >> the build.gradle to not include the time stamp, at least by default. > >> > >> -- Kevin > >> > >> > >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: > >>>>>> That could be prevented by removing line 1547: project.version = > >>>>>> MAVEN_VERSION from the build script. > >>>>> Interesting. That is only used for the maven "publishing" tasks, and > >>>>> shouldn't affect the main build artifacts. I don't see the generated > >>>>> version number showing up anywhere in the build output. It would be > >>>>> easy enough to suppress this for non-production builds, but I'd want > >>>>> to understand how it is causing problems. Does gradle (and thus the > >>>>> NetBeans gradle plugin), assign some semantic meaning to the > >>>>> project.version attribute? > >>>> There is no semantic association. It is just the binding of the > >>>> sub-projects together. Recent Gradle doesn't generate the jar files > >>>> of the sub-projects if not asked for that specifically. Though if > >>>> javafx:base project is asked of it's main output it would be a jar > >>>> file with a second precision suffix in it's name. Also if you ask for > >>>> the dependencies of javafx:graphics it will list a dependency on a > >>>> javafx:base base jar with the second precision suffix in its name. > >>>> The jar file does not have to be exist, NetBeans still would able to > >>>> find out the dependency between the two sub-projects, but these jar > >>>> names shall be the same. So if these two queries happen in different > >>>> times the jar name would not match. > >>> Got it. We explicitly disable the jar task for each modular project, > >>> since we don't need them, so we never would have noticed this. If I > >>> enable them, I can see the jar files with the full version number, > >>> including the date string. > >>> > >>> I'll file a bug to fix it. I'll need to do it in such a way that won't > >>> disrupt generating maven artifacts for testing (actual maven artifacts > >>> for uploading won't be affected anyway), but it should be easy to do. > >>> > >>> -- Kevin > >>> > > From kevin.rushforth at oracle.com Thu Jul 23 17:36:59 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 23 Jul 2020 10:36:59 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: References: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> <12316cfd-1509-a355-9efa-c128ec6e5ffd@oracle.com> Message-ID: <50fade05-a5bd-3739-045e-c4fb9aefdcea@oracle.com> In that case, we can probably remove the time stamp from MAVEN_VERSION altogether in a follow-up fix, since it is never used for any released version, including early access builds. Not a high priority though once the entire publishing task is qualified by a property. -- Kevin On 7/23/2020 10:26 AM, Joeri Sykora wrote: > We have never had the need to publish snapshot versions. We do however > publish early access builds quite regularly (e.g. 15-ea+6) for the > versions that are in development. > > Op do 23 jul. 2020 18:44 schreef Kevin Rushforth > >: > > The proposed fix will be to disable the maven publishing tasks by > default, and to not set the project.version at all. So this will > decouple the maven publishing tasks, and they won't interfere with > normal developer or production builds. > > Joeri or Johan can confirm, but if they ever do upload a bundle for > testing, I'm pretty sure they would use a SNAPSHOT designation (set > manually). > > -- Kevin > > > On 7/23/2020 5:55 AM, Eric Bresie wrote: > > Is there a need for some further cleanup dependency between > builds maybe to remove duplicate jars / modules with different > time stamps? > > > > Rather than time stamp in these cases should it just use a > SNAPSHOT designation instead? > > > > Eric Bresie > > Ebresie at gmail.com > >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth > > > wrote: > >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to > track fixing > >> the build.gradle to not include the time stamp, at least by > default. > >> > >> -- Kevin > >> > >> > >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: > >>>>>> That could be prevented by removing line 1547: > project.version = > >>>>>> MAVEN_VERSION from the build script. > >>>>> Interesting. That is only used for the maven "publishing" > tasks, and > >>>>> shouldn't affect the main build artifacts. I don't see the > generated > >>>>> version number showing up anywhere in the build output. It > would be > >>>>> easy enough to suppress this for non-production builds, but > I'd want > >>>>> to understand how it is causing problems. Does gradle (and > thus the > >>>>> NetBeans gradle plugin), assign some semantic meaning to the > >>>>> project.version attribute? > >>>> There is no semantic association. It is just the binding of the > >>>> sub-projects together. Recent Gradle doesn't generate the jar > files > >>>> of the sub-projects if not asked for that specifically. Though if > >>>> javafx:base project is asked of it's main output it would be > a jar > >>>> file with a second precision suffix in it's name. Also if you > ask for > >>>> the dependencies of javafx:graphics it will list a dependency > on a > >>>> javafx:base base jar with the second precision suffix in its > name. > >>>> The jar file does not have to be exist, NetBeans still would > able to > >>>> find out the dependency between the two sub-projects, but > these jar > >>>> names shall be the same. So if these two queries happen in > different > >>>> times the jar name would not match. > >>> Got it. We explicitly disable the jar task for each modular > project, > >>> since we don't need them, so we never would have noticed this. > If I > >>> enable them, I can see the jar files with the full version number, > >>> including the date string. > >>> > >>> I'll file a bug to fix it. I'll need to do it in such a way > that won't > >>> disrupt generating maven artifacts for testing (actual maven > artifacts > >>> for uploading won't be affected anyway), but it should be easy > to do. > >>> > >>> -- Kevin > >>> > From kcr at openjdk.java.net Thu Jul 23 17:45:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 17:45:10 GMT Subject: RFR: 8169501: GIF animation is too fast In-Reply-To: References: Message-ID: On Fri, 15 May 2020 07:42:40 GMT, Bhawesh Choudhary wrote: > issue is caused by the threshold value for frame duration used by javaFx before it gets normalized. JavaFx is using > threshold value 10 while other browser (Safari, Firefox) is using 50 due to which, value between 10 and 50 don't get > normalized and animation runs at faster speed. To fix the issue change frame duration normalization value to <= 50. > Safari : https://bugs.webkit.org/show_bug.cgi?id=14413 Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=386269 This is pending response to comments above. ------------- PR: https://git.openjdk.java.net/jfx/pull/221 From kcr at openjdk.java.net Thu Jul 23 17:46:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 17:46:25 GMT Subject: RFR: 8244297: memory leak test utility [v4] In-Reply-To: <02hKtV2O8WDJUuXZZ-5dtlawHafSm91QcElR_PvuddQ=.a5528377-2c8e-41df-9873-b052e9b564b6@github.com> References: <02hKtV2O8WDJUuXZZ-5dtlawHafSm91QcElR_PvuddQ=.a5528377-2c8e-41df-9873-b052e9b564b6@github.com> Message-ID: On Tue, 21 Jul 2020 12:27:05 GMT, Florian Kirmaier wrote: >> The createGarbage method stimulates the GC. All unit tests are green without it, but according to my memory some tests >> in an earlier version of this library were unstable without this. I can also change the configuration to create 0 >> garbage. > > Any news about this PR? Now that `jfx15` is pretty much done, we'll put this back on the queue to review. ------------- PR: https://git.openjdk.java.net/jfx/pull/204 From kcr at openjdk.java.net Thu Jul 23 17:55:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 17:55:35 GMT Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren logs an exception In-Reply-To: References: Message-ID: On Tue, 19 May 2020 10:29:12 GMT, Ajit Ghaisas wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8245181 >> >> Root cause : The exception just gets logged and does not result in test failure. >> >> Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this >> mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I >> have removed System.out.printlns that were causing log pollution. > > I completed the work with an incorrect branch name. I will continue using this branch only for this fix. @aghaisas Is this PR still relevant? If not, then go ahead and close it. ------------- PR: https://git.openjdk.java.net/jfx/pull/224 From kcr at openjdk.java.net Thu Jul 23 17:59:48 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 17:59:48 GMT Subject: RFR: [WIP]8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Sat, 11 Apr 2020 09:53:46 GMT, Ambarish Rapte wrote: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Once the merge conflicts and review comments are addressed, I'll put this back on my review queue. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From kcr at openjdk.java.net Thu Jul 23 22:01:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 22:01:18 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central Message-ID: When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). ------------- Commit messages: - 8250238: Media fails to load libav 58 library when using modules from maven central Changes: https://git.openjdk.java.net/jfx/pull/272/files Webrev: https://webrevs.openjdk.java.net/jfx/272/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250238 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/272.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/272/head:pull/272 PR: https://git.openjdk.java.net/jfx/pull/272 From kcr at openjdk.java.net Thu Jul 23 22:01:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 22:01:18 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: References: Message-ID: <6xRRBtNJT0eMq1SYKWxGBxnpc4ukXc4QllGEEvbVUSs=.7bf2beba-a708-4690-b555-bc526133176d@github.com> On Thu, 23 Jul 2020 21:40:05 GMT, Kevin Rushforth wrote: > When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the > jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry > for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in > [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). NOTE: This is targeted to `jfx15`. As such I would like a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/272 From kcr at openjdk.java.net Thu Jul 23 22:01:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Jul 2020 22:01:36 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: <6xRRBtNJT0eMq1SYKWxGBxnpc4ukXc4QllGEEvbVUSs=.7bf2beba-a708-4690-b555-bc526133176d@github.com> References: <6xRRBtNJT0eMq1SYKWxGBxnpc4ukXc4QllGEEvbVUSs=.7bf2beba-a708-4690-b555-bc526133176d@github.com> Message-ID: On Thu, 23 Jul 2020 21:40:52 GMT, Kevin Rushforth wrote: >> When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the >> jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry >> for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in >> [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). > > NOTE: This is targeted to `jfx15`. As such I would like a second reviewer. @sashamatveev can you review? @tiainen or @johanvos can one of you review as well? ------------- PR: https://git.openjdk.java.net/jfx/pull/272 From almatvee at openjdk.java.net Thu Jul 23 22:35:17 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 23 Jul 2020 22:35:17 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 21:40:05 GMT, Kevin Rushforth wrote: > When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the > jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry > for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in > [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/272 From almatvee at openjdk.java.net Thu Jul 23 22:35:17 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 23 Jul 2020 22:35:17 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: References: <6xRRBtNJT0eMq1SYKWxGBxnpc4ukXc4QllGEEvbVUSs=.7bf2beba-a708-4690-b555-bc526133176d@github.com> Message-ID: <3TTjQ_dahGPW689tfea3nkMznuVCAY9B7jkWLbIH1Tc=.26bc7bac-e40d-4472-9520-77f05889b9f4@github.com> On Thu, 23 Jul 2020 21:44:22 GMT, Kevin Rushforth wrote: >> NOTE: This is targeted to `jfx15`. As such I would like a second reviewer. > > @sashamatveev can you review? > > @tiainen or @johanvos can one of you review as well? Looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/272 From aghaisas at openjdk.java.net Fri Jul 24 06:34:26 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 24 Jul 2020 06:34:26 GMT Subject: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren logs an exception In-Reply-To: References: Message-ID: <-nz4RNGicgJCSJOWKdX1VnPhkSiu2qiNUQBWLm_sRzQ=.32174bf8-7103-4510-8540-168d95f9ac80@github.com> On Thu, 23 Jul 2020 17:53:24 GMT, Kevin Rushforth wrote: >> I completed the work with an incorrect branch name. I will continue using this branch only for this fix. > > @aghaisas Is this PR still relevant? If not, then go ahead and close it. This test does not throw exception anymore after JDK-8193800 is fixed. I am closing this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/224 From aghaisas at openjdk.java.net Fri Jul 24 06:34:27 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 24 Jul 2020 06:34:27 GMT Subject: Withdrawn: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren logs an exception In-Reply-To: References: Message-ID: On Tue, 19 May 2020 10:25:24 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8245181 > > Root cause : The exception just gets logged and does not result in test failure. > > Fix : Added the mechanism to catch and handle UncaughtException. Test test_rt35039_resetRootChildren fails with this > mechanism. Fixed the test failure by adding the check in TreeTableView class. In addition, unrelated to above fix, I > have removed System.out.printlns that were causing log pollution. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/224 From sykora at openjdk.java.net Fri Jul 24 08:20:30 2020 From: sykora at openjdk.java.net (Joeri Sykora) Date: Fri, 24 Jul 2020 08:20:30 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 21:40:05 GMT, Kevin Rushforth wrote: > When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the > jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry > for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in > [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). I've tested on Ubuntu 20.04 and playing media files works again with this fix. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/272 From jvos at openjdk.java.net Fri Jul 24 07:49:02 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 24 Jul 2020 07:49:02 GMT Subject: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 22:33:04 GMT, Alexander Matveev wrote: >> When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the >> jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry >> for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in >> [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). > > Marked as reviewed by almatvee (Reviewer). This should indeed go into 15. ------------- PR: https://git.openjdk.java.net/jfx/pull/272 From arapte at openjdk.java.net Fri Jul 24 10:08:21 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 24 Jul 2020 10:08:21 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 8 May 2020 12:36:41 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 11 commits: > - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight > - Attenuation and range changed internally to floats from doubles > - Fixed shader compilation errors for 2 and 3 lights in es2 > - Addressing review comments > - Fixed whitespaces > - Correction for indexes > - Docs and year update > - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into > 8217472_Add_attenuation_for_PointLight > - GL pipeline > - Separate range from attenuation > - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed Added some minor comments. The changes suggested in the shader cause no difference in FPS, but only reduces number of instructions in compiled fragment shader. I verified it in the compiled D3D shader, that the change reduces one multiplication instruction. The glCompileShader() API performs some optimizations on the shader. But the optimizations would be implementation specific. The difference of fps in different machines may be caused by difference of glCompileShader() implementation. On the shader side there are few ways of doing [glsl optimizations](https://www.khronos.org/opengl/wiki/GLSL_Optimizations). This may be worth for a quick try now or later as follow on. modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 174: > 173: > 174: private static final double DEFAULT_LINEAR_CONSTANT = NGPointLight.getDefaultLa(); > 175: Small correction needed, `DEFAULT_LINEAR_CONSTANT` -> `DEFAULT_LINEAR_ATTENUATION` similarly, `DEFAULT_QUADRATIC_CONSTANT` -> `DEFAULT_QUADRATIC_ATTENUATION` modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main3Lights.frag line 92: > 91: d += clamp(dot(n,l), 0.0, 1.0) * (lights[0].color).rgb * att; > 92: s += pow(clamp(dot(-refl, l), 0.0, 1.0), power) * lights[0].color.rgb * att; > 93: } These three lines can be changed as: float attenuatedColor = (lights[0].color).rgb / (lights[0].attn.x + lights[0].attn.y * dist + lights[0].attn.z * dist * dist); d += clamp(dot(n,l), 0.0, 1.0) * attenuatedColor; s += pow(clamp(dot(-refl, l), 0.0, 1.0), power) * attenuatedColor; Similar change in the 1 light and 2 lights shader. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h line 76: > 75: d += saturate(dot(n, l)) * gLightColor[i].xyz * attn; > 76: s += pow(saturate(dot(-refl, l)), power) * gLightColor[i].xyz * attn; > 77: } The temporary variables ca, la, qa will be removed by shader compiler optmization, so has no extra cost involved here. But we can reduce one multiplication instruction by changing the rest of the code as, float attenuatedColor = gLightColor[i].xyz / (ca + la * dist + qa * dist * dist); float3 l = normalize(L[i].xyz); d += saturate(dot(n, l)) * attenuatedColor; s += pow(saturate(dot(-refl, l)), power) * attenuatedColor; ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/43 From bchoudhary at openjdk.java.net Fri Jul 24 11:27:06 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 24 Jul 2020 11:27:06 GMT Subject: RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 16:36:01 GMT, Kevin Rushforth wrote: >> Update to GTK WebKit 2.28.3 >> https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html > > Marked as reviewed by kcr (Lead). Tested on all three platform. Looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/271 From bchoudhary at openjdk.java.net Fri Jul 24 11:27:06 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 24 Jul 2020 11:27:06 GMT Subject: RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes In-Reply-To: References: Message-ID: <0ibWJ5wXuWVYc3iFF4hwFB3HR1GUaebiu8o2eHNxSSM=.e1d085e1-acb0-401a-9895-c826c00cb94b@github.com> On Thu, 23 Jul 2020 05:34:50 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.3 > https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html Marked as reviewed by bchoudhary (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/271 From kcr at openjdk.java.net Fri Jul 24 12:11:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Jul 2020 12:11:17 GMT Subject: [jfx15] Integrated: 8250238: Media fails to load libav 58 library when using modules from maven central In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 21:40:05 GMT, Kevin Rushforth wrote: > When running a JavaFX application using the JavaFX modules from maven central, the native libraries are packed into the > jar file, and then unpacked as needed by the JavaFX runtime. This fails for libavplugin-ffmpeg-58.so, because the entry > for the `avplugin-ffmpeg-58` library is missing from the list of dependent libraries of `jfxmedia` in > [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). This pull request has now been integrated. Changeset: 6b008925 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6b008925 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8250238: Media fails to load libav 58 library when using modules from maven central Reviewed-by: almatvee, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/272 From ajoseph at openjdk.java.net Fri Jul 24 12:12:19 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 24 Jul 2020 12:12:19 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v6] In-Reply-To: <5ZvCdQhLSzUf-gpbfBj3Cx5ZtJgVZ3xqaL-mgkwnV9k=.ecb8559f-611b-4238-ac0b-f8c42dcb746e@github.com> References: <5ZvCdQhLSzUf-gpbfBj3Cx5ZtJgVZ3xqaL-mgkwnV9k=.ecb8559f-611b-4238-ac0b-f8c42dcb746e@github.com> Message-ID: <5o-DWzEPwNyJIlglbJhHTdRnHzV2XYMzmGokxTWsCJY=.d79d67e8-e8aa-47e8-83b4-9bca8350ba18@github.com> On Tue, 21 Jul 2020 21:50:39 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > HiDPI printing and Rendering fix modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp line 93: > 92: auto deviceScaleFactor = document().deviceScaleFactor(); > 93: maskImageContext.applyDeviceScaleFactor(deviceScaleFactor); > 94: For javafx port specific code in WebKit, it should be enclosed in `#if PLATFORM(JAVA)`. But I think that there should be a better approach as other ports don't require this scaling of `deviceScaleFactor` ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From ajoseph at openjdk.java.net Fri Jul 24 12:41:16 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 24 Jul 2020 12:41:16 GMT Subject: Integrated: 8249839: Cherry pick GTK WebKit 2.28.3 changes In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 05:34:50 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.3 > https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html This pull request has now been integrated. Changeset: 926b5b6b Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/926b5b6b Stats: 531 lines in 36 files changed: 64 ins; 379 del; 88 mod 8249839: Cherry pick GTK WebKit 2.28.3 changes Reviewed-by: kcr, bchoudhary ------------- PR: https://git.openjdk.java.net/jfx/pull/271 From ebresie at gmail.com Fri Jul 24 14:54:28 2020 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 24 Jul 2020 09:54:28 -0500 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: <50fade05-a5bd-3739-045e-c4fb9aefdcea@oracle.com> References: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> <12316cfd-1509-a355-9efa-c128ec6e5ffd@oracle.com> <50fade05-a5bd-3739-045e-c4fb9aefdcea@oracle.com> Message-ID: Would a inclusion of timestamp within generated META-INF\MANIFEST.MF allow some 'timestamp" without impacting the generated jar name also be worth considering? Eric Bresie ebresie at gmail.com On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth wrote: > In that case, we can probably remove the time stamp from MAVEN_VERSION > altogether in a follow-up fix, since it is never used for any released > version, including early access builds. Not a high priority though once > the entire publishing task is qualified by a property. > > -- Kevin > > > On 7/23/2020 10:26 AM, Joeri Sykora wrote: > > We have never had the need to publish snapshot versions. We do however > > publish early access builds quite regularly (e.g. 15-ea+6) for the > > versions that are in development. > > > > Op do 23 jul. 2020 18:44 schreef Kevin Rushforth > > >: > > > > The proposed fix will be to disable the maven publishing tasks by > > default, and to not set the project.version at all. So this will > > decouple the maven publishing tasks, and they won't interfere with > > normal developer or production builds. > > > > Joeri or Johan can confirm, but if they ever do upload a bundle for > > testing, I'm pretty sure they would use a SNAPSHOT designation (set > > manually). > > > > -- Kevin > > > > > > On 7/23/2020 5:55 AM, Eric Bresie wrote: > > > Is there a need for some further cleanup dependency between > > builds maybe to remove duplicate jars / modules with different > > time stamps? > > > > > > Rather than time stamp in these cases should it just use a > > SNAPSHOT designation instead? > > > > > > Eric Bresie > > > Ebresie at gmail.com > > >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth > > > > > wrote: > > >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to > > track fixing > > >> the build.gradle to not include the time stamp, at least by > > default. > > >> > > >> -- Kevin > > >> > > >> > > >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > > >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > > >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: > > >>>>>> That could be prevented by removing line 1547: > > project.version = > > >>>>>> MAVEN_VERSION from the build script. > > >>>>> Interesting. That is only used for the maven "publishing" > > tasks, and > > >>>>> shouldn't affect the main build artifacts. I don't see the > > generated > > >>>>> version number showing up anywhere in the build output. It > > would be > > >>>>> easy enough to suppress this for non-production builds, but > > I'd want > > >>>>> to understand how it is causing problems. Does gradle (and > > thus the > > >>>>> NetBeans gradle plugin), assign some semantic meaning to the > > >>>>> project.version attribute? > > >>>> There is no semantic association. It is just the binding of the > > >>>> sub-projects together. Recent Gradle doesn't generate the jar > > files > > >>>> of the sub-projects if not asked for that specifically. Though > if > > >>>> javafx:base project is asked of it's main output it would be > > a jar > > >>>> file with a second precision suffix in it's name. Also if you > > ask for > > >>>> the dependencies of javafx:graphics it will list a dependency > > on a > > >>>> javafx:base base jar with the second precision suffix in its > > name. > > >>>> The jar file does not have to be exist, NetBeans still would > > able to > > >>>> find out the dependency between the two sub-projects, but > > these jar > > >>>> names shall be the same. So if these two queries happen in > > different > > >>>> times the jar name would not match. > > >>> Got it. We explicitly disable the jar task for each modular > > project, > > >>> since we don't need them, so we never would have noticed this. > > If I > > >>> enable them, I can see the jar files with the full version > number, > > >>> including the date string. > > >>> > > >>> I'll file a bug to fix it. I'll need to do it in such a way > > that won't > > >>> disrupt generating maven artifacts for testing (actual maven > > artifacts > > >>> for uploading won't be affected anyway), but it should be easy > > to do. > > >>> > > >>> -- Kevin > > >>> > > > > From kcr at openjdk.java.net Fri Jul 24 17:49:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Jul 2020 17:49:03 GMT Subject: RFR: 8250553: This is not a bug and should not be integrated Message-ID: _NOTE: This PR should not be integrated. It is only a test. ------------- Commit messages: - 8250553: This is not a bug and should not be integrated Changes: https://git.openjdk.java.net/jfx/pull/273/files Webrev: https://webrevs.openjdk.java.net/jfx/273/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250553 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/273/head:pull/273 PR: https://git.openjdk.java.net/jfx/pull/273 From kcr at openjdk.java.net Fri Jul 24 20:31:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Jul 2020 20:31:52 GMT Subject: RFR: 8250553: This is not a bug and should not be integrated In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 17:35:20 GMT, Kevin Rushforth wrote: > _NOTE: This PR should not be integrated. It is only a test._ Closing this PR. The Description contains the results of the testing, specifically: * ?? Failed to retrieve information on issue `8250553`. ------------- PR: https://git.openjdk.java.net/jfx/pull/273 From kcr at openjdk.java.net Fri Jul 24 20:31:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Jul 2020 20:31:53 GMT Subject: Withdrawn: 8250553: This is not a bug and should not be integrated In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 17:35:20 GMT, Kevin Rushforth wrote: > _NOTE: This PR should not be integrated. It is only a test._ This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/273 From kcr at openjdk.java.net Fri Jul 24 21:43:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Jul 2020 21:43:25 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 8 May 2020 12:36:41 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 11 commits: > - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight > - Attenuation and range changed internally to floats from doubles > - Fixed shader compilation errors for 2 and 3 lights in es2 > - Addressing review comments > - Fixed whitespaces > - Correction for indexes > - Docs and year update > - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into > 8217472_Add_attenuation_for_PointLight > - GL pipeline > - Separate range from attenuation > - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed High-level comments: 1. The API docs look good. If you change the public API to `@since 16` then you can also update the CSR and move it to the "Submitted" state. 2. I think it would be good to cleanup the performance test and make it part of this PR, maybe in `tests/performance` (which currently only has the not-very-useful `VMPerformance` subdir) or `tests/manual`. 3. We need some functional tests, ideally automated ones in `tests/system` I also left a few inline comments. I haven't reviewed the shaders yet, so I do that, in addition to further testing, next week. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/PointLightHelper.java line 2: > 1: /* > 2: * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Update the "last modified year" for 2020 or else revert (this applies to all copyright year updates). modules/javafx.graphics/src/main/java/com/sun/javafx/scene/PointLightHelper.java line 77: > 76: } > 77: } Minor: missing newline here modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 187: > 186: 0, 0, 0, 0, // r g b w > 187: 1, 0, 0, 0); // ca la qa maxRange > 188: } Minor: maybe use the getDefaultXxxx methods of NGPointLight? modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 51: > 50: * results in the light's color being subtracted from the material instead of added to it, thus creating a > 51: * "shadow caster". > 52: *

Can you think of any problems that might arise by supporting negative coefficients? If not, then this seems fine. modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 108: > 107: * @defaultValue {@code Double.POSITIVE_INFINITY} > 108: * @since 14 > 109: */ `@since 16` ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kevin.rushforth at oracle.com Fri Jul 24 23:00:38 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 Jul 2020 16:00:38 -0700 Subject: Fixing NetBeans Gradle Support for OpenJFX In-Reply-To: References: <537de748-1046-4408-9d9e-b6881979d253@Erics-iPhone-X> <12316cfd-1509-a355-9efa-c128ec6e5ffd@oracle.com> <50fade05-a5bd-3739-045e-c4fb9aefdcea@oracle.com> Message-ID: For developer builds, the full version includes the time stamp. This is reflected in the "javafx.runtime.version" system property. For release builds, the time stamp is replaced with the build number. We've never included a time stamp anywhere else, and I don't see much need to add one without a good reason. -- Kevin On 7/24/2020 7:54 AM, Eric Bresie wrote: > Would a inclusion of timestamp within generated META-INF\MANIFEST.MF allow > some 'timestamp" without impacting the generated jar name also be worth > considering? > > Eric Bresie > ebresie at gmail.com > > > On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth > wrote: > >> In that case, we can probably remove the time stamp from MAVEN_VERSION >> altogether in a follow-up fix, since it is never used for any released >> version, including early access builds. Not a high priority though once >> the entire publishing task is qualified by a property. >> >> -- Kevin >> >> >> On 7/23/2020 10:26 AM, Joeri Sykora wrote: >>> We have never had the need to publish snapshot versions. We do however >>> publish early access builds quite regularly (e.g. 15-ea+6) for the >>> versions that are in development. >>> >>> Op do 23 jul. 2020 18:44 schreef Kevin Rushforth >>> >: >>> >>> The proposed fix will be to disable the maven publishing tasks by >>> default, and to not set the project.version at all. So this will >>> decouple the maven publishing tasks, and they won't interfere with >>> normal developer or production builds. >>> >>> Joeri or Johan can confirm, but if they ever do upload a bundle for >>> testing, I'm pretty sure they would use a SNAPSHOT designation (set >>> manually). >>> >>> -- Kevin >>> >>> >>> On 7/23/2020 5:55 AM, Eric Bresie wrote: >>> > Is there a need for some further cleanup dependency between >>> builds maybe to remove duplicate jars / modules with different >>> time stamps? >>> > >>> > Rather than time stamp in these cases should it just use a >>> SNAPSHOT designation instead? >>> > >>> > Eric Bresie >>> > Ebresie at gmail.com >>> >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth >>> > >>> wrote: >>> >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to >>> track fixing >>> >> the build.gradle to not include the time stamp, at least by >>> default. >>> >> >>> >> -- Kevin >>> >> >>> >> >>> >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: >>> >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: >>> >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: >>> >>>>>> That could be prevented by removing line 1547: >>> project.version = >>> >>>>>> MAVEN_VERSION from the build script. >>> >>>>> Interesting. That is only used for the maven "publishing" >>> tasks, and >>> >>>>> shouldn't affect the main build artifacts. I don't see the >>> generated >>> >>>>> version number showing up anywhere in the build output. It >>> would be >>> >>>>> easy enough to suppress this for non-production builds, but >>> I'd want >>> >>>>> to understand how it is causing problems. Does gradle (and >>> thus the >>> >>>>> NetBeans gradle plugin), assign some semantic meaning to the >>> >>>>> project.version attribute? >>> >>>> There is no semantic association. It is just the binding of the >>> >>>> sub-projects together. Recent Gradle doesn't generate the jar >>> files >>> >>>> of the sub-projects if not asked for that specifically. Though >> if >>> >>>> javafx:base project is asked of it's main output it would be >>> a jar >>> >>>> file with a second precision suffix in it's name. Also if you >>> ask for >>> >>>> the dependencies of javafx:graphics it will list a dependency >>> on a >>> >>>> javafx:base base jar with the second precision suffix in its >>> name. >>> >>>> The jar file does not have to be exist, NetBeans still would >>> able to >>> >>>> find out the dependency between the two sub-projects, but >>> these jar >>> >>>> names shall be the same. So if these two queries happen in >>> different >>> >>>> times the jar name would not match. >>> >>> Got it. We explicitly disable the jar task for each modular >>> project, >>> >>> since we don't need them, so we never would have noticed this. >>> If I >>> >>> enable them, I can see the jar files with the full version >> number, >>> >>> including the date string. >>> >>> >>> >>> I'll file a bug to fix it. I'll need to do it in such a way >>> that won't >>> >>> disrupt generating maven artifacts for testing (actual maven >>> artifacts >>> >>> for uploading won't be affected anyway), but it should be easy >>> to do. >>> >>> >>> >>> -- Kevin >>> >>> >>> >> From nlisker at openjdk.java.net Sat Jul 25 17:33:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 25 Jul 2020 17:33:06 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs Message-ID: Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. ------------- Commit messages: - Initial commit of 8246343 Changes: https://git.openjdk.java.net/jfx/pull/274/files Webrev: https://webrevs.openjdk.java.net/jfx/274/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246343 Stats: 27 lines in 6 files changed: 3 ins; 2 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/274.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274 PR: https://git.openjdk.java.net/jfx/pull/274 From kcr at openjdk.java.net Sat Jul 25 17:43:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 25 Jul 2020 17:43:45 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020 17:16:25 GMT, Nir Lisker wrote: > Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. Just a couple quick comments for now. I'll review it next week. modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html line 723: > 722: ObservableList, ObservableMap or class="code">ObservableSet 723: uses a special onChange attribute that points to a > handler method with a ListChangeListner, MapChangeListener or class="code">SetChangeListener parameter, respectively. 724:

ListChangeListner --> ListChangeListener modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 234: > 233: /** > 234: * Creates an {@code VBox} layout with {@code spacing = 0}. > 235: * @param children the initial set of children for this pane As long as you are fixing this: _an_ VBox --> _a_ VBox ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From nlisker at openjdk.java.net Sat Jul 25 17:48:11 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 25 Jul 2020 17:48:11 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020 17:44:02 GMT, Kevin Rushforth wrote: >> modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html line 723: >> >>> 722: ObservableList, ObservableMap or >> class="code">ObservableSet 723: uses a special onChange attribute that points to a >>> handler method with a ListChangeListner, MapChangeListener or >> class="code">SetChangeListener parameter, respectively. 724:

>> >> ListChangeListner --> ListChangeListener > > Also, the `.Change` was correct before your fix, unless I'm missing something. I misunderstood point 3 in the JBS issue. I thought that the change was to remove `.Change`. ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From kcr at openjdk.java.net Sat Jul 25 17:48:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 25 Jul 2020 17:48:10 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020 17:38:30 GMT, Kevin Rushforth wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > > modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html line 723: > >> 722: ObservableList, ObservableMap or > class="code">ObservableSet 723: uses a special onChange attribute that points to a >> handler method with a ListChangeListner, MapChangeListener or > class="code">SetChangeListener parameter, respectively. 724:

> > ListChangeListner --> ListChangeListener Also, the `.Change` was correct before your fix, unless I'm missing something. ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From nlisker at openjdk.java.net Sat Jul 25 18:11:55 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 25 Jul 2020 18:11:55 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: > Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/274/files - new: https://git.openjdk.java.net/jfx/pull/274/files/29271615..5c7d74ef Webrevs: - full: https://webrevs.openjdk.java.net/jfx/274/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/274.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274 PR: https://git.openjdk.java.net/jfx/pull/274 From kcr at openjdk.java.net Sat Jul 25 18:12:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 25 Jul 2020 18:12:17 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020 18:11:55 GMT, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 234: > 233: /** > 234: * Creates n {@code VBox} layout with {@code spacing = 0}. > 235: * @param children the initial set of children for this pane oops: n -> a Also, you might look through the file for "an vbox" since it occurs in other places. ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From nlisker at openjdk.java.net Sun Jul 26 10:10:09 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 26 Jul 2020 10:10:09 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: > Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: VBox and HBox fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/274/files - new: https://git.openjdk.java.net/jfx/pull/274/files/5c7d74ef..141e78f1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/274/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.01-02 Stats: 11 lines in 2 files changed: 0 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/274.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274 PR: https://git.openjdk.java.net/jfx/pull/274 From aghaisas at openjdk.java.net Mon Jul 27 10:21:14 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Jul 2020 10:21:14 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors Message-ID: Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. ------------- Commit messages: - add explicit constructors Changes: https://git.openjdk.java.net/jfx/pull/275/files Webrev: https://webrevs.openjdk.java.net/jfx/275/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249647 Stats: 116 lines in 21 files changed: 114 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/275.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/275/head:pull/275 PR: https://git.openjdk.java.net/jfx/pull/275 From fastegal at openjdk.java.net Mon Jul 27 10:21:25 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 27 Jul 2020 10:21:25 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors In-Reply-To: References: Message-ID: <0wNM0OvGfewNbfn67qjEFnsQZ-wPgKYbCmhs65i7xXo=.2d6f01c7-c425-4949-9cbd-83e2e080b01f@github.com> On Mon, 27 Jul 2020 10:07:31 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 > Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. The single sentence of the min doc should end with a period, iirc ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/275 From aghaisas at openjdk.java.net Mon Jul 27 11:26:28 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Jul 2020 11:26:28 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors [v2] In-Reply-To: References: Message-ID: <7Yd8w-fEXL3Oh5NGCNKwfHqqAYMY9KAt0hxrK6jNkvY=.e43a9362-2bf5-402c-a705-3a382647392f@github.com> > Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 > Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: review_fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/275/files - new: https://git.openjdk.java.net/jfx/pull/275/files/012d2320..ee05a923 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/275/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/275/webrev.00-01 Stats: 21 lines in 21 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/275.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/275/head:pull/275 PR: https://git.openjdk.java.net/jfx/pull/275 From aghaisas at openjdk.java.net Mon Jul 27 11:26:29 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Jul 2020 11:26:29 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors In-Reply-To: <0wNM0OvGfewNbfn67qjEFnsQZ-wPgKYbCmhs65i7xXo=.2d6f01c7-c425-4949-9cbd-83e2e080b01f@github.com> References: <0wNM0OvGfewNbfn67qjEFnsQZ-wPgKYbCmhs65i7xXo=.2d6f01c7-c425-4949-9cbd-83e2e080b01f@github.com> Message-ID: On Mon, 27 Jul 2020 10:16:07 GMT, Jeanette Winzenburg wrote: > The single sentence of the min doc should end with a period, iirc ;) Thanks. Yes, I missed out on it.. will fix soon. ------------- PR: https://git.openjdk.java.net/jfx/pull/275 From Rony.Flatscher at wu.ac.at Mon Jul 27 13:09:54 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 27 Jul 2020 15:09:54 +0200 Subject: A request for FXML exxamples (Re: [jfx15] Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: <5dd0d434-5631-e7fe-f1f3-5366c1f02192@wu.ac.at> On 26.07.2020 12:10, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > VBox and HBox fixes > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/274/files > - new: https://git.openjdk.java.net/jfx/pull/274/files/5c7d74ef..141e78f1 > > Webrevs: > - full: https://webrevs.openjdk.java.net/jfx/274/webrev.02 > - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.01-02 > > Stats: 11 lines in 2 files changed: 0 ins; 2 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/274.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274 > > PR: https://git.openjdk.java.net/jfx/pull/274 One of the changes reads (at ): modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html Viewed @@ -720,7 +720,7 @@

Special handlers for collections a

Collections and object properties cannot be listen to using setOnEvent() methods. For these reason, special handler methods need to be used. ObservableList, ObservableMap or ObservableSet uses a special onChange attribute that points to a handler method with a ListChangeListener.Change, MapChangeListener.Change or SetChangeListener.Change parameter, respectively.


    <VBox fx:controller="com.foo.MyController"

Does anyone have FXML examples where "onChange" for ObservableList, ObservableMap and ObservableSet?
get employed?

---rony



From github.com+17347324+Torbuntu at openjdk.java.net  Mon Jul 27 14:31:37 2020
From: github.com+17347324+Torbuntu at openjdk.java.net (Tor (torbuntu))
Date: Mon, 27 Jul 2020 14:31:37 GMT
Subject: RFR: 8201568: zForce touchscreen input device fails when closed
 and immediately reopened
In-Reply-To: 
References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com>
 
 <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com>
 <6o8qSlwswav0zA97KO1AcFkc9S9N10m5T4O1WiGs5Fk=.28d3812f-a8cd-4c80-990b-af07aaf1c084@github.com>
 
Message-ID: 

On Thu, 9 Jul 2020 22:35:01 GMT, John Neffenger  wrote:

> By the way, do you know whether I would be able to use a PinePhone
I have been trying to run JavaFX on the PinePhone ever since I got it. The OS I'm using is Fedora and it is aarch64,
which means I had to add that arch to build.gradle to compile it. As is the touchscreen doesn't respond correctly at
all. Every touch reports as a mouse_entered, mouse_exited event.

How can I set the `monocle.platform=Linux` to test?

-------------

PR: https://git.openjdk.java.net/jfx/pull/258

From nlisker at openjdk.java.net  Mon Jul 27 15:40:02 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Mon, 27 Jul 2020 15:40:02 GMT
Subject: [jfx15] RFR: 8249647: Many classes in package
 javafx.beans.binding in module javafx.base have implicit no-arg constructors
 [v2]
In-Reply-To: <7Yd8w-fEXL3Oh5NGCNKwfHqqAYMY9KAt0hxrK6jNkvY=.e43a9362-2bf5-402c-a705-3a382647392f@github.com>
References: 
 <7Yd8w-fEXL3Oh5NGCNKwfHqqAYMY9KAt0hxrK6jNkvY=.e43a9362-2bf5-402c-a705-3a382647392f@github.com>
Message-ID: 

On Mon, 27 Jul 2020 11:26:28 GMT, Ajit Ghaisas  wrote:

>> Issue : https://bugs.openjdk.java.net/browse/JDK-8249647
>> Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review_fixes

Please use `@code` for all class names, like `{@code StringBinding}`.

-------------

Changes requested by nlisker (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/275

From github.com+1413266+jgneff at openjdk.java.net  Mon Jul 27 16:07:16 2020
From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger)
Date: Mon, 27 Jul 2020 16:07:16 GMT
Subject: RFR: 8201568: zForce touchscreen input device fails when closed
 and immediately reopened
In-Reply-To: 
References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com>
 
 <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com>
 <6o8qSlwswav0zA97KO1AcFkc9S9N10m5T4O1WiGs5Fk=.28d3812f-a8cd-4c80-990b-af07aaf1c084@github.com>
 
 
Message-ID: 

On Mon, 27 Jul 2020 14:26:44 GMT, Tor (torbuntu)  wrote:

> Is there somewhere I can find an embedded aarch64 version?

If I had a PinePhone, I would try to get the 32-bit *armhf* build of JavaFX working. That's the one you build with
`gradle -PCOMPILE_TARGETS=armv6hf sdk jmod`. You may need to switch operating systems. See the [Ask Ubuntu
question](https://askubuntu.com/q/1090351) "Can I run an ARM32 bit App on an ARM64bit platform which is running Ubuntu
16.04?"

-------------

PR: https://git.openjdk.java.net/jfx/pull/258

From github.com+17347324+Torbuntu at openjdk.java.net  Mon Jul 27 16:55:59 2020
From: github.com+17347324+Torbuntu at openjdk.java.net (Tor (torbuntu))
Date: Mon, 27 Jul 2020 16:55:59 GMT
Subject: RFR: 8201568: zForce touchscreen input device fails when closed
 and immediately reopened
In-Reply-To: 
References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com>
 
 <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com>
 <6o8qSlwswav0zA97KO1AcFkc9S9N10m5T4O1WiGs5Fk=.28d3812f-a8cd-4c80-990b-af07aaf1c084@github.com>
 
 
 
Message-ID: 

On Mon, 27 Jul 2020 16:05:02 GMT, John Neffenger  wrote:

>>> By the way, do you know whether I would be able to use a PinePhone
>> 
>> I have been trying to run JavaFX on the PinePhone ever since I got it. The OS I'm using is Fedora and it is aarch64,
>> which means I had to add that arch to build.gradle to compile it. As is the touchscreen doesn't respond correctly at
>> all. Every touch reports as a mouse_entered, mouse_exited event.  Though this is due to using the Desktop JavaFX. Is
>> there somewhere I can find an embedded aarch64 version? Since desktop javafx/OpenJFX only runs monocle in headless
>> according to this: https://wiki.openjdk.java.net/display/OpenJFX/Monocle
>
>> Is there somewhere I can find an embedded aarch64 version?
> 
> If I had a PinePhone, I would try to get the 32-bit *armhf* build of JavaFX working. That's the one you build with
> `gradle -PCOMPILE_TARGETS=armv6hf sdk jmod`. You may need to switch operating systems. See the [Ask Ubuntu
> question](https://askubuntu.com/q/1090351) "Can I run an ARM32 bit App on an ARM64bit platform which is running Ubuntu
> 16.04?"

I do not know of a currently supported 32-bit armhf OS for the PinePhone.
This issue affects Desktop JavaFX linux touch as well, so I suppose I'll need to dig into adding that in, which was
mentioned on this older issue: https://github.com/javafxports/openjdk-jfx/issues/329#issuecomment-459433106

Thanks for the quick reply!

-------------

PR: https://git.openjdk.java.net/jfx/pull/258

From kcr at openjdk.java.net  Mon Jul 27 17:36:55 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 27 Jul 2020 17:36:55 GMT
Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 26 Jul 2020 10:10:09 GMT, Nir Lisker  wrote:

>> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VBox and HBox fixes

A few inline comments, but otherwise looks fine.

modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java line 599:

> 598:     /**
> 599:      * Commits an edit to the value of the cell.
> 600:      * Call this function when appropriate (based on the user interaction requirements

A similar change could be made to `startEdit` and `cancelEdit` in the same class.

modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java line 615:

> 614:      * implementations - it should be sufficient to simply call this method
> 615:      * when appropriate (e.g., when the user pressed the Enter key, you may do something
> 616:      * like {@code cell.commitEdit(converter.fromString(textField.getText()));}

Since you are changing this, perhaps you might also fix the one in the previous paragraph as well -- the one in the `
    ` ... `
` block? modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 245: > 244: /** > 245: * Creates an {@code HBox} layout with{@code spacing = 0}. > 246: * @param children the initial set of children for this pane missing a space between `with` and `{@code` modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 163: > 162: * If no vertical grow priority is set on a child, the vbox will never > 163: * allocate it additional vertical space, if available. > 164: *

This isn't a new problem, but the following is awkward: "If no vertical grow priority is set on a child, the vbox will never allocate it additional vertical space, if available." If this is trying to say that the vbox will never allocate extra space for that child, then it should be reworded slightly. Maybe something like this? "If no vertical grow priority is set on a child, the vbox will never allocate any additional vertical space for that child." I note that HBox has the same awkward sentence. modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 175: > 174: * allocate it additional horizontal space if available. > 175: *

> 176: * Setting the value to {@code null} will remove the constraint. See comment in VBox that applies to this section as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From nlisker at gmail.com Mon Jul 27 20:39:50 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 27 Jul 2020 23:39:50 +0300 Subject: A request for FXML exxamples (Re: [jfx15] Fix mistakes in FX API docs [v3] In-Reply-To: <5dd0d434-5631-e7fe-f1f3-5366c1f02192@wu.ac.at> References: <5dd0d434-5631-e7fe-f1f3-5366c1f02192@wu.ac.at> Message-ID: Hi Rony, I think that this PR is not the place for this question since it only fixes a typo there. On Mon, Jul 27, 2020 at 4:12 PM Rony G. Flatscher wrote: > On 26.07.2020 12:10, Nir Lisker wrote: > >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some > additional fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one > additional commit since the last revision: > > > > VBox and HBox fixes > > > > ------------- > > > > Changes: > > - all: https://git.openjdk.java.net/jfx/pull/274/files > > - new: > https://git.openjdk.java.net/jfx/pull/274/files/5c7d74ef..141e78f1 > > > > Webrevs: > > - full: https://webrevs.openjdk.java.net/jfx/274/webrev.02 > > - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.01-02 > > > > Stats: 11 lines in 2 files changed: 0 ins; 2 del; 9 mod > > Patch: https://git.openjdk.java.net/jfx/pull/274.diff > > Fetch: git fetch https://git.openjdk.java.net/jfx > pull/274/head:pull/274 > > > > PR: https://git.openjdk.java.net/jfx/pull/274 > > One of the changes reads (at < > https://git.openjdk.java.net/jfx/pull/274/files>): > > > modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html > < > https://github.com/openjdk/jfx/pull/274/files#diff-7057a6e3191138952057e494b1753773 > > > > Viewed > > @@ -720,7 +720,7 @@

id="collections_and_property_handlers">Special handlers for > collections a > >

Collections and object properties cannot be listen to using class="code">setOn class="variable">Event() methods. > > For these reason, special handler methods need to be used. > > ObservableList, class="code">ObservableMap or class="code">ObservableSet > > uses a special onChange attribute that > points to a handler method with > a ListChangeListener.Change, class="code">MapChangeListener.Change or class="code">SetChangeListener.Change parameter, respectively. > >

> >
>
>     <VBox fx:controller="com.foo.MyController"
>
> Does anyone have FXML examples where "onChange" for ObservableList,
> ObservableMap and ObservableSet
> get employed?
>
> ---rony
>
>
>

From nlisker at openjdk.java.net  Mon Jul 27 20:49:16 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Mon, 27 Jul 2020 20:49:16 GMT
Subject: [jfx15] RFR: 8228570: Add various documentation clarifications
Message-ID: 

Adds clarifications to the documentation in various places. Some notes:

* Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were
  updated to Java 8 only.
* Point 8 has been deferred until all the animation bugs have been resolevd.
* Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback
  extractor)` method. Later I found that `observableList(List list, Callback extractor)` already
  talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them.
* Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that
  this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and
  there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality
  instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently.
I think that in the future we will want to let the user define what a change is (for example, by creating an
overridable method with the current behavior as the default, or using object equality and letting the user override
that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation
`IndentityHashMap` to deal with this ambiguity.

-------------

Commit messages:
 - Initial commit of 8228570

Changes: https://git.openjdk.java.net/jfx/pull/276/files
 Webrev: https://webrevs.openjdk.java.net/jfx/276/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8228570
  Stats: 122 lines in 9 files changed: 60 ins; 13 del; 49 mod
  Patch: https://git.openjdk.java.net/jfx/pull/276.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/276/head:pull/276

PR: https://git.openjdk.java.net/jfx/pull/276

From nlisker at openjdk.java.net  Mon Jul 27 21:16:41 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Mon, 27 Jul 2020 21:16:41 GMT
Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v4]
In-Reply-To: 
References: 
Message-ID: 

> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/274/files
  - new: https://git.openjdk.java.net/jfx/pull/274/files/141e78f1..7bb6ff16

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/274/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.02-03

  Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/274.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274

PR: https://git.openjdk.java.net/jfx/pull/274

From nlisker at openjdk.java.net  Mon Jul 27 21:16:44 2020
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Mon, 27 Jul 2020 21:16:44 GMT
Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <1iQFO7Dh-91WFVjdFxyQbFpt31QcIP42WcR5xHBZ5lk=.170beeff-1a52-48a1-87a7-71aec76de051@github.com>

On Mon, 27 Jul 2020 17:32:26 GMT, Kevin Rushforth  wrote:

>> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   VBox and HBox fixes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 163:
> 
>> 162:      * If no vertical grow priority is set on a child, the vbox will never
>> 163:      * allocate it additional vertical space, if available.
>> 164:      * 

> > This isn't a new problem, but the following is awkward: > > "If no vertical grow priority is set on a child, the vbox will never allocate it additional vertical space, if > available." > If this is trying to say that the vbox will never allocate extra space for that child, then it should be reworded > slightly. Maybe something like this? > "If no vertical grow priority is set on a child, the vbox will never allocate any additional vertical space for that > child." > I note that HBox has the same awkward sentence. Your suggestion looks good, I tried not to rewrite too much initially. ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From kcr at openjdk.java.net Mon Jul 27 21:33:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Jul 2020 21:33:06 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v3] In-Reply-To: <1iQFO7Dh-91WFVjdFxyQbFpt31QcIP42WcR5xHBZ5lk=.170beeff-1a52-48a1-87a7-71aec76de051@github.com> References: <1iQFO7Dh-91WFVjdFxyQbFpt31QcIP42WcR5xHBZ5lk=.170beeff-1a52-48a1-87a7-71aec76de051@github.com> Message-ID: On Mon, 27 Jul 2020 20:52:57 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 163: >> >>> 162: * If no vertical grow priority is set on a child, the vbox will never >>> 163: * allocate it additional vertical space, if available. >>> 164: *

>> >> This isn't a new problem, but the following is awkward: >> >> "If no vertical grow priority is set on a child, the vbox will never allocate it additional vertical space, if >> available." >> If this is trying to say that the vbox will never allocate extra space for that child, then it should be reworded >> slightly. Maybe something like this? >> "If no vertical grow priority is set on a child, the vbox will never allocate any additional vertical space for that >> child." >> I note that HBox has the same awkward sentence. > > Your suggestion looks good, I tried not to rewrite too much initially. Yeah, the only reason I suggested it is that I had to read that sentence three times before I realized what it was trying to say. ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From kcr at openjdk.java.net Mon Jul 27 21:50:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Jul 2020 21:50:38 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: <3owMa8Q5iZhojCV8YBO7PPxAUx2g9Whhh-cfmjzH19E=.f0b3da53-867e-46ec-ac75-aa256e139ba4@github.com> On Mon, 27 Jul 2020 21:16:41 GMT, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From arapte at openjdk.java.net Tue Jul 28 08:59:14 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 28 Jul 2020 08:59:14 GMT Subject: RFR: [WIP]8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v2] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge with master - 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing ------------- Changes: https://git.openjdk.java.net/jfx/pull/172/files Webrev: https://webrevs.openjdk.java.net/jfx/172/webrev.01 Stats: 211 lines in 6 files changed: 151 ins; 49 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From aghaisas at openjdk.java.net Tue Jul 28 10:00:37 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 28 Jul 2020 10:00:37 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors [v3] In-Reply-To: References: Message-ID: <5GeK8kqAcm99H3Jo45deQRO1M5gXGtYpXgr9xFFKZLg=.b187238e-5eba-4860-89bd-2b963b6a27ac@github.com> > Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 > Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: add @code tag to class name doc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/275/files - new: https://git.openjdk.java.net/jfx/pull/275/files/ee05a923..f73de6ed Webrevs: - full: https://webrevs.openjdk.java.net/jfx/275/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/275/webrev.01-02 Stats: 21 lines in 21 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/275.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/275/head:pull/275 PR: https://git.openjdk.java.net/jfx/pull/275 From nlisker at openjdk.java.net Tue Jul 28 11:17:54 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 11:17:54 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors [v3] In-Reply-To: <5GeK8kqAcm99H3Jo45deQRO1M5gXGtYpXgr9xFFKZLg=.b187238e-5eba-4860-89bd-2b963b6a27ac@github.com> References: <5GeK8kqAcm99H3Jo45deQRO1M5gXGtYpXgr9xFFKZLg=.b187238e-5eba-4860-89bd-2b963b6a27ac@github.com> Message-ID: <680k-_gfiNt87AZOKYrN150IvQqSg6WEci7bgHzGTxk=.dbe8e2ae-f6d1-4b9b-9312-1bfa0fac6b55@github.com> On Tue, 28 Jul 2020 10:00:37 GMT, Ajit Ghaisas wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 >> Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > add @code tag to class name doc Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/275 From Rony.Flatscher at wu.ac.at Tue Jul 28 11:18:36 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 28 Jul 2020 13:18:36 +0200 Subject: Seeking FXML examples with the "onChange" attribute defined for ObservableList, ObservableMap, ObservableSet ... Message-ID: <54712f71-7eeb-f37c-b4bf-1d5aee7b8025@wu.ac.at> Hi Nir, On 27.07.2020 22:39, Nir Lisker wrote: > Hi Rony, > > I think that this PR is not the place for this question since it only fixes a typo there. sorry, my bad, not realizing that the reply will be taken as part of the PR! This time with a proper new e-mail. --- In there are corrections for the text relating to documenting the "onChange" attribute for "ObservableList" supplying a "ListChangeListener.Change" [1], "ObservableMap" supplying a "MapChangeListener.Change" [2] or "ObservableSet" supplying a "SetChangeListener.Change" [3]. Does anyone have FXML examples for defining the "onChange" attribute for any of the three Observable{List|Map|Set}? ---rony [1] "ListChangeListener.Change": [2] "MapChangeListener.Change":? [3] "SetChangeListener.Change": From nlisker at openjdk.java.net Tue Jul 28 12:46:46 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 12:46:46 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Thu, 23 Jul 2020 12:06:17 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 11 commits: >> - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight >> - Attenuation and range changed internally to floats from doubles >> - Fixed shader compilation errors for 2 and 3 lights in es2 >> - Addressing review comments >> - Fixed whitespaces >> - Correction for indexes >> - Docs and year update >> - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into >> 8217472_Add_attenuation_for_PointLight >> - GL pipeline >> - Separate range from attenuation >> - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed > > modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main3Lights.frag line 92: > >> 91: d += clamp(dot(n,l), 0.0, 1.0) * (lights[0].color).rgb * att; >> 92: s += pow(clamp(dot(-refl, l), 0.0, 1.0), power) * lights[0].color.rgb * att; >> 93: } > > These three lines can be changed as: > float attenuatedColor = (lights[0].color).rgb / (lights[0].attn.x + lights[0].attn.y * dist + lights[0].attn.z * dist * > dist); d += clamp(dot(n,l), 0.0, 1.0) * attenuatedColor; > s += pow(clamp(dot(-refl, l), 0.0, 1.0), power) * attenuatedColor; > Similar change in the 1 light and 2 lights shader. Interesting, I'd think the compiler would have optimized it. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Tue Jul 28 12:59:16 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 12:59:16 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 21:29:06 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 11 commits: >> - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight >> - Attenuation and range changed internally to floats from doubles >> - Fixed shader compilation errors for 2 and 3 lights in es2 >> - Addressing review comments >> - Fixed whitespaces >> - Correction for indexes >> - Docs and year update >> - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into >> 8217472_Add_attenuation_for_PointLight >> - GL pipeline >> - Separate range from attenuation >> - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed > > modules/javafx.graphics/src/main/java/javafx/scene/PointLight.java line 51: > >> 50: * results in the light's color being subtracted from the material instead of added to it, thus creating a >> 51: * "shadow caster". >> 52: *

> > Can you think of any problems that might arise by supporting negative coefficients? If not, then this seems fine. No, I've tested the functionality and it seemed to be working well. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Tue Jul 28 13:17:29 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 13:17:29 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 21:01:08 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 11 commits: >> - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight >> - Attenuation and range changed internally to floats from doubles >> - Fixed shader compilation errors for 2 and 3 lights in es2 >> - Addressing review comments >> - Fixed whitespaces >> - Correction for indexes >> - Docs and year update >> - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into >> 8217472_Add_attenuation_for_PointLight >> - GL pipeline >> - Separate range from attenuation >> - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/PointLightHelper.java line 2: > >> 1: /* >> 2: * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > Update the "last modified year" for 2020 or else revert (this applies to all copyright year updates). Can the script not get it? ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Tue Jul 28 13:30:56 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 13:30:56 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 21:41:04 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 11 commits: >> - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight >> - Attenuation and range changed internally to floats from doubles >> - Fixed shader compilation errors for 2 and 3 lights in es2 >> - Addressing review comments >> - Fixed whitespaces >> - Correction for indexes >> - Docs and year update >> - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into >> 8217472_Add_attenuation_for_PointLight >> - GL pipeline >> - Separate range from attenuation >> - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed > > High-level comments: > > 1. The API docs look good. If you change the public API to `@since 16` then you can also update the CSR and move it to > the "Submitted" state. 2. I think it would be good to cleanup the performance test and make it part of this PR, maybe > in `tests/performance` (which currently only has the not-very-useful `VMPerformance` subdir) or `tests/manual`. 3. We > need some functional tests, ideally automated ones in `tests/system` > I also left a few inline comments. I haven't reviewed the shaders yet, so I do that, in addition to further testing, > next week. @arapte > I verified it in the compiled D3D shader, that the change reduces one multiplication instruction in most of the shaders. I'd like to know how you did that. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Tue Jul 28 13:48:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Jul 2020 13:48:08 GMT Subject: [jfx15] RFR: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors [v3] In-Reply-To: <5GeK8kqAcm99H3Jo45deQRO1M5gXGtYpXgr9xFFKZLg=.b187238e-5eba-4860-89bd-2b963b6a27ac@github.com> References: <5GeK8kqAcm99H3Jo45deQRO1M5gXGtYpXgr9xFFKZLg=.b187238e-5eba-4860-89bd-2b963b6a27ac@github.com> Message-ID: On Tue, 28 Jul 2020 10:00:37 GMT, Ajit Ghaisas wrote: >> Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 >> Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > add @code tag to class name doc Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/275 From kcr at openjdk.java.net Tue Jul 28 13:49:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Jul 2020 13:49:13 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 13:15:02 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/PointLightHelper.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. >>> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> Update the "last modified year" for 2020 or else revert (this applies to all copyright year updates). > > Can the script not get it? Yes, it can. So it would be fine to leave it. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From aghaisas at openjdk.java.net Tue Jul 28 14:01:28 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 28 Jul 2020 14:01:28 GMT Subject: [jfx15] Integrated: 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 27 Jul 2020 10:07:31 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8249647 > Fix : Added missing explicit no-arg constructors to classes in package javafx.beans.binding in module javafx.base. This pull request has now been integrated. Changeset: fc38ce64 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/fc38ce64 Stats: 116 lines in 21 files changed: 0 ins; 114 del; 2 mod 8249647: Many classes in package javafx.beans.binding in module javafx.base have implicit no-arg constructors Reviewed-by: nlisker, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/275 From ajoseph at openjdk.java.net Tue Jul 28 16:38:28 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 28 Jul 2020 16:38:28 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Mon, 27 Jul 2020 21:16:41 GMT, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 257: > 256: * @param spacing the amount of horizontal space between each child > 257: * @param children The initial set of children for this pane > 258: * @since JavaFX 8.0 Minor typo (The -> the) ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From bchoudhary at openjdk.java.net Tue Jul 28 17:52:50 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 28 Jul 2020 17:52:50 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v7] In-Reply-To: References: Message-ID: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Removed RenderSVGResourceMasker changes and added fix for HIDPI mask rendering ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/312d068a..ef47709f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/213/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.05-06 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From bchoudhary at openjdk.java.net Tue Jul 28 17:52:56 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 28 Jul 2020 17:52:56 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v6] In-Reply-To: <5o-DWzEPwNyJIlglbJhHTdRnHzV2XYMzmGokxTWsCJY=.d79d67e8-e8aa-47e8-83b4-9bca8350ba18@github.com> References: <5ZvCdQhLSzUf-gpbfBj3Cx5ZtJgVZ3xqaL-mgkwnV9k=.ecb8559f-611b-4238-ac0b-f8c42dcb746e@github.com> <5o-DWzEPwNyJIlglbJhHTdRnHzV2XYMzmGokxTWsCJY=.d79d67e8-e8aa-47e8-83b4-9bca8350ba18@github.com> Message-ID: On Fri, 24 Jul 2020 12:10:00 GMT, Arun Joseph wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> HiDPI printing and Rendering fix > > modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp line 93: > >> 92: auto deviceScaleFactor = document().deviceScaleFactor(); >> 93: maskImageContext.applyDeviceScaleFactor(deviceScaleFactor); >> 94: > > For javafx port specific code in WebKit, it should be enclosed in `#if PLATFORM(JAVA)`. But I think that there should > be a better approach as other ports don't require this scaling of `deviceScaleFactor` RenderSVGResourceMasker.cpp changes are removed now. ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From nlisker at openjdk.java.net Tue Jul 28 18:42:46 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 18:42:46 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: > Adds clarifications to the documentation in various places. Some notes: > > * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were > updated to Java 8 only. > * Point 8 has been deferred until all the animation bugs have been resolevd. > * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback > extractor)` method. Later I found that `observableList(List list, Callback extractor)` already > talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. > * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that > this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and > there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality > instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. > I think that in the future we will want to let the user define what a change is (for example, by creating an > overridable method with the current behavior as the default, or using object equality and letting the user override > that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation > `IndentityHashMap` to deal with this ambiguity. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Corrected javadoc generation errors ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/276/files - new: https://git.openjdk.java.net/jfx/pull/276/files/851c64ca..a44bfb18 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/276/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/276/webrev.00-01 Stats: 22 lines in 3 files changed: 2 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/276/head:pull/276 PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Tue Jul 28 18:53:14 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 18:53:14 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v5] In-Reply-To: References: Message-ID: > Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/274/files - new: https://git.openjdk.java.net/jfx/pull/274/files/7bb6ff16..c74c4824 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/274/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/274/webrev.03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/274.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/274/head:pull/274 PR: https://git.openjdk.java.net/jfx/pull/274 From nlisker at openjdk.java.net Tue Jul 28 19:28:43 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 28 Jul 2020 19:28:43 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v6] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with three additional commits since the last revision: - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into 8217472_Add_attenuation_for_PointLight - Addressed review comments - Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/2e1223ed..c5481066 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/43/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/43/webrev.04-05 Stats: 34 lines in 7 files changed: 1 ins; 0 del; 33 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Tue Jul 28 19:47:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Jul 2020 19:47:07 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 18:53:14 GMT, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From github.com+17347324+Torbuntu at openjdk.java.net Wed Jul 29 02:41:50 2020 From: github.com+17347324+Torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Wed, 29 Jul 2020 02:41:50 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 3 Jul 2020 13:49:54 GMT, Kevin Rushforth wrote: >> @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. > >> If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. > > Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. Would it be possible and related to add the gtk touch events to this PR as part of the Glass GTK3 update? Or would follow up update PR adding that be more appropriate? Currently linux desktop does not have touch support because of the missing gesture/touch events from gtk3. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From arapte at openjdk.java.net Wed Jul 29 07:35:08 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 29 Jul 2020 07:35:08 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: <9a30Yn7FkO8u20KEy5aXUgkFUbCd1vbg84CJxiGz4vk=.251fdc40-abde-4368-9516-d6f3bdfc5c16@github.com> On Tue, 28 Jul 2020 13:28:38 GMT, Nir Lisker wrote: > I'd like to know how you did that. Compiled hlsl shader binaries are stored in folder `rt\modules\javafx.graphics\build\headers\PrismD3D\hlsl`. The `fxc` command that generates these files is in `build.gradle`. We can just make a copy and do a text comparison of the generated shader binaries with and without a change. Note: Existing files should to be deleted to generate new ones.(gradle clean is not necessary) ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From arapte at openjdk.java.net Wed Jul 29 08:05:49 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 29 Jul 2020 08:05:49 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 12:44:18 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main3Lights.frag line 92: >> >>> 91: d += clamp(dot(n,l), 0.0, 1.0) * (lights[0].color).rgb * att; >>> 92: s += pow(clamp(dot(-refl, l), 0.0, 1.0), power) * lights[0].color.rgb * att; >>> 93: } >> >> These three lines can be changed as: >> float attenuatedColor = (lights[0].color).rgb / (lights[0].attn.x + lights[0].attn.y * dist + lights[0].attn.z * dist * >> dist); d += clamp(dot(n,l), 0.0, 1.0) * attenuatedColor; >> s += pow(clamp(dot(-refl, l), 0.0, 1.0), power) * attenuatedColor; >> Similar change in the 1 light and 2 lights shader. > > Interesting, I'd think the compiler would have optimized it. The optimizations done by `glCompileShader()` is implementation specific and so little gray area (There may be a way to compare the compiled shaders but I have not investigated on that). But the similar change in hlsl shader is saving one multiplication instruction. So I am assuming that this change might also save just one multiplication instruction. As with this change there is no difference in FPS, it seems trivial. But given it is in fragment shader it is worth saving instructions. I will leave it to you to make a call on this(for both hlsl and glsl). Just that we should keep similar arithmetics in both glsl and hlsl shaders. So either change both or none. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Wed Jul 29 09:19:29 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 29 Jul 2020 09:19:29 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 21:25:06 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 11 commits: >> - Merge branch 'master' into 8217472_Add_attenuation_for_PointLight >> - Attenuation and range changed internally to floats from doubles >> - Fixed shader compilation errors for 2 and 3 lights in es2 >> - Addressing review comments >> - Fixed whitespaces >> - Correction for indexes >> - Docs and year update >> - Merge remote-tracking branch 'nlisker/8217472_Add_attenuation_for_PointLight' into >> 8217472_Add_attenuation_for_PointLight >> - GL pipeline >> - Separate range from attenuation >> - ... and 1 more: https://git.openjdk.java.net/jfx/compare/4ec163df...2e1223ed > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 187: > >> 186: 0, 0, 0, 0, // r g b w >> 187: 1, 0, 0, 0); // ca la qa maxRange >> 188: } > > Minor: maybe use the getDefaultXxxx methods of NGPointLight? The only impact this has is that the range will be maximal instead of 0. When these reach the shader, they will run the lighting computation as opposed to skipping it. I'm not sure if this will have any performance impact though. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From aghaisas at openjdk.java.net Wed Jul 29 09:41:07 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 29 Jul 2020 09:41:07 GMT Subject: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 18:53:14 GMT, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From nlisker at openjdk.java.net Wed Jul 29 09:44:24 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 29 Jul 2020 09:44:24 GMT Subject: [jfx15] Integrated: 8246343: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Sat, 25 Jul 2020 17:16:25 GMT, Nir Lisker wrote: > Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional fixes in the vicinity. This pull request has now been integrated. Changeset: 487854cb Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/487854cb Stats: 40 lines in 6 files changed: 4 ins; 5 del; 31 mod 8246343: Fix mistakes in FX API docs Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/274 From kevin.rushforth at oracle.com Wed Jul 29 12:41:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 29 Jul 2020 05:41:51 -0700 Subject: REMINDER: JavaFX 15 RDP2 starts tomorrow [was: Proposed schedule for JavaFX 15] In-Reply-To: References: Message-ID: <958369a7-3a48-b1e0-a6bf-95dd932bc8e4@oracle.com> As a reminder, RDP2 for JavaFX 15 starts tomorrow, July 30, 2020 at 16:00 UTC (09:00 Pacific time). P1-P2 bugs can still be fixed during RDP2 with explicit approval, although the bar will be appropriately high. Test or doc bugs of any priority can still be fixed without explicit approval (beyond the code review). I'll send details tomorrow once RDP2 starts. -- Kevin On 3/12/2020 10:11 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 15. > > RDP1: Jul 2, 2020 (aka ?feature freeze?) > RDP2: Jul 30, 2020 > Freeze: Aug 20, 2020 > GA: September 8, 2020 > > We plan to fork a jfx15 stabilization branch at RDP1. The GA date is > expected to be one week ahead of JDK 15, matching what we did for 14. > > As a slight change from previous releases, the start of RDP1, the > start of RDP2, and the code freeze will be 16:00 UTC on the respective > dates. > > Please let Johan or me know if you have any questions. > > -- Kevin > From jvos at openjdk.java.net Wed Jul 29 14:43:09 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 29 Jul 2020 14:43:09 GMT Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has focus [v6] In-Reply-To: References: Message-ID: <9k-Dpu3fb31EWLCBwjsPX1WgSKqE04DxfRgipg5LBV0=.630d5319-d600-4a85-83b5-9dfd2c69a8df@github.com> On Thu, 25 Jun 2020 18:20:55 GMT, Abhinay Agarwal wrote: >> In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard. >> Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This >> condition fails in cases where the control already has focus but the keyboard is not visible. Ideally, the keyboard >> should be shown again when the user taps on the TextInputControl. >> This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard if the TextInput control is >> both editable and focused. > > Abhinay Agarwal has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/219 From arapte at openjdk.java.net Wed Jul 29 19:44:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 29 Jul 2020 19:44:39 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 18:42:46 GMT, Nir Lisker wrote: >> Adds clarifications to the documentation in various places. Some notes: >> >> * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were >> updated to Java 8 only. >> * Point 8 has been deferred until all the animation bugs have been resolevd. >> * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback >> extractor)` method. Later I found that `observableList(List list, Callback extractor)` already >> talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. >> * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that >> this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and >> there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality >> instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. >> I think that in the future we will want to let the user define what a change is (for example, by creating an >> overridable method with the current behavior as the default, or using object equality and letting the user override >> that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation >> `IndentityHashMap` to deal with this ambiguity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected javadoc generation errors Changes requested by arapte (Reviewer). modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 310: > 309: /** > 310: * Creates a new empty observable list that is backed by an array list. > 311: * @see #observableList(java.util.List) Can make the similar change on line number 372 as well. modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 321: > 320: /** > 321: * Creates a new empty observable list backed by an array list that listens to changes in observables of its > items. 322: * The {@code extractor} parameter specifies observables (usually properties) of the objects in the > created list. When there is observable list -> `{@code ObservableList}` modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 138: > 137: * @return the text to display in the label > 138: * @defaultValue {@code ""} (empty string} > 139: */ Some other classes use a format like `@defaultValue empty string`. May be the similar pattern should be followed. modules/javafx.graphics/src/main/java/javafx/animation/Timeline.java line 59: > 58: * of Timeline's keyFrames. > 59: *

> 60: * It is not possible to change the {@code keyFrames} of a running {@code Timeline}. Guessing that this `

` is moved down here so that the keyFrame related explanation is continuous. Even the next `

` talks about `keyFrames`, so may be it can be moved further down after next `

` on line 64 ? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 3401: > 3400: *

  • {@link #layoutXProperty layoutX}, {@link #layoutYProperty layoutY} and > 3401: * {@link #translateXProperty translateX}, {@link #translateYProperty translateY}, {@link #translateZProperty > translateZ}
  • 3402: * I think the translate properties should still remain in a separate `
  • `. layout and translate, they together determine the final translation but are different properties. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 5523: > 5522: * Defines the {@code ObservableList} of {@link Transform} objects to be applied to this {@code Node}. The > transforms in this list 5523: * are applied in the reverse order of which they are specified as per matrix > multiplication rules. This list of transforms 5524: * is applied before scaling ({@link #scaleXProperty scaleX}, > {@link #scaleYProperty scaleY} and {@link #scaleZProperty scaleZ}), `The transforms in this list are applied in the reverse order of which they are specified as per matrix multiplication rules` To apply transformations in a specific order their respective matrices should be multiplied in reverse order. So just the order of multiplication is reverse but the transformation are applied in same order as they are added into the `getTransforms()`. I think phrasing it as 'the transforms are applied in reverse order...' would not be accurate and confusing to reader. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 326: > 325: * list. Predefined transforms are applied afterwards in this order: scale, rotation and translation. These are > applied using the 326: * {@link #scaleXProperty scaleX}, {@link #scaleYProperty scaleY}, {@link #scaleZProperty > scaleZ}, {@link #rotateProperty rotate}, 327: * {@link #translateXProperty translateX}, {@link #translateYProperty > translateY} and {@link #translateZProperty translateZ} This block of comment sounds useful to me. It does talk very specifically about the order of transforms in the `getTransforms()` and is correct. How about keeping this block and then continue the new comment from `Custom...` ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From tsayao at openjdk.java.net Wed Jul 29 20:48:27 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 29 Jul 2020 20:48:27 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> On Wed, 29 Jul 2020 02:39:31 GMT, Tor (torbuntu) wrote: >>> If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. >> >> Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. > > Would it be possible and related to add the gtk touch events to this PR as part of the Glass GTK3 update? Or would > follow up update PR adding that be more appropriate? > Currently linux desktop does not have touch support because of the missing gesture/touch events from gtk3. @Torbuntu Not to this PR, I don't want to delay it too much. But can be done (I just do not own a touch device currently). ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+17347324+Torbuntu at openjdk.java.net Wed Jul 29 21:03:59 2020 From: github.com+17347324+Torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Wed, 29 Jul 2020 21:03:59 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> Message-ID: On Wed, 29 Jul 2020 20:46:16 GMT, Thiago Milczarek Sayao wrote: >> Would it be possible and related to add the gtk touch events to this PR as part of the Glass GTK3 update? Or would >> follow up update PR adding that be more appropriate? >> Currently linux desktop does not have touch support because of the missing gesture/touch events from gtk3. > > @Torbuntu Not to this PR, I don't want to delay it too much. But can be done (I just do not own a touch device > currently). Sounds good! I have a few devices I'd be more than excited to test on, and even help add the feature myself if I can figure it out if time is a big issue? ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From nlisker at openjdk.java.net Wed Jul 29 22:15:53 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 29 Jul 2020 22:15:53 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v7] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added performance test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/c5481066..31060231 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/43/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/43/webrev.05-06 Stats: 457 lines in 5 files changed: 457 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Wed Jul 29 22:41:42 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 29 Jul 2020 22:41:42 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v8] In-Reply-To: References: Message-ID: <09Jm6GZfhCpelTeYAkZTFSqD3qnmR250httZvGtb6nU=.e4cb859a-7737-475d-a773-3001300763b4@github.com> > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespaces ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/31060231..d77204aa Webrevs: - full: https://webrevs.openjdk.java.net/jfx/43/webrev.07 - incr: https://webrevs.openjdk.java.net/jfx/43/webrev.06-07 Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Wed Jul 29 23:09:52 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 29 Jul 2020 23:09:52 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v9] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/d77204aa..e20f8a48 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/43/webrev.08 - incr: https://webrevs.openjdk.java.net/jfx/43/webrev.07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From stevenyi at gmail.com Wed Jul 29 23:28:50 2020 From: stevenyi at gmail.com (Steven Yi) Date: Wed, 29 Jul 2020 19:28:50 -0400 Subject: Deadlock: JFXPanel, ContextMenu, macOS Message-ID: Hi All, I'm not sure if this is the place to report this, but hopefully so. (I did not see a way to create an account or report issues on JBS.) I am using JavaFX embedded within a Swing application and had found intermittent deadlocks on macOS that I wasn't sure why it was happening. I was finally able to create a minimal working example and have published it here: https://github.com/kunstmusik/ContextMenuHangingTest The switching applications seems to be a key to getting the deadlock to happen. Testing with debugger in Netbeans, when the app freezes, I paused the app and saw this in the Java FX Application Thread stack: "JavaFX Application Thread" at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) at sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) at sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) at com.sun.glass.ui.Window.setView(Window.java:416) at com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get at com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) at com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) at javafx.stage.Window$12.invalidated(Window.java:1085) at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) at javafx.stage.Window.setShowing(Window.java:1174) at javafx.stage.Window.show(Window.java:1189) at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) at javafx.stage.PopupWindow.show(PopupWindow.java:417) at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) at com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) at com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) at javafx.event.Event.fireEvent(Event.java:198) at javafx.scene.Node.fireEvent(Node.java:8885) at javafx.scene.control.Button.fire(Button.java:203) at com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) at com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle at com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) at com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle at com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.event.Event.fireEvent(Event.java:198) at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) at javafx.scene.Scene.processMouseEvent(Scene.java:1885) at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) at com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run at java.security.AccessController.doPrivileged(AccessController.java) at com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) at com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run at java.security.AccessController.doPrivileged(AccessController.java) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) at com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) Any help would be very much appreciated. Thanks, Steven From nlisker at openjdk.java.net Thu Jul 30 00:01:30 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 30 Jul 2020 00:01:30 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v10] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Moved test folder ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/e20f8a48..3ab051d2 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/43/webrev.09 - incr: https://webrevs.openjdk.java.net/jfx/43/webrev.08-09 Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Thu Jul 30 00:01:30 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 30 Jul 2020 00:01:30 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 21:41:04 GMT, Kevin Rushforth wrote: > 1. The API docs look good. If you change the public API to `@since 16` then you can also update the CSR and move it to > the "Submitted" state. I moved it to the PROPOSED state. > 2. I think it would be good to cleanup the performance test and make it part of this PR, maybe in `tests/performance` > (which currently only has the not-very-useful `VMPerformance` subdir) or `tests/manual`. I added it under `tests/performance`. > 3. We need some functional tests, ideally automated ones in `tests/system` What should this test do? Which example should I follow? By the way, The `tests` project is broken in Eclipse because several source folders, like `tests\system\src\testapp6`, define their own `module-info.java`, and it's illegal in Eclipse to have several of these in a project. To have the tests there compile, the Eclipse files will need to be updated. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From nlisker at openjdk.java.net Thu Jul 30 00:46:26 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 30 Jul 2020 00:46:26 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors Message-ID: This was missed the in Javadoc fixes for 15. Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. ------------- Commit messages: - Initial commit of 8250799 Changes: https://git.openjdk.java.net/jfx/pull/277/files Webrev: https://webrevs.openjdk.java.net/jfx/277/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250799 Stats: 67 lines in 3 files changed: 46 ins; 11 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/277.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/277/head:pull/277 PR: https://git.openjdk.java.net/jfx/pull/277 From arapte at openjdk.java.net Thu Jul 30 07:01:22 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 30 Jul 2020 07:01:22 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v3] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Thu, 23 Jul 2020 17:57:34 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: >> >> - revert unintended line deletion >> - changes to address to review > > Once the merge conflicts and review comments are addressed, I'll put this back on my review queue. Please review the updated change: 1. Changed the approach to add a property named `removeKeyMappingsForComboBoxEditor` to ListView when creating it from ComboBox. Please do suggest if this name sounds Ok. 2. When this property is present some KeyMappings that are needed for ComboBox Editor get removed from `ListViewBehavior`. 3. I have considered to remove some more KeyMappings which seem like they should be passed on to ComboBox's Editor.(method `removeKeyMappingsForComboBoxEditor()`) 4. There is an existing issue with `BehaviorBase`: [JDK-8250807](https://bugs.openjdk.java.net/browse/JDK-8250807). Due to this issue, KeyMappings from child `InputMap` do not get removed. So the keys CTRL+SHIFT+HOME and CTRL+SHIFT+END will still not work with ComboBox editor. 5. Updated ComboBoxTest for additional keys. 6. Keeping the tests added for ListView, as they seem reasonable and not present already. Change is very specific to ComboBox editor, so it should not affect any other tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Thu Jul 30 07:01:21 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 30 Jul 2020 07:01:21 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v3] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: - revert unintended line deletion - changes to address to review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/f0c94d60..7f528241 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/172/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/172/webrev.01-02 Stats: 177 lines in 6 files changed: 103 ins; 44 del; 30 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From mp at jugs.org Thu Jul 30 07:24:26 2020 From: mp at jugs.org (Michael Paus) Date: Thu, 30 Jul 2020 09:24:26 +0200 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: References: Message-ID: <21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org> Hi Steven, the right place for bug reports like this is here: Michael Am 30.07.20 um 01:28 schrieb Steven Yi: > Hi All, > > I'm not sure if this is the place to report this, but hopefully so. (I did > not see a way to create an account or report issues on JBS.) > > I am using JavaFX embedded within a Swing application and had found > intermittent deadlocks on macOS that I wasn't sure why it was happening. I > was finally able to create a minimal working example and have published it > here: > > https://github.com/kunstmusik/ContextMenuHangingTest > > The switching applications seems to be a key to getting the deadlock to > happen. Testing with debugger in Netbeans, when the app freezes, I paused > the app and saw this in the Java FX Application Thread stack: > > "JavaFX Application Thread" > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > at sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > at sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > at com.sun.glass.ui.Window.setView(Window.java:416) > at > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > at > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > at com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > at javafx.stage.Window$12.invalidated(Window.java:1085) > at > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > at > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at javafx.stage.Window.setShowing(Window.java:1174) > at javafx.stage.Window.show(Window.java:1189) > at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > at javafx.stage.PopupWindow.show(PopupWindow.java:417) > at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > at > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > at > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > at > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > at > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > at > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > at > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > at javafx.event.Event.fireEvent(Event.java:198) > at javafx.scene.Node.fireEvent(Node.java:8885) > at javafx.scene.control.Button.fire(Button.java:203) > at > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > at > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > at com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > at > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > at > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > at > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > at > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > at > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > at > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > at > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > at javafx.event.Event.fireEvent(Event.java:198) > at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > at > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > at java.security.AccessController.doPrivileged(AccessController.java) > at > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > at com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > at java.security.AccessController.doPrivileged(AccessController.java) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > at com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > Any help would be very much appreciated. > > Thanks, > Steven From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Jul 30 08:37:11 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 30 Jul 2020 08:37:11 GMT Subject: Integrated: 8245053: Keyboard doesn't show when TextInputControl has focus In-Reply-To: References: Message-ID: <2ZuCWIWCyiVnMLTQHSW3sZfRSk1FNWrCd514IFoXtao=.4f771e32-69c1-4ebc-97c4-f133e5577e20@github.com> On Thu, 14 May 2020 19:22:54 GMT, Abhinay Agarwal wrote: > In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard. > Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This > condition fails in cases where the control already has focus but the keyboard is not visible. Ideally, the keyboard > should be shown again when the user taps on the TextInputControl. > This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard if the TextInput control is > both editable and focused. This pull request has now been integrated. Changeset: 5d34d724 Author: Abhinay Agarwal Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/5d34d724 Stats: 93 lines in 2 files changed: 6 ins; 63 del; 24 mod 8245053: Keyboard doesn't show when TextInputControl has focus Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/219 From nlisker at openjdk.java.net Thu Jul 30 12:00:04 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 30 Jul 2020 12:00:04 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v2] In-Reply-To: References: Message-ID: > This was missed the in Javadoc fixes for 15. > > Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added note on immutability ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/277/files - new: https://git.openjdk.java.net/jfx/pull/277/files/5e7274ab..72c0b00d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/277/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/277/webrev.00-01 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/277.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/277/head:pull/277 PR: https://git.openjdk.java.net/jfx/pull/277 From stevenyi at gmail.com Thu Jul 30 13:46:25 2020 From: stevenyi at gmail.com (Steven Yi) Date: Thu, 30 Jul 2020 09:46:25 -0400 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: <21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org> References: <21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org> Message-ID: Hi Michael, Thanks for the link, I missed that when I went to explore JBS. I'll report the issue there. All best, Steven On Thu, Jul 30, 2020 at 3:25 AM Michael Paus wrote: > Hi Steven, > the right place for bug reports like this is here: > > Michael > > Am 30.07.20 um 01:28 schrieb Steven Yi: > > Hi All, > > > > I'm not sure if this is the place to report this, but hopefully so. (I > did > > not see a way to create an account or report issues on JBS.) > > > > I am using JavaFX embedded within a Swing application and had found > > intermittent deadlocks on macOS that I wasn't sure why it was happening. > I > > was finally able to create a minimal working example and have published > it > > here: > > > > https://github.com/kunstmusik/ContextMenuHangingTest > > > > The switching applications seems to be a key to getting the deadlock to > > happen. Testing with debugger in Netbeans, when the app freezes, I paused > > the app and saw this in the Java FX Application Thread stack: > > > > "JavaFX Application Thread" > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > > at sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > > at sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > > at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > > at com.sun.glass.ui.Window.setView(Window.java:416) > > at > > > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > > at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > > at > > > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > > at com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > > at javafx.stage.Window$12.invalidated(Window.java:1085) > > at > > > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > > at > > > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > > at javafx.stage.Window.setShowing(Window.java:1174) > > at javafx.stage.Window.show(Window.java:1189) > > at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > > at javafx.stage.PopupWindow.show(PopupWindow.java:417) > > at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > > at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > > at > > > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > > at > > > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > > at > > > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > > at > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > at > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > at > > > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > at > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > at > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > at > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > at > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > at > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > at > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > > at javafx.event.Event.fireEvent(Event.java:198) > > at javafx.scene.Node.fireEvent(Node.java:8885) > > at javafx.scene.control.Button.fire(Button.java:203) > > at > > > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > > at > > > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > > at > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > > at > > > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > > at > > > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > > at > > > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > > at > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > at > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > at > > > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > at > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > at > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > at > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > at > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > at > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > at > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > > at javafx.event.Event.fireEvent(Event.java:198) > > at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > > at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > > at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > > at > > > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > > at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > > at java.security.AccessController.doPrivileged(AccessController.java) > > at > > > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > > at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > > at > > > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > > at com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > > at java.security.AccessController.doPrivileged(AccessController.java) > > at > > > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > > at com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > > at > > > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > > Any help would be very much appreciated. > > > > Thanks, > > Steven > > > From kevin.rushforth at oracle.com Thu Jul 30 14:57:20 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Jul 2020 07:57:20 -0700 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: References: <21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org> Message-ID: If you can provide a small, standalone test case as part of the bug report, that would be ideal. Thanks. -- Kevin On 7/30/2020 6:46 AM, Steven Yi wrote: > Hi Michael, > > Thanks for the link, I missed that when I went to explore JBS. I'll report > the issue there. > > All best, > Steven > > > On Thu, Jul 30, 2020 at 3:25 AM Michael Paus wrote: > >> Hi Steven, >> the right place for bug reports like this is here: >> >> Michael >> >> Am 30.07.20 um 01:28 schrieb Steven Yi: >>> Hi All, >>> >>> I'm not sure if this is the place to report this, but hopefully so. (I >> did >>> not see a way to create an account or report issues on JBS.) >>> >>> I am using JavaFX embedded within a Swing application and had found >>> intermittent deadlocks on macOS that I wasn't sure why it was happening. >> I >>> was finally able to create a minimal working example and have published >> it >>> here: >>> >>> https://github.com/kunstmusik/ContextMenuHangingTest >>> >>> The switching applications seems to be a key to getting the deadlock to >>> happen. Testing with debugger in Netbeans, when the app freezes, I paused >>> the app and saw this in the Java FX Application Thread stack: >>> >>> "JavaFX Application Thread" >>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) >>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) >>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) >>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) >>> at sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) >>> at sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) >>> at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) >>> at com.sun.glass.ui.Window.setView(Window.java:416) >>> at >>> >> com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) >>> at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get >>> at >>> >> com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) >>> at com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) >>> at javafx.stage.Window$12.invalidated(Window.java:1085) >>> at >>> >> javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >>> at >>> >> javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>> at javafx.stage.Window.setShowing(Window.java:1174) >>> at javafx.stage.Window.show(Window.java:1189) >>> at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) >>> at javafx.stage.PopupWindow.show(PopupWindow.java:417) >>> at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) >>> at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) >>> at >>> >> com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) >>> at >>> >> com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle >>> at >>> >> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) >>> at >>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) >>> at >>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) >>> at >>> >> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) >>> at >>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) >>> at >>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> at >>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> at >>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> at >>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> at >>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) >>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) >>> at javafx.event.Event.fireEvent(Event.java:198) >>> at javafx.scene.Node.fireEvent(Node.java:8885) >>> at javafx.scene.control.Button.fire(Button.java:203) >>> at >>> >> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) >>> at >>> >> com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle >>> at >> com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) >>> at >>> >> com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle >>> at >>> >> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) >>> at >>> >> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) >>> at >>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) >>> at >>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) >>> at >>> >> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) >>> at >>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) >>> at >>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> at >>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> at >>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> at >>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> at >>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) >>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) >>> at javafx.event.Event.fireEvent(Event.java:198) >>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) >>> at javafx.scene.Scene.processMouseEvent(Scene.java:1885) >>> at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) >>> at >>> >> com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) >>> at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run >>> at java.security.AccessController.doPrivileged(AccessController.java) >>> at >>> >> com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) >>> at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run >>> at >>> >> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) >>> at com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run >>> at java.security.AccessController.doPrivileged(AccessController.java) >>> at >>> >> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) >>> at com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run >>> at >>> >> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >>> Any help would be very much appreciated. >>> >>> Thanks, >>> Steven >> >> From stevenyi at gmail.com Thu Jul 30 15:45:31 2020 From: stevenyi at gmail.com (Steven Yi) Date: Thu, 30 Jul 2020 11:45:31 -0400 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: References: <21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org> Message-ID: Hi Kevin, I pasted in the minimal reproducible example with the issue I filed as well as a link to the github repo; I hope the everything is in order. Thanks, Steven On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth wrote: > If you can provide a small, standalone test case as part of the bug > report, that would be ideal. > > Thanks. > > -- Kevin > > > On 7/30/2020 6:46 AM, Steven Yi wrote: > > Hi Michael, > > > > Thanks for the link, I missed that when I went to explore JBS. I'll > report > > the issue there. > > > > All best, > > Steven > > > > > > On Thu, Jul 30, 2020 at 3:25 AM Michael Paus wrote: > > > >> Hi Steven, > >> the right place for bug reports like this is here: > >> > >> Michael > >> > >> Am 30.07.20 um 01:28 schrieb Steven Yi: > >>> Hi All, > >>> > >>> I'm not sure if this is the place to report this, but hopefully so. (I > >> did > >>> not see a way to create an account or report issues on JBS.) > >>> > >>> I am using JavaFX embedded within a Swing application and had found > >>> intermittent deadlocks on macOS that I wasn't sure why it was > happening. > >> I > >>> was finally able to create a minimal working example and have published > >> it > >>> here: > >>> > >>> https://github.com/kunstmusik/ContextMenuHangingTest > >>> > >>> The switching applications seems to be a key to getting the deadlock to > >>> happen. Testing with debugger in Netbeans, when the app freezes, I > paused > >>> the app and saw this in the Java FX Application Thread stack: > >>> > >>> "JavaFX Application Thread" > >>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > >>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > >>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > >>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > >>> at > sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > >>> at > sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > >>> at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > >>> at com.sun.glass.ui.Window.setView(Window.java:416) > >>> at > >>> > >> > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > >>> at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > >>> at > >>> > >> > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > >>> at com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > >>> at javafx.stage.Window$12.invalidated(Window.java:1085) > >>> at > >>> > >> > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > >>> at > >>> > >> > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > >>> at javafx.stage.Window.setShowing(Window.java:1174) > >>> at javafx.stage.Window.show(Window.java:1189) > >>> at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > >>> at javafx.stage.PopupWindow.show(PopupWindow.java:417) > >>> at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > >>> at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > >>> at > >>> > >> > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > >>> at > >>> > >> > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > >>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > >>> at javafx.event.Event.fireEvent(Event.java:198) > >>> at javafx.scene.Node.fireEvent(Node.java:8885) > >>> at javafx.scene.control.Button.fire(Button.java:203) > >>> at > >>> > >> > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > >>> at > >>> > >> > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > >>> at > >> com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > >>> at > >>> > >> > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > >>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > >>> at javafx.event.Event.fireEvent(Event.java:198) > >>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > >>> at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > >>> at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > >>> at > >>> > >> > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > >>> at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > >>> at java.security.AccessController.doPrivileged(AccessController.java) > >>> at > >>> > >> > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > >>> at com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > >>> at > >>> > >> > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > >>> at com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > >>> at java.security.AccessController.doPrivileged(AccessController.java) > >>> at > >>> > >> > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > >>> at com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > >>> at > >>> > >> > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > >>> Any help would be very much appreciated. > >>> > >>> Thanks, > >>> Steven > >> > >> > > From kevin.rushforth at oracle.com Thu Jul 30 15:54:47 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Jul 2020 08:54:47 -0700 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: References: <21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org> Message-ID: <4831d1fa-3774-0d96-98b2-4bec45e4b9ca@oracle.com> Thanks, I'll take a look at it and let you know if we need anything else. -- Kevin On 7/30/2020 8:45 AM, Steven Yi wrote: > Hi Kevin, > > I pasted in the minimal reproducible example with the issue I filed as > well as a link to the github repo; I hope the everything is in order. > > Thanks, > Steven > > > On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth > > wrote: > > If you can provide a small, standalone test case as part of the bug > report, that would be ideal. > > Thanks. > > -- Kevin > > > On 7/30/2020 6:46 AM, Steven Yi wrote: > > Hi Michael, > > > > Thanks for the link, I missed that when I went to explore JBS. > I'll report > > the issue there. > > > > All best, > > Steven > > > > > > On Thu, Jul 30, 2020 at 3:25 AM Michael Paus > wrote: > > > >> Hi Steven, > >> the right place for bug reports like this is here: > >> > >> Michael > >> > >> Am 30.07.20 um 01:28 schrieb Steven Yi: > >>> Hi All, > >>> > >>> I'm not sure if this is the place to report this, but > hopefully so. (I > >> did > >>> not see a way to create an account or report issues on JBS.) > >>> > >>> I am using JavaFX embedded within a Swing application and had > found > >>> intermittent deadlocks on macOS that I wasn't sure why it was > happening. > >> I > >>> was finally able to create a minimal working example and have > published > >> it > >>> here: > >>> > >>> https://github.com/kunstmusik/ContextMenuHangingTest > >>> > >>> The switching applications seems to be a key to getting the > deadlock to > >>> happen. Testing with debugger in Netbeans, when the app > freezes, I paused > >>> the app and saw this in the Java FX Application Thread stack: > >>> > >>> "JavaFX Application Thread" > >>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > >>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > >>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > >>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > >>> at > sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > >>> at > sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > >>> at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > >>> at com.sun.glass.ui.Window.setView(Window.java:416) > >>> at > >>> > >> > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > >>> at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > >>> at > >>> > >> > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > >>> at > com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > >>> at javafx.stage.Window$12.invalidated(Window.java:1085) > >>> at > >>> > >> > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > >>> at > >>> > >> > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > >>> at javafx.stage.Window.setShowing(Window.java:1174) > >>> at javafx.stage.Window.show(Window.java:1189) > >>> at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > >>> at javafx.stage.PopupWindow.show(PopupWindow.java:417) > >>> at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > >>> at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > >>> at > >>> > >> > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > >>> at > >>> > >> > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > >>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > >>> at javafx.event.Event.fireEvent(Event.java:198) > >>> at javafx.scene.Node.fireEvent(Node.java:8885) > >>> at javafx.scene.control.Button.fire(Button.java:203) > >>> at > >>> > >> > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > >>> at > >>> > >> > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > >>> at > >> > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > >>> at > >>> > >> > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > >>> at > >>> > >> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > >>> at > >>> > >> > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at > >>> > >> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > >>> at > >>> > >> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > >>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > >>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > >>> at javafx.event.Event.fireEvent(Event.java:198) > >>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > >>> at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > >>> at > javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > >>> at > >>> > >> > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > >>> at > com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > >>> at > java.security.AccessController.doPrivileged(AccessController.java) > >>> at > >>> > >> > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > >>> at > com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > >>> at > >>> > >> > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > >>> at > com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > >>> at > java.security.AccessController.doPrivileged(AccessController.java) > >>> at > >>> > >> > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > >>> at > com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > >>> at > >>> > >> > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > >>> Any help would be very much appreciated. > >>> > >>> Thanks, > >>> Steven > >> > >> > From kevin.rushforth at oracle.com Thu Jul 30 16:07:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Jul 2020 09:07:51 -0700 Subject: JavaFX 15 is in Rampdown Phase Two (RDP2) Message-ID: <97c876d3-909a-6fd7-7166-4d864f87f286@oracle.com> To: OpenJFX Developers As a reminder, JavaFX 15 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bugs, and test or doc bugs of any priority, can be fixed during RDP2. Explicit approval is needed for bug fixes (except for doc and test fixes), and all enhancements to go in to the jfx15 branch. 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 15 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx15-fix-request", "openjfx15-fix-yes", "openjfx15-fix-no" and "openjfx15-fix-nmi", "openjfx15-enhancement-request", "openjfx15-enhancement-yes", "openjfx15-enhancement-no" and "openjfx15-enhancement-nmi" as corresponding labels. Note that if a fix is approved to integrate into jfx15 (with the appropriate approval label added by a lead), then the PR should be targeted to the jfx15 branch. There is no need to also create a separate PR to integrate it into master -- we will continue to periodically sync jfx15 --> master for the duration of the openjfx15 release. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in openjfx15. We need to be extremely careful about including anything that introduces risk. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 16 as of today). This is usually what we want. A PR should be targeted to `jfx15` if, and only if, it is intended for OpenJFX 15 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx15`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 16. Reviewers also need to be extra careful when reviewing PRs targeted to jfx15 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-March/025410.html [2] http://openjdk.java.net/jeps/3 From nlisker at openjdk.java.net Thu Jul 30 16:42:00 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 30 Jul 2020 16:42:00 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v3] In-Reply-To: References: Message-ID: > This was missed the in Javadoc fixes for 15. > > Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Corrected NumberFormat constructor text ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/277/files - new: https://git.openjdk.java.net/jfx/pull/277/files/72c0b00d..8f19315b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/277/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/277/webrev.01-02 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/277.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/277/head:pull/277 PR: https://git.openjdk.java.net/jfx/pull/277 From ebresie at gmail.com Fri Jul 31 12:16:07 2020 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 31 Jul 2020 07:16:07 -0500 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: 4831d1fa-3774-0d96-98b2-4bec45e4b9ca@oracle.com References: CANtcCs6WtwPuFQq6ny9j5gOxfPe9dhmcg1wrOPJkvT7twXTKdw@mail.gmail.com 21deba7f-d6cf-a29e-b03a-850142be1dd3@jugs.org CANtcCs7pbDN9YPrPitmX+VZO7JEp7b0dnGd9QjT8MGpuX5d-oA@mail.gmail.com bb2f604b-ed35-24eb-2827-232b72efae4e@oracle.com CANtcCs6MHPrRVGc6koPGBTUGobmcpM2FE7gn_ogGmDsCrD7UzA@mail.gmail.com CANtcCs6MHPrRVGc6koPGBTUGobmcpM2FE7gn_ogGmDsCrD7UzA@mail.gmail.com Message-ID: <98f62a62-3b62-418b-8075-411bdde43073@iPad> What was the ticket? Eric Bresie Ebresie at gmail.com > On July 30, 2020 at 10:54:47 AM CDT, Kevin Rushforth wrote: > Thanks, I'll take a look at it and let you know if we need anything else. > > -- Kevin > > > On 7/30/2020 8:45 AM, Steven Yi wrote: > > Hi Kevin, > > > > I pasted in the minimal reproducible example with the issue I filed as > > well as a link to the github repo; I hope the everything is in order. > > > > Thanks, > > Steven > > > > > > On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth > > > wrote: > > > > If you can provide a small, standalone test case as part of the bug > > report, that would be ideal. > > > > Thanks. > > > > -- Kevin > > > > > > On 7/30/2020 6:46 AM, Steven Yi wrote: > > > Hi Michael, > > > > > > Thanks for the link, I missed that when I went to explore JBS. > > I'll report > > > the issue there. > > > > > > All best, > > > Steven > > > > > > > > > On Thu, Jul 30, 2020 at 3:25 AM Michael Paus > > wrote: > > > > > > > Hi Steven, > > > > the right place for bug reports like this is here: > > > > > > > > Michael > > > > > > > > Am 30.07.20 um 01:28 schrieb Steven Yi: > > > > > Hi All, > > > > > > > > > > I'm not sure if this is the place to report this, but > > hopefully so. (I > > > > did > > > > > not see a way to create an account or report issues on JBS.) > > > > > > > > > > I am using JavaFX embedded within a Swing application and had > > found > > > > > intermittent deadlocks on macOS that I wasn't sure why it was > > happening. > > > > I > > > > > was finally able to create a minimal working example and have > > published > > > > it > > > > > here: > > > > > > > > > > https://github.com/kunstmusik/ContextMenuHangingTest > > > > > > > > > > The switching applications seems to be a key to getting the > > deadlock to > > > > > happen. Testing with debugger in Netbeans, when the app > > freezes, I paused > > > > > the app and saw this in the Java FX Application Thread stack: > > > > > > > > > > "JavaFX Application Thread" > > > > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > > > > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > > > > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > > > > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > > > > > at > > sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > > > > > at > > sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > > > > > at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > > > > > at com.sun.glass.ui.Window.setView(Window.java:416) > > > > > at > > > > > > > > > > > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > > > > > at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > > > > > at > > > > > > > > > > > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > > > > > at > > com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > > > > > at javafx.stage.Window$12.invalidated(Window.java:1085) > > > > > at > > > > > > > > > > > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > > > > > at > > > > > > > > > > > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > > > > > at javafx.stage.Window.setShowing(Window.java:1174) > > > > > at javafx.stage.Window.show(Window.java:1189) > > > > > at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > > > > > at javafx.stage.PopupWindow.show(PopupWindow.java:417) > > > > > at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > > > > > at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > > > > > at > > > > > > > > > > > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > > > > > at > > > > > > > > > > > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > > > > > at > > > > > > > > > > > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > > > > at > > > > > > > > > > > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > > > > at > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > at > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > at > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > > > > > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > > > > > at javafx.event.Event.fireEvent(Event.java:198) > > > > > at javafx.scene.Node.fireEvent(Node.java:8885) > > > > > at javafx.scene.control.Button.fire(Button.java:203) > > > > > at > > > > > > > > > > > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > > > > > at > > > > > > > > > > > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > > > > > at > > > > > > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > > > > > at > > > > > > > > > > > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > > > > > at > > > > > > > > > > > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > > > > > at > > > > > > > > > > > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > > > > at > > > > > > > > > > > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > > > > at > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > at > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > at > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > at > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > > > > > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > > > > > at javafx.event.Event.fireEvent(Event.java:198) > > > > > at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > > > > > at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > > > > > at > > javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > > > > > at > > > > > > > > > > > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > > > > > at > > com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > > > > > at > > java.security.AccessController.doPrivileged(AccessController.java) > > > > > at > > > > > > > > > > > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > > > > > at > > com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > > > > > at > > > > > > > > > > > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > > > > > at > > com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > > > > > at > > java.security.AccessController.doPrivileged(AccessController.java) > > > > > at > > > > > > > > > > > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > > > > > at > > com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > > > > > at > > > > > > > > > > > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > > > Any help would be very much appreciated. > > > > > > > > > > Thanks, > > > > > Steven > > > > > > > > > > > From stevenyi at gmail.com Fri Jul 31 15:48:29 2020 From: stevenyi at gmail.com (Steven Yi) Date: Fri, 31 Jul 2020 11:48:29 -0400 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: <98f62a62-3b62-418b-8075-411bdde43073@iPad> References: <98f62a62-3b62-418b-8075-411bdde43073@iPad> Message-ID: I haven't seen a bug posted to the system so I suppose it is still under review. When I submitted it, I got an automated response that there was an internal review ID of 9066237 if that is of use to anyone. On Fri, Jul 31, 2020 at 8:16 AM Eric Bresie wrote: > What was the ticket? > > Eric Bresie > Ebresie at gmail.com > > On July 30, 2020 at 10:54:47 AM CDT, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > Thanks, I'll take a look at it and let you know if we need anything else. > > > > -- Kevin > > > > > > On 7/30/2020 8:45 AM, Steven Yi wrote: > > > Hi Kevin, > > > > > > I pasted in the minimal reproducible example with the issue I filed as > > > well as a link to the github repo; I hope the everything is in order. > > > > > > Thanks, > > > Steven > > > > > > > > > On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth > > > > > wrote: > > > > > > If you can provide a small, standalone test case as part of the bug > > > report, that would be ideal. > > > > > > Thanks. > > > > > > -- Kevin > > > > > > > > > On 7/30/2020 6:46 AM, Steven Yi wrote: > > > > Hi Michael, > > > > > > > > Thanks for the link, I missed that when I went to explore JBS. > > > I'll report > > > > the issue there. > > > > > > > > All best, > > > > Steven > > > > > > > > > > > > On Thu, Jul 30, 2020 at 3:25 AM Michael Paus > > > wrote: > > > > > > > > > Hi Steven, > > > > > the right place for bug reports like this is here: > > > > > > > > > > Michael > > > > > > > > > > Am 30.07.20 um 01:28 schrieb Steven Yi: > > > > > > Hi All, > > > > > > > > > > > > I'm not sure if this is the place to report this, but > > > hopefully so. (I > > > > > did > > > > > > not see a way to create an account or report issues on JBS.) > > > > > > > > > > > > I am using JavaFX embedded within a Swing application and had > > > found > > > > > > intermittent deadlocks on macOS that I wasn't sure why it was > > > happening. > > > > > I > > > > > > was finally able to create a minimal working example and have > > > published > > > > > it > > > > > > here: > > > > > > > > > > > > https://github.com/kunstmusik/ContextMenuHangingTest > > > > > > > > > > > > The switching applications seems to be a key to getting the > > > deadlock to > > > > > > happen. Testing with debugger in Netbeans, when the app > > > freezes, I paused > > > > > > the app and saw this in the Java FX Application Thread stack: > > > > > > > > > > > > "JavaFX Application Thread" > > > > > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > > > > > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > > > > > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > > > > > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > > > > > > at > > > sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > > > > > > at > > > sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > > > > > > at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > > > > > > at com.sun.glass.ui.Window.setView(Window.java:416) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > > > > > > at > com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > > > > > > at > > > com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > > > > > > at javafx.stage.Window$12.invalidated(Window.java:1085) > > > > > > at > > > > > > > > > > > > > > > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > > > > > > at > > > > > > > > > > > > > > > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > > > > > > at javafx.stage.Window.setShowing(Window.java:1174) > > > > > > at javafx.stage.Window.show(Window.java:1189) > > > > > > at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > > > > > > at javafx.stage.PopupWindow.show(PopupWindow.java:417) > > > > > > at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > > > > > > at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > > > > > > at > > > > > > > > > > > > > > > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > > > > > > at > > > > > > > > > > > > > > > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > > at > com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > > > > > > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > > > > > > at javafx.event.Event.fireEvent(Event.java:198) > > > > > > at javafx.scene.Node.fireEvent(Node.java:8885) > > > > > > at javafx.scene.control.Button.fire(Button.java:203) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > > > > > > at > > > > > > > > > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > > > > > at > com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > > > > > > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > > > > > > at javafx.event.Event.fireEvent(Event.java:198) > > > > > > at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > > > > > > at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > > > > > > at > > > javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > > > > > > at > > > com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > > > > > > at > > > java.security.AccessController.doPrivileged(AccessController.java) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > > > > > > at > > > com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > > > > > > at > > > com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > > > > > > at > > > java.security.AccessController.doPrivileged(AccessController.java) > > > > > > at > > > > > > > > > > > > > > > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > > > > > > at > > > com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > > > > > > at > > > > > > > > > > > > > > > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > > > > Any help would be very much appreciated. > > > > > > > > > > > > Thanks, > > > > > > Steven > > > > > > > > > > > > > > > > From perini.davide at dpsoftware.org Fri Jul 31 21:07:33 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 31 Jul 2020 23:07:33 +0200 Subject: Tray Icon? Message-ID: Hi all guys, love JavaFX, it's so productive, so easy to use, can't understand why the world don't use it "for some tasks". I know that tray icon can be easily done with AWT but is there something for JavaFX? Is it possible to create a tray icon with JavaFX? Thanks Davide From mp at jugs.org Fri Jul 31 22:01:03 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 1 Aug 2020 00:01:03 +0200 Subject: Tray Icon? In-Reply-To: References: Message-ID: <79cb98be-4a07-c789-da15-984f16fed21e@jugs.org> You can add such an icon to your JavaFX app if you bundle it with the jpackage tool distributed with JDK 14+ Am 31.07.20 um 23:07 schrieb Davide Perini: > Hi all guys, > love JavaFX, it's so productive, so easy to use, can't understand why > the world don't use it "for some tasks". > > I know that tray icon can be easily done with AWT but is there > something for JavaFX? > Is it possible to create a tray icon with JavaFX? > > Thanks > Davide From swpalmer at gmail.com Fri Jul 31 23:34:08 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 31 Jul 2020 19:34:08 -0400 Subject: Tray Icon? In-Reply-To: <79cb98be-4a07-c789-da15-984f16fed21e@jugs.org> References: <79cb98be-4a07-c789-da15-984f16fed21e@jugs.org> Message-ID: No you can?t. System tray support is something else, not an application icon in the start bar or doc. Scott > On Jul 31, 2020, at 6:02 PM, Michael Paus wrote: > > ?You can add such an icon to your JavaFX app if you bundle it with the jpackage tool distributed with JDK 14+ > >> Am 31.07.20 um 23:07 schrieb Davide Perini: >> Hi all guys, >> love JavaFX, it's so productive, so easy to use, can't understand why the world don't use it "for some tasks". >> >> I know that tray icon can be easily done with AWT but is there something for JavaFX? >> Is it possible to create a tray icon with JavaFX? >> >> Thanks >> Davide > > > From swpalmer at gmail.com Fri Jul 31 23:45:28 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 31 Jul 2020 19:45:28 -0400 Subject: Tray Icon? In-Reply-To: References: Message-ID: <91261036-D07C-4034-96E3-AAF77BD44930@gmail.com> I should also point out that this shortcoming was identified nearly 9 years ago. https://bugs.openjdk.java.net/browse/JDK-8092115 I would love to make some progress on this, but I think doing it right is a bigger job than ?outsiders? can tackle. Ideally most of the desktop APIs should be supported by JavaFX without AWT/Swing. I think that requires some careful thought. Some of the code should be independent of the UI toolkit and it could be shared between the AWT and JavaFX implementations. In a modular JRE we shouldn?t need the Swing modules to have a system tray icon in a JavaFX app. Scott > On Jul 31, 2020, at 7:34 PM, Scott Palmer wrote: > > ? No you can?t. System tray support is something else, not an application icon in the start bar or doc. > > Scott > >> On Jul 31, 2020, at 6:02 PM, Michael Paus wrote: >> >> ?You can add such an icon to your JavaFX app if you bundle it with the jpackage tool distributed with JDK 14+ >> >>>> Am 31.07.20 um 23:07 schrieb Davide Perini: >>> Hi all guys, >>> love JavaFX, it's so productive, so easy to use, can't understand why the world don't use it "for some tasks". >>> >>> I know that tray icon can be easily done with AWT but is there something for JavaFX? >>> Is it possible to create a tray icon with JavaFX? >>> >>> Thanks >>> Davide >> >> >>