United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6729405 Java with GTK L&F freezes(slows down repeatedly) when embedding Mozilla/XulRunner
6729405 : Java with GTK L&F freezes(slows down repeatedly) when embedding Mozilla/XulRunner

Details
Type:
Bug
Submit Date:
2008-07-24
Status:
Closed
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2009-05-18
Component:
client-libs
OS:
linux
Sub-Component:
javax.swing
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6.1
Fixed Versions:
6u14

Related Reports

Sub Tasks

Description
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.

Comments
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.
2008-11-27 
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.
2008-07-24


Hardware and Software, Engineered to Work Together