KeyCode in the javafx.scene.robot.Robot interface
Hello! I maintain a test harness for JavaFX applications: https://www.github.com/io7m-com/xoanon I expose an interface that uses the javafx.scene.robot.Robot interface internally, but I expose a slightly higher level API that allows for (amongst other things) typing text as strings on components rather than sending individual key codes. The problem I immediately run into is that KeyCodes are keyboard layout specific, and there doesn't appear to be any way to detect what keyboard layout is in use. If I, for example, send the KeyCode for the `@` symbol, I'll actually get `"` on some keyboard layouts. This can cause some types of tests to fail, even though the code is correct. Consider a test where an email address is typed into a text field, and then the form containing the field is checked to see if the text field accepted/rejected the text as being a valid email address. On some keyboard layouts, a test that sends the string "some...@example.com" will fail because what ends up in the text field is actually "someone"example.com". I provide a workaround for this: At the start of the test suite run, xoanon will send every KeyCode to a text field one at a time and see what character appeared in the text field as a result. It then builds a mapping between characters to KeyCodes, and it can then do the translations as necessary when running the rest of the test suite: https://github.com/io7m-com/xoanon?tab=readme-ov-file#keymap-generation Unfortunately, this is still rather flaky. This often seems to fail more or less at random for reasons that aren't clear to me. Is there some way the Robot interface could be extended to allow for typing strings? Failing that, is there some way JavaFX could advertise the underlying keyboard map? I feel like some underlying component must know the information I'm trying to infer, but it doesn't seem to be exposed anywhere that I've been able to find. -- Mark Raynsford | https://www.io7m.com
Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v11]
> Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, > fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to > EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on > X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Use prismES2EGLX11 as build name - Changes: - all: https://git.openjdk.org/jfx/pull/1381/files - new: https://git.openjdk.org/jfx/pull/1381/files/51c35579..47985493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=09-10 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381
Re: RFR: 8322964: Optimize performance of CSS selector matching [v9]
On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff Looks good to me. - Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2051622575
