Travis Furrer

I ran into the exact same question today. I believe something like the following code (which makes use of [org.testfx.util.WaitForAsyncUtils](https://testfx.github.io/TestFX/docs/javadoc/testfx-core/javadoc/org.testfx/org/testfx/util/WaitForAsyncUtils.html)) may be a solution: ``` waitForAsyncFx(10000, () -> { waitFor(10,...

Multi-threaded capability and implementations of the asynchronous APIs would be a terrific step forward! I assume this would require some non-trivial changes to provide the necessary thread safety, correct?

@kevinrushforth any updates on this issue? While trying to convert my large project over to modules, I got stuck on this exact same thing. However in my case, the resources...

I see that this behavior has come up twice in issues, but each time it was dismissed because the discussion was not purely about the computational cost of the matcher....

I'd like to add that during the super-slow rendering, there is a single "COM surrogate" process which appears to be using as much CPU time as is possible for a...

Just to add to the hypothesis put forth by @KaiHuaDou, I saw (via the "Details" tab on Task Manager to see PIDs) a separate new "PowerToys.SvgThumbnailProvider.exe" process for each individual...

Here's one hard data point: I'm seeing it take 3-4 seconds to render each trivial SVG (simple icons). This is with PowerToys 0.66.0 on Windows 11, a high-performance CPU, with...

I just hit this too. Of course another workaround (for us gradle folks) is to use forkEvery=1. That results in significantly increased test suite runtimes, but since TestFX suites already...

Ran into same problem. I was able to get it working simply by editing the ScenicView launcher script to add the following: --add-opens org.scenicview.scenicview/org.scenicview.view.tabs=javafx.base

I ultimately ended up just creating an alternate run configuration (only for use when debugging with this tool) which places everything on the classpath instead of the modulepath. This prevented...