From a51f18c04d28b77e7cc2728c0cb85a2b2998ef54 Mon Sep 17 00:00:00 2001
From: Stephen Blott
Date: Sat, 2 Apr 2016 06:51:56 +0100
Subject: Use port for frame-to-background messages.

Without considering the size of the data passed, ports seem to be about
5 times fast than sendMessage(), so we use ports of link-hint messages
wherever possible.
---
 background_scripts/main.coffee | 7 +++++++
 1 file changed, 7 insertions(+)

(limited to 'background_scripts/main.coffee')

diff --git a/background_scripts/main.coffee b/background_scripts/main.coffee
index 663871de..107edc45 100644
--- a/background_scripts/main.coffee
+++ b/background_scripts/main.coffee
@@ -335,6 +335,9 @@ Frames =
   initializeTopFrameUIComponents: ({tabId}) ->
     portsForTab[tabId][0]?.postMessage handler: "initializeTopFrameUIComponents"
 
+  linkHintsMessage: ({request, tabId, frameId}) ->
+    HintCoordinator.onMessage extend(request, {frameId}), tab: id: tabId
+
 handleFrameFocused = ({tabId, frameId}) ->
   frameIdsForTab[tabId] ?= []
   frameIdsForTab[tabId] = cycleToFrame frameIdsForTab[tabId], frameId
@@ -351,6 +354,10 @@ cycleToFrame = (frames, frameId, count = 0) ->
 HintCoordinator =
   tabState: {}
 
+  # These messages can be received via sendRequestHandlers or via a Frames port.  The Frames port seems to be
+  # considerably faster (about a factor of 5), so we use that whenever possible.  However, when sending
+  # messages, we use chrome.tabs.sendMessage because, in tabs with many frames, broadcasting seems (?) likely
+  # to be faster.
   onMessage: (request, {tab: {id: tabId}}) ->
     if request.messageType of this
       this[request.messageType] tabId, request
-- 
cgit v1.2.3