Only PaintLayerPaintingOverlayScrollbars is actually ever set
to a different value in different codepaths.
-PaintLayerHaveTransparency can just be replaced with
isTransparent() calls.
-PaintLayerPaintingCompositingScrollingPhase is unused.
-PaintLayerPaintingCompositingAllPhases is always set,
which means that the other three compositing ones are
also always set.
The third bullet more clearly falls out when you see that
the only caller of paintLayerContents is
paintLayerContentsAndReflection, which sets
PaintLayerPaintingCompositingAllPhases on the paint flags.
Get rid of paintLayerContentsAndReflection since we no
longer have reflections.
The rest of the changes are all just propagating the now
always false or true booleans in paintLayerContents.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/778883002
It was added for compositing overflow:scroll, which we don't do.
This also means that only the RespectOverflowClip enum value is
used. And PaintingClipRectsIgnoringOverflowClip is unused.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/778753002
Since we don't support using the component build to produce mojo apps,
we can simplify the build targets in a few ways:
*) every mojo_native_application must depend on the c system thunks,
so just make that part of the template instead of requiring the dep
*) there's no such thing as depending on gles2 headers from a component,
so delete the forwarding group.
Most targets that want to use the gles2 headers in a mojo context
want to depend on an implementation through the thunks, so
//mojo/public/c/gles2 does just that. A smaller number of targets (such
as the implementation of the thunks) want to just depend on the headers
but not an impl, so they can depend on //mojo/public/c/gles2:headers.
The //mojo/public/gles target isn't that useful since the only thing we
expose is a set of C entry points.
We can probably also simplify the c system targets, but that's trickier
due to more extensive use from the chromium side.
BUG=438701
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/780733002
The StyleRule classes supported copy() operations and mutable
property sets so that we could do copy-on-write and mutate them
using the CSSOM. Sky doesn't have a CSSOM like this though,
so we can remove all this code and make the StyleRule classes
effectively immutable after construction (the parser does mutate some
rules though).
I also removed some other dead code in the StyleRule hierarchy,
like some left over mutation methods that the CSSOM used to use.
R=eseidel@chromium.org, ojan@chromium.org
Review URL: https://codereview.chromium.org/758573005
These were a feature for allowing multiple
scripting contexts to access the same global
state without leaking wrappers between them.
For example, if the inspector wanted to
modify window.Array.dangerousFunction = ...
it wouldn't want the author's content to have
access to that.
This feature is not part of Sky's security model
and thus this is just dead code.
I tried to remove worlds all together, but there
is something special about how we use a
"fake" world (which is neither main nor isolated)
for GC, regexp and testing.
R=rafaelw@chromium.org, abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/776143003
Includes updates to ui/ and mojo/services for cc and gpu changes and
a minor update to a unit test in sky/ for skia interface changes.
Review URL: https://codereview.chromium.org/761903003
TouchAdjustment adjusts the hit test rects to nearby elements so
that when touch targets are too small they can still be hit by users. Instead
applications should just make their touch targets big enough, and if they
need adjustment it should be implemented at the framework level.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/774053003
We should come up with a better way to implement this feature for the
inspector, the current implementation uses CSSOM wrappers and is n^2
over the number of rules in the page.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/772363002
In preparation of simplifying how we collect and process sheets now
that we don't support descendant, sibling and tree boundary crossing
rules we should switch to always going down the Reconstruct path.
This might be somewhat slower to start, but because our rules are so
much simpler we should be able to rebuild the StyleEngine to do
something simpler and faster.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/774953002
It was attempting to load InjectedScript, etc.
with the wrong path and hitting a CHECK().
I moved InjectedScript and DebugScript into
the v8_inspector directory and fixed their loading.
I also broke the dependency from v8_inspector
onto engine/platform by moving the horrible
Platform::loadResource hack out of PlatformImpl
into a new file just for v8_inspector.
In this process I also found some (broken!)
code for showing the broken image icon which
if we ever hit would just have crashed, so
I removed that code as well.
BUG=435243
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/776743002
Removed all uses of Frame in InspectorTraceEvents
in the process, since none of them actually
needed a Frame (since each sky instance only
has one frame).
I've just been burning down the list of core
includes using:
grep "#include" sky/engine/v8_inspector/* -h | sort | uniq | sort | grep core
TBR=yurys@chromium.org
BUG=435243
Review URL: https://codereview.chromium.org/771323002
This doesn't fully separate v8_inspector from
core, but it does lay the path.
The next steps to removing v8_inspector is to
remove all the # FIXME: Remove lines in the
deps section of v8_inspector/BUILD.gn.
gn check out/Debug v8_inspector
will tell us if we've successfully removed
all the dependencies.
It's unclear if we want to remove the wtf
dependency, but definitely all of the engine/core
dependencies should be removed and presumably
replaced with abstract interfaces which can be provided
to v8_inspector by its host.
Given the size of this patch (and that it's largely
mechanical) I plan to TBR it.
Most of this was done with tools/git/move_source_file.py
TBR=yurys@chromium.org
Review URL: https://codereview.chromium.org/772563003
We not longer have compositing, so these states are gone.
This was causing asserts to hit because we'd go from
PaintInvalidationClean to InPaintInvalidation, which is
now a valid transition if a new frame is pumped without
style or layout being dirtied.
Unfortunately, we can't test this until we fix test_sky
to actually pump fake frames.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/755843003
This adds a tracing service that can aggregate tracing data from
multiple sources and write a json file out to disk that trace-viewer can
understand. This also teaches the shell, sky_viewer, and various other
services how to register themselves with the tracing service and provide
tracing data on demand. Finally, this teaches the skydb prompt to tell
the tracing service to start/stop tracing when the 'trace' command is
issued.
The tracing service exposes two APIs, a collector interface and a
coordinator interface. The collector interface allows different entities
to register themselves as being capable of producing tracing data. The
coordinator interface allows asking the service to collect data from
all registered sources and flushing the collected data to disk.
The service keeps track of all open connections to registered sources
and broadcasts a request for data whenever the coordinator's Start
method is called, then aggregates all data send back into a single
trace file. In this patch, the tracing service simply gives all sources
1 second to return data then flushes to disk. Ideally it would keep
track of how many requests it sent out and give each source a certain
amount of time to respond but this is simple and works for most cases.
The tracing service can talk to any source that is capable of producing
data that the trace-viewer can handle, which is a broad set, but in
practice many programs will want to use //base/debug's tracing to
produce trace data. This adds code at //mojo/common:tracing_impl that
registers a collector hooked up to //base/debug's tracing system. This
can be dropped in to the mojo::ApplicationDelegate::Initialize()
implementation for most services and applications to easily enable
base tracing. Programs that don't use //base, or that want to register
additional data sources that can talk to trace viewer (perhaps providing
data that's more easily available from another thread, say) may want
to create additional connections to the tracing service.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/769963004
