Is there any further information on this? @CaseyHillers @dnfield @flar

Is there any further information on this? @CaseyHillers @dnfield @flar

I'm 99% sure the problems shown in internal testing were due to the missing restore call in the new DL code in SML.

Try adding a unit test that has other layers that render after SML and you should see that they are included inside the SML's saveLayer when they should not be. Then add the restore in SML::Paint and it should go away...

Perhaps we should also add some debug code around the Paint call in Container::PaintChildren that makes sure that the restore count is the same before and after calling a layer's Paint method?

I'm not sure how that restore count check will work across a PlatformView layer, but it should probably be OK in the current system as we broadcast all save/restores to all canvases, so whichever leaf canvas returns from the Paint call should have the same restore count as the leaf canvas we had going into the Paint call...

Perhaps we should also add some debug code around the Paint call in Container::PaintChildren that makes sure that the restore count is the same before and after calling a layer's Paint method?

Perhaps use the AutoSaveLayer to make sure that the node doesn't forget to restore when it calls saveLayer

Perhaps we should also add some debug code around the Paint call in Container::PaintChildren that makes sure that the restore count is the same before and after calling a layer's Paint method?

Perhaps use the AutoSaveLayer to make sure that the node doesn't forget to restore when it calls saveLayer

Yes, but also provide a debugging verification in PaintChildren so that any layer that "rolls its own" is caught early. That's what I was getting at. Some of these layers might involve code outside of our normal control so it can't hurt to have a simple debug check to enforce the condition.