Re: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
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
Re: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
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
Re: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
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
[jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
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
Re: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
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
Re: RFR: [WIP]8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing
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
Re: RFR: 8245181: TreeTableViewTest > test_rt35039_resetRootChildren logs an exception
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
Re: RFR: 8244297: memory leak test utility [v4]
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
Re: RFR: 8169501: GIF animation is too fast
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
Re: RFR: 8249777: build.gradle: project.version should not contain time stamps [v2]
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
Re: RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes
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
Re: Fixing NetBeans Gradle Support for OpenJFX
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 ebre...@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
Fullscreen canvas
Hi all, is it possible to create a fullscreen canvas? I don't find a good doc for JavaFX and canvas. Thanks Davide
Re: RFR: 8249777: build.gradle: project.version should not contain time stamps [v2]
> 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
Re: Re: Fixing NetBeans Gradle Support for OpenJFX
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 ebre...@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 > > >
Re: RFR: 8249777: build.gradle: project.version should not contain time stamps
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
Re: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]
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
Re: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]
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
Re: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4]
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
Re: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4]
> 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
