diff options
author | bokan <bokan@chromium.org> | 2014-09-09 13:40:42 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2014-09-09 20:51:01 +0000 |
commit | 88eae010cdf470913c2575222185c6ab99067df4 (patch) | |
tree | 83d35a93d52c701276ae0185a4eee5468dabb8f4 /cc/trees/layer_tree_host_common.h | |
parent | 1df5b71300297a83efb39b8666ba0ff44369947c (diff) | |
download | chromium_src-88eae010cdf470913c2575222185c6ab99067df4.zip chromium_src-88eae010cdf470913c2575222185c6ab99067df4.tar.gz chromium_src-88eae010cdf470913c2575222185c6ab99067df4.tar.bz2 |
Made Blink aware of top controls offset
Added all the plumbing to make Blink aware of the top controls position
and how its viewport has been resized as a result. This CL adds all the
machinery and plumbing but does not yet connect main-thread scrolls to
the top controls. This is needed to support scrolling the top controls
during slow-scrolls as well as correct viewport behavior in the virtual
viewport pinch-to-zoom.
The machinery for top controls now includes two values:
top_controls_layout_height: The amount that the viewport was shrunk to
accommodate the top controls. This is updated only during a layout that
causes a viewport resize (i.e. RenderWidget::OnResize). The compositor
needs this to know how much the viewport layer has already been resized
by Blink.
top_controls_content_offset: The amount that the top controls are showing.
This will be the same as top_controls_layout_height right after a viewport
resize, but will diverge since the top controls will move without
immediately causing a RenderWidget resize.
Blink now keeps track of the top controls "content offset", which is the
distance the content is offset from the top of the screen due to top
controls. It receives updates to this value from the Impl thread during
a commit and echos them back to the compositor.
On the compositor side, the top controls layout height is moved into the
LayerTreeImpl. This is necessary since a commit will change the viewport
layer's size on the pending tree. Keeping it in LayerTreeHostImpl meant
that, until the pending tree was activated, the top controls layout height
corresponded to the viewport bounds in the pending tree. This was causing
flickering as the viewport container was the incorrect size for a short
time. The compositor also keeps track of the top controls content offset
value. The top controls offset uses the same model as page scale, keeping
an offset (the value as known by the main thread), a delta from the main
thread's value, and a sent_delta to keep track of what has been sent to
the main thread.
See https://codereview.chromium.org/513053003 for Blink-side patch.
BUG=333143
Review URL: https://codereview.chromium.org/511253003
Cr-Commit-Position: refs/heads/master@{#294003}
Diffstat (limited to 'cc/trees/layer_tree_host_common.h')
-rw-r--r-- | cc/trees/layer_tree_host_common.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/cc/trees/layer_tree_host_common.h b/cc/trees/layer_tree_host_common.h index c86c4aa..1f47172 100644 --- a/cc/trees/layer_tree_host_common.h +++ b/cc/trees/layer_tree_host_common.h @@ -140,6 +140,7 @@ struct CC_EXPORT ScrollAndScaleSet { std::vector<LayerTreeHostCommon::ScrollUpdateInfo> scrolls; float page_scale_delta; + float top_controls_delta; ScopedPtrVector<SwapPromise> swap_promises; }; |