-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8335468: [XWayland] JavaFX hangs when calling java.awt.Robot.getPixelColor #22131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back azvegint! A progress list of the required criteria for merging this PR into |
@azvegint This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 200 new 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 this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I tested it on an Ubuntu 24.04 system running Wayland both with and without the FX fix in openjdk/jfx#1639
@honkar-jdk or @prrace Do one of you want to review this? |
Sure Kevin. I can take a look at it later today. |
Tested the changes on Ubuntu 24.04 with JDK alone (without JFX fix) and did not observe any issues in Robot related tests (automated + manual). Since this is an interop fix, I'll be testing it JDK + JFX fix next. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, tested without/with jdk fix and without/with jfx fix combinations.
Interop tests work as expected with jdk + jfx fix.
/integrate |
Going to push as commit 965aace.
Your commit was automatically rebased without conflicts. |
This is a linux only issue and this PR contains two parts(they are available as two separate commits):
a. 8335468: [XWayland] JavaFX hangs when calling java.awt.Robot.getPixelColor
b. 8335469: [XWayland] crash when an AWT ScreenCast session overlaps with an FX ScreenCast session
b.
is not reproducible withouta.
being fixed.More about both cases:
a.
Previously we used a blocking
g_main_context_iteration
call, this prevents normal execution if there is a GTK main loop running in the process.Now we are handling 3 cases:
If there is no GTK main loop running
Example: just a JDK only application.
In this case we call
g_main_context_iteration(NULL, TRUE)
as before (whengtk_main_level() == 0
).If there is a GTK main loop running, but we are not requesting pixels on its thread
Example: application showing a
JFXPanel
, but are requesting pixels from a main thread.Now we are not trying to block thread:
g_main_context_iteration(NULL, FALSE)
(whengtk_main_level() > 0
) .If there is a GTK main loop running, and we are requesting pixels on its thread
Example: a JavaFX application trying to get pixels on the FX application thread, e.g. from a button callback.
Now we go nested with
gtk_main()
jdk commit
b.
After fixing
a.
the crash appears:Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
This is to reduce overhead in case of frequent consecutive screen captures.
When we perform a cleanup to close the session, we internally call
pw_deinit
.It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by
pw_init
(please note thatThis function can be called multiple times.
).So the solution is not to call
pw_deinit
because we don't really need it, and it needs to be applied to both the JDK and JavaFX.jdk commit / jfx commit
FX review counterpart
Testing in different scenarios looks good.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22131/head:pull/22131
$ git checkout pull/22131
Update a local copy of the PR:
$ git checkout pull/22131
$ git pull https://git.openjdk.org/jdk.git pull/22131/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22131
View PR using the GUI difftool:
$ git pr show -t 22131
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22131.diff
Using Webrev
Link to Webrev Comment