Comment 8 for bug 1550371

I added a few trace events in Oxide earlier that would aid debugging in chrome://tracing/. Unfortunately, there's no way to save the trace from the browser for offline viewing (as it's incompatible with the way we do downloads) and I can't take a screenshot of it because screenshots on Freiza are broken.

I'll try to describe the first main observation:

1) After the webview compositor has finished producing a frame, it calls in to oxide::CompositorSingleThreadProxy::SwapCompositorFrame.
2) At this point, we insert a fence in the command stream and flush.
3) After the fence is signalled, we run oxide::CompositorSingleThreadProxy::ContinueSwapGLFrame.
4) This ends up entering QQuickItem::update for the webview, which schedules a sync.
5) At the end of the sync (OxideQQuickWebView::updatePaintNode), we call back in to the webview compositor to notify it that the swap has completed and that the old buffer can be used as the back buffer.

I've added a trace event to time how long it takes to get from 2 to 3 - it's currently ~5-6ms. This is basically how long it takes the GPU service to execute the commands that were just flushed for compositing the webview, and isn't particularly out of the ordinary.

I've also added a trace event to time between 4 and 5, which is basically timing how long it takes between scheduling an update and the sync completing, and I'm seeing regular delays of up to 30ms. Within 5ms of scheduling an update (calling QQuickItem::update), the main thread appears to be completely blocked (although, I am only looking at compositor events in chrome://tracing/).

Whilst there are optimizations we can work in Oxide, the main bottleneck here appears to be something else.