Use SwingWorker for Safe Async UI Modification#14756
Use SwingWorker for Safe Async UI Modification#14756johannes-wolf wants to merge 1 commit intomagefree:masterfrom
Conversation
| this.jPanel.remove(mageCard); | ||
| }); | ||
| t.start(); | ||
| SwingWorker<Void, Void> worker = new SwingWorker<Void, Void>() { |
There was a problem hiding this comment.
SwingUtilities.invokeLater instead?
There was a problem hiding this comment.
With SwingWorker, Plugins.instance.onRemoveCard(mageCard, count); runs on a non-Swing thread, but the done() callback gets called on the EDT. So I guess, for this scenario SwingWorker might be better, as it does not block the EDT.
But I can change it to SwingUtilities.invokeLater if you want to.
|
Yes, it’s important to modify GUI in swing thread only, e.g. on gui events/methods. If some game code must modify GUI/component like card then it must modify data only or call it inside a swing thread like PR example with invokelater. All that exceptions with miss/null inner component are related to that restricted gui modification from other threads. |
|
There is a helper method to find such use cases: ThreadUtils. ensureRunInGUISwingThread 
|
johannes-wolf
force-pushed
the
fix-battlefield-async-panel-access
branch
from
915e898 to
f519458
Compare
|
Closed. I will provide a better fix in a new PR. |
2 participants
It is not allowed to modify UI in a raw
Thread, so we must useSwingWorkerfor async operations that modify the UI on completion (https://docs.oracle.com/javase/8/docs/api/javax/swing/SwingWorker.html).This could potentially fix some of the UI bugs/crashes.
(Second fix in
doClickseems only used by tests but should also not useThread.)