- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Thu, 29 Jan 2009 11:31:55 +1100
- To: W3C SVG Public Working Group <public-svg-wg@w3.org>
- Message-ID: <4980F8FB.9010606@cisra.canon.com.au>
Dudes,
I have an action [1] (ACTION-2412) to Merge 'enable-background' definition to
align with Filters module.
I've examined the wording for the values for 'enable-background' for the filters
module [2] which reads
[[
A value of new indicates two things:
* It enables the ability of children of the current element to access the
background image.
* It indicates that a new (i.e., initially transparent black) background
image canvas is established and that (in effect) all children of the current
element shall be rendered into the new background image canvas in addition to
being rendered onto the target device.
A meaning of enable-background: accumulate (the initial/default value) depends
on context:
* If an ancestor element has a property value of 'enable-background:new',
then all renderable child elements of the current element are rendered both onto
the parent element's background image canvas and onto the target device.
* Otherwise, there is no current background image canvas, so it is only
necessary to render the renderable elements onto the target device. (No need to
render to the background image canvas.)
]]
Not all of this wording can be used for the compositing module. Because of the
compositing model used by the module. A group or container in the compositing
module indicates a group buffer is created for compositing into. The
'enable-background' property defines how the group buffer is initialised.
In the filters module the 'new' value indicates that child elements of a
container element are rendered to both the "new background image canvas" in
addition to the target device. This has the known problem of including the
background twice for compositing operations when using filters.
The compositing module is designed to correct this by specifying that when
enable-background="new" child elements of the container element are rendered to
only the "new background image canvas". So I'm not sure if it's possible to
merge wording for the 'new' value.
In the filters module the 'accumulate' value indicates that no background buffer
is created (as far as I can tell). In the compositing module a background buffer
is created with a copy of the background and a second opacity channel buffer is
created. This buffer stores the percentage of the background in the group buffer
and is initially opaque. The group buffer is treated as the canvas for the
children of the group. Additionally, as objects are placed into the group
buffer, they are also placed into the opacity channel buffer using a defined
operation in the compositing spec. Before the group buffer is composited onto
the canvas, any remaining background color in the group buffer is removed using
the values in the opacity channel buffer. Other post rendering steps such as the
opacity are performed after this step, and before compositing the result onto
the canvas.
I've attached some examples and expected output to this email to illustrate the
differences in behaviours between filters and compositing when enable-background
is used.
[1] http://www.w3.org/Graphics/SVG/WG/track/actions/2412
[2] http://www.w3.org/TR/SVGFilter12/#AccessBackgroundImage
Attachments
- image/svg+xml attachment: filter-enablebackground-test-accumulate.svg
- image/svg+xml attachment: filter-enablebackground-test-new.svg
- image/svg+xml attachment: compop-enablebackground-test-accumulate.svg
- image/svg+xml attachment: compop-enablebackground-test-new.svg
- image/png attachment: compop-enablebackground-test-accumulate.png
- image/png attachment: compop-enablebackground-test-new.png
- image/png attachment: filter-enablebackground-test-accumulate.png
- image/png attachment: filter-enablebackground-test-new.png
Received on Thursday, 29 January 2009 00:32:39 UTC