W3C home > Mailing lists > Public > www-svg@w3.org > July 2001

Fwd: [Moderator Action] Re: Dynamic Rendering Order??

From: Dean Jackson <dean@w3.org>
Date: Mon, 2 Jul 2001 08:42:35 +1000
To: www-svg@w3.org
Message-ID: <20010702084235.A27436@grorg.org>
You have to subscribe to post. 

----- Forwarded message from Robert DiBlasi <r_diblasi@hotmail.com> -----

X-Envelope-From: www-svg-request@tux.w3.org  Sat Jun 30 14:21:37 2001
X-Originating-IP: [166.90.66.110]
From: "Robert DiBlasi" <r_diblasi@hotmail.com>
To: www-svg@w3.org
Cc: chris@w3.org
Old-Date: Sat, 30 Jun 2001 18:21:06 -0000
X-OriginalArrivalTime: 30 Jun 2001 18:21:06.0394 (UTC) FILETIME=[6D9C73A0:01C10191]
X-Diagnostic: Not on the accept list
Subject: [Moderator Action] Re: Dynamic Rendering Order??
X-Diagnostic: Mail coming from a daemon, ignored
X-Envelope-To: www-svg
X-UIDL: 93b753a5cc780e1326fd71172e80f3ed

Chris, Mjumbe, W3c working group


<Mjumbe_wrote>
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.
</Mjumbe_wrote>

When I read this comment.....it made me sit back and think about what he
was wanting to do.....my first thought was the SAX users will not be
happy with this solution......then I thought that if the complete
document does have to be read first to make DOM tree....then he has a
point....(I'm not a computer graphics guru)...but logically ...his
argument seems to work.

....then a little light went on.....just an idea...mind you...but would
it be possible to have an attribute that belongs to any element that
creates a new viewport? I know there are rendering hints.....but may a
presentation attribute that would state "painters-model", "z-index"
or "mix" (combination of both painter algorithm and z-index)

something like:
<svg width = "200" height= "200" paint-model = "z-index">

'paint-model'
Value:   painter | z-index | mixed
Initial:   painter
Applies to:   all elements that create a new viewport
Inherited:   ?
Percentages:   N/A
Media:   visual
Animatable:   yes

I put a '?' on inherited because I thought of a dynamically generated
document could add elements that would change the paint-model.....I
guess that a developer chould check the attribute and change it if have
changed the paint-model........


this idea leads to a document that can use just z-index or a document
that uses just the painter algorithm(default) or both in the same
document..

I would like to know what individuals in the w3c working group and SVG
community think about such a suggestion ...I'm really interested in the
problems it would pose!!


I think z-index is an interesting suggestion to make for SVG 2.0 ...if
there is one ;-)

just a thought....

we all learn by sharing what we know
Robert A. DiBlasi




From: "Mjumbe Ukweli" <mjumbewu@hotmail.com>
To: chris@w3.org, jr@amanue.com
Cc: www-svg@w3.org
Date: Sat, 30 Jun 2001 11:56:00 -0400
Message-ID: <F195rVjYKtWfN3vSAMf00012085@hotmail.com>
Subject: Re: Dynamic Rendering Order??

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

                                                  &#8226; mjumbe &#8226;

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

----- End forwarded message -----
Received on Sunday, 1 July 2001 18:46:58 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:20 GMT