W3C home > Mailing lists > Public > www-svg@w3.org > June 2012

Making suspendRedraw, unsuspendRedraw, and forceRedraw optional in SVG

From: Philip Rogers <pdr@google.com>
Date: Wed, 6 Jun 2012 22:33:24 -0400
Message-ID: <CAJgFLLv2TvH0xhruyHQCY=ozj6WFw20AAVrDdzwOH7Wf9CoBWw@mail.gmail.com>
To: www-svg@w3.org
www-svg,

I've explored implementing suspendRedraw [1] and unsuspendRedraw in WebKit
and I think these features may no longer be useful, or could be improved by
making their functionality optional. There are similar concerns about
forceRedraw.

In browserland, both WebKit and IE10 have stubbed-out implementations of
suspendRedraw, and Mozilla implemented it but removed it because it hurt
performance [2]. Presumably all major browsers already decouple DOM
modification / painting, and have dirty repaint support so there is no way
for suspendRedraw to help performance in these areas--a confusing concept
to our end users [3]. Furthermore, for finely grained control in syncing
paint times (such as games), browsers now support RequestAnimationFrame
which was not available when suspendRedraw and forceRedraw were introduced.

Is there a compelling usecase for suspendRedraw and forceRedraw?

Given the lack of support in implementations and the questionable utility
of these methods, I would like to ask the group to consider making this
functionality optional.

Philip

[1]
http://www.w3.org/TR/SVG/single-page.html#struct-__svg__SVGSVGElement__suspendRedraw
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=616892
[3] https://bugs.webkit.org/show_bug.cgi?id=10408
Received on Thursday, 7 June 2012 02:34:14 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:51 GMT