Thomas DeWeese wrote: > >> - When many changes to the DOM are made in rapid succession, can > >> the re-rendering process get arbitrarily far behind? Or does it > >> know how to interrupt and restart itslef as soon as a new change > >> is made? > > Changes are never made while rendering is occurring. Currently > when most runnables in the UpdateManager queue complete it checks > if the rendering tree has any changes. If it doesn't it goes to > next next runnable. > > If it does have changes it checks if it has very recently rendered > the document (see UpdateManager.MIN_REPAINT_TIME) if so it checks if > there are other 'repaint' runnables in the run queue if so, it does > not render the document. > > Otherwise it updates the rendering of the document. > > This system should ensure that a flood of small runnables > will not 'clog' the system as it will execute a number of them > before MIN_REPAINT_TIME is reached. > > It is probably worth noting that there is a tagging interface > 'NoRepaintRunnable' which will inhibit calling repaint when the > runnable completes.
Thanks for this explanation, that helps a lot. I played with this value and got somewhat better results. I think you are correct that the underlying reality is that my updates are time consuming :-) > I don't know what your runnables look like, if they each just > tweak one small thing this probably isn't good (although I honestly > think the system should handle this case pretty well), if you are > already do a lot of stuff in each runnable I suspect that the system > simply can't keep up with the demand.... I have a map with a bunch of rooms, and what I'm doing is changing the fills in each room to make them different colors, gradients, etc. It's useful to "batch" together all the initial updates that color all the rooms when the map is first loaded. One thing that's interesting is that it seems that adding/modifying the "fill" attribute of a <polygon> directly updates slightly faster than adding a new <use> element which references the <polygon> with a different "fill". Must be due to the creation of a new GVT node in the latter case but not the former? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
