Help diagnosing a change that triggers a PaintUnderInvalidationChecker::CheckNewItem() failure

[Colin Blundell]

Hi Xianzhu and blink-dev@,

I'm in the last stages of eliminating Canvas2DLayerBridge. At this point the primary blocker is Canvas2D code that checks for the existence of the bridge as a proxy to determine whether task <foo> is doable.

In putting together a POC changing these callsites, I've hit one issue, which I've isolated down to a minimal CL: If I align CanvasRenderingContext2D::FinalizeFrame() with OffscreenCanvasRenderingContext2D::FinalizeFrame() in being guarded only by the canvas not being null (rather than CanvasRC2D's current check of the canvas *and* its bridge not being null), I hit a PaintUnderInvalidationChecker::CheckNewItem() error in this test. The CL gives the full details.

I don't have any real insight into what this failure is signaling at a higher level. Would you be able to provide insight on whether it indicates (a) that the change is actually problematic or (b) that there is a problem to fix with the check and/or test infrastructure that this change is tickling?

Thanks,

Colin

[Xianzhu Wang]

bcc blink-dev

A paint-under-invalidation means that a DisplayItemClient (normally a LayoutObject) has not been invalidated (via DisplayItemClient::Invalidate) while its painted result will change. In production (with under-invalidation checking disabled by default) that may cause stale painting displayed. For some web tests, we enable under-invalidaton checking to crash on such problems. See this doc for more details about paint invalidation.

In your case, the DisplayItemClient is "LayoutHTMLCanvas CANVAS id='canvas'". It painted an empty foreground in the previous document life cycle, and paints (forced by under-invalidation checking) an image rect in the current cycle, but it has not been invalidated. If under-invalidation checking is disabled, you'll see missing image rect.

Based on the code, I guess canvas() changed from false to true in the current cycle, but we don't invalidate in this case. We seem to have some code (maybe in HTMLCanvasElement) that invalidates the DisplayItemClient when IsPaintable() changes, so the previous code works.

I think you just need to call SetShouldDoFullPaintInvalidation when canvas() changes.