- From: Mjumbe Ukweli <mjumbewu@hotmail.com>
- Date: Sat, 30 Jun 2001 11:56:00 -0400
- To: chris@w3.org, jr@amanue.com
- Cc: www-svg@w3.org
>From: Chris Lilley <chris@w3.org> > >Jim Rosenberg wrote: > > > Did the SVG committee consider making rendering order an attribute? > > ...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. > not necessarily. if 'z-index' were a factor in rendering then it would simply not be the best choice for renderers to use the painters algorithm in the traditional way. renderers could (and should) simply parse the document _completely_ before they do any rendering. they would then know what the 'z-index' says is on top and what it says is on bottom before anything is drawn. when a developer wants to alter the order dynamically (especially in animation) i can see where there would be a decay in speed. however, if an SVG developer wants to animate the 'z-index' property of an element then i think s/he should be able to. s/he should just be conscious of the impact that it may have on speed of rendering (no different from animating with filter effects). > > 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. i, for one, hope it does make it into SVG2. • mjumbe • _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Received on Saturday, 30 June 2001 11:56:32 UTC