Re: Dynamic Rendering Order??

Jim Rosenberg wrote:

> My understanding is that rendering order is determined by the order in which
> something occurs in the SVG document. 

Yes. This is the classical 'Painters algorithm' which is widely used in
computer graphics.

>  I.e. it is not an attribute (if
> that's the right term) like x or y. 

Correct. 

> Did the SVG committee consider making rendering order an attribute? 

We considered making it a property, specifically the 'z-index' property
already defined in CSS2.

>  If this
> was considered and rejected, I'd be quite curious to know the rationale.

Mixing up both document order and z-index ws seens as problematic -
doing a tree swivel copes with bringingthings to the front or back in
dynamic environments.

Using a strict painters algorithm allows content to be displayed
incrementally as it streams in, while minimising redraws

Due to the compositing methods, which can require quite a lot of
offscreen buffers, particularly with group opacity and filter effects
and most especially when 'enable background' is used on filters, it was
felt essential to know the rendering order. Otherwise, a large amount of
recalculation would take place as each element was loaded and every time
any mutation event happened which might change which elements were
picked by selectors, which might change which properties applied to
which elements, which might change the z-index. All of which would
dramatically slow rendering.

> What is the best method of changing rendering order dynamically -- in an on
> mouseOver handler, for instance?  I'm just getting started studying SVG, so
> there is much I don't understand yet.  From what limited amount I do know,
> it looks as though the only choices to do rendering order dynamically are
> (1) create SVG on the fly and

That is certainly one possibility

>  (2) have multiple versions of a drawing
> embedded and hide and show groups to pick the one with the right rendering
> order.  

Also possible

> Both of these have problems.  For (1) I'm concerned about the
> ramifications for preloading.  (When I want to change the rendering order, I
> *don't* want this to require a new HTTP request, for example.)  

Okay. Depending on how you did things, (ie client-side generation using
the DOM) you would not generate a new HTTP request.

> (2) could
> get out of hand in a hurry, geometrically exploding the size of the
> document. 

Unless you sue the 'symbol' and 'use' elements in which case,a couple of
groups of use elements does not make an appreciable difference to file
size. geometry is defined once and used multiple times.


> If making rendering order an attribute was not already considered and
> rejected, is there any chance of getting this discussed for an SVG 2.0?

It could still be re-evaluated for a later version of SVG, depending on
results from an experimental implementation so that we could assess the
impact on rendering speed as opposed to the simplicity of merely
animating the z-index property.

-- 
Chris

Received on Saturday, 30 June 2001 09:38:53 UTC