JDK-6729405 : Java with GTK L&F freezes(slows down repeatedly) when embedding Mozilla/XulRunner
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2008-07-24
  • Updated: 2011-01-19
  • Resolved: 2009-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u14 b01Fixed
Note: The product release specified is not correct (correct value was not available), the correct would be "future".

We are working on integrating/embedding Mozilla/Xulrunner 1.9 into NetBeans IDE. We have hit this issue.
We are using JDK 6 or JDK 7 respectivelly. The problem occures with GTK L&F. It freezes (stops until internal timeout expires) repeatedly, and causes it to be unusable. It is caused by thread unsafe control of paiting of GTK L&F.
Our engineer (Michal Ceresna) provides a solution for the problem, which would make painting thread safe (see suggested fix - it would be in GTKNativeEngine clas).

Here I am attaching Michal's more comprehensive description:
Let me sum up the status of the current implementation on linux.

There are four look&feels shipped with swing under linux:
Metal, Motif and 2 different implementations for Gtk.
Out of those, one implementation of the Gtk l&f  freezes
in one particular place. No other problems are known
when using the other looks&feels

On the other side, mozswing has now an implementation
of the gtk event loop spining that I consider to be technically
the right solution.

The reason is, that the integration of swing and gtk happens
on the toolkit level and therefore:

*) independent of the mozilla and used mozilla version
*) future proof
*) capable of including other gtk-based native components
   in the same swing application (e.g. a movie player)

However it has problems to coexist with the native implementation
of gtk l&f. The reason of the problem is that the native gtk l&f
implementation does that expect other gtk code (=mozilla) to be running
in-process inside of the same swing application.

EVALUATION I decided to postpone the fix until 6u14 because it's gonna be a high risk fix. It will have one more synchronization, dynamic loading of one more native library for gdk_threads_enter/gdk_threads_leave methods and extra testing.

SUGGESTED FIX Also here attaching Michal's comment about the nature of possible fix: I've succeeded today to create a patch for the gtk l&f that fixes the problem. The fix is just 2 lines of code and adds proper gtk locking to the l&f and so makes the l&f thread safe: public class MyGTKNativeEngine extends GTKNativeEngine { @Override public void startPainting(Graphics g, int x, int y, int w, int h, Object... args) { Gtk.gtk.gdk_threads_enter(); super.startPainting(g, x, y, w, h, args); } @Override public void finishPainting() { super.finishPainting(); Gtk.gtk.gdk_threads_leave(); } } Now you should decide if this is an acceptable solution for the problem, or I should work on the another option.