Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 08 Sep, 2014 34 commits
  3. 07 Sep, 2014 6 commits
    • jamesr@chromium.org's avatar
      GN: Update heap stubs for android · f396411b
      jamesr@chromium.org authored 
      On non-intel (aka non x86/x64) we can compile the assembly stubs as a
source_set and not use yasm.

R=brettw@chromium.org

Review URL: https://codereview.chromium.org/541933003

git-svn-id: svn://svn.chromium.org/blink/trunk@181529 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      f396411b
    • pdr@chromium.org's avatar
      [trivial] Remove RenderBox::MarginSign · f09857c5
      pdr@chromium.org authored 
      This patch removes the unused MarginSign enum. I noticed this while
searching how we name enums in Blink as part of another patch.

Since I was in the area, I fixed the comment about margins as well.

R=esprehn

Review URL: https://codereview.chromium.org/548113002

git-svn-id: svn://svn.chromium.org/blink/trunk@181528 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      f09857c5
    • bokan@chromium.org's avatar
      Made Blink aware of top controls offset (Blink-side) · d1a94178
      bokan@chromium.org authored 
      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/511253003 for Chromium-side patch.

BUG=333143

Review URL: https://codereview.chromium.org/513053003

git-svn-id: svn://svn.chromium.org/blink/trunk@181527 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      d1a94178
    • pdr@chromium.org's avatar
      Remove hasContentsLayer and isMainFrameRenderViewLayer from CLM · 5b9340b2
      pdr@chromium.org authored 
      This patch removes some deadcode from CompositedLayerMapping:
1) hasContentsLayer - this function name was confusing.
2) isMainFrameRenderViewLayer - state is now all within CLM.

No new tests, no change in behavior.

Review URL: https://codereview.chromium.org/542863007

git-svn-id: svn://svn.chromium.org/blink/trunk@181526 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      5b9340b2
    • noel@chromium.org's avatar
      Remove fast/multicol rebaseline request from TestExpectations · 39b648c8
      noel@chromium.org authored 
      Rebaseline-o-matic failing to rebaseline these results: some issue with
changing to it's third_party/WebKit directory. Remove baseline requests
for multicol tests on Snowleopard Debug:

fast/multicol/pagination-h-horizontal-bt.html
fast/multicol/pagination-h-horizontal-tb.html
fast/multicol/pagination-v-horizontal-bt.html
fast/multicol/pagination-v-horizontal-tb.html
fast/multicol/client-rects.html

TBR=wangxianzhu@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=409708

Review URL: https://codereview.chromium.org/553673002

git-svn-id: svn://svn.chromium.org/blink/trunk@181525 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      39b648c8
    • noel@chromium.org's avatar
      Submit of Mac 10.6 rebaselines for fast/composting tests · db042691
      noel@chromium.org authored 
      Rebaseline server is not submitting them at thit time, event though it
has been asked to do so. Ran webkit-patch rebaseline-expectations, and
pulled results from the 10.6 Mac bots for submit (old skool).

TBR=wangxianzhu@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=None

Review URL: https://codereview.chromium.org/554503002

git-svn-id: svn://svn.chromium.org/blink/trunk@181524 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      db042691