Bug 37642

Summary: Use a lower-overhead mechanism for plug-in message throttling
Product: WebKit Reporter: Steve Falkenburg <sfalken>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal    
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Other   
OS: OS X 10.5   
Attachments:
Description Flags
Patch aroben: review+

Description Steve Falkenburg 2010-04-15 00:50:42 PDT
Use a lower-overhead mechanism for plug-in message throttling
Comment 1 Steve Falkenburg 2010-04-15 01:14:47 PDT
Created attachment 53416 [details]
Patch
Comment 2 Adam Roben (:aroben) 2010-04-15 09:36:36 PDT
Comment on attachment 53416 [details]
Patch

> +        - The timer used to process the excess messages had a very low timeout (1ms).
> +          Other browsers use a value of 5ms for this delay.

You could say which "other browsers", for posterity's sake.

> +// Set a timer to make sure we process any queued messages at least every 16ms.
> +static const double MessageThrottleTimeInterval = 0.016;

It might be good to say (both here and in the ChangeLog) how 16ms was chosen.

> +// During a continuous stream of timers, process one every 5ms.
> +static const double MessageDirectProcessingInterval = 0.005;

I think you meant "stream of messages".

> @@ -74,11 +81,21 @@ void PluginMessageThrottlerWin::appendMe
>      if (!m_front)
>          m_front = message;
>  
> +    // If it has been more than MessageDirectProcessingInterval between throttled messages,
> +    // go ahead and process a message directly.
> +    double currentTime = WTF::currentTime();
> +    if (currentTime - m_lastMessageTime > MessageDirectProcessingInterval) {
> +        processQueuedMessage();
> +        m_lastMessageTime = currentTime;
> +        if (!m_front)
> +            return;
> +    }
> +

Seems like we should update m_lastMessageTime in processQueuedMessage() instead of here.

r=me
Comment 3 Steve Falkenburg 2010-04-15 09:52:17 PDT
Thanks for review.

Resetting m_lastMessageTime is processQueuedMessage resulted in messages not being processed in the direct 5ms mode.
Comment 4 Steve Falkenburg 2010-04-15 13:26:21 PDT
Committed r57650: <http://trac.webkit.org/changeset/57650>