Consider combining the constellation and compositor tasks

[pcwalton]

When implementing some basic features of the CefFrame API, I found it necessary for the compositor thread to block on the constellation thread. This led me to wonder whether we're better served by just combining the two tasks, to avoid the memory overhead of multiple threads and to reduce complexity by eliminating the requirement that algorithms that involve the two be distributed algorithms.

Both the constellation and the compositor both live in compositing, suggesting their natural connection, and most other browser engines combine the two threads as well. This should not be a performance issue since the constellation doesn't do any heavy computation—it's purely coordination.

[jdm]

I can't recall if we talked about one constellation per tab or whether a constellation would contain multiple tabs. There could be a mismatch with the single compositor if the former.

[larsbergstrom]

That was the original plan (Constellation-per-tab) and I thought it was also intended to serve as an IPC boundary if we end up doing tab process isolation in the future. I thought the idea was that the compositor would be the only trusted UI process and that everything running within a given constellation could have restricted privileges.

[KiChjang]

Is this still desired, given that we have a different model?