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/
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.
*** Bug 11275 has been marked as a duplicate of this bug. ***
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.
Do we still want to support it? I know that it is still part of the spec.
In Mozillaland we have mixed feeling about these methods in general, for example see https://bugzilla.mozilla.org/show_bug.cgi?id=616892#c3.
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
(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.
(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
(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.
(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.
> 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?
(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
(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.
(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
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.
The spec also neuters these methods by defining that they do nothing now, too.