Archie Cobbs wrote:
Thomas DeWeese wrote:
This _is_ precisely what stopProcessing does. Note that the canceled event may be delayed a while (in many cases the current action, parse, build, render may complete, however the next 'phase' will not start).
Ok, that makes sense... so this implies that no matter what happens, any phase that is reported as having started is always subsequently reported as having been either canceled or completed...
Correct, it may also report that it is 'failed', although stopping processing should not directly make this happen.
While I've got your ear, here's another unanswered email...
I'm trying to understand what threads are doing what in Batik when using JSVGCanvas and have some basic questions...
- When manipulating the DOM, the UpdateManager's thread must be used. Are listeners are notified by the same thread in which the actual manipulation is done? So the next manipulation in the run queue does not happen until all listeners are notified of the previous change?
Correct, when the DOM is changed (from the UpdateManager thread) all effected listeners are called immediately. Thus all the listeners are notified even before the DOM call completes.
- 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.
Has anyone had to do manual "buffering" of DOM changes to avoid the rendering getting to far behind?
I have not had to do this. My personal suspicion is that you are simply trying to do too much - the system really can't keep up. Obviously turning off updates for a while lightens the load but at the cost of reducing interactivity. There is no advanced load balancing in the UpdateManager (time stamping runnables and checking how old the average runnable is and adjusting the frequency of rendering, introducing waits when people try to add runnables, etc) but neither is it totally stupid.
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....
http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=3928
It seems from my observation that the rendering can in fact get arbitrarily far behind (this is why I need to use suspend() and resume() (as described in aforementioned bug)). Can you confirm that this is indeed the case?
Well it is a queue if you add things faster than it can take them out it will get behind. This can happen regardless of rendering (for example if you add runnables with wait(1000) and add 10 a second the queue will just keep getting longer - even though no rendering takes place).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
