The description of this bug might be a bit hard to follow, but load the test below with paint-flashing on and you'll see what I mean. I'm testing with patches from bug 722923 and bug 724189 applied. This bug is important for b2g.

As expected, InvalidateTransformLayer stops thinking the frame has a layer when the invalidation starts. Breakpoint 2, nsIFrame::InvalidateTransformLayer (this=0x7fffe023cd38) at /home/cjones/mozilla/mozilla-central/layout/generic/nsFrame.cpp:4376 $79 = true Breakpoint 2, nsIFrame::InvalidateTransformLayer (this=0x7fffe023cd38) at /home/cjones/mozilla/mozilla-central/layout/generic/nsFrame.cpp:4376 $80 = false This might be a little tricky to fix.

FrameLayerBuilder::GetDedicatedLayer (gdb) p layer->HasUserData(&gColorLayerUserData) $772 = false (gdb) p layer->HasUserData(&gImageLayerUserData) $773 = false (gdb) p layer->HasUserData(&gThebesDisplayItemLayerUserData) $774 = true

We stop building an nsDisplayTransform when the invalidations start.

We're *building* the displaytransform, it just gets "optimized away" after the visible part scrolls offscreen. This patch forces the entire frame of the display transform to be "visible", when we're using the prerender optimization. Makes the extra invalidation go away except for some artifacts that persist for a while after the animation finishes. Not sure what's up with that. I don't know if this is the right approach or not.

Comment on attachment 595681 [details] [diff] [review] something like this? Actually yeah this is wrong. I don't know what I was thinking. Start on top of https://bugzilla.mozilla.org/attachment.cgi?id=595597&action=edit. And instead of using mFrame->GetRect(), use GetVisualOverflowRectRelativeToSelf() and add ToReferenceFrame() before you transform it.

Needs a test. Might have to wait until tomorrow (running out of gas).

Stealing most of the test from bug 722923. Will be polite and not conflict it out if I can avoid that.

When I extract the core of this test and run it in FF, it works perfectly: invalidates before patch, doesn't after. But it doesn't work when ported to mochitest-chrome as here :(. Not sure what's up.

The test might be failing to check the element corresponding to the thebeslayer that's being invalidated. id="bg", document.body, and document.documentElement don't seem to be it. Or something else is wrong.

The previous test seemed to be interacting badly with the color-layer optimization. That probably confused checkAndClearPaintedState(). This one works fine, and when run standalone I see the invalidated region in the outer <div> (the one with the gradient) persist forever. But the test still isn't catching the invalidation :(. Not sure what to do here. Hate to patch and run, but at this point it's starting to look like the cost expended on the test is beginning to outweigh its benefit. roc, happy to defer the call to you.

(This decision is most likely to affect Matt, so pulling him.)

(In reply to Chris Jones [:cjones] [:warhammer] from comment #10) > at this point it's starting to look like the cost > expended on the test is beginning to outweigh its benefit. Agreed.

You can land this along with the already-reviewed patch from bug 722603 that you depend on.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #11) > (This decision is most likely to affect Matt, so pulling him.) Fine with me. Just need to make sure we manually recheck these things when landing display list based invalidation.

Reviewed try logs with roc and decided that patch is ready to land. http://hg.mozilla.org/integration/mozilla-inbound/rev/92d08776a039

https://hg.mozilla.org/mozilla-central/rev/92d08776a039 I assume this should stay open for the test... if not please resolve.

This stayed fixed with dlbi.