I've implemented Windowed Rendering support for Linux...

[Slartie]

...and it appears to be working just fine, but as I didn't know much about X11 development and am also pretty new to CEF and JCEF as well, I wanted to post this here for review. I guess it's mostly of interest to the project maintainer, magreenblatt Maybe it's good enough to possibly add it to the official JCEF version? The omission of windowed rendering on Linux seems like a big missing feature to me that should really be adressed.

You can see the changes on a branch I created in a forked JCEF (and CEF) repo on Github: https://github.com/S1artie/java-cef/com ... 76bbb85cc8 - I'm personally more a Github user than Bitbucket, but I'd of course be glad to create a "real" pull request on Bitbucket with these changes if desired. Otherwise, feel free to pull the changes from my Github commit.

I have encountered multiple...let's say "challenges"...during the process and have added extensive commenting to the commit linked above explaining my motivations and findings. Unfortunately there's even one mandatory change to CEF itself, as you can see in the comments, but I guess it is a pretty trivial one.

[magreenblatt]

Awesome! Thank you for sharing this I had just started trying to implement this myself and had not yet discovered XInitThreads to resolve the xlib message handling issues.

[magreenblatt]

Can you also share a PR for your CEF change that you made?

[Slartie]

It's linked in the biggest of the commit comments here: https://github.com/S1artie/java-cef/com ... #r30374319

That links to the CEF fork commit over here: https://github.com/S1artie/cef/commit/0 ... 66e6197843

That one just allows multithreaded message loops on Linux as well, which was a requirement to get the JCEF changes to work.

[magreenblatt]

I've been looking at implementing multi-threaded message loop support in cefclient on Linux. cefclient uses GTK, so I was thinking I need a separate GTK/GLib message pump from Chromium's. However, this doesn't appear to be supported by GLib (see, for example, this comment in MessagePumpGlib: https://cs.chromium.org/chromium/src/ba ... &g=0&l=146). Chromium uses g_main_context_default, and even if I create a separate GMainContext in cefclient it seems to only execute messages on one of the message pumps (mine, or Chromium's). I've uploaded my work-in-progress patch against 3497 branch here: http://magpcss.net/files/linux_multiloop_3497.patch

Do you have any experience with this?

[Slartie]

Unfortunately not, all this Linux windowing and window toolkit stuff is pretty new to me and I was basically fishing in murky waters all the time while implementing my patches, learning about the different bits and pieces while stumbling around in the codebase. Regarding multi-threaded message looping in particular, I just decided to blindly remove the restriction at some point in a desperate attempt to see what would happen, because I was just getting super-weird window behavior all the time and nothing appeared to help, and to my surprise it actually appeared to work I did not yet see any negative effect up until now, but that might be only because of my very constrained test case (after all I was just interested in getting Java CEF to run on Linux, so I didn't look at the more general CEF use case for integration in native applications).

[magreenblatt]

Thanks, I managed to figure it out. The key is to call `g_main_context_push_thread_default` after creating the GMainContext, and then be sure to call gdk_threads_enter/gdk_threads_leave as described here: https://www.geany.org/manual/gtk/gtk-faq/x482.html. And then some extra stuff to keep yourself from deadlocking constantly while refactoring due to the default GDK global lock not being re-entrant.

[magreenblatt]

Multi-threaded message loop support for Linux added to CEF in https://bitbucket.org/chromiumembedded/cef/issues/2512

[magreenblatt]

I'm testing your JCEF commit with the detailed sample app and the new CEF build that supports multi-threaded message loop. Everything so far is working great except if I try to click one of the top menus. When that happens the whole Java application window stops responding. If I run with an OSR browser then the top menu behaves as expected. Here are the detailed app changes to work with your commit, which I'm otherwise using as-is:

Code: Select all

diff --git java/tests/detailed/MainFrame.java java/tests/detailed/MainFrame.java
index 3ec4d8c..352dc59 100644
--- java/tests/detailed/MainFrame.java
+++ java/tests/detailed/MainFrame.java
@@ -44,12 +44,12 @@ public class MainFrame extends BrowserFrame {
     public static void main(String[] args) {
         // OSR mode is enabled by default on Linux.
         // and disabled by default on Windows and Mac OS X.
-        boolean osrEnabledArg = OS.isLinux();
+        boolean osrEnabledArg = false;
         boolean transparentPaintingEnabledArg = false;
         String cookiePath = null;
         for (String arg : args) {
             arg = arg.toLowerCase();
-            if (!OS.isLinux() && arg.equals("--off-screen-rendering-enabled")) {
+            if (arg.equals("--off-screen-rendering-enabled")) {
                 osrEnabledArg = true;
             } else if (arg.equals("--transparent-painting-enabled")) {
                 transparentPaintingEnabledArg = true;


Have you seen this issue?

[magreenblatt]

The top menus issue is fixed by also adding this code to the detailed app:

Code: Select all

if (OS.isLinux()) {
  // This is crucial to get Linux Windowed Rendering to function correctly!
  // The initXlibForMultithreading call must be done before ANY other call
  // to Xlib from this process, including calls from the Java runtime.
  System.loadLibrary("jcef");
  CefApp.initXlibForMultithreading();
}