422058 - Call suspendRedraw and unsuspendRedraw automatically as needed for optimal DOM performance

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030904 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030904 Minefield/3.0b5pre

My suggestion is to change the SVG DOM implementation such that redrawing suspended by default whenever a script is running.

It's easy to demonstrate that scripts that do a lot of SVG DOM manipulation get a signigicant performance boost in FF3 from calling suspendRedraw at the beginning and unsuspendRedraw at the end. In fact, making these calls is essential to obtain performance comparable to FF2 for scripts that run as part of initial page loading (FF2 only starts layout after page load). For example, compare the performance of these two attachments:

Without susendRedraw: https://bugzilla.mozilla.org/attachment.cgi?id=258652 With suspendRedraw: https://bugzilla.mozilla.org/attachment.cgi?id=259097

It's also easy to demonstrate that having redrawing suspended whilst a script is running has no visible effect because in mozilla the results of a script are only seen when it finishes or blocks (e.g. on an alert). This is true even if forceRedraw() is used.

My suggestion is to change the SVG DOM implementation such that having redraw suspended while a script is running the default behaviour - i.e. have and implicit call to suspendedRedraw() whenever a script begins execution and an implicit call to unsuspendRedraw() whenever a script finishes. When a script performs some action where the results can be seen, e.g. blocking on an alert, implicitly call unsuspendRedraw() before the action and suspendRedraw() again afterwards. If a script makes explicit calls to suspendRedraw(), unsuspendRedraw() or forceRedraw() then the DOM should stop honour these calls at the expense of the implicit calls. At least to the extent it does at the moment (forceRedraw() seems to be an effective no-op at the moment whilst suspendRedraw() and unsuspendRedraw() take effect on completion/blocking of the calling script).

It seems to me that's the behaviour everyone would want so why not do it automatically ?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Optimal performance is dependent on script authors calling suspendRedraw() and unsuspendRedraw() even though doing so has no visible effect.

Expected Results:  
Optimal performance should be the default behaviour.

What's there at the moment is almost designed to trip people up. Like saying "You can only have fast performance if you make a call to this goFaster() method that does nothing else but making it go faster but which we won't call on your behalf".

Comment 1

[Robert Longson [:longsonr]]

Anyone implementing the would have to be very careful as suspendRedraw and unsuspendRedraw are slow. If you have a script which does something very simple the likely impact is to worsen performance rather than improve it. On the other hand if you do something complex in a script it will, of course boost performance as Duncan said.

We used to do suspendRedraw automatically when elements were inserted and removed this for performance reasons as its overhead was so noticable.

Determining whether a script is complex enough to warrant the overhead of suspendRedraw or not is presumably not straightforward which, I would imagine is why the SVG specification authors left it as a manual operation for the web site designer.

Comment 2

[Duncan Loveday]

How slow ? I can understand that doing potentially thousands of calls to suspendRedraw and unsuspendRedraw, e.g. doing it for every DOM operation, could be noticeable but would the addition of one call to suspendRedraw at the beginning and one call to unsuspendRedraw at the end really be significant even in a short-running script ?

If so, perhaps the DOM could maintain a count of DOM operations and do the implicit suspendRedraw if this count reaches a threshold amount.

Comment 3

[Duncan Loveday]

(In reply to comment #1)
> Determining whether a script is complex enough to warrant the overhead of
> suspendRedraw or not is presumably not straightforward which, I would imagine
> is why the SVG specification authors left it as a manual operation for the web
> site designer.
> 
Thinking about this, suppose a web site designer determined that his/her script was one that didn't benefit from suspendRedraw()/unsuspendRedraw() in Firefox. Could they be assured that this would also be the case in, say, Opera or Safari ? Answer: No - because those implementations have different performance trade-offs. Conclusion: A web site designer shouldn't be expected to make the decision. It should be part of the browser implementation.

Just offering one possible opinion, not expecting it to be acted upon.

Comment 4

[Jonathan Watt [:jwatt]]

On Mac I get pretty much the same results for the two testcases in comment 0.

Comment 5

[Duncan Loveday]

It's a bit quicker for me with suspendRedraw but not massively so.

Comment 6

[Robert Longson [:longsonr]]

suspendRedraw and unsuspendRedraw don't do anything any more.