Re: SVG12: Text Layout vs Scripting

Hi Jon,

Jon Ferraiolo wrote:

> Actually, I agree with Bjoern here. I would expect that forceRedraw() 
> does exactly what it says (i.e., the display gets updated and thereby 
> made current) and I agree with Bjoern that the implicit requirement that 
> goes along with this is that all pending processing to make the document 
> current and the updated presentation correct should also happen.

    Sure, I wasn't really arguing that forceRedraw might not have
his desired effect, of course putting in a wait 10,000 would also
likely have the desired effect - that doesn't mean it should be
codified in the standard!

> My understanding of forceRedraw() is that it is an 
> optimization-inhibitor. The SVG processing model is that with every DOM
> change, everything in the extended DOM gets recomputed and the display 
> is updated. However, if a user agent were implemented in this manner, 
> performance sometimes would be too slow and the screen would flicker too 
> much.

    Sure.

> Instead, a common implementation approach is to have intelligent update 
> logic within the user agent that batches various operations and update 
> the display only when idle loop processing occurs and all other update 
> logic (other than redisplay) has happened. For example, perhaps keyboard 
> input is given the highest priority and keyboard input gets pulled off 
> the queue before text layout and screen redisplay occurs. If you put 
> forceRedraw() in your key event handler, then you could disable this 
> user agent optimization, force a full update of the DOM (including 
> getBBox(), etc), and of course update the display.

    My point is that if you already have the code to make forceRedraw
work.  Which would be as you say, to first force a full update of the
DOM, and then update the display, there is no reason not to have
getBBox first check a dirty bit (is the DOM for this node up to date?)
and if not bring the DOM up to date using the same code as is in the
first step of forceRedraw.

    Is there some reason you think users will _want_ getBBox to return
non-sense results?  Or do you believe (as I do) that in _every_ case
where users would get a nonsense result the desired behavior is to
get the real result - in which case the implementation would always be
correct, and not introduce unneeded overhead (and actually save by
potentially not doing the repaint), by revalidating the DOM.

    Additionally, a good implementation may be able to restrict the
DOM update to just the node (or node and ancestors) in question.

Received on Wednesday, 12 January 2005 14:21:19 UTC