Re: SVG12: Text Layout vs Scripting

Thomas,
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.

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.

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.

Jon

At 05:21 AM 1/12/2005, Thomas DeWeese wrote:

>Bjoern Hoehrmann wrote:
>>* Thomas DeWeese wrote:
>>
>>>>Thus, please change the SVG 1.2 Working Draft such that it is clear that
>>>>calling forceRedraw() has the desired effect (text layout for all text
>>>>content elements in the document tree is completed and consequently the
>>>>text layout depended method calls such as getComputedTextLength() and
>>>>getBBox() work as expected)
>>>
>>>    Please _don't_ do this!
>>You seem to imply that forceRedraw() currently does not necessarily
>>cause this and that it should not cause this. Maybe you can clarify
>>why you think so or what you mean instead?
>
>    I don't think any SVG DOM calls should depend on calling
>forceRedraw().  This would be a horrible hack.  As to weather
>forceRedraw currently does or doesn't cause this behavior I have no
>idea for ASV, I know it does nothing for Batik.  If the implementation
>can render the document (i.e. forceRedraw will work) then the
>implementation can and should have these methods work, without
>requiring people to call some 'magic' method.
>
>>>   I'd be curious how you came to this conclusion, because I just
>>>checked Batik and ASV and both of them behave this way (getBBox works
>>>on text that has been dynamically created and inserted into the
>>>document, before any rendering has happened).  In my mind this is the
>>>only reasonable solution.
>>With Adobe SVG Viewer 6.0 Build 38363 the following [...]
>>does not work reliably, especially when re-loading the document, most
>>of the time a computed text length of 0 will be reported. Sometimes an
>>accurate length is reported though, so maybe you've hit some kind of
>>race condition. Adobe SVG Viewer 3.0x is subject to the same problem as
>>far as I can tell.
>
>    So I only get this problem with the _Beta_ ASV 6.0 on IE (your
>test works fine with ASV 6.0 and Mozilla, and on all my browsers for
>ASV 3.02).  I would be curious to hear what Adobe has to say but I
>would personally write this off as a bootstrapping bug in 6.0.
>
>>   <svg
>>     xmlns               = "http://www.w3.org/2000/svg"
>>     version             = "1.2"
>>   >
>>   <text y = '100' font-size='50'>
>>     <tspan onload="alert(evt.target.getComputedTextLength())"
>>     >Scalable Vector Graphics</tspan>
>>   </text>
>>   </svg>
>
>

Received on Wednesday, 12 January 2005 14:01:12 UTC