[Webkit-unassigned] [Bug 111405] New: [EFL][Qt][WK2] Make PageViewportController more readable.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=111405

           Summary: [EFL][Qt][WK2] Make PageViewportController more
                    readable.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: luxtella at company100.net


Refactor PageViewportController to reveal subtle intention handling scaling and
scrolling more explicitly.

Note we only use pending mechanism when PageViewportController is the source of
scaling or scrolling, and didRenderFrame() plays a role to notify time to flush
pending variables to the client.

1. Scaling
There are two kind sources of scaling events: PageViewportController itself and
the client (a.k.a the viewport).

If the client is the source, we must change the scale of PageViewportController
and WebCore immediately.

If PageViewportController is the source, we pend to sychronize the scale with
the client until receiving didRenderFrame() call, while we notify WebCore
immediately. It is because it is a special case in which we concern about
performance: setPageScaleFactorWithPendingChange() and
updateMinimumScaleToFit().

One big change is that didRenderFrame() does not call WebPageProxy::scalePage()
because didRenderFrame() is time to sychronize the scale of
PageViewportController with the client. If we call WebPageProxy::scalePage() in
didRenderFrame(), we will receive redundant didRenderFrame() call one more time.

2. Scrolling
There are three kind sources of scrolling events: PageViewportController itself,
the client and WebCore.

If the client is the source, we must change the scroll position of
PageViewportController and WebCore immediately.

If PageViewportController is the source, we pend to sychronize the scroll
position with the client until receiving didRenderFrame() call, while we notify
WebCore immediately. It is because it is a special case in which we concern
about performance: didCommitLoad() and the special case of pageDidRequestScroll().

If WebCore is the source, PageViewportController::pageDidRequestScroll() is
called. We must change the scroll position of PageViewportController and the
client  immediately.

There is one big changes: PageViewportControllerClient::setViewportPosition()
does not call PageViewportController::didChangeContentsVisibility().
didChangeContentsVisibility() is called when the client is the source of scaling
or scrolling events and setViewportPosition() is called when
PageViewportController want to syncronize the scroll position with the client,
so setViewportPosition() must not call didChangeContentsVisibility().
I introduced PageViewportControllerClientQt::m_isViewportPositionSychronizingWithPageViewportController
to achieve above requirement.

In addition, I introduced m_changingViewportAttributes to not change the scale
and scroll position during changingViewportAttributes. Currently,
PageViewportController::didChangeViewportAttributes() overuses
m_pendingPositionChange and m_pendingScaleChange for the purpose of
m_changingViewportAttributes.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.