Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread #255
This pull request modifies
Because the issue only affects the final rendered pixels, I added assertions to catch the error in the Monocle classes
Below are animated images showing a few frames from a JavaFX animation on the Monocle VNC platform before and after the fix.
Before the fix
After the fix
The error occurs with software rendering when a subclass of
In the first case, the non-direct byte buffer method
In the second case,
Most subclasses of
Because of implementation choices, only the Monocle platforms end up having visible errors in their rendered pixels. While there are ways to work around the issue just for Monocle, this pull request is an attempt to correct the error at its source.
To reproduce the problem, I used the JavaFX application epd-javafx with the following command:
$ java --add-modules=javafx.graphics \ --module-path=$HOME/lib/armv6hf-sdk/lib \ -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw \ -jar dist/epd-javafx.jar --pattern=3 --loops=0
You can run the command on an actual ARM device or on a QEMU armhf virtual machine running on an amd64 Linux host. I connected to the Monocle VNC server with the Remmina VNC client on port 5901 with 24-bit color and encryption disabled.
Even without access to an ARM device or virtual machine, you can capture the error on any Linux desktop by adding similar
Let me know if you would like information on installing a QEMU armhf virtual machine, or details on the assertions and
kevinrushforth left a comment
At first glance the fix looks fine (aside from the
I tested this pull request on all of the following platforms:
This is a tricky timing problem on most platforms, so I used rather intrusive techniques to catch the error and verify it was fixed. The bug is easily visible only on the Monocle VNC platform.
I tested the desktop platforms as follows:
I tested the embedded platforms as follows:
This seems to be a safe fix to me. As mentioned in
@jgneff This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type
Since the source branch of this PR was last updated there have been 10 commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge
As you are not a known OpenJDK Author, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@kevinrushforth, @arapte) but any other Committer may sponsor as well.
Your commit was automatically rebased without conflicts.
Pushed as commit d67c47f.