Hi Lukasz,
Lukasz Matuszczak wrote:
In my fight with SwingGraphicsNode I'm trying to repaint it (inside JSVGCanvas) after intercepting repaint method call on a swing component. I'm calling fireGraphicsNodeChangeStarted() and fireGraphicsNodeChangeCompleted() in overridden repaint() method but I don't see any results until there is some mouse event sent to JSVGCanvas.
I've found out that UpdateManager must be somehow notified about new changes, but I can't call UpdateManager.repaint() directly because it's protected.
Thus my current solution is:
Well you shouldn't be calling the fireGraphicsNodeChangeStarted/Completed methods outside of the UpdateManager thread (or else you risk concurrent modification exceptions). So I would suggest that the correct thing is:
public void repaint(long tm, int x, int y, int width, int height) {
ctx.getUpdateManager().getUpdateRunnableQueue().invokeLater(
new Runnable() {
public void run() {
fireGraphicsNodeChangeStarted();
fireGraphicsNodeChangeCompleted();
}
});
}
}It looks terrible, but it almost works (sometimes the component seems to be not repainted, or repainted too late). I would like to know if there is another proper way to force node to be repainted.
No the UpdateManager (as it's name would suggest) is the manager of all updates/repaints. Since the updates/repaints can not occur while the DOM/GVT are being modified the the only proper way to trigger a repaint is to have control of the update thread. I wouldn't be surprised if your issues with repaints are related to not calling changeStarted/completed from the Update Manager thread. You should be aware that like with swing if someone/something is 'tying up' the UpdateManager thread your updates will be delayed until they are done.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
