Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v8]
> This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative > positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 > 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix @Override - Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/61fe8ff3..322e7af0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080
Re: RFR: 8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale
On Wed, 20 Sep 2023 14:46:35 GMT, Kevin Rushforth wrote: >> Snapping introduces differences between computed values and snapped values, >> so we need to use non-zero tolerance when checking for equality. The >> maximum tolerance is (1 / scale) - one display pixel scaled back to the >> local coordinates. >> >> The tests have been modified to use the scale-specific tolerance. >> >> Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%). > > tests/system/src/test/java/test/util/Util.java line 490: > >> 488: double scale = win.getRenderScaleX(); >> 489: // distance between pixels in the local (unscaled) >> coordinates is (1 / scale) >> 490: return 1.0 / scale; > > Is this computation what you want? This will give a smaller tolerance for a > screen scale of, say, 2.0 (0.5) than it will for 1.0 (1). Intuitively, this > seems backwards. For a screen scale of 1, a tolerance of 1 might be too > large, whereas for a screen scale of 3, a tolerance of 0. might be too > small. If the goal is to account for the results of snapping, then would a > fixed tolerance of 0.5 be better? It's possible I'm missing something. this tolerance is to account for snapping, but it should be one half of the display pixel instead of the whole pixel (i.e. `0.5 / scale`). With 0.5, these tests fail because we need JDK-8299753 to go first (and pass with the fix). What we can do is to merge this change and change the tolerance as a part of JDK-8299753. - PR Review Comment: https://git.openjdk.org/jfx/pull/1234#discussion_r1331993490
Re: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v5]
On Wed, 20 Sep 2023 15:09:24 GMT, Lukasz Kostyra wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added >> testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and >> then iconifying the top one - this is similar to already existing >> `IconifyTest.java` but it tests just the iconfication process and nothing >> more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ >> overlapping each other. After maximization/fullscreen top stage (being >> always on top as well) should cover the bottom stage. Moreover, FullScreen >> and Maximize are differentiated by checking if window decoration exists - >> maximized Stage will have its decoration taking space on top of the screen, >> whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color >> when called a second time. This only happened on macOS and with FullScreen >> test (others worked fine). Unfortunately I couldn't figure out why it >> returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved >> color checks into separate `runAndWait()`-s with a small sleep between them, >> which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > Lukasz Kostyra has updated the pull request incrementally with one additional > commit since the last revision: > > Replace waitForIdle with sleep, add sleep at the end of setupStages double checked on macOS, looks good. thanks! - Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1240#pullrequestreview-1636178951
Re: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v5]
On Wed, 20 Sep 2023 15:09:24 GMT, Lukasz Kostyra wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added >> testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and >> then iconifying the top one - this is similar to already existing >> `IconifyTest.java` but it tests just the iconfication process and nothing >> more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ >> overlapping each other. After maximization/fullscreen top stage (being >> always on top as well) should cover the bottom stage. Moreover, FullScreen >> and Maximize are differentiated by checking if window decoration exists - >> maximized Stage will have its decoration taking space on top of the screen, >> whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color >> when called a second time. This only happened on macOS and with FullScreen >> test (others worked fine). Unfortunately I couldn't figure out why it >> returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved >> color checks into separate `runAndWait()`-s with a small sleep between them, >> which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > Lukasz Kostyra has updated the pull request incrementally with one additional > commit since the last revision: > > Replace waitForIdle with sleep, add sleep at the end of setupStages Looks good. - Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1240#pullrequestreview-1636152183
Re: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v5]
On Wed, 13 Sep 2023 15:08:12 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Replace waitForIdle with sleep, add sleep at the end of setupStages > > tested on macOS 13.5.1 (looks good), with some minor comments and suggestions. @andy-goryachev-oracle Did you want a change to review this? - PR Comment: https://git.openjdk.org/jfx/pull/1240#issuecomment-1728140598
Re: Combining JavaFX with native UI and shaders?
Yeah, I’ve used Java/JVM a lot and I appreciate the platform independent aspects. I’ve heard Python people say that their app-design philosophy is to build most of it in Python but drop down into C for the bits where they want to optimize performance in the extreme. So they sacrifice some of the run-anywhere convenience for that. I would use Python myself but the lack of a nicer type system with generics drives me nuts, so I was hoping a similar technique would be available in Java/JavaFX. I hadn’t considered the gaming engines. I’ll take a look at those. thanks, Rob > On Sep 20, 2023, at 3:51 AM, John Hendrikx wrote: > > The idea behind JavaFX (and most Java API's) is to provide a platform > independent API, allowing you to write things once and have it run on all > supported platforms. Exposing an API that is only available on one platform > would go against that idea. You either need to do a lot of hacking to reach > the underlying metal API's, or use JavaFX only as an overlay (having JavaFX > run in a transparent child window) while the main window is accessed directly > (also needs some hacking), or use another framework more suited to your > purpose (maybe one of the gaming frameworks). > > --John > > On 20/09/2023 00:04, Rob Nikander wrote: >> Hi, >> >> I’m interested in using JavaFX for a app’s UI, but for parts of the UI I >> want to use the native OS’s GPU API, to get the maximum possible >> performance. So on macOS, for example, I want to render it with Metal and >> write Metal shaders. Is this possible, maybe with help from JNI? >> >> Rob >>
Re: RFR: 8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale
On Thu, 7 Sep 2023 18:26:50 GMT, Andy Goryachev wrote: > Snapping introduces differences between computed values and snapped values, > so we need to use non-zero tolerance when checking for equality. The maximum > tolerance is (1 / scale) - one display pixel scaled back to the local > coordinates. > > The tests have been modified to use the scale-specific tolerance. > > Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%). The changes to the test look fine to me. I did ad a question about the new test utility method, but I'll leave it up to you as to whether and how you want to fix it. tests/system/src/test/java/test/util/Util.java line 490: > 488: double scale = win.getRenderScaleX(); > 489: // distance between pixels in the local (unscaled) > coordinates is (1 / scale) > 490: return 1.0 / scale; Is this computation what you want? This will give a smaller tolerance for a screen scale of, say, 2.0 (0.5) than it will for 1.0 (1). Intuitively, this seems backwards. For a screen scale of 1, a tolerance of 1 might be too large, whereas for a screen scale of 3, a tolerance of 0. might be too small. If the goal is to account for the results of snapping, then would a fixed tolerance of 0.5 be better? It's possible I'm missing something. - Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1234#pullrequestreview-1635833485 PR Review Comment: https://git.openjdk.org/jfx/pull/1234#discussion_r1331751243
Re: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v5]
> PR adds tests mentioned in the title - a new `AttributesTest` class is added > testing iconification, maximization and full-screen-ification of a Stage. > > All variants are tested with decorated stage style. > > Iconification is tested via overlaying two stages on top of one another, and > then iconifying the top one - this is similar to already existing > `IconifyTest.java` but it tests just the iconfication process and nothing > more. > > Maximization and FullScreen are both tested by creating two stages _not_ > overlapping each other. After maximization/fullscreen top stage (being always > on top as well) should cover the bottom stage. Moreover, FullScreen and > Maximize are differentiated by checking if window decoration exists - > maximized Stage will have its decoration taking space on top of the screen, > whereas FullScreen one will not. > > **NOTE:** on macOS I had issues with `getColor()` returning a valid color > when called a second time. This only happened on macOS and with FullScreen > test (others worked fine). Unfortunately I couldn't figure out why it > returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved > color checks into separate `runAndWait()`-s with a small sleep between them, > which seemed to help `getColor()` return proper values. > > Verified to work on Windows 11, macOS and Linux. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Replace waitForIdle with sleep, add sleep at the end of setupStages - Changes: - all: https://git.openjdk.org/jfx/pull/1240/files - new: https://git.openjdk.org/jfx/pull/1240/files/37e3d31a..130070dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=03-04 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1240.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1240/head:pull/1240 PR: https://git.openjdk.org/jfx/pull/1240
Re: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v4]
On Mon, 18 Sep 2023 13:14:34 GMT, Lukasz Kostyra wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added >> testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and >> then iconifying the top one - this is similar to already existing >> `IconifyTest.java` but it tests just the iconfication process and nothing >> more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ >> overlapping each other. After maximization/fullscreen top stage (being >> always on top as well) should cover the bottom stage. Moreover, FullScreen >> and Maximize are differentiated by checking if window decoration exists - >> maximized Stage will have its decoration taking space on top of the screen, >> whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color >> when called a second time. This only happened on macOS and with FullScreen >> test (others worked fine). Unfortunately I couldn't figure out why it >> returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved >> color checks into separate `runAndWait()`-s with a small sleep between them, >> which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > Lukasz Kostyra has updated the pull request incrementally with one additional > commit since the last revision: > > Fix skip comment on testMaximizedStageBeforeShow > > Comment pointed at wrong JDK issue (aka. Copy-Paste's Error) Added both the `sleep(1000)` at the end of `setupStages` and replaced `waitForIdle` back to sleeps. - PR Comment: https://git.openjdk.org/jfx/pull/1240#issuecomment-1727912898
Re: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo [v2]
On Wed, 20 Sep 2023 07:33:51 GMT, Ajit Ghaisas wrote: >> - Removed README file >> - Added README.md file with details >> >> For formatted output of README.md - See : >> https://github.com/aghaisas/jfx-tests/tree/update_readme > > Ajit Ghaisas has updated the pull request incrementally with one additional > commit since the last revision: > > review fixes Marked as reviewed by angorya (Reviewer). - PR Review: https://git.openjdk.org/jfx-tests/pull/11#pullrequestreview-1635789427
Re: Combining JavaFX with native UI and shaders?
There's this library: https://github.com/Teragam/JFXShader/ Hopefully JavaFX supports shaders in a near future. You can do incredible stuff with them and most recent UI libraries support them. :-) -- Pedro Duque Vieira - https://www.pixelduke.com
Re: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo [v2]
On Wed, 20 Sep 2023 07:33:51 GMT, Ajit Ghaisas wrote: >> - Removed README file >> - Added README.md file with details >> >> For formatted output of README.md - See : >> https://github.com/aghaisas/jfx-tests/tree/update_readme > > Ajit Ghaisas has updated the pull request incrementally with one additional > commit since the last revision: > > review fixes Marked as reviewed by kcr (Lead). - PR Review: https://git.openjdk.org/jfx-tests/pull/11#pullrequestreview-1635372271
Re: Combining JavaFX with native UI and shaders?
The idea behind JavaFX (and most Java API's) is to provide a platform independent API, allowing you to write things once and have it run on all supported platforms. Exposing an API that is only available on one platform would go against that idea. You either need to do a lot of hacking to reach the underlying metal API's, or use JavaFX only as an overlay (having JavaFX run in a transparent child window) while the main window is accessed directly (also needs some hacking), or use another framework more suited to your purpose (maybe one of the gaming frameworks). --John On 20/09/2023 00:04, Rob Nikander wrote: Hi, I’m interested in using JavaFX for a app’s UI, but for parts of the UI I want to use the native OS’s GPU API, to get the maximum possible performance. So on macOS, for example, I want to render it with Metal and write Metal shaders. Is this possible, maybe with help from JNI? Rob
Re: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo [v2]
> - Removed README file > - Added README.md file with details > > For formatted output of README.md - See : > https://github.com/aghaisas/jfx-tests/tree/update_readme Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: review fixes - Changes: - all: https://git.openjdk.org/jfx-tests/pull/11/files - new: https://git.openjdk.org/jfx-tests/pull/11/files/76dcf4ea..2597220a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=11&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=11&range=00-01 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx-tests/pull/11.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/11/head:pull/11 PR: https://git.openjdk.org/jfx-tests/pull/11
Re: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo
On Fri, 15 Sep 2023 15:04:59 GMT, Kevin Rushforth wrote: >> README.md line 50: >> >>> 48: - To run a single test provide - `-Dtests=>> SceneGraphTests/tests>` before `test` in above command >>> 49: >>> 50: 7) **Generating golden images** >> >> terminology: would a "reference images" be a better term? > > The tool uses the term "golden image". Changing it would be a larger change > than just the README file (and probably not worth the effort). Keeping the established term "golden image" - PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1331126908
