Hi Cameron, Cameron McCormack <[EMAIL PROTECTED]> wrote on 09/26/2008 02:14:22 AM:
> I?m debugging threading issues in my application, which is based on > JSVGCanvas. I wasn?t doing any correct Swing threading for a start, and > now I want to ensure that all of my interactions with the JSVGCanvas are > performed correctly. Ok. > Now I know (as we all do :)) that modifications to the document that is > currently displayed in the canvas must be done in the UpdateManager?s > RunnableQueue. What about any other calls to public methods on > JSVGCanvas: should they be done in the Swing event dispatch thread? Yes, that is the design. All interaction with the Swing component should be done in the Swing thread. > Canvas listeners (like GVTTreeBuilderListener) are fired in the Swing > event dispatch thread, yes? Uhh, yes I think. Something tickles the back of my memory that we didn't fire all of those listeners in the Swing thread (which is probably a bug). It may be that they were fixed however. > And how about public methods on the BridgeContext: do they need to be > done in the UpdateManager?s RunnableQueue too? For example, if I call > BridgeContext.getGraphicsNode(), will that need to be in the > RunnableQueue because the elementNodeMap will possibly be modified > because of document modifications in the UpdateManager thread? Correct, the Bridge context is effectively part of the DOM. Since you mention getGraphicsNode I'll extend that statement to also include the GVT tree... So all GVT methods should also be called in the UpdateManager's thread. Hope that helps.
