Support #894
Mis à jour par Sebastien Jacquot il y a plus de 10 ans
Only for Mac OS X, TXM freezes during its initialization and the splash screen never ends.
*Hypothesis 1* :
It seems to be due to a SWT/AWT mix problem. We can't neither identify nor reproduce this bug at this moment. It may be linked to specific configuration (there are some known bugs in JVM 7 + Cocoa according to the JVM version).
It may be due to JFreeChart initialization during the Toolbox initialization that causes a deadlock with the UI thread. "ImageIO.getWriterFormatNames();" call (in ChartsEngine.populateSupportedOutputRasterFileFormats) may be the reason.
*Solution 1*
For Mac OS X, deactivate the call to ImageIO
*Conclusion 1*
I still had a few hang up after this fix but I don't know if it's the same problem.
*Solution 2*
Another solution may be to lazy initialize the ChartEngine just before we need it. And then avoid UI thread deadlock.
*Solution 3*
Since we can not reproduce this bug, wait until we can study an involved machine where the hang up occurs and get some information about the JVM threads stack to exactly determine which class are involved in the blocking process.
*Temporary workaround*
If TXM freezes at splash screen on Mac OS X, to kill TXM process, press CMD + ALT + ESC then select TXM in the opened dialog box then "Force Quit" and confirm.
Starting TXM with R charts engine does not hang up. So we can edit "org.txm.rcpapplication.prefs" to force the R/SVG mode, then run TXM, the 2 involved parameters/lines should be replaced as following:
<pre>
charts_engine_name=r_charts_engine
charts_engine_output_format=svg
</pre>
Once it launched, use the parameters UI entry to switch back to JFC charts engine.
*Hypothesis 1* :
It seems to be due to a SWT/AWT mix problem. We can't neither identify nor reproduce this bug at this moment. It may be linked to specific configuration (there are some known bugs in JVM 7 + Cocoa according to the JVM version).
It may be due to JFreeChart initialization during the Toolbox initialization that causes a deadlock with the UI thread. "ImageIO.getWriterFormatNames();" call (in ChartsEngine.populateSupportedOutputRasterFileFormats) may be the reason.
*Solution 1*
For Mac OS X, deactivate the call to ImageIO
*Conclusion 1*
I still had a few hang up after this fix but I don't know if it's the same problem.
*Solution 2*
Another solution may be to lazy initialize the ChartEngine just before we need it. And then avoid UI thread deadlock.
*Solution 3*
Since we can not reproduce this bug, wait until we can study an involved machine where the hang up occurs and get some information about the JVM threads stack to exactly determine which class are involved in the blocking process.
*Temporary workaround*
If TXM freezes at splash screen on Mac OS X, to kill TXM process, press CMD + ALT + ESC then select TXM in the opened dialog box then "Force Quit" and confirm.
Starting TXM with R charts engine does not hang up. So we can edit "org.txm.rcpapplication.prefs" to force the R/SVG mode, then run TXM, the 2 involved parameters/lines should be replaced as following:
<pre>
charts_engine_name=r_charts_engine
charts_engine_output_format=svg
</pre>
Once it launched, use the parameters UI entry to switch back to JFC charts engine.