Proposals/buffered rendering expansion

From SVG

For a function to support smooth zooming and panning, it was decided to apply specifications of extended SVGT1.2 buffered rendering. This is a proposal for that from stakagi.

Buffered rendering

This property was prepared for for performance optimization of UA. It is accomplished by providing a hint to the UA about how often an element is modified.

According to the specifications, when 'static' is appointed, UA can provide an effect to be able to improve the generation performance of the next frame by promoting the reuse of the off-screen buffer.

CSS Will Change Module Level 1 may provide a similar hint.

Re-use of the off-screen buffer at the time of zooming and panning

We assume that zooming and panning is to change 'transform' attribute of the element. In other words, because the DOM editing that transform is changed to happens, we can consider that buffered-rendering="static" does not contribute to a performance enhancement of zooming and panning. It is because it should not be always applied because it causes the following indication deterioration.

  • A blank domain appears when panned outside a buffer area.
  • A blank domain appear at the time of the zoom down in the same way
  • Display resolution decrease at the time of zoom up

From upper list, continuous reusing of an off screen buffer after zooming and panning operation cannot offer desirable result. On the other hand, it provides possibility to improve a frame rate in the case of huge data to apply during transition of the zooming and panning (and rotating). Because smooth zooming and panning are applied as basic user interface with many touch screen devices, this technique is used many with a touch screen devices.

In this way, though the special strategy that a frame rate is more important than quality of the drawing should be applied during zooming and panning, it is difficult for UA to control it without clear statement from application heuristically. And only existing SVGT1.2 buffered-rendering and CSS will-change may not support it. That is because they do not show a strategy of the reflection of the DOM change to indication, and they only show the frequency of the DOM change.

Therefore, the SVG contents creator should be able to appoint the choice of such a trade-off strategy by distinguished attribute values.

Possibility of absorption 'buffered-rendering' into 'will-change'

Present 'buffered-rendering' and 'will-change' have considerably similar characteristics. If 'buffered-rendering' attribute is absorbed in 'will-change' property, directions of such a strategy will become less suitable as that property. In this case, the study of the following chapters may be almost meaningless. However, such a strategy should be expressed as evoluted 'image-rendering' attribute. ( e.g. image-rendering = 'optimizeZoomingAndPanning' )

Relaated discussion: http://lists.w3.org/Archives/Public/www-svg/2014Apr/0022.html

Studies of the current implementations about zooming & panning

This link is a table of the test results of zooming and panning using the large SVG contents in several browsers on Windows.

It seems that the usabiliity of panning is improving without a hint.

On the other hand, it of zooming has the considerable issues. And more complicated nested svg documents has not been tested yet.

Running mode in SVG

Running mode (referencing mode) in User Agent, which is for referencing SVG data and embed it to the other content, was defined in SVG Integration 1.0.

A correspondence table between modes and behaviours for DOM and rendering is described as below.

Immediate Mode Static Mode Animated Mode Dynamic Interactive Mode
Hittest x x x o
DOM Operation x x o o
Re-rendering x o o o
Offscreen Image Buffering o o o o
'buffered-rendering' (SVGT1.2) - static - dynamic
'buffered-rendering' (proposed) immediate (or ...?) static animated interactive (or dynamic)

The value of "buffered-rendering" attribute in SVG Tiny 1.2 is added in this table.

In addition, the correspondence between Features in SVG Integration 1.0 and the above behaviours is as below.

declarative animation, script execution = DOM Operation
interaction = Hittest
external reference, link traversal :N/A (for security features)

The extension of "buffered-rendering" for smooth zooming and panning is very similar to a behaviour in immediate mode.

The difference between "static" mode and this smooth zooming & panning UI mode is that SVG creators hope to transform SVG content without re-rendering as if of bitimage to improve frame rates, even though "transform" attribute is changed.

The followings are duplicates of descriptions of 'buffered-rendering' in SVG Tiny 1.2.

auto
Indicates that the user agent is expected to use a reasonable compromise between speed of update and resource allocation.
dynamic
Indicates that the element is expected to be modified often.
static
Indicates that the element is not expected to be modified often. This suggests that user agent may be able to allocate resources, such as an offscreen buffer, that would allow increased performance in redraw. It does not mean that the element will never change. If an element is modified when the value is 'static', then redraw might have reduced performance.

Extended 'buffered-rendering' Modes

As described in the above section, the value for the proposed 'buffered-rendering' attribute might be aligned to the referencing mode for SVG Integration 1.0.

'interactive' (or 'dynamic' for compatibility)
This mode is set when SVG creators want to provide SVG contents with an animation in as high frame rates as possible and prompt interactivity. (Anything should NOT be sacrificed)
'animated'
This mode is set when SVG creators want to provide SVG contents with animation in as high frame rate as possible instead of sacrificing some interactivity (hittesting). If an element in this mode is set interactivity, UA performance would degrades.
'static'
This mode is set when SVG creators want to provide SVG contents drawn in high display quality and high frame rates. On the other hand, this mode allows UA to sacrifice animation (DOM operations) and interactivity. UA would be able to provide successive frames to users by reusing "offscreen buffer" unless animation and interactive operation occurs.
'immediate' ('bitimage'?, 'prerenderedImage'?, staticImage?, 'canvas'? (Because the behavior closely resembles with canvas))
This mode is set when SVG creators want to provide SVG contents in high frame rates even though not only animation and interactivity but also display quality are sacrificed. UA would be able to provide successive frames to users by reusing offscreen buffer as in the shadow of degrading display quality. When the DOM "transform" attribute is changed, an image for rendering an initial frame is transformed and drawn without re-rendering as if the content is "bitimage".

Sense of animated mode

At Web and TV Convergence workshop held in March, 2014, a following performance issue of SVG is reported. The reporter tried the experimental broadcast that displayed SVG with a web browser embedded in television receiver as follows.

We made a football (soccer) programme with Hybridcast technology using a large amount of data in realtime.
The viewer can put widgets on the screen and see rich play data.
...
The last widget is a heatmap.
We tried to make it with SVG but the performance of Hybridcast TV sets so far were not yet sufficient so we used images instead.
...

(Captured Screen)

They changed it with a bit image, because they felt that a performance of SVG rendering was a bottleneck. This may be improved if animated mode functions effectively, because hittesting was an unnecessary with their use cases.