Description[Ozone-DRI] Assume window IPC arrives before surface IPC
Creating a DriWindow happens before the Compositor associated with
it. On DriWindow creation an IPC is sent to the GPU process to
initialize the window on the GPU side. The Compositor also sends
an IPC to create a surface for the window. Since the same channel
is used when IPC-ing both messages, the order of IPCs should be
maintained. Thus, assume that, on the GPU side, the window (delegate)
is already present when trying to create a surface.
Note the previous implementation was working around an issue during
initialization where the channel wasn't established. The issue was
that the channel in the platform was established late, so the IPCs
in Chrome would be serviced before the IPCs in the Ozone platform.
For clarity, these are the major steps taken at startup when creating
a window:
1) PostTaskOnUI(create GpuProcessHostShim)
2) Create WindowTreeHost
3) Create DriWindow
a) If channel established PostTaskOnIO(create window on GPU)
4) WindowTreeHost::OnAcceleratedWidget()
5) Create Compositor
6) PostTaskOnUI(create output surface)
7) MessageLoop::Run()
8) Execute task in (1)
a) Create GpuProcessHostShim
b) OnChannelEstablished
i) DriWindow::OnChannelEstablished -> PostTaskOnIO(create window
on GPU)
9) Execute task in (6) -> PostTaskOnIO(create surface on GPU)
Note, even if the channel isn't up and running in step (8), messages
will be queued internally in GpuProcessHost. Thus the messages in
(8) and (9) will be queued in the correct order.
BUG=none
NOTRY=true
Committed: https://crrev.com/60ee6c04a0c218b290581364289cae3297fa40d8
Cr-Commit-Position: refs/heads/master@{#313521}
Patch Set 1 #
Messages
Total messages: 7 (2 generated)
|