Re: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v7]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Precalculate size of cells that are likely going to be used in rendering. This avoid resizing cells after their position has been laid out, leading to misalignments. Relaxed some tests that check on the number of invocations on updateItem. We heavily use the accumcell for calculating sizes, and that cell is released every time, leading to a call to updateItem as well (but this call should not do any CPU intensive work) - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/c7d722d3..67b351ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=05-06 Stats: 95 lines in 4 files changed: 65 ins; 18 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6]
On Mon, 23 May 2022 20:44:47 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked >> without having a layout calculation in between, the old (wrong) size is used >> to calculcate the total estimate. This happens e.g. when the size is changed >> in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache >> containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Try to keep visible cells at their original position when improving the > estimate. > This reduces annoying effects when re-layouting cells without relevant > changes. > > This should not be done when we don't have a valid estimate yet/anymore, > or when the absoluteOffset is set to infinity (which may happen if the > position is set to infinity, which is the case in some calls in Skin > classes). To give some background: the reason for this PR is to fix (real or perceived) regression after https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed. The original problem was this: in case a ListView contains items with different heights, the scrollbar can show weird jumps as it considers all cells to have the same height. The "easy" solution to this would be to pre-calculate the height of all cells, but that would be a potential performance issue. The approach taken in JDK-8089589 is to gradually improve the information about the different sizes of the cells, and it fixes the weird jumps (at the very least, it avoids jumping upwards when scrolling down and vice versa). However, this gradual improvements can cause other visual disturbances. Initially, we improved the parameters whenever a layoutChildren was invoked. However, this leads to undesired effects in case layoutChildren is invoked again after a specific goal is asked (e.g. scroll to a cell with a specific index). A consequence of the gradual improvement is that the algorithm realizes the first cell need to move upwards or downwards a bit, but that will destroy the state where a cell should be positioned exactly at a given position. The latest commit fixes this, by modifying the parameters (absoluteOffset and position) in such a way that they lead to improvements, yet keep the visible cells intact. This broke a number of tests, as there are cases where keeping these cells intact is not what we want. When there is no cached estimate, or when the absoluteOffset has a bogus value, we do not want to maintain the previous situation. I'm moving this PR to draft until I have more confirmation about the (perceived) stability. - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Try to keep visible cells at their original position when improving the estimate. This reduces annoying effects when re-layouting cells without relevant changes. This should not be done when we don't have a valid estimate yet/anymore, or when the absoluteOffset is set to infinity (which may happen if the position is set to infinity, which is the case in some calls in Skin classes). - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/aa08ba26..c7d722d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=04-05 Stats: 121 lines in 2 files changed: 75 ins; 29 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v4]
On Wed, 18 May 2022 13:39:12 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured >> for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows >> , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No >> regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Space correction works with our new build approach. - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/797
Re: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1
On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in > the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not > present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx17u/pull/54
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v4]
On Tue, 10 May 2022 15:19:58 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Use constant value for DPI Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3]
On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Scale screen dimensions This looks now more in line with what the other platforms are doing. We expect the native layer to deal with low-level window/screen handling, and they should notify the java layer in case of relevant events. - PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed [v3]
On Wed, 4 May 2022 16:55:30 GMT, Jose Pereda wrote: >> This PR updates the screen for each window even for the case where the old >> screen has been disposed but there is a new screen instance found for such >> window. >> >> This is the case of Android, where the lifecycle of the application allows >> destroying the native screen when the app goes to the background, and >> providing a new native screen, in case it comes back to the foreground. >> Before this PR, the screen for the window wasn't updated after returning >> from the background, and if orientation changes happened, the dimensions >> were wrong. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Scale screen dimensions modules/javafx.graphics/src/main/native-glass/monocle/android/nativeBridge.c line 171: > 169: 0, 0, (jint) width, (jint) height, > 170: 0, 0, (jint) width, (jint) height, > 171: 100, 100, (jfloat) 1, (jfloat) 1, androidDensity, > androidDensity); might be good to replace the `100` with e.g. `dpi` and assign a constant value (100) at the top of this file to it, in case we later want to retrieve that in a more dynamic way. - PR: https://git.openjdk.java.net/jfx/pull/778
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Mon, 25 Apr 2022 09:00:54 GMT, Florian Kirmaier wrote: >> I agree with that observation. The mathematical perfect situation would be >> to pre-calculate the height of all items, so that the scrolbar position can >> be exact, and the content placing can be exact as well. That would be at the >> price of a major performance overhead for large lists. For small lists, this >> overhead is more acceptable. >> >> I agree that this is something that could be rather application-defined >> instead of having heuristics in the ListView. >> >> As a historical note, before >> https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed, all items were >> considered of equali height for the position of the scrollbar. In the >> current case, if that precondition holds, the estimated size will be the >> real size, so in that case there is no need to calculate the height of every >> item before getting the correct total size. >> This is again something the application knows best -- even with non-fixed >> cell heights, the expected variations might be small enough and if they are >> randomly spread, the estimate will soon be "good enough". > > @johanvos > As requested, we've made a unit test, which tests this bug. > It's based on your test and our original test class. It can be added to the > ListViewTest. > You can find it, in the JDK ticket. > > Btw, adding the cells incrementally seems to make a difference - which is why > the new test class tests both cases. > > It accepts various inputs of cell sizes - and should work with any inputs. > It should catch all the cases from the original test class. > Because it works with all possible inputs - one could even make a random > test-cases generator to make sure it works in every case. > > It basically only works well, when the sizes are only 20s - in most other > cases it fails. The later reported issues were due to the fact that the estimatedSize got updated during the layoutChildren call. That makes things much more complicated and leads to discrepancies. I disabled the updates to the estimated size during the layoutChildren call, so that all operations that are happening in that call are using a consistent value of the estimated size. We now pass all the tests added by @FlorianKirmaier on the JBS issue . Those tests are great regression tests. - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v5]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Don't recalculate estimated size while doing a layout cycle. There are a number of paths possible that first calculate an offset/position, and later do a layoutChildren pass. The offset/position calculations (e.g. in scrollTo calls) assume a specific estimatedSize. If that size is changed between the first call and the layoutChildren logic, the result will not look as intended. Hence, we should avoid updating the estimated size at the start of the layout phase. We can do it safely at the end. Thanks to Zeiss and Florian Kirmaier for providing additional tests. - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/2b1b4bdc..aa08ba26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=03-04 Stats: 116 lines in 2 files changed: 115 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
[jfx17u] Integrated: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element
On Mon, 2 May 2022 13:14:05 GMT, Johan Vos wrote: > Reviewed-by: aghaisas, jvos This pull request has now been integrated. Changeset: 62ab00bd Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/62ab00bd5c8913fb8089b3d02404366db1d52c37 Stats: 42 lines in 4 files changed: 37 ins; 0 del; 5 mod 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element Backport-of: 115833923a644be8328b8f7a7a6845e5b42a57b3 - PR: https://git.openjdk.java.net/jfx17u/pull/52
[jfx17u] Integrated: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element
Reviewed-by: aghaisas, jvos - Commit messages: - 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element Changes: https://git.openjdk.java.net/jfx17u/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=52=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276167 Stats: 42 lines in 4 files changed: 37 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx17u/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/52/head:pull/52 PR: https://git.openjdk.java.net/jfx17u/pull/52
[jfx17u] Integrated: 8276553: ListView scrollTo() is broken after fix for JDK-8089589
On Sat, 30 Apr 2022 18:48:06 GMT, Johan Vos wrote: > Reviewed-by: kcr, mstrauss This pull request has now been integrated. Changeset: 83534e2d Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/83534e2df8f4d20a661ae68c1c6f9925302953e3 Stats: 29 lines in 5 files changed: 19 ins; 2 del; 8 mod 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Backport-of: d3fbb516c428876bd2389bbfd40f95a811ea6af8 - PR: https://git.openjdk.java.net/jfx17u/pull/50
[jfx17u] Integrated: 8274137: TableView scrollbar/header misaligned when reloading data
On Sat, 30 Apr 2022 18:44:09 GMT, Johan Vos wrote: > Reviewed-by: kcr, aghaisas This pull request has now been integrated. Changeset: ca0e5a47 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/ca0e5a4752e3a0ab2c9b6950c61678b4b07c4749 Stats: 34 lines in 3 files changed: 34 ins; 0 del; 0 mod 8274137: TableView scrollbar/header misaligned when reloading data Backport-of: b591912c749edef1e6c1b8509a8ea10e9fe9000f - PR: https://git.openjdk.java.net/jfx17u/pull/49
[jfx17u] RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589
Reviewed-by: kcr, mstrauss - Commit messages: - 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Changes: https://git.openjdk.java.net/jfx17u/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=50=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276553 Stats: 29 lines in 5 files changed: 19 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jfx17u/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/50/head:pull/50 PR: https://git.openjdk.java.net/jfx17u/pull/50
[jfx17u] RFR: 8274137: TableView scrollbar/header misaligned when reloading data
Reviewed-by: kcr, aghaisas - Commit messages: - 8274137: TableView scrollbar/header misaligned when reloading data Changes: https://git.openjdk.java.net/jfx17u/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=49=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274137 Stats: 34 lines in 3 files changed: 34 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/49/head:pull/49 PR: https://git.openjdk.java.net/jfx17u/pull/49
Re: [jfx11u] RFR: 8283218: Update GStreamer to 1.20.1
On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the > `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to > resolve. Here is a summary of the changes. The jfx mainline patch applied > cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was > skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in > surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx11u/pull/94
Re: [jfx11u] RFR: 8276174: JavaFX build fails on macOS aarch64
On Sat, 30 Apr 2022 13:51:23 GMT, Kevin Rushforth wrote: > Backport to `jfx11u` so we can build on macOS / aarch64 without needing to > specify `-PCOMPILE_TARGET=arm64`. It isn't a clean backport, since I also had > to include the definition of `IS_AARCH64` which is present in mainline, but > not in `jfx11u` (it was added as part of another unrelated fix that isn't > backported to `jfx11u`). Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx11u/pull/100
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v5]
On Wed, 20 Apr 2022 23:08:00 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v5] Marked as reviewed by jvos (Reviewer). I have this working on Ubuntu 18.04, and that gives me enough confidence that with the appropriate toolchain it can be built for 16.04. Exploring glib-lite.so sounds like a good plan. - PR: https://git.openjdk.java.net/jfx/pull/768
[jfx11u] Integrated: 8283328: Update libxml2 to 2.9.13
On Wed, 20 Apr 2022 13:21:39 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte This pull request has now been integrated. Changeset: 1b214b04 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/1b214b04f78e5bbf2d49f63e7995f55141dba6b4 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Backport-of: b0f2521219efc1b0d0c45088736d5105712bc2c9 - PR: https://git.openjdk.java.net/jfx11u/pull/84
[jfx18] Integrated: 8283328: Update libxml2 to 2.9.13
On Wed, 20 Apr 2022 13:29:36 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte This pull request has now been integrated. Changeset: 2a1805a2 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/2a1805a2b9ac83011677b654d2505d7147a6e916 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Backport-of: b0f2521219efc1b0d0c45088736d5105712bc2c9 - PR: https://git.openjdk.java.net/jfx/pull/777
[jfx17u] Integrated: 8283328: Update libxml2 to 2.9.13
On Wed, 20 Apr 2022 13:24:53 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte This pull request has now been integrated. Changeset: 5c0d0a65 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/5c0d0a653f6066c545b2cc61655f29e99c9ccca6 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Backport-of: b0f2521219efc1b0d0c45088736d5105712bc2c9 - PR: https://git.openjdk.java.net/jfx17u/pull/41
[jfx18] RFR: 8283328: Update libxml2 to 2.9.13
Reviewed-by: jvos, kcr, arapte - Commit messages: - 8283328: Update libxml2 to 2.9.13 Changes: https://git.openjdk.java.net/jfx/pull/777/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=777=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod Patch: https://git.openjdk.java.net/jfx/pull/777.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/777/head:pull/777 PR: https://git.openjdk.java.net/jfx/pull/777
[jfx17u] RFR: 8283328: Update libxml2 to 2.9.13
Reviewed-by: jvos, kcr, arapte - Commit messages: - 8283328: Update libxml2 to 2.9.13 Changes: https://git.openjdk.java.net/jfx17u/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=41=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod Patch: https://git.openjdk.java.net/jfx17u/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/41/head:pull/41 PR: https://git.openjdk.java.net/jfx17u/pull/41
[jfx11u] RFR: 8283328: Update libxml2 to 2.9.13
Reviewed-by: jvos, kcr, arapte - Commit messages: - 8283328: Update libxml2 to 2.9.13 Changes: https://git.openjdk.java.net/jfx11u/pull/84/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=84=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod Patch: https://git.openjdk.java.net/jfx11u/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/84/head:pull/84 PR: https://git.openjdk.java.net/jfx11u/pull/84
[jfx18] Integrated: 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch
On Wed, 20 Apr 2022 07:00:46 GMT, Johan Vos wrote: > Increase security version to 2 for JavaFX 18.0.2 This pull request has now been integrated. Changeset: 60d76c8b Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/60d76c8b5d60a816376aa569ad562b56fc790b4c Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/776
Backport requests for JavaFX 11, 17, 18
Hi Kevin, I request permission to backport the following issue to JavaFX 11.0.16, JavaFX 17.0.4 and JavaFX 18.0.2 https://bugs.openjdk.java.net/browse/JDK-8283328 Apart from whitespace warnings, the patch applies clean - Johan
[jfx11u] Integrated: 8285152: Change JavaFX release version to 11.0.16 in jfx11u
On Wed, 20 Apr 2022 06:37:08 GMT, Johan Vos wrote: > Update security version for JavaFX 11 to 16. This pull request has now been integrated. Changeset: f0440390 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/f0440390bdb064c7a5a4cfd19bdba47322cd3009 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8285152: Change JavaFX release version to 11.0.16 in jfx11u Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx11u/pull/83
[jfx17u] Integrated: 8285153: Change JavaFX release version to 17.0.4 in jfx17u
On Wed, 20 Apr 2022 06:43:32 GMT, Johan Vos wrote: > Update security version for JavaFX 17 to 4. This pull request has now been integrated. Changeset: b41307ff Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/b41307ff3f0cec70f1eafe808173ec0fb0cba36c Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8285153: Change JavaFX release version to 17.0.4 in jfx17u Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx17u/pull/40
[jfx17u] RFR: 8285153: Change JavaFX release version to 17.0.4 in jfx17u
Update security version for JavaFX 17 to 4. - Commit messages: - Increase security version to 4 Changes: https://git.openjdk.java.net/jfx17u/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=40=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285153 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx17u/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/40/head:pull/40 PR: https://git.openjdk.java.net/jfx17u/pull/40
[jfx18] RFR: 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch
Increase security version to 2 for JavaFX 18.0.2 - Commit messages: - Increase security version to 2 for JavaFX 18.0.2 Changes: https://git.openjdk.java.net/jfx/pull/776/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=776=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285181 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/776.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/776/head:pull/776 PR: https://git.openjdk.java.net/jfx/pull/776
[jfx11u] RFR: 8285152: Change JavaFX release version to 11.0.16 in jfx11u
Update security version for JavaFX 11 to 16. - Commit messages: - Update security version for JavaFX 11 to 16. Changes: https://git.openjdk.java.net/jfx11u/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=83=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285152 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/83/head:pull/83 PR: https://git.openjdk.java.net/jfx11u/pull/83
Re: [jfx18, jfx17u, jfx11u] RFR: Request to backport April 2022 CPU changes
Approved. On Tue, Apr 19, 2022 at 6:03 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released April > 2022 CPU to jfx:jfx18 (for 18.0.1), jfx17u (for 17.0.3) and to jfx11u > (for 11.0.15) . > > https://github.com/kevinrushforth/jfx17u/compare/4af7ee97f3...cpu-2204-sync > https://github.com/kevinrushforth/jfx11u/compare/1c3d966688...cpu-2204-sync > https://github.com/kevinrushforth/jfx/compare/7e2cefba7f...18-cpu-2204-sync > > For each repo, this is a straight backport (patches initially applied > cleanly, but then the same merge conflict had to be resolved in each > code line as was done in the mainline) of the two FX fix that went into > the April CPU. > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the jfx18 branch of the jfx repo, and to the master > branch of the jfx17u and jfx11u repos rather than via a pull request. > > Thanks. > > -- Kevin > >
Re: RFR: Request to sync April 2022 changes into jfx master
Approved. On Tue, Apr 19, 2022 at 6:03 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to sync changes from to the just-released April 2022 > CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/d1110f4795...cpu-2204-sync > > As a note, the patches initially applied cleanly, but there was a > subsequent merge conflict with the WebKit 613.1 update that had to be > resolved. > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the master branch of the jfx repo rather than via a > pull request. > > -- Kevin > >
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked >> without having a layout calculation in between, the old (wrong) size is used >> to calculcate the total estimate. This happens e.g. when the size is changed >> in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache >> containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. I agree with that observation. The mathematical perfect situation would be to pre-calculate the height of all items, so that the scrolbar position can be exact, and the content placing can be exact as well. That would be at the price of a major performance overhead for large lists. For small lists, this overhead is more acceptable. I agree that this is something that could be rather application-defined instead of having heuristics in the ListView. As a historical note, before https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed, all items were considered of equali height for the position of the scrollbar. In the current case, if that precondition holds, the estimated size will be the real size, so in that case there is no need to calculate the height of every item before getting the correct total size. This is again something the application knows best -- even with non-fixed cell heights, the expected variations might be small enough and if they are randomly spread, the estimate will soon be "good enough". - PR: https://git.openjdk.java.net/jfx/pull/712
[jfx18] Integrated: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2)
On Wed, 13 Apr 2022 16:00:41 GMT, Johan Vos wrote: > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: 7e2cefba Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/7e2cefba7f28fc0570b7495a08203756caa5327c Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Backport-of: 6f201f7a02dba14328d183e7d0db5dede4416ce4 - PR: https://git.openjdk.java.net/jfx/pull/774
[jfx18] RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2)
Reviewed-by: kcr, jvos - Commit messages: - 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Changes: https://git.openjdk.java.net/jfx/pull/774/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=774=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282099 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod Patch: https://git.openjdk.java.net/jfx/pull/774.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/774/head:pull/774 PR: https://git.openjdk.java.net/jfx/pull/774
[jfx18] Integrated: 8281711: Cherry-pick WebKit 613.1 stabilization fixes
On Wed, 13 Apr 2022 15:22:22 GMT, Johan Vos wrote: > Stabilization fixes from WebKitGTK 2.34.5 > > Reviewed-by: jvos, kcr This pull request has now been integrated. Changeset: 0402975a Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/0402975a4cae590296915ea9bd9ea755c97f1ca2 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod 8281711: Cherry-pick WebKit 613.1 stabilization fixes Stabilization fixes from WebKitGTK 2.34.5 Backport-of: 418d3437923fed0a298c48b54214af069e3bb3bd - PR: https://git.openjdk.java.net/jfx/pull/773
[jfx18] RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes
Stabilization fixes from WebKitGTK 2.34.5 Reviewed-by: jvos, kcr - Commit messages: - 8281711: Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx/pull/773/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=773=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod Patch: https://git.openjdk.java.net/jfx/pull/773.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/773/head:pull/773 PR: https://git.openjdk.java.net/jfx/pull/773
[jfx18] Withdrawn: 8281711: Cherry-pick WebKit 613.1 stabilization fixes
On Wed, 13 Apr 2022 14:15:29 GMT, Johan Vos wrote: > Stabilization fixes from WebKitGTK 2.34.5 > > Reviewed-by: jvos, kcr This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jfx/pull/772
[jfx18] RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes
Stabilization fixes from WebKitGTK 2.34.5 Reviewed-by: jvos, kcr - Commit messages: - 8281711: Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx/pull/772/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=772=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod Patch: https://git.openjdk.java.net/jfx/pull/772.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/772/head:pull/772 PR: https://git.openjdk.java.net/jfx/pull/772
[jfx18] Integrated: 8281459: WebKit 613.1 build broken on M1
On Wed, 13 Apr 2022 13:43:18 GMT, Johan Vos wrote: > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: 1d74 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/1d74d01addf3b6481f0af7866c8454b6cfdf Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8281459: WebKit 613.1 build broken on M1 Backport-of: cdebc6cbafb579148b4addee44d307bd9739454b - PR: https://git.openjdk.java.net/jfx/pull/771
[jfx18] RFR: 8281459: WebKit 613.1 build broken on M1
Reviewed-by: kcr, jvos - Commit messages: - 8281459: WebKit 613.1 build broken on M1 Changes: https://git.openjdk.java.net/jfx/pull/771/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=771=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281459 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/771.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/771/head:pull/771 PR: https://git.openjdk.java.net/jfx/pull/771
[jfx18] Integrated: 8278980: Update WebKit to 613.1
On Wed, 13 Apr 2022 12:35:18 GMT, Johan Vos wrote: > Co-authored-by: Ajit Ghaisas > Co-authored-by: Jay Bhaskar > Co-authored-by: Kevin Rushforth > Reviewed-by: kcr, jvos, aghaisas This pull request has now been integrated. Changeset: f19b57ae Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/f19b57ae44090d775d9adf52b2013933eba0aa02 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod 8278980: Update WebKit to 613.1 Reviewed-by: kcr Backport-of: 6f28d912024495278c4c35ab054bc2aab480b3e4 - PR: https://git.openjdk.java.net/jfx/pull/770
[jfx18] RFR: 8278980: Update WebKit to 613.1
Co-authored-by: Ajit Ghaisas Co-authored-by: Jay Bhaskar Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, aghaisas - Commit messages: - 8278980: Update WebKit to 613.1 Changes: https://git.openjdk.java.net/jfx/pull/770/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=770=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278980 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod Patch: https://git.openjdk.java.net/jfx/pull/770.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/770/head:pull/770 PR: https://git.openjdk.java.net/jfx/pull/770
[jfx18] Integrated: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1
On Wed, 13 Apr 2022 08:59:45 GMT, Johan Vos wrote: > Update JavaFX release version to 18.0.1 in jfx18 branch This pull request has now been integrated. Changeset: 87cb6594 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/87cb65949c468774bd6973198e45bb3e372f52f3 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/769
Re: [jfx18] RFR: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 [v2]
> Update JavaFX release version to 18.0.1 in jfx18 branch Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Update version in .jcheck/conf to 18.0.1 - Changes: - all: https://git.openjdk.java.net/jfx/pull/769/files - new: https://git.openjdk.java.net/jfx/pull/769/files/5b378e98..f8032a38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=769=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=769=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/769/head:pull/769 PR: https://git.openjdk.java.net/jfx/pull/769
backport requests for 18.0.1
Hi Kevin, I request approval to backport the following issues to the jfx18 branch, for JavaFX 18.0.1: JDK-8278980: Update WebKit to 613.1 JDK-8281459: WebKit 613.1 build broken on M1 JDK-8281711: Cherry-pick WebKit 613.1 stabilization fixes JDK-8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) - Johan
[jfx18] RFR: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1
Update JavaFX release version to 18.0.1 in jfx18 branch - Commit messages: - Update JavaFX release version to 18.0.1 in jfx18 branch Changes: https://git.openjdk.java.net/jfx/pull/769/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=769=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284812 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/769/head:pull/769 PR: https://git.openjdk.java.net/jfx/pull/769
Re: RFR: 8281564: Update cmake to 3.22.3
On Tue, 5 Apr 2022 04:54:55 GMT, Ambarish Rapte wrote: > Update cmake to 3.22.3 > Verified build on all three platforms. > The sanity test looks good. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/767
Re: RFR: 8283328: Update libxml2 to 2.9.13 [v2]
On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest >> stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: >> https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Add README.md and update libxml2.md Looks good and works fine on Mac/Linux/Windows - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/764
Re: RFR: 8283328: Update libxml2 to 2.9.13 [v2]
On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest >> stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: >> https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Add README.md and update libxml2.md This looks good. Just for my understanding: this is the 2.9.13-tagged plus the fix for the issue with xmlValidNormalizeString() with --without-valid-build (https://gitlab.gnome.org/GNOME/libxml2/-/commit/d05317cee5eb2bd35269b7706a8850c6c3097de3) ? I notice there was a followup patch (https://gitlab.gnome.org/GNOME/libxml2/-/commit/b057239b3f65c8dd9d472fc878214ea4b1d852d3) but that doesn't touch files we have, and since builds are compiling for me, it seems that we are all good now. - PR: https://git.openjdk.java.net/jfx/pull/764
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3]
On Fri, 25 Mar 2022 16:26:34 GMT, Kevin Rushforth wrote: > It looks like there are some failing unit tests now. I fixed them. - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Don't shift cells if we are already showing the lowest index cell. - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/a931ba75..2b1b4bdc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8283402: Update to gcc 11.2 on Linux
On Tue, 29 Mar 2022 11:50:32 GMT, Kevin Rushforth wrote: >> No, it will use whatever the latest is for GitHub actions. There doesn't >> seem to be an 11.2 package for GHA. It should be sufficient for most >> testing, but highlights one of the limitations of relying on GitHub Actions >> for anything more than a sanity test. > > (based on the printout I see in the log files, the current version of gcc 1.x > available on the GHA Linux nodes is 11.1) 11.1 is what I'm using on 18.04 and 20.04 as well. I wonder if that is good enough, or are there particular reasons why you want to update to 11.2 ? - PR: https://git.openjdk.java.net/jfx/pull/761
Re: RFR: 8283517: Update boot JDK to 18
On Fri, 25 Mar 2022 12:16:18 GMT, Kevin Rushforth wrote: > JDK 18 has been released, so we should update the default boot JDK used to > build JavaFX to JDK 18. This will not affect the minimum boot JDK version. I > have confirmed that gradle 7.3 works with JDK 18, so we don't need to update > gradle at this time. > > I have done a full set of tests on all three platforms. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/760
Re: RFR: 8283402: Update to gcc 11.2 on Linux
On Fri, 25 Mar 2022 12:19:10 GMT, Kevin Rushforth wrote: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK > 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. .github/workflows/submit.yml line 86: > 84: set -x > 85: sudo apt-get update > 86: sudo apt-get install libgl1-mesa-dev libx11-dev libxxf86vm-dev > libxt-dev pkg-config libgtk2.0-dev libgtk-3-dev libxtst-dev gcc-11 g++-11 Did this install 11.2? The CI is using Focal, and afaik there is no gcc-11.2 for focal? - PR: https://git.openjdk.java.net/jfx/pull/761
Re: RFR: 8280369: native library cache should be platform/arch specific
On Fri, 25 Mar 2022 18:12:23 GMT, Glavo wrote: > Currently, OpenJFX extracts the native library into a local folder and loads > it when it is not part of the JRE. > > Now we have a notable problem with the fact that a platform may actually run > programs of multiple CPU architectures. > > Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In > addition to this, ARM machines may also execute AMD64 programs by transpiling. > > For OpenJFX of different architectures on the same system, their native > libraries have the same file name, but their contents are different. Since > they will try to unpack the native library into the same folder, this will > cause file conflicts. > > A practical example is when I run the same JavaFX application with both > 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that > starts later crashes because it cannot unzip the native libraries: > > Crash logs (The length exceeds the GitHub limit): > https://paste.ubuntu.com/p/NZBK3pNrh7/ > > Here I avoid the problem by adding `os.arch` to the cache path. > > I ran the tests on Ubuntu 20.04 after the modification and no tests were > broken. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/762
Re: RFR: 8280369: native library cache should be platform/arch specific
On Fri, 25 Mar 2022 18:12:23 GMT, Glavo wrote: > Currently, OpenJFX extracts the native library into a local folder and loads > it when it is not part of the JRE. > > Now we have a notable problem with the fact that a platform may actually run > programs of multiple CPU architectures. > > Most commonly, 32-bit x86 applications can be executed on Windows AMD64. In > addition to this, ARM machines may also execute AMD64 programs by transpiling. > > For OpenJFX of different architectures on the same system, their native > libraries have the same file name, but their contents are different. Since > they will try to unpack the native library into the same folder, this will > cause file conflicts. > > A practical example is when I run the same JavaFX application with both > 32-bit and 64-bit Java on a Windows AMD64 platform, and the application that > starts later crashes because it cannot unzip the native libraries: > > Crash logs (The length exceeds the GitHub limit): > https://paste.ubuntu.com/p/NZBK3pNrh7/ > > Here I avoid the problem by adding `os.arch` to the cache path. > > I ran the tests on Ubuntu 20.04 after the modification and no tests were > broken. This looks good, and I can't see possible regression (e.g. issues with non-existing parent directories, or files that have the same name as the directory that will be created by this PR). It is indeed very useful given the increase in potential architectures. I'm doing a few more automatic tests before approving. - PR: https://git.openjdk.java.net/jfx/pull/762
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2]
On Tue, 22 Mar 2022 08:47:42 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked >> without having a layout calculation in between, the old (wrong) size is used >> to calculcate the total estimate. This happens e.g. when the size is changed >> in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache >> containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Add the option to shift all cells down in case the current calculations > would lead to empty cells at the end of the view, > while there are available cells before the beginning of the view. There was a problem in ListView, in which cells are shifted down in case there are empty cells being rendered while there are leading cells available. I also added a testcase for this that fails before and succeeds after. - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v3]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add test to check if there are no empty cells at the end of a List in case there are enough leading cells available. - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/05935373..a931ba75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=01-02 Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3]
On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio >> only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder >> cannot handle AAC elementary streams directly. DirectShow decoder works >> without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will >> be reloaded when fMP4 stream changes resolution. Dynamic format change did >> not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/726
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3]
On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio >> only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder >> cannot handle AAC elementary streams directly. DirectShow decoder works >> without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will >> be reloaded when fMP4 stream changes resolution. Dynamic format change did >> not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] This looks really great. I'm doing a few more tests before approving, but I don't expect issues. I wonder if we can add some simple resources that allow testing the different protocols on different platforms? - PR: https://git.openjdk.java.net/jfx/pull/726
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v2]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add the option to shift all cells down in case the current calculations would lead to empty cells at the end of the view, while there are available cells before the beginning of the view. - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/d1ab8afb..05935373 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=00-01 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
[jfx11u] Integrated: 8203463: [Accessibility, Narrator] NPE in TableView
On Thu, 17 Mar 2022 20:56:32 GMT, Johan Vos wrote: > Reviewed-by: kcr This pull request has now been integrated. Changeset: bf32dd8a Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/bf32dd8a52876b0c0a53e9f73d64b0a986829626 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8203463: [Accessibility, Narrator] NPE in TableView Backport-of: c705bd493931d88650542be5466d6add359f45b9 - PR: https://git.openjdk.java.net/jfx11u/pull/81
[jfx17u] Integrated: 8197991: Selecting many items in a TableView is very slow
On Fri, 18 Mar 2022 07:42:37 GMT, Johan Vos wrote: > Co-authored-by: Naohiro Yoshimoto > Reviewed-by: kcr, aghaisas This pull request has now been integrated. Changeset: 4af7ee97 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/4af7ee97f37cb18b3433afc3b128b10d3401f29c Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod 8197991: Selecting many items in a TableView is very slow Backport-of: 8c4f966b163f68c517574e38c394b9349551ad08 - PR: https://git.openjdk.java.net/jfx17u/pull/39
[jfx17u] Integrated: 8203463: [Accessibility, Narrator] NPE in TableView
On Fri, 18 Mar 2022 07:42:11 GMT, Johan Vos wrote: > Reviewed-by: kcr This pull request has now been integrated. Changeset: 53d443bf Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/53d443bffa34c971c7c6192649caa9aba2acb5f5 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8203463: [Accessibility, Narrator] NPE in TableView Backport-of: c705bd493931d88650542be5466d6add359f45b9 - PR: https://git.openjdk.java.net/jfx17u/pull/38
[jfx11u] Integrated: 8197991: Selecting many items in a TableView is very slow
On Thu, 17 Mar 2022 21:01:51 GMT, Johan Vos wrote: > Co-authored-by: Naohiro Yoshimoto > Reviewed-by: kcr, aghaisas This pull request has now been integrated. Changeset: 1c3d9666 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/1c3d9666884b6689d7b982a8541c692468512bf0 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod 8197991: Selecting many items in a TableView is very slow Backport-of: 8c4f966b163f68c517574e38c394b9349551ad08 - PR: https://git.openjdk.java.net/jfx11u/pull/82
[jfx17u] RFR: 8197991: Selecting many items in a TableView is very slow
Co-authored-by: Naohiro Yoshimoto Reviewed-by: kcr, aghaisas - Commit messages: - 8197991: Selecting many items in a TableView is very slow Changes: https://git.openjdk.java.net/jfx17u/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=39=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod Patch: https://git.openjdk.java.net/jfx17u/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/39/head:pull/39 PR: https://git.openjdk.java.net/jfx17u/pull/39
[jfx17u] RFR: 8203463: [Accessibility, Narrator] NPE in TableView
Reviewed-by: kcr - Commit messages: - 8203463: [Accessibility, Narrator] NPE in TableView Changes: https://git.openjdk.java.net/jfx17u/pull/38/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=38=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203463 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/38.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/38/head:pull/38 PR: https://git.openjdk.java.net/jfx17u/pull/38
[jfx11u] RFR: 8197991: Selecting many items in a TableView is very slow
Co-authored-by: Naohiro Yoshimoto Reviewed-by: kcr, aghaisas - Commit messages: - 8197991: Selecting many items in a TableView is very slow Changes: https://git.openjdk.java.net/jfx11u/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=82=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod Patch: https://git.openjdk.java.net/jfx11u/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/82/head:pull/82 PR: https://git.openjdk.java.net/jfx11u/pull/82
[jfx11u] RFR: 8203463: [Accessibility, Narrator] NPE in TableView
Reviewed-by: kcr - Commit messages: - 8203463: [Accessibility, Narrator] NPE in TableView Changes: https://git.openjdk.java.net/jfx11u/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=81=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203463 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/81/head:pull/81 PR: https://git.openjdk.java.net/jfx11u/pull/81
Re: RFR: 8283183: Skip failing PredefinedMeshManagerTest tests
On Tue, 15 Mar 2022 18:50:15 GMT, Kevin Rushforth wrote: > We continue to get intermittent test failures in `PredefinedMeshManagerTest` > due to an OOM error. See the GitHub Actions run for [PR > 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) > for a recent failure. This test failure is tracked by > [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that > test bug is fixed, I propose to skip the two test methods, > `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are > prone to OOM errors. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/754
Re: RFR: 8283183: Skip failing PredefinedMeshManagerTest tests
On Tue, 15 Mar 2022 18:50:15 GMT, Kevin Rushforth wrote: > We continue to get intermittent test failures in `PredefinedMeshManagerTest` > due to an OOM error. See the GitHub Actions run for [PR > 753](https://github.com/openjdk/jfx/pull/753/checks?check_run_id=5559141397) > for a recent failure. This test failure is tracked by > [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449). Until that > test bug is fixed, I propose to skip the two test methods, > `cylinderCacheTest` and `sphereCacheTest`, that allocate large meshes and are > prone to OOM errors. I am ok with ignoring these tests. Since these tests will typically throw an OOM exception on shared CI systems, it might be good to make the ignore conditionally -- but I'm ok with ignoring them in general as well. - PR: https://git.openjdk.java.net/jfx/pull/754
Re: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2]
On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/752
Re: RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2)
On Tue, 22 Feb 2022 17:15:19 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. Ok on mac/linux/win x86_64 and on linux aarch64 - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/740
Re: RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2)
On Tue, 22 Feb 2022 17:15:19 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. I notice changes specific to AArch64 and Linux, so I did a testbuild on Linux AArch64 which was successful. Will test the mac/linux/windows regular builds soon. - PR: https://git.openjdk.java.net/jfx/pull/740
Re: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2]
On Wed, 16 Feb 2022 13:08:04 GMT, Ambarish Rapte wrote: >> Include additional stabilization fixes of WebKit 613.1 >> Sanity testing did not show any concerns. > > Ambarish Rapte has updated the pull request incrementally with one additional > commit since the last revision: > > correct unintentional change Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/733
Re: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2]
On Wed, 16 Feb 2022 13:08:04 GMT, Ambarish Rapte wrote: >> Include additional stabilization fixes of WebKit 613.1 >> Sanity testing did not show any concerns. > > Ambarish Rapte has updated the pull request incrementally with one additional > commit since the last revision: > > correct unintentional change Looks good on Linux. - PR: https://git.openjdk.java.net/jfx/pull/733
Re: RFR: 8281459: WebKit 613.1 build broken on M1
On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which > caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches > with the WebKit mainline. Confirmed that this now builds fine on M1 - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/730
Re: RFR: 8281459: WebKit 613.1 build broken on M1
On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which > caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches > with the WebKit mainline. Thanks for the quick patch. This looks good om Linux-aarch64 (which suffered from the same issue). I'll do a test on M1 tomorrow. - PR: https://git.openjdk.java.net/jfx/pull/730
Re: JavaFX with Python/JS
Hi Thiago, Yes, that is possible, and I've done that years ago with some simple python code, that resulted in a array of numbers that can then be visualised with JavaFX. It is really cool indeed, but back then the Python support was limited (e.g. no numpy). As for huge marketing opportunity: the problem is most often that someone has to *do* the marketing. Which is typically harder/more expensive than doing the technical work. But from a pure technical point: it makes very much sense. - Johan On Mon, Feb 7, 2022 at 2:21 PM Thiago Milczarek Sayão < thiago.sa...@gmail.com> wrote: > Hi, > > Would it be possible to use JavaFx with python/graalvm ? > Maybe javascript? > > Gluon, > > Would that not be a huge marketing opportunity? Write apps in python/js ? > > Cheers. >
Re: RFR: 8278980: Update WebKit to 613.1 [v2]
On Wed, 2 Feb 2022 15:29:51 GMT, Ambarish Rapte wrote: >> Update JavaFX WebKit to GTK WebKit 2.34 (613.1). >> >> Verified the updated version build, tests run and sanity testing. >> This does not cause any issues except a unit test failure >> `IrresponsiveScriptTest`. >> It is recorded and ignored using >> [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) > > Ambarish Rapte has updated the pull request incrementally with one additional > commit since the last revision: > > Restore commits that were mistakenly reverted. > > 8279013: ES2Pipeline fails to detect AMD vega20 graphics card > 8277853: With Touch enabled devices scrollbar disappears and the table is > scrolled to the beginning > 8277122: SplitPane divider drag can hang the layout builds on all platforms, basic tests are ok. We should do an EA release soon after this is merged, so we can have more testers. - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/723
Re: RFR: 8278980: Update WebKit to 613.1
Hi Kevin, Thanks for filing [JDK-8281089]. I think this is the way forward indeed. The longer we delay moving to VS 2019, the more problems we can expect. I'll build/test the WebKit 613.1 as well. - Johan On Wed, Feb 2, 2022 at 1:49 PM Kevin Rushforth wrote: > On Wed, 2 Feb 2022 07:34:55 GMT, Ambarish Rapte > wrote: > > > Update JavaFX WebKit to GTK WebKit 2.34 (613.1). > > > > Verified the updated version build, tests run and sanity testing. > > This does not cause any issues except a unit test failure > `IrresponsiveScriptTest`. > > It is recorded and ignored using [JDK-8280421]( > https://bugs.openjdk.java.net/browse/JDK-8280421) > > One other thing to note about this update is that WebKit 613.1 will not > compile with Visual Studio 2017 -- it requires VS 2019. This is similar to > the previous 612.1 update, [JDK-8268849]( > https://bugs.openjdk.java.net/browse/JDK-8268849), where a follow-on fix, > [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), was > needed. I filed a similar bug this time: > > [JDK-8278983](https://bugs.openjdk.java.net/browse/JDK-8278983): WebKit > 613.1 build fails with Visual Studio 2017 > > but it doesn't seem so straight-forward. We are likely at the point where > we need to require VS 2019 to build (I note that WebKit itself has required > VS 2019 for about 1.5 years). In order to eventually backport this to > JavaFX 11, we will need to solve a long-standing problem when `jlink`ing > the JavaFX jmods into a JDK that was built with an earlier version of the > Visual Studio compiler than the one used to build JavaFX. I filed the > following to track this: > > [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089): JavaFX > built with VS2019 and jlinked into JDK 11.x fails to start > > - > > PR: https://git.openjdk.java.net/jfx/pull/723 >
Re: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card
On Mon, 20 Dec 2021 17:48:19 GMT, Paul wrote: > I have an AMD Radeon VII (vega20) series GPU which is identifying with a > vendor string of "AMD". > > This is not present in the `X11GLFactory` list of `preQualificationFilter` > vendor names, so my system (and probably any other vega20 based cards under > Linux) will always fall back to software rendering. > > This adds the "amd" string to the `preQualificationFilter` list. I agree this would be a good and easy fix. Since there is an easy fallback to sw-rendering, this issue might impact more runtime environments than we are aware of. @kevinrushforth is there anything we can do to check the OCA status? - PR: https://git.openjdk.java.net/jfx/pull/698
Re: [jfx11u] RFR: 8280489: Change JavaFX release version in jfx11u to 11.0.15
On Tue, 25 Jan 2022 01:20:04 GMT, Kevin Rushforth wrote: > Bump release version in `jfx11u` repo to 11.0.15 for the start of a new > release. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx11u/pull/69
Re: [jfx17u] RFR: 8280490: Change JavaFX release version in jfx17u to 17.0.3
On Tue, 25 Jan 2022 01:19:11 GMT, Kevin Rushforth wrote: > Bump release version in `jfx17u` repo to 17.0.3 for the start of a new > release. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx17u/pull/29
Re: The openjfx native library cache path should be platform dependent
That sounds correct indeed. I filed
https://bugs.openjdk.java.net/browse/JDK-8280369 for this.
Thanks for reporting!
- Johan
On Thu, Jan 20, 2022 at 6:14 AM Glavo wrote:
> I noticed that openjfx packaged in jar caches native libraries in
> ~/.openjfx/cache/${version}, it is not related to the system and
> architecture.
>
> It should be noted that in fact, we can start programs with different
> architectures on the same system. A typical example is that Windows x86
> software can be run on the Windows amd64 platform.
> With the popularization of aarch64 architecture, this situation will become
> more common: The software of Windows x86 and Windows amd64 can be run on
> the Windows aarch64 platform, and the software of MacOs x86 can be run on
> the MacOS aarch64.
>
> The native library file names of different schemas on the same system are
> usually the same, which will cause conflicts.
> For example, I tried to launch the same JavaFX application on my Windows
> amd64 machine with two jdks that for x86 architecture and amd64
> architecture at the same time, and it crashed:
>
> https://paste.ubuntu.com/p/NZBK3pNrh7/
>
> On ARM machines, it is often necessary to run x86 applications through
> translators, and such crashes may be more common.
>
> I think openjfx should adjust the cache path of the native library, such as
> ~/.openjfx/cache/17.0.2/win-aarch64/.
> This can avoid crashes and avoid openjfx repeatedly decompressing the
> native library to cover the native libraries of other architectures.
>
> I don't have a JBS account. If you need to open an issue for this problem,
> please do it for me, thanks.
>
Re: [jfx17u, jfx11u] RFR: Request to backport January 2022 CPU changes
Approved Op di 18 jan. 2022 om 18:25 schreef Kevin Rushforth < kevin.rushfo...@oracle.com>: > Hi Johan, > > I request approval to backport the changes from the just-released > January 2022 CPU to jfx17u (for 17.0.2) and to jfx11u (for 11.0.14) . > > https://github.com/kevinrushforth/jfx17u/compare/b6b7207a19...cpu-2201-sync > https://github.com/kevinrushforth/jfx11u/compare/e80660685e...cpu-2201-sync > > For each repo, this is a straight backport (patch applies cleanly) of > the one FX fix that went into the January CPU. > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the master branch of the jfx17u and jfx11u repos > rather than via a pull request. > > Thanks. > > -- Kevin > >
Re: [jfx18] RFR: Request to sync January 2022 changes into jfx
Approved. Op di 18 jan. 2022 om 18:25 schreef Kevin Rushforth < kevin.rushfo...@oracle.com>: > Hi Johan, > > I request approval to sync changes from to the just-released January > 2022 CPU release into the 'jfx18' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/a2a0acff66...cpu-2201-sync > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the jfx18 branch of the jfx repo rather than via a > pull request. > > -- Kevin > >
Re: [jfx18] RFR: 8273998: Clarify specification for Window properties controlled by the window manager
On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify > that the values for some properties and methods can be changed or ignored by > the platform. Several of the properties already have a comment to the effect > that the value can change externally, and thus the properties are not > bindable, but this should be clarified further and for all such properties > and methods. > > See the Description of the JBS issues for this bug and its associated CSR for > more details. Re-approved - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/708
Re: RFR: 8273998: Clarify specification for Window properties controlled by the window manager
On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify > that the values for some properties and methods can be changed or ignored by > the platform. Several of the properties already have a comment to the effect > that the value can change externally, and thus the properties are not > bindable, but this should be clarified further and for all such properties > and methods. > > See the Description of the JBS issues for this bug and its associated CSR for > more details. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/708
Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]
On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourgès wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path >> clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement >> fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix >> in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, >> reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot >> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized >> MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS >> 19.05 with many variants, improving almost-sorted datasets. We are >> collaborating to provide a complete Sort framework (15 algorithms, many >> various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourgès has updated the pull request incrementally with one > additional commit since the last revision: > > added test for huge polygon coords Building and testing works, I am looking into the diffs as well now. The DualPivotQuicksort20191112Ext seems to be an improved version of what is in java.util. Ideally, we can somehow extend or leverage the version in java.util without duplicating the original code. For testing: one of the tests I would like to do is to see if the complexity increases as expected when increasing coordinates. Since the original Dual-Pivot quicksort has O(n log(n)) time complexity, it should be possible to have an upper bound on the number of invocations. - PR: https://git.openjdk.java.net/jfx/pull/674
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. This looks good with the current tools/OS behaviour. It is still a bit of a hack, which may result in unexpected behaviour when the macos-specific tools change. But this is a general observation with macos, so I believe this is indeed the best (and least intrusive way) to prevent the crashes. - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8273998: Clarify specification for Window properties controlled by the window manager
On Fri, 7 Jan 2022 18:19:23 GMT, Kevin Rushforth wrote: > Update the API specification for the `Window` and `Stage` classes to clarify > that the values for some properties and methods can be changed or ignored by > the platform. Several of the properties already have a comment to the effect > that the value can change externally, and thus the properties are not > bindable, but this should be clarified further and for all such properties > and methods. > > See the Description of the JBS issues for this bug and its associated CSR for > more details. This looks ok to me. The clarifications make sense. There is unfortunately no guarantee about (low-level) cross-platform behaviour in these cases, but at least the JavaDoc makes this clear. - PR: https://git.openjdk.java.net/jfx/pull/708
RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed
When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. - Commit messages: - resize cell when getting it from the pile, and recalculate total estimated size Changes: https://git.openjdk.java.net/jfx/pull/712/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=712=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277785 Stats: 63 lines in 2 files changed: 63 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8279615: Change JavaFX release version to 19
On Fri, 7 Jan 2022 12:55:33 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 19. I will integrate this immediately > after forking the `jfx18` stabilization branch, which is scheduled for > Thursday, January 13, 2022 at 16:00 UTC. ok (once 18 is branched) - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/707
Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used
On Wed, 17 Nov 2021 22:05:25 GMT, Laurent Bourgès wrote: > Draft PR to see how big is the MarlinFX 0.9.4.5 patch (DPQS, Path clipper > fixes to handle huge coords) @bourgesl can you rename the title of this PR to 8274066: Polygon filled outside its area when very large coordinates are used - PR: https://git.openjdk.java.net/jfx/pull/674
Re: [jfx17u] RFR: 8279396: Define version in .jcheck/conf
On Tue, 4 Jan 2022 16:39:00 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in > support of a Skara bot config change to take the fix version from the repo. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx17u/pull/27
Re: [jfx11u] RFR: 8279396: Define version in .jcheck/conf
On Tue, 4 Jan 2022 16:45:52 GMT, Kevin Rushforth wrote: > Backport fix to add `version` property to `.jcheck/conf`. This is needed in > support of a Skara bot config change to take the fix version from the repo. > > NOTE: the `UPDATING-version.md` file was not present in the repo. I copied it > from mainline, since the instructions are identical. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx11u/pull/68
