Re: [SVGMobile12] What is the point of section 3 ("Rendering Model")?

On Friday, May 20, 2005, 2:06:44 PM, Ian wrote:

IH> Section 3 ("Rendering Model") is very vague, much too vague to be 
IH> implemented by user agents in an interoperable way.

IH> The section is written so as to be a single normative conformance criteria
IH> ("the result [of] the implementation SHALL match that described [here]")
IH> but it is not clear which parts of the chapter are actually intended that
IH> way and which are intended to merely be expository.

IH> Examples of the vagueness of the definition include section 3.3, wherein
IH> the paint order is defined such that "the first element is painted first",
IH> without defining "first" (depth-first? breadth-first? pre-order? in-order?
IH> post-order? alphabetical? z-index property?), and is section 3.4.1, where
IH> the requirement is that "the fill is painted first, then the stroke", 
IH> without defining how the paint operations are performed.

IH> The rest of the chapter consists either of incomplete introductory 
IH> material (e.g. section 3.4 omits foreignObject from its list of graphic 
IH> elements, as mentioned in other last call comments; section 3.5 doesn't 
IH> say anything about how the parent compositing is performed or even if that
IH> compositing is to be done by the SVG processor or if it is outside the 
IH> scope of the spec), or of links to other sections (e.g. 3.2, 3.4.2, 3.4.3
IH> merely link to later definitions).

IH> Please either remove this section or rewrite it so that it actually 
IH> clearly states what it is intending to state, with testable, implementable
IH> conformance criteria.

The rendering chapter for Tiny is indeed quite brief. The corresponding
chapter for Full, however, includes considerably more truly critical
information which is not described elsewhere in the SVG specification.
For Full, this chapter describes how clipping, masking, filter effects,
group opacity and markers relate to each other, particularly the order
in which these more complex graphics operations occur. Thus, we will
preserve the rendering chapter in Tiny in order to maintain parallelism
with the Full specification and to facilitate editing for future SVG

We disagree that the chapter does not serve its intent. Although Tiny's
rendering model is much easier than Full's, key details in this chapter
include reference to the painter's model (a well-known term in computer
graphics, also sometimes called the painter's algorithm) and the fact
that fills happen before strokes. Both are critical processing model
details that need to be stated and are not stated elsewhere.

The text in this chapter has been part of the SVG specification since
the beginning. We do not feel it is necessary to rewrite this chapter
around testable assertions for the Tiny 1.2 specification since SVG Tiny
1.1 has several implementations already which implement the rendering
model correctly. The rendering model aspects of SVG have proven to have
been implemented reliably across many different implementations.

The text in section 3.5 is vague on purpose. It expressed the intent
that SVG content should be alpha-composited against its viewport.
However, the SVG specification is not the right place to define
normative and clear integration rules. CDF and WICD are now upon us, so
we will soon have a rightful place to define the rules for SVG or other
child document formats to be composited with the parent's drawing

We agree that the "the first element is painted first" is ambiguous; as
such, following a suggestion from Boris Zbarsky, we changed the wording
to say the following:

    Elements in an SVG document fragment have an implicit drawing order.
    Element are rendered using a pre-order, depth-first walk of the SVG
    document fragment. Subsequent elements are painted on top of
    previously painted elements.

 Chris Lilley          
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 25 October 2005 01:27:12 UTC