Bug 185425 – REGRESSION(r230743): Mousemove events are not coalesced properly, mousemove/drag is very laggy

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Blaze Burg]

Oops.

[Blaze Burg]

<rdar://problem/39323336>

[Blaze Burg]

Created attachment 339824 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 339824 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=339824&action=review

> Source/WebKit/UIProcess/WebPageProxy.cpp:1929
> +    bool lastQueuedEventWasAMouseMove = m_mouseEventQueue.size() > 1 && m_mouseEventQueue.last().type() == WebEvent::MouseMove;

Why not size() > 0 ?
I would call it lastQueuedEventWasMouseMove or do away with the variable entirely.

[Blaze Burg]

(In reply to Simon Fraser (smfr) from comment #3)
> Comment on attachment 339824 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=339824&action=review
> 
> > Source/WebKit/UIProcess/WebPageProxy.cpp:1929
> > +    bool lastQueuedEventWasAMouseMove = m_mouseEventQueue.size() > 1 && m_mouseEventQueue.last().type() == WebEvent::MouseMove;
> 
> Why not size() > 0 ?

Events are dequeued when WebProcess is done handling them.

If size 0, then nothing is being processed in WebProcess.
If size 1, we sent the event and are waiting on the reply.
If size 2, then the first event is being processed and the second event is queued and will be sent to WebProcess when the previous event is retired.

So if there is only one event and it's a mousemove, we can't update it because it's already been sent.

> I would call it lastQueuedEventWasMouseMove or do away with the variable
> entirely.

[Blaze Burg]

Created attachment 339863 [details]
For EWS

[Blaze Burg]

Created attachment 339874 [details]
For EWS

[Blaze Burg]

Committed r231511: <https://trac.webkit.org/changeset/231511>

[Lucas Forschler]

Mass move bugs into the DOM component.