Hi,

I'm not sure what you are getting at in this bug. Are you suggesting a particular
heuristic be moved to Blink?

I'm curious as to what is the purpose of this optimization in cc, where it selectively asks for display lists for particular layers from blink. Is it to avoid spending time in recording display items for layers that will not be drawn in a frame update? And if so, does the current setup achieve this?

Yes, this code is optimizing which layers update themselves. Paint (recording
DisplayItemLists) and invalidation still happen, but various other later updates in cc are saved.

See  issue 591561  for some discussion about whether it's a good idea to get rid
of these optimizations. We decided not to, in part because of UI compositor use cases,
and in part because it does seem legitimate to avoid work.

Closing this bug.

Thanks for clearing that up. I thought the aim was to avoid paint which is why I was a bit confused.

Avoiding paint used to be one of the purposes, but now that we have synchronized paint (as of Chrome 49) it does not surve that purpose. Note that for the UI
compositor use case, it does indeed avoid paint, because its painting code is
on-demand unlike Blink.

Yeah I looked at the code and looks like the old on-demand code-path for blink painting is only used for testing now. Are there any plans for implementing similar optimizations to avoid paint in blink, to work with synchronized paint?

We will probably implement similar things at some point, yes. Right now we're
focused on re-implementing the compositing system with equivalent performance.