Revert "Rename dart_master.cpp to .cc, consistent with chromium style"
Revert "Move the files we're actually building into bindings2"
This reverts commit 0fc92de0468213f621cba0fbdfd96c1625052ba7.
This reverts commit 155144772817476e87bbe20ddc2071308e3f61e6.
This reverts commit fda181ae2420071af887b5914bd9a9bda8a09725.
These CLs belong in the skydart branch.
TBR=rafaelw@chromium.org
Review URL: https://codereview.chromium.org/860273005
This is for doing masking based off the alpha channel of
an image. This is a feature we want to support, but we
want a more general imperative API that the declarative thing
is built on top of.
In the meantime, the code is getting in our way and the
feature was already broken (likely from before making sky public).
We just paint the mask image on top instead of doing the actual
masking.
This patch just removes the parsing. Followup patches will
remove the implementation code.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/892903002
Normal trace events already go directly to base. This CL removes the remaining
trace events that were still indirected through blink::Platform. These were
just the half-finished inspector timeline trace events, which currently aren't
actually hooked up to anything.
This CL also removes the redunant "convertable to trace format" wrappers and
moves their one remaining use over to just using the version in base directly.
R=eseidel@google.com, ojan@chromium.org
Review URL: https://codereview.chromium.org/889823002
This is just a mechanical removal. No logic changes
beyond removing the PaintPhaseSelection checks.
Most of these are just early returns to avoid doing
unnecessary work if we're only painting selections.
But now that we paint selections during the foreground
paint phase, we no longer need the early returns since
we're going to paint everything anyways.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/886933002
These appear to have been for ensuring that you
only paint elements in a given subtree. It's not clear
to me exactly how you get to painting an element that
is not rooted at the RenderLayer you started with.
I think it's just not possible in Sky anymore.
This code was added in 2004 for drag images, which
we no longer support.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/882223005
HTMLIFrameElement was adding the observer in navigateView. If the same
HTMLIFrameElement navigated multiple times HTMLIFrameElement would
attach itself as an observer more than once. ObserverList doesn't like
this.
Also adds src as an attribute of HTMLIFrameElement so that I can do:
iframe.src = xxx
in script
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/885783002
Update from https://crrev.com/313321
This roll is to pick up a fix which prevents -Wl,--as-needed being used
in Release ASAN builds.
This also has some manual changes to mojo only code to fix interface
changes from chromium (mainly, changes in skia interfaces, and changes
in cc). It updates a cc patch, which started failing to apply I also
added patch files to deal with the upstream move of mojo to
third_party/mojo/.
BUG=452105
TBR=jamesr@chromium.org
Review URL: https://codereview.chromium.org/885443002
Mostly just mechanical changes. The one surprising bit
is that RenderLayer no longer needs to explictly paint
outlines. I tested manually that before this patch,
the paintOutline call in RenderLayer was needed for
outlines on positioned elements and that after this
patch it's not.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/878023002
The semantics of requestAnimationFrame and scheduleVisualUpdate are slightly
different. If you're inside a requestAnimationFrame, then calling
requestAnimationFrame should schedule you for next frame. However, if you're
inside a requestAnimationFrame and you scheduleVisualUpdate, that's a noop
because we've already got a visual update pending. When we merge the codepaths,
we broke requestAnimationFrame because it became a noop when called inside a
request animation frame.
We really ought to split up the two roles of requestAnimationFrame (run before
the frame boundary and run once per frame).
R=esprehn@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/880013003
Commit efc3afd428bd85fd3d12e0dc941b5eb7248ca30b broke it because
we'd computed an empty foreground layer. Now that background
painting is part of the foreground phase, we need to use the
background rect for clipping. As best I can tell, the
background rect is always >= the size of the foreground
rect, so it should be safe to use.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/876243002
We've simplified RenderBlock::layout to the point where we
no longer need it or layoutBlock. The RenderBlock subclasses
can just override layout the way every other renderer does.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/876663003
Jagged edge outlines are more complexity than is justified
for the use-cases. We should enable to use-cases like this,
but with a lower-level line-box + custom painting API.
Removes the paintOutline method on RenderInline. Also removed
a number of dead methods that call absoluteRects so we can delete
that method and related code.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/867653005
This CL uses the aura fling curve to ease flings. Also, I've made Event#timeStamp
use consistent units and timebase with the requestAnimationFrame timestamp. Now
both are doubles of milliseconds since the epoch.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/880473003
It causes a full screen raster right now, lets name it for what it does.
This also matches the name used in PageAnimator.
Merge WebWidgetClient into WebViewClient.
They're always the same thing in sky. I also removed all the methods that
don't do anything in sky.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/880713003
First step in getting rid of paint phases. Verified that
deleting this phase entirely would cause flights-app-pixel.sky
to fail and that it still passes in this patch, which just does
the background painting as part of the foreground phase.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/867463005
The only scheduleAnimation() methods left are going through the layers of
client interfaces. I'll rename and remove those next. This is working
towards making requestAnimationFrame() not cause a full repaint and also
making it more clear to callers that scheduling a frame causes a raster.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/875283003
This was to support doing background: -webkit-canvas(#id) where you could then
get the canvas with document.getCSSCanvasContext(id) and draw into it which
is a poor form of custom drawing for elements. In Sky we'll have real custom
painting instead of just background images hacked in like this.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/876913002
