Bug 158826 – Specialize synchronous event tracking per event type

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Benjamin Poulain]

Specialize synchronous event tracking per event type

[Benjamin Poulain]

Created attachment 281433 [details]
Patch

[Benjamin Poulain]

Created attachment 281440 [details]
Patch

[Benjamin Poulain]

Created attachment 281478 [details]
Patch

[Benjamin Poulain]

Created attachment 281485 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 281485 [details]
Patch

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

> Source/WTF/wtf/HashMap.h:540
> -        if (bPos == notFound || it->value != bPos->value)
> +        if (bPos == notFound || !(it->value == bPos->value))

This is a bit sad because a class may implement a much cheaper operator != than operator ==. I don't think you should make this change.

> Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.cpp:254
> +        for (const auto& synchronousEventRegion : m_eventTrackingRegions.eventSpecificSynchronousDispatchRegions) {
> +            for (auto rect : synchronousEventRegion.value.rects()) {

Would be nice to log the event name here if possible.

> Source/WebCore/platform/EventTrackingRegions.cpp:47
> +    return asynchronousDispatchRegion.isEmpty()
> +        && eventSpecificSynchronousDispatchRegions.isEmpty();

No need to wrap.

> Source/WebKit2/Shared/Scrolling/RemoteScrollingCoordinatorTransaction.cpp:501
> +            for (const auto& synchronousEventRegion : node.eventTrackingRegions().eventSpecificSynchronousDispatchRegions) {
> +                for (auto rect : synchronousEventRegion.value.rects()) {

Dump event names.

> Source/WebKit2/UIProcess/WebPageProxy.cpp:1943
> +    if (static_cast<uintptr_t>(b) > static_cast<uintptr_t>(a))
> +        return b;
> +    return a;

return static_cast<TrackingType>(std::max<>(static_cast<uintptr_t>(a),static_cast<uintptr_t>(b))) ?

> Source/WebKit2/UIProcess/WebPageProxy.cpp:1983
> +    // We don't want to WebCore to be able to setup its state correctly after some
> +    // events were dismissed. We send everything, WebCore updates its internal state and dispatch what is needed.

I find this hard to understand.

[Benjamin Poulain]

Created attachment 281932 [details]
Patch

[Benjamin Poulain]

Created attachment 281946 [details]
Patch

[Benjamin Poulain]

Comment on attachment 281946 [details]
Patch

Clearing flags on attachment: 281946

Committed r202408: <http://trac.webkit.org/changeset/202408>

[Benjamin Poulain]

All reviewed patches have been landed.  Closing bug.