Re: Making suspendRedraw, unsuspendRedraw, and forceRedraw optional in SVG

On Thu, 07 Jun 2012 04:33:24 +0200, Philip Rogers <pdr@google.com> wrote:

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

I've come to the same conclusion, and we will be removing the  
implementation of at least  
unsuspendRedraw/unsuspendRedrawAll/suspendRedraw in coming Opera versions.  
ForceRedraw might be removed too, unless there's feedback to indicate it's  
needed. Removal might mean stubbed-out implementation for some time  
(depends on how much content we're willing to break).

> Is there a compelling usecase for suspendRedraw and forceRedraw?

At this point I don't think so.

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

I think these methods should be removed from the SVG2 DOM, or possibly  
stubbed if necessary for compat with old content.

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 7 June 2012 10:02:06 UTC