Currently we pull them out of the IPC message queue in order. Dispatching each message is relatively costly, and events like mousemove/touchmove can trigger fairly expensive dispatch and get behind, introducing noticeable lag.
We should also use this for repaint requests, since we always want to service the most recent one and never process "stale" ones.
The right way to do this is bug 636063, though now that we have IPDL |union|s we may not need that complex of an API.
Created attachment 654164 [details] [diff] [review]
Compress touchmove events across processes
FWIW, Try confirms that this was the patch that caused the problems.
Bug 636063 by itself:
Try also confirmed that all the patches work fine
I guess I can push to try again, but if it comes back green (again), I have no idea what to do.
Also, none of this code runs in native-fennec.
Unless you'd prefer that I not, I'm going to re-push 636063 and 784647 to inbound in a little bit. Here are the Try runs I did:
For what it's worth, I did a Try push earlier that passed with all 3. It wasn't until after today's inbound merge that it blew up.
(In reply to Ryan VanderMeulen from comment #7)
> Unless you'd prefer that I not, I'm going to re-push 636063 and 784647 to
> inbound in a little bit.
It strikes me that one difference between try and inbound is that try will always clobber, though it worries me if that actually does affect the test runs. However, your push to try that failed in the same way doesn't convince me that that's a valid hypothesis.
There is no earthly reason this patch could break native-android tests. I'll do another push to try with latest inbound and see if the planets align differently now.
Another green run on try. Relanded