RenderSVGContainer (<g>) should not repaint when its bounds change (unless it has a filter)

• Component: SVG
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

RenderSVGContainer (<g>) should not repaint when its bounds change (unless it has a filter)

The only time a <g> actually causes pixels to be rendered to the screen is when it has a filter.  All other times, it shouldn't need to do any repainting.

Currently if you have an item moving inside a large <g>, causing the bounds of that <g> to change, the entire <g> will repaint!  I've attached a patch which addresses this, but seems to expose another repaint issue (or two), so it can't be landed at this time.

[Eric Seidel (no email)]

Created attachment 16557 [details]
test case (use quartz debug "flash on screen updates" to see the bug

[Eric Seidel (no email)]

Created attachment 16563 [details]
potential fix

This seems to dramatically improve lively kernel.  It does not however fix the attached test case.  The attached test case's behavior is changed, but the new behavior might actually be an intentional side effect of absoluteClippedOverflowRect() describing the size of the content of the <svg> instead of the actual svg's bounds.  I don't know enough about absoluteClippedOverflowRect's expected behavior to know for certain.

I'm also not sure this fix is 100% ready as I think it may regress Space Invaders ever so slightly:
http://www.croczilla.com/svg/samples/invaders/invaders.svg

I have not seen any other regressions in my surfing of the SVG web.

[Eric Seidel (no email)]

bug 15352 covers other redraw issues for space invaders

[Eric Seidel (no email)]

I was wrong.  Invaders is no worse than before.  This patch is ready for review.

[Oliver Hunt]

Comment on attachment 16563 [details]
potential fix

r=me if you make a decent changelog, and confirm the correction on lively kerne;

[Eric Seidel (no email)]

landed as r26077 on feature-branch.