Re: [Rendering Order] Some early feedback

Hmmm,
a nasty author can simply put a g-element around any element to
be able to reorder all rendered elements. 
This mainly blows up the source code and shows that this
approach does not prevent authors using it in a way, hard to
interprete by a viewer ;o)

On the other hand, one can do this right now with SVG1.1
with a simple trick, if things are predictable and simple
enough:
Just put all g-groups (or elements) in the defs element
and reference them with use elements. Then animate
the xlink:href of the use elements to get the intended
rendering order ;o)


My use case:
Consider a planet moving around a sun (sideview).
Sometimes the planet is in front of the sun, sometimes
behind. One has to change the rendering order in
a time dependent way. Currently I do this with the
trick mentioned above (or with two planets, one 
behind and one in front and some display:none 
sometimes for the front one). Of course this can get
more complex in a complete planetary system
with several planets and maybe moons,
especially because this has typically no short
periodicity, required for a simple declarative
animation as available with SVG1.1.

If as proposed render-order is animatable, 
one can simply map the distance in the direction
perpendicular to the canvas into render-order
numbers and animate render-order with these
values - this solves the problem of the complex
planetary system without short periodicity and looks
already pretty useful (for other applications with
not simply predictable changes of the render-order
too, of course).
Therefore it could be even more convenient to
allow floating point numbers instead just integers.
This saves some computing efforts to transform the
coordinate into a large integer.



As far as I understand the example, the g with a
largest render-order is on top - as far as I have seen,
this is not formally defined, should be done of course ;o) 
Should be noted too, what happens, if two g elements
have the same render-order. I assume, that the last in the
source code is on top.
If referenced with use - this property is inherited I assume,
if the referenced g does not have its own render-order
specified?
Because the use is formally replaced with a g in the generated
content, is it ok for such cases to put the render-order in the g 
as well and does it apply to the generated-g?


For the use case above, it could be more useful of course
to be able to combine this approach the 3D-transfrom
proposal to use the z-axis (after transformation) somehow 
for the render-order.
Then one could maybe think of a space-ship moving 
around the system, changing the 'render-order-axis' as
well ;o)



Olaf

Received on Saturday, 24 October 2009 12:53:00 UTC