This allows the DisplayCompositor in the GPU to still end up inside the command buffer's implementation so it can do things like sync tokens and mailboxes. But the implementation of GLRenderer would need to be inside the command buffer and do those things directly instead of thru command buffer APIs.

If we want to share code still, then DirectRenderer would need to exist for software, so instead of DrawCompositorFrame, maybe DrawRenderPass would be more appropriate. Possibly DrawDrawQuad.. but hopefully not as that's more commands! 

Note, overlays would be implemented entirely inside the command buffer too. As would platform-specific mac wonders.

Is that really blocking?
It may very well be worth doing, but not exactly trivial to do.

Not sure yet, I'm leaving it as blocking shipping for now, but we won't know until we collect more data.

This should go under performance-specific stuff. I'll move.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

kylechar@ is actively discussing issues with the InProcessCommandBuffer. Please update.

I think the plan of record is getting SkiaRenderer working and no longer using InProcessCommandBuffer.