Buffered rendering in SVG

, , ,

One of the things recently added to Opera is support for the buffered-rendering SVG property. SVG content providers can use this property to provide a hint to the implementation about how often an element is modified so it can make better speed vs. memory trade-offs.

The attribute values for buffered-rendering are auto, dynamic, and static. From the SVG Tiny 1.2 recommendation:

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

This may sound abstract, so let's have a look at an actual example. The first demo, which does not have buffered rendering specified, is an SVG image with an embedded PNG, on top of which a complex filter is applied. When hovering over the image, the filter is disabled in a radius around the pointer. When viewed in Opera 10.6x, you can see the performance is quite slow, and the filter-less circle has trouble catching up with the pointer.

If we now set the buffered-rendering property on the containing <g> to static (see demo 2), you'll notice the performance will be much faster. This is because the static value makes the browser cache the filter rendering as a raster, resulting in a better allocation of resources, and thus better performance.

Now, interestingly enough, the difference between these two demos will be less obvious when viewed in the latest Opera 10.70 snapshots: they both perform very well, and there is only a small performance delay on the first example. The reason for this is because the Opera 10.70 builds come with a number of SVG filter optimizations, which, of course, is even better ;-)

So, to wrap up this post, here's another example of buffered rendering - you'll notice a clear difference in framerate between the two demos. Be sure to try out buffered rendering in your own SVG graphics, and let us know how it goes!

Opera and the .net magazine awardsCSS box-shadow experiments

Comments

dahulevogyre Tuesday, August 31, 2010 7:03:55 PM

truly excellent !!
I love it.

Hello hi perf SVG.

Aux Wednesday, September 1, 2010 6:08:11 AM

I would note one small thing, but very important one. I have currently 30FPS rendering limit in Opera prefs to match my 60Hz monitor setting, but tiger demo shows 34fps. And even when it drops sometimes right to the 30fps these frames are NOT syncronised with monitor. That leads to jerky motion.

Please make SVG animation syncronised with video output.

Александр Карпинскийhomm Wednesday, September 1, 2010 10:55:50 AM

Unregistered user Wednesday, September 1, 2010 12:50:38 PM

xeon0541 writes: cpu usage very high

Marek Pawłowskilockoom Wednesday, September 1, 2010 1:24:37 PM

Originally posted by homm:

Opera 10.6 buffers image too early


Confirmed.

Charles SchlossChas4 Wednesday, September 1, 2010 1:28:16 PM

cool

Michael Johnsonpitredbeard Wednesday, September 1, 2010 7:27:44 PM

Problems aside, this is nice. I note that it the first two demos work in the latest Firefox stable release (although the second is still very very slow) but not in the latest Chrome release (no image at all).

Interestingly, the latest IE9 preview shows the image, but not the filter, so it at least has some SVG support (at long last!)

Michael Johnsonpitredbeard Wednesday, September 1, 2010 7:28:48 PM

Originally posted by homm:

Opera 10.6 buffers image too early



For me, I don't see the stripes. Everything else comes in.

Rafael Luikrafaelluik Thursday, September 9, 2010 10:29:56 PM

WOW!!!! bigeyes

Write a comment

New comments have been disabled for this post.