Archie Cobbs-2 wrote: > > One possibility might be to make the changes, serialize the document, > then repair all the changes all within a single Runnable executed > within the update manager thread. Then the "redraw" would end up being > a no-op. >
That was originally what I tried, but all of my methods that modify the DOM, including the one that flips the visibility of layers, themselves do their work in in update manager's thread, so calling them naively causes them to get queued after the serialization thread. I just added code that checks if we are already running in the update manager thread, and if so, skip the enqueing. Works great. This is just like the EventQueue.isDispatchThread() boilerplate I have in some of my Swing code - don't know why that didn't occur to earlier. Thanks! Archie Cobbs-2 wrote: > > In fact, depending on your application design it may be incorrect to > serialize the DOM from anywhere BUT the update manager thread, due to > the risk of getting an inconsistent "snapshot" caused by races with > other DOM updates. > Right, which is why I thought I probably would need to suspend the update manager. -- View this message in context: http://www.nabble.com/update-DOM-without-rendering-tf3705320.html#a10364689 Sent from the Batik - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
