Bug #1225
Updated by Sebastien Jacquot over 6 years ago
Charts don't work anymore on MAC OS X with last setup.
All SWT/AWT bridges in Composite are affected:
R chart engine, JFC chart engine and "old" SVG Batik Editor (it's the one used when opening an SVG file from the "File" view)
SWT_AWT bridging is bugged with the couple SWT 4.4 (or >= 4.0 ?) + JRE 7/JRE 8 on MAC OS X
With R chart engine and "old" SVG Batik Editor => TXM hangs up
With JFC charts engine => TXM slows down and the chart is not displayed/refreshed
Involved classes:
* /org.txm.rcp/src/main/java/org/txm/rcp/chartsengine/jfreechart/swt/JFCComposite.java
* /org.txm.rcp/src/main/java/org/txm/rcp/chartsengine/svgbatik/swt/SVGComposite.java
* /org.txm.rcp/src/main/java/org/txm/rcpapplication/svg/SVGComposite.java
If someone think about some other AWT/SWT bridges in TXM RCP, please let me know.
See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=418245
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-November/006252.html
https://bugs.openjdk.java.net/browse/JDK-8020165
h3. Solution 1
Asynchronously call Call the frame.setVisible(true) in the an asynch thread Swing thread (invokeLater()) or in the SWT main thread (Display.getDefault().asyncexec()) thred
h3 .Observation .Conclusion
The JFC charts are well displayed but the UI and the refresh of the chart are slowed. Plus, the asynchronous call may be problematic since the chart editor part needs the chart to be constructed so it's too strongly linked to the runtime execution context
h3. Solution 2
Keep Java 1.6 as embeded JRE version
h3. Important note
This note is also strongly linked to the choice of the JVM version that will be embedded embeded in TXM. It seems one of the next Oracle JVM direction is to switch from Swing to JavaFX as default GUI API. JavaFX is now natively included in Java 8 API.
h3 .Conclusion
The only viable solution seems to stay in Java 1.6 for the embedded JVM version.
h3 .Validation tests
All SWT/AWT bridges in Composite are affected:
R chart engine, JFC chart engine and "old" SVG Batik Editor (it's the one used when opening an SVG file from the "File" view)
SWT_AWT bridging is bugged with the couple SWT 4.4 (or >= 4.0 ?) + JRE 7/JRE 8 on MAC OS X
With R chart engine and "old" SVG Batik Editor => TXM hangs up
With JFC charts engine => TXM slows down and the chart is not displayed/refreshed
Involved classes:
* /org.txm.rcp/src/main/java/org/txm/rcp/chartsengine/jfreechart/swt/JFCComposite.java
* /org.txm.rcp/src/main/java/org/txm/rcp/chartsengine/svgbatik/swt/SVGComposite.java
* /org.txm.rcp/src/main/java/org/txm/rcpapplication/svg/SVGComposite.java
If someone think about some other AWT/SWT bridges in TXM RCP, please let me know.
See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=418245
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-November/006252.html
https://bugs.openjdk.java.net/browse/JDK-8020165
h3. Solution 1
Asynchronously call Call the frame.setVisible(true) in the an asynch thread Swing thread (invokeLater()) or in the SWT main thread (Display.getDefault().asyncexec()) thred
h3 .Observation .Conclusion
The JFC charts are well displayed but the UI and the refresh of the chart are slowed. Plus, the asynchronous call may be problematic since the chart editor part needs the chart to be constructed so it's too strongly linked to the runtime execution context
h3. Solution 2
Keep Java 1.6 as embeded JRE version
h3. Important note
This note is also strongly linked to the choice of the JVM version that will be embedded embeded in TXM. It seems one of the next Oracle JVM direction is to switch from Swing to JavaFX as default GUI API. JavaFX is now natively included in Java 8 API.
h3 .Conclusion
The only viable solution seems to stay in Java 1.6 for the embedded JVM version.
h3 .Validation tests