Bug 10408 - SVGSVGElement does not support suspendRedraw, unsuspendRedraw
Summary: SVGSVGElement does not support suspendRedraw, unsuspendRedraw
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P4 Normal
Assignee: Nobody
URL: http://www.w3.org/TR/SVG/struct.html#...
Keywords:
: 11275 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-15 01:04 PDT by Eric Seidel (no email)
Modified: 2014-06-01 18:31 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2006-08-15 01:04:01 PDT
SVGSVGElement does not support suspendRedraw, unsuspendRedraw

These might require some ugly hacks to make work.  I'm not sure.

Hyatt would would be a good person to have comment here.

We could at least add Javascript stub methods, as many SVGs seem to fail without these methods.  One example:
http://www.carto.net/papers/svg/us_crime_2000/
Comment 1 Eric Seidel (no email) 2006-08-28 15:33:31 PDT
One way to do this is to save off a bitmap copy of the SVG subtree on suspendRedraw, and then use that for any paint() calls during the suspended period.  Only after a unsuspendRedraw would normal drawing resume.

I'm not sure what the needs for hit-testing are.

suspendRedraw might have to actually freeze the whole rendering subtree, not sure.
Comment 2 Eric Seidel (no email) 2007-06-12 11:11:47 PDT
*** Bug 11275 has been marked as a duplicate of this bug. ***
Comment 3 Cameron McCormack 2008-04-08 01:11:29 PDT
Note that an SVG 1.1 erratum (http://www.w3.org/2003/01/REC-SVG11-20030114-errata#remove_exception_on_unsuspendredraw) removes the exception for unsuspendRedraw, so the comment in the placeholder function is currently misleading.
Comment 4 Dirk Schulze 2012-02-01 21:27:21 PST
Do we still want to support it? I know that it is still part of the spec.
Comment 5 Cameron McCormack 2012-02-01 21:33:28 PST
In Mozillaland we have mixed feeling about these methods in general, for example see https://bugzilla.mozilla.org/show_bug.cgi?id=616892#c3.
Comment 6 Raks 2012-06-04 04:17:32 PDT
We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.

So I would urge someone to support suspendRedraw and so please prioritize it

In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this
Comment 7 Philip Rogers 2012-06-04 10:19:06 PDT
(In reply to comment #6)
> We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.
> 
> So I would urge someone to support suspendRedraw and so please prioritize it
> 
> In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this

Would suspendredraw actually solve your usecase? If repaint is suspended, the portions of the svg document that were not visible initially would not have been drawn to begin with, and therefore would not be available when you scroll the svg portion. While drawing is suspended, the SVG portion would not be redrawn at all, which is probably not what you want.
Comment 8 Raks 2012-06-04 21:19:49 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.
> > 
> > So I would urge someone to support suspendRedraw and so please prioritize it
> > 
> > In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this
> 
> Would suspendredraw actually solve your usecase? If repaint is suspended, the portions of the svg document that were not visible initially would not have been drawn to begin with, and therefore would not be available when you scroll the svg portion. While drawing is suspended, the SVG portion would not be redrawn at all, which is probably not what you want.

I would not suspend the node which has scrolling but all the other nodes. The whole of UI has lots of images but the node having srolling may have a tenth of all the images. Unless SVG repaint is already optimized to paint only the part of the screen which is dirtied, calling suspendRedraw all other nodes which are not changing during scrolling will help
Comment 9 Philip Rogers 2012-06-05 10:31:58 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.
> > > 
> > > So I would urge someone to support suspendRedraw and so please prioritize it
> > > 
> > > In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this
> > 
> > Would suspendredraw actually solve your usecase? If repaint is suspended, the portions of the svg document that were not visible initially would not have been drawn to begin with, and therefore would not be available when you scroll the svg portion. While drawing is suspended, the SVG portion would not be redrawn at all, which is probably not what you want.
> 
> I would not suspend the node which has scrolling but all the other nodes. The whole of UI has lots of images but the node having srolling may have a tenth of all the images. Unless SVG repaint is already optimized to paint only the part of the screen which is dirtied, calling suspendRedraw all other nodes which are not changing during scrolling will help

SVG's repaint is already optimized to only paint the parts of the screen that are dirty.
Comment 10 Philip Rogers 2012-06-06 07:25:26 PDT
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.
> > > > 
> > > > So I would urge someone to support suspendRedraw and so please prioritize it
> > > > 
> > > > In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this
> > > 
> > > Would suspendredraw actually solve your usecase? If repaint is suspended, the portions of the svg document that were not visible initially would not have been drawn to begin with, and therefore would not be available when you scroll the svg portion. While drawing is suspended, the SVG portion would not be redrawn at all, which is probably not what you want.
> > 
> > I would not suspend the node which has scrolling but all the other nodes. The whole of UI has lots of images but the node having srolling may have a tenth of all the images. Unless SVG repaint is already optimized to paint only the part of the screen which is dirtied, calling suspendRedraw all other nodes which are not changing during scrolling will help
> 
> SVG's repaint is already optimized to only paint the parts of the screen that are dirty.

Just a quick followup--it's always good to double-check these things. I instrumented the code and wroteup a testcase and verified that RenderSVGImage::paint skips the hard work if the dirty rect doesn't intersect the image repaint rect.
Comment 11 Dirk Schulze 2012-06-06 10:14:08 PDT
> Just a quick followup--it's always good to double-check these things. I instrumented the code and wroteup a testcase and verified that RenderSVGImage::paint skips the hard work if the dirty rect doesn't intersect the image repaint rect.

Sorry for the late reply. But this is exactly the reason why suspendRedraw would be counter productive. You would scroll and suddenly the content disappears, just because the drawing got suspend and we clip to the visible content.

But it looks like you have performance issues. Raks, can you add an example that we can profile?
Comment 12 Raks 2012-06-07 08:53:49 PDT
(In reply to comment #11)
> > Just a quick followup--it's always good to double-check these things. I instrumented the code and wroteup a testcase and verified that RenderSVGImage::paint skips the hard work if the dirty rect doesn't intersect the image repaint rect.
> 
> Sorry for the late reply. But this is exactly the reason why suspendRedraw would be counter productive. You would scroll and suddenly the content disappears, just because the drawing got suspend and we clip to the visible content.
> 
> But it looks like you have performance issues. Raks, can you add an example that we can profile?

Its part of our app, so let me make a separate file and recreate it for you to analyze, will take couple of days
Comment 13 Raks 2012-06-07 08:57:50 PDT
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > (In reply to comment #6)
> > > > > We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.
> > > > > 
> > > > > So I would urge someone to support suspendRedraw and so please prioritize it
> > > > > 
> > > > > In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this
> > > > 
> > > > Would suspendredraw actually solve your usecase? If repaint is suspended, the portions of the svg document that were not visible initially would not have been drawn to begin with, and therefore would not be available when you scroll the svg portion. While drawing is suspended, the SVG portion would not be redrawn at all, which is probably not what you want.
> > > 
> > > I would not suspend the node which has scrolling but all the other nodes. The whole of UI has lots of images but the node having srolling may have a tenth of all the images. Unless SVG repaint is already optimized to paint only the part of the screen which is dirtied, calling suspendRedraw all other nodes which are not changing during scrolling will help
> > 
> > SVG's repaint is already optimized to only paint the parts of the screen that are dirty.
> 
> Just a quick followup--it's always good to double-check these things. I instrumented the code and wroteup a testcase and verified that RenderSVGImage::paint skips the hard work if the dirty rect doesn't intersect the image repaint rect.

@Philip, yes infact I was expecting that  Webkit should paint only the dirtied area but since I was'nt sure about it and suspendRedraw was there in the specs, I used it and it did'nt work. I agree I should have looked in the code to see optimization already done.
Comment 14 Philip Rogers 2012-06-07 09:26:42 PDT
(In reply to comment #13)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #8)
> > > > (In reply to comment #7)
> > > > > (In reply to comment #6)
> > > > > > We are using SVG to create UI for our WeApp and we feel a need for suspendRedraw. The case is as follows. As scrolling is not supported by SVG we have implemented our own scrolling using translation but what we have observed is that scrolling is not smooth if the whole of UI has lots of images like 200 of them. Now this could be because the whole page is repainted and drawing only that  part of the svg document which has scrolling would probably solve our problem.
> > > > > > 
> > > > > > So I would urge someone to support suspendRedraw and so please prioritize it
> > > > > > 
> > > > > > In general once you provide the feature people will use them and infact find interesting uses of them. So please do not think of dropping this
> > > > > 
> > > > > Would suspendredraw actually solve your usecase? If repaint is suspended, the portions of the svg document that were not visible initially would not have been drawn to begin with, and therefore would not be available when you scroll the svg portion. While drawing is suspended, the SVG portion would not be redrawn at all, which is probably not what you want.
> > > > 
> > > > I would not suspend the node which has scrolling but all the other nodes. The whole of UI has lots of images but the node having srolling may have a tenth of all the images. Unless SVG repaint is already optimized to paint only the part of the screen which is dirtied, calling suspendRedraw all other nodes which are not changing during scrolling will help
> > > 
> > > SVG's repaint is already optimized to only paint the parts of the screen that are dirty.
> > 
> > Just a quick followup--it's always good to double-check these things. I instrumented the code and wroteup a testcase and verified that RenderSVGImage::paint skips the hard work if the dirty rect doesn't intersect the image repaint rect.
> 
> @Philip, yes infact I was expecting that  Webkit should paint only the dirtied area but since I was'nt sure about it and suspendRedraw was there in the specs, I used it and it did'nt work. I agree I should have looked in the code to see optimization already done.

This is completely not your fault--the spec is incredibly misleading here, in my opinion. I've started work on having this removed from the spec and sent out an email to www-svg: http://lists.w3.org/Archives/Public/www-svg/2012Jun/0025.html
Comment 15 Dirk Schulze 2014-05-12 04:26:59 PDT
We probably don't want to have it in WebKit at this point. We already optimize drawing and collect a set of commands before redrawing if possible. Other things like not repainting certain "layers" over and over again seems more important. This is already covered by buffered-rendering property or (possibly) will-change.
Comment 16 Cameron McCormack 2014-06-01 18:31:51 PDT
The spec also neuters these methods by defining that they do nothing now, too.