Closed Bug 811210 Opened 7 years ago Closed 7 years ago

Jank in RPCChannel::WaitForNotify while panning in Google Streetview


(Core :: IPC, defect)

Windows 7
Not set





(Reporter: jaws, Unassigned)


(Whiteboard: [Snappy][sps])

Looking at the profile, 67.8% of the jank is spent in RPCChannel::WaitForNotify. Further, this appears to come from the call to MsgWaitForMultipleObjects (

The fourth parameter to MsgWaitForMultipleObjects is the time-out interval, which is currently being set to INFINITE.

I think we should be able to replace this line with a loop that has a shorter timeout and then spins the event loop before trying again.
I saw this while using Google Streetview with Flash 11.4.402.287 on Nightly 11-10-2012.
This profile basically says "the plugin process is responding slowly". This is a blocking wait on purpose, because we are waiting for the plugin process to reply to the NPAPI call. We must not spin the event loop here. You really need to understand why the plugin (is this Flash or a streetview plugin?) is not responding quickly.
This was using Flash. I don't have a streetview plugin installed.

Is there nothing that we can do in the instance where the plugin is slow to respond?
In general, that's correct. We can possibly try profiling the Flash processes to see what they are doing and whether we can repriorize our requests above that activity. I'd love to try that, but it's basically profiling black magic to get useful data out of that, especially without Flash sources.
Is this bug INVALID or WONTFIX then?

I admit to not knowing much about this area of the codebase, but it seems like we should specify a reasonable timeout here instead of infinity.
We have a 45-second timeout.
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.