-
Bug
-
Resolution: Fixed
-
P2
-
6.1
-
b01
-
x86
-
linux
-
Not verified
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.
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.