xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Sorotokin <psoro...@adobe.com>
Subject Re: FlowText
Date Tue, 03 Feb 2004 01:43:34 GMT
At 04:45 PM 2/2/2004 -0500, Thomas DeWeese wrote:
>Hi Peter,
>   I'm not sure why this isn't being discussed on www-svg as it seems a
>more appropriate forum - please feel free to redirect there.
>Peter Sorotokin wrote:
>>At 07:00 PM 2/1/2004 +0100, Chris Lilley wrote:
>>>TD> yes I consider the changes  detrimental, the new formulation
>>>TD> will be harder to author correctly, and _much_ harder to implement.
>>>So you said. Your comments, along with other folks comments, will of
>>>course be taken into account.
>>I would really like to see the details on why the new formulation is 
>>harder to implement and author. It certainly seems much, much easier to 
>>me than the old one - on both implementation and authoring side.
>    The reason it is harder to implement is because these new test
>attributes have to be made available on every element in SVG.  Thus
>this new 'rendering contextual' behavior must be all the classes
>supporting graphical elements in SVG.  Some of this may be able to be
>moved into base classes but certainly not all of it.

In my opinion things are easy both in case where they apply to all elements
and when they apply to just one element. I do not see this as added complexity.

>     It may be important to note that one of the main purposes of the
>resolution switching code is to avoid the generation of the associated
>rendering tree until needed - in hand with this is avoiding fetching
>external resources until a particular rendering branch is selected.

I understand that this is the way Batik implemented - but it is very much
Batik-specific. Our fetching strategy was always much more aggressive, in part
because of animations. We fetch the image as soon as it is inserted in the
tree (in 1.2 there is a prefetch element that would give us better 

In any case - how this is different from any "switching" attributes? They all
behave like that and have to be implemented this way. One already can simply
modify them with the script.

Also, I don't even think that most of the use for these attributes will come
from the people who want to avoid loading stuff for zoomed view; I think it is
extremely useful to simply avoid cluttering the view with small details. Thus
it is very natural to allow these attributes on all elements - they belong 

>So this is not a simple matter of building the entire rendering tree
>and just deciding if a particular node should paint it's self or not,
>the rendering tree needs to morph as the user navigates.  This
>add another layer of complexity to the whole 'dirty' region management
>because sometimes elements added to the rendering tree are coming
>from DOM manipulations and sometimes from render context changes
>in the first case you want to generate dirty regions for the next render 
>for the later case you don't want to generate dirty regions
>(because the change to render context will cause everything to
>repaint anyways).

I think that if images are to be loaded conservatively (as they should
be in 1.2) it is expected from the UA not to load images which are clipped
out (unless prefetch is specified). This means that pan and zoom should be 
into account already.

>     Add to this issues like a use element that references the same
>multi-resolution content with different scale factors, or the
>'overview' pane in Squiggle (provides a thumbnail view of document
>for navigation) and this get's extremely complex to manage when
>it's allowed to happen on any element anywhere.

I still do not see the problem. I think that once external resource is 
requested (and only
once it is requested), it should be loaded. So one can simply concentrate 
on requesting
resources only when needed for simple implementation.

>     By having a single element that does resolution dependent
>switching this complex code is much more centralized.  The current
>proposal essentially requires adding the functionality of this element
>to every element in SVG.

No, you'd add it only in base element, so it's not like you have to write 
this code
many times. We don't have single element to do opacity, right? And 
"disabling" logic
for required features already should be on every element.

>     There are also deeper architectural issues for Batik because it
>generally builds it's rendering tree up front (this is nice for
>error handling as you know if the document is good or not before
>you go to display it).  This change would strongly push all
>implementations to building the rendering tree 'on the fly' for
>the first rendering.
>     As to authoring, there are two major issues.  First for
>multi-resolution data you almost always want boundary information
>tied to the resolution selecting information.  The 'special
>purpose' element can enforce this (in the few cases where you don't
>really want bounds you can override 'overflow').  By having two
>independent test attributes it is easy to forget the requiredView
>attribute - the effect of this would be a general loss of performance
>something that is easy to miss when all files are local but a big
>mistake when it goes 'live'.

I think that the most useful way is not to load element until it is visible.
I agree that requiredView is not a good idea.


>      Secondly because the requiredView attribute doesn't clip -
>"small" errors in the specification would be _incredibly_ difficult to
>detect, they would generally show up when panning over the document as
>'missing' data pan a little more 'boing' it pops in - ugg!
>      Also I find it ironic that requiredView is considered a test
>attribute for 'switch' as in at least one of it's major use cases
>(tiling content) it can't be used in a switch it must be used outside
>(otherwise at the seams you would lose one or the other tile).
>      Incidentally the boundary information error is not just a
>'what if' this was exactly one of the bugs I ran into - I changed
>some stuff that accidentally disabled the viewport testing, everything
>rendered just fine - it was just a bit slow (I was working with
>local files), it wasn't until I checked in the debugger and noticed it
>fetching/drawing all these 'offscreen' high resolution images that I
>realized why it was slow.  I don't know how an end user would detect
>this, he would likely just think that it was slow. Now this was a
>bug in my implementation not a bug in content but it made it very clear
>to me that it is important that content authors not be allowed to
>easily make the same mistake!

To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message