Resize is crazy expensive in Mus+Ash in terms of number of IPCs. There are two channels to resize: through the window server, and through mus-gpu=>window server. Today, if a parent wishes to resize a child, the following happens:
1. parent tells window server to resize child.
2. window server receives request and forwards it to the child.
3. the child resizes and submits a compositor frame with a new surface ID
4. mus-gpu receives the new surface ID and sends it over to mus-ws.
5. mus-ws identifies the parent and sends the parent the surface ID.
6. the parent receives the new surface ID, embeds it in a layer, and submits a new compositorframe to mus-gpu.
All of these steps are along the critical path. Note that this glosses over lifetime management. Those IPCs need not be along the critical path (they can happen in parallel).
We can simplify resize immensely with the following flow:
1. parent tells child to resize.
2. parent gets surface Id from child that is a promise for the new size.
3. parent embeds surface ID in layer, and submits a new CompositorFrame.
Let's evaluate the security, and lifetime management implications of this approach and let's implement it!
Comment 1 by fsam...@chromium.org
, Oct 12 2016