If we can't get IPC latency down, or if it is unacceptable latency, see if we can send touch events from the content to the parent directly.

We need to be sure that the problem is IPC latency and not that the main thread event loop is busy first.

Which touch events are going from the content to the parent? Generally touch events go from the parent to the child process.

Woops thanks for catching that. Updated title to reflect the actual situation.

Thanks, that makes more sense. And for the record, whenever I have encountered delays in touch events going from parent -> content (I've seen delays of 2 seconds or more) it's been because the content main thread is busy doing stuff. On Fennec on slow devices we regularly encounter gecko busy for upwards of 5 seconds.

If pan/zoom messages don't need to hit the main thread then we can do something about it. If they do then we're back to the same problem of keeping our main thread event loops responsive.

For APZ-driven async panning and zooming, touch events need to go through the parent process main thread, but not the content process main thread. I filed bug 930939 a while ago to also remove the parent process main thread dependency, along with a diagram that illustrates what is happening.

From the summit, we probably need bug 930939. Some option might be a signal that says a vsync occurred then we can read the touch events off main thread.

From bug 991420, using a signal, we're able to get the latency down from ~1-2 seconds sometimes with IPC to on average ~.1 ms, which is great. We only want to send a signal from the b2g parent process -> foreground content process and that schedules a nsRefreshDriver::Tick. Then we ignore the signal until we're done ticking the refresh driver so we don't overload the system. I think this is the way to go for Project Silk.

After chatting with :bent, possible alternatives to a signal: Create a new PBackground in the child that does nothing but listen to vsync. When the vsync message from the Parent::PBackground occurs, it wakes up the new thread in the child process which atomically set a flag instead. Then alter the main thread event loop to do something different maybe like tick the refresh driver. Will have the ordering problems of the event loop. Also try using the standard PBackground thread which goes from Parent::PBackground thread -> Content::Main thread, bypassing the Parent process::main thread and just posting a task on the event loop. Can also try from a Parent::PBackground thread -> Content::PBackground Thread. Still goes from PBackground thread -> IPC | cross process -> PIPC -> PBackground Ask roc, if we know when a vsync occurs, could we prioritize a nsRefreshDriver::tick before other things and reorder the event loop. Will get to this only if taking input events off main thread isn't good enough. PBackground links http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentChild.cpp#643 http://mxr.mozilla.org/mozilla-central/source/dom/ipc/PContent.ipdl#276

Touch events have to be processed by content and with bug 930939, touch events get processed first, we can resolve for now. Reopen if still an issue.