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

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

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.


[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 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:51 UTC