Bug 1157908 - Give Gecko thread Looper low priority; r=snorp
authorJim Chen <nchen@mozilla.com>
Mon, 27 Apr 2015 20:52:52 -0400
changeset 241290 cad4ead8fc8817115611dbaff449265861bb206c
parent 241289 ac11b098effd3d18aa072494805f868dc49a6f8a
child 241291 a2619dca0a1691f3b01bc9defa595c9de9179a91
push id59081
push usernchen@mozilla.com
push dateTue, 28 Apr 2015 00:55:39 +0000
treeherdermozilla-inbound@a2619dca0a16 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerssnorp
bugs1157908
milestone40.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1157908 - Give Gecko thread Looper low priority; r=snorp
ipc/glue/MessagePump.cpp
widget/android/nsAppShell.cpp
--- a/ipc/glue/MessagePump.cpp
+++ b/ipc/glue/MessagePump.cpp
@@ -18,20 +18,16 @@
 #include "nsDebug.h"
 #include "nsServiceManagerUtils.h"
 #include "nsString.h"
 #include "nsThreadUtils.h"
 #include "nsTimerImpl.h"
 #include "nsXULAppAPI.h"
 #include "prthread.h"
 
-#ifdef MOZ_WIDGET_ANDROID
-#include "AndroidBridge.h"
-#endif
-
 #ifdef MOZ_NUWA_PROCESS
 #include "ipc/Nuwa.h"
 #endif
 
 using base::TimeTicks;
 using namespace mozilla::ipc;
 
 NS_DEFINE_NAMED_CID(NS_TIMER_CID);
@@ -100,25 +96,16 @@ MessagePump::Run(MessagePump::Delegate* 
     if (!keep_running_)
       break;
 
     // NB: it is crucial *not* to directly call |aDelegate->DoWork()|
     // here.  To ensure that MessageLoop tasks and XPCOM events have
     // 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()
 #ifdef MOZ_NUWA_PROCESS
     && (!IsNuwaReady() || !IsNuwaProcess())
 #endif
    )
       mDelayedWorkTimer->Cancel();
--- a/widget/android/nsAppShell.cpp
+++ b/widget/android/nsAppShell.cpp
@@ -238,16 +238,25 @@ nsAppShell::ProcessNextNativeEvent(bool 
         js::ProfileEntry::Category::EVENTS);
 
     nsAutoPtr<AndroidGeckoEvent> curEvent;
     {
         MutexAutoLock lock(mCondLock);
 
         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();
 
             // hmm, should we really hardcode this 10s?
 #if defined(DEBUG_ANDROID_EVENTS)
             PRTime t0, t1;
             EVLOG("nsAppShell: waiting on mQueueCond");