994970 - (butter) Investigate Sending Touch Events from parent to content bypassing IPC

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect, P2)

Description

[Mason Chang [Inactive] [:mchang]]

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.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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

Comment 3

[Mason Chang [Inactive] [:mchang]]

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

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 7

[Mason Chang [Inactive] [:mchang]]

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.

Comment 8

[Mason Chang [Inactive] [:mchang]]

Attachment: signalData Sheet1.pdf

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.

Comment 9

[Mason Chang [Inactive] [:mchang]]

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

Comment 10

[Mason Chang [Inactive] [:mchang]]

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.