Bug 1157908 - Give Gecko thread Looper low priority; r=snorp

This commit is contained in:
Jim Chen 2015-04-24 14:40:55 -04:00
parent 90e0911a81
commit a46ab26a5f
2 changed files with 9 additions and 13 deletions

View File

@ -23,10 +23,6 @@
#include "nsXULAppAPI.h"
#include "prthread.h"
#ifdef MOZ_WIDGET_ANDROID
#include "AndroidBridge.h"
#endif
#ifdef MOZ_NUWA_PROCESS
#include "ipc/Nuwa.h"
#endif
@ -105,15 +101,6 @@ MessagePump::Run(MessagePump::Delegate* aDelegate)
// equal priority, we sensitively rely on processing exactly one
// Task per DoWorkRunnable XPCOM event.
#ifdef MOZ_WIDGET_ANDROID
// This processes messages in the Android Looper. Note that we only
// get here if the normal Gecko event loop has been awoken above.
// Bug 750713
if (MOZ_LIKELY(AndroidBridge::HasEnv())) {
did_work |= mozilla::widget::GeckoAppShell::PumpMessageLoop();
}
#endif
did_work |= aDelegate->DoDelayedWork(&delayed_work_time_);
if (did_work && delayed_work_time_.is_null()

View File

@ -243,6 +243,15 @@ nsAppShell::ProcessNextNativeEvent(bool mayWait)
curEvent = PopNextEvent();
if (!curEvent && mayWait) {
// This processes messages in the Android Looper. Note that we only
// get here if the normal Gecko event loop has been awoken
// (bug 750713). Looper messages effectively have the lowest
// priority because we only process them before we're about to
// wait for new events.
if (widget::GeckoAppShell::PumpMessageLoop()) {
return true;
}
PROFILER_LABEL("nsAppShell", "ProcessNextNativeEvent::Wait",
js::ProfileEntry::Category::EVENTS);
mozilla::HangMonitor::Suspend();