Bug 11164 – SVG opacity code needs further optimizations

• Component: SVG
• Status: NEW

[Eric Seidel (no email)]

SVG opacity code could be further optimized.

Right now our largest inefficiency in the opacity code is the number of times we call beginTransparencyLayer/endTransparencyLayer.  Each call creates a new context the size of the current clip region.  This can mean many large mallocs and frees.

An example:

<g opacity="0.5">
    <rect x="223" y="490" width="483" height="142" style="fill:red" />
    <g opacity="0.5">
        <rect x="377" y="82" width="271" height="121" style="fill:blue; fill-opacity:0.5" />
    </g>
</g>

This results in the use of two transparency layers when only one is truly necessary.  This modified SVG would render exactly the same:

<g opacity="0.5">
    <rect x="223" y="490" width="483" height="142" style="fill:red" />
    <rect x="377" y="82" width="271" height="121" style="fill:blue; fill-opacity:0.25" />
</g>

Containers need not create a transparency layer if they know that they only contain non-overlapping objects consisting of a simple fill or stroke (not both).

[Dirk Schulze]

Isn't it possible to do it without transparencyLayer's? If an element has an opacity < 1.0, we multiply the opacity of it's childs with the opacity of the current element.
The last element of the tree is something that is rendered by SVGPaintServerSolid, -Pattern, Gradient and we use globalOpacity there.
Images need an extra handler, because they are not rendered via an SVGPaintServer.
That means for you example:

<g>
    <rect x="223" y="490" width="483" height="142" style="fill:red; fill-opacity:0.5" />
    <g>
        <rect x="377" y="82" width="271" height="121" style="fill:blue;
fill-opacity:0.125" />
    </g>
</g>

[Dirk Schulze]

Isn't it faster to use context->setAlpha(float) instead of transparencyLayer's, and let the graphic engine let do the work? Or are there other problems with it?