On Wed, 8 Sep 2021 07:52:31 GMT, Florian Kirmaier <fkirma...@openjdk.org> wrote:
>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer
>> is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race Condition in the resource pool, but
>> a new one is created for the Printing Thread.
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8271395
> QuantumRenderer is no longer public
Inline
modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
line 451:
> 449: try {
> 450: CountDownLatch latch = new CountDownLatch(1);
> 451:
> com.sun.javafx.tk.quantum.QuantumRenderer.getInstance().execute(() -> {
Minor: this is in the same package, so you don't need the full package name. As
long as you are making other changes, you might change this, too.
A bigger question is that I think this is the first time we've used execute
directly. I'm not sure that's a problem, but want to take a second look at it.
The other places where we run a job on the renderer all use
`Toolkit.getToolkit(). addRenderJob()`, which ultimately calls `submit()`.
modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
line 453:
> 451:
> com.sun.javafx.tk.quantum.QuantumRenderer.getInstance().execute(() -> {
> 452: runnable.run();
> 453: latch.countDown();
If you do stick with the current approach, you would need a try / finally here,
to avoid blocking the caller indefinitely. But in that case the exception isn't
thrown back to the caller. I think using the existing method that returns a
Future might be better.
-------------
PR: https://git.openjdk.org/jfx/pull/618
