This CL makes it possible to build sky_shell on Linux. It doesn't do much, but
it doesn't crash on startup. The goal is to evetually be able to test sky_shell
on the bots and to be able to run the test_sky on Mac.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1202323002.
This file doesn't belong in the SDK because it is an implementation detail of
the Sky engine. Instead, this CL moves the code for dart:sky.internals into the
snapshot. This CL is a step towards merging dart:sky.internals with dart:sky,
which also resides in the snapshot.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1200953007.
* Cherrypick crrev.com/333293 (freetype -> freetype-android).
* Update mojo/go/go.py to use android-16 (NDK API level 16), which is
4.1 (first Jelly Bean). Chromium dropped support for 14.
* TODO (separately): also update tools/go/upload.py and upload new
binaries?
* Roll android_tools (to match Chromium).
* Small fixes to match //base changes: base::ObserverList, TraceConfig,
ThreadTicks, etc.
* Restore build/ls.py (and add it to the list of files to not roll).
* Remove the dependency on third_party/instrumented_libraries.
* Add "enable_topchrome_md = false" to build/config/ui.gni.
* Add build/config/ui.gni to files_not_to_roll in
update_from_chromium.py. (We should probably get rid of the use_glib
variable/argument, and others as well.)
* Remove mojo/tools/roll/{roll_network_service.py,
roll_network_service_patches/network_service.patch}. These are for
rolling from Chromium, whereas we now have/use monet.
* Roll buildtools (to match Chromium).
* Modify sanitizer gn/gni files to make it work (patch included).
(Maybe the patch even works -- I haven't checked.)
TBR=rockot@chromium.org,jamesr@chromium.org,rogulenko@google.com
Review URL: https://codereview.chromium.org/1180693002.
This also fixes an issue where eglChooseConfig was
only being called in InitializeOneOff, which is
only called once per process. This CL makes
choosing the config happen once per GLSurface
instead, which will ultimately permit apps to
create multiple native_viewports with different
surface configurations on the same display. The
eglDisplay object is still a global, though.
R=abarth@chromium.org, viettrungluu@chromium.org, jamesr@chromium.org
Review URL: https://codereview.chromium.org/1168993002.
This would occur when bringing SkyDemo to the front after
having viewed a SkyView based demo and then paused
the SkyActivity (by going to the Android Launcher, etc.)
I also fixed deploy_domokit_site.py to ignore .gitignore files
found in packages. We should actually probably ignore these
when creating the packages in the first place, but
this check seems valid regardless. The .gitignore for
sky/lib/assets was causing the assets not to get pushed
to the demo site.
R=abarth@chromium.org, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1163323007.
Fixed the mojo deploy script to no longer deploy mojo.
mojo now uses a more sophisticated CDN, etc.
Fixed old fn.dart to work again. :) Looks like it was
victim of a mass rename.
Fixed engine.cc to be able to handle navigating from
WebView content to SkyView content. We can't handle
the other direction yet, but we don't need to.
/sky_home is written in the .sky system but all of our
new examples are .dart (and thus SkyView).
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1165003006
We're currently in a transition between using main.sky and main.dart
files as our main() entry point for Sky applications.
This CL makes this runtime controlable by path name. If it finds
a .dart in the path name it will use SkyView, otherwise it will
fall back to the existing WebView codepath.
SkyView does not expose a window object and much of the existing
Sky Engine is not initialized when main() is run. Clients should
be transitioning away from main.sky towards main.dart in the near
future, however main.dart is probably not ready for general
consumption at this point.
R=ianh@google.com
Review URL: https://codereview.chromium.org/1152313002
It's useful to be able to call org.domokit.sky.shell.SkyMain.ensureInitialized() when implementing custom Android Activities. This commit makes ensureInitialized() public for this purpose.
Unrelated changes:
Added curly braces to pass PRESUBMIT check.
Add Lex Berezhny <lex@damoti.com> to AUTHORS file in order to be able to commit fixes (and pass PRESUBMIT check).
Patch by Lex Berezhny <lex@damoti.com>.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1135953004
This rolls in //base, //build and //sandbox/linux and updates other
things to match, in particular:
*) Update build_v8.patch
*) Add junit, mockito and roboelectric to DEPS for android test rules
*) Update DEPS for grit
*) Fix up various GN files for os->target_os rename
*) Fix up a few places that were using //base/float_util to use std::isnan
*) Fix up a few places using ApiCompatibilityUtil to use Android SDK directly
as well as a few miscellaneous fixes.
Many portions based on ncbray's work in
https://codereview.chromium.org/1108173002/R=ncbray@chromium.orgTBR=ncbray@chromium.org
Review URL: https://codereview.chromium.org/1124763003
1) Factors InkWell out of Material so that components can use an ink well
without needing the shadow/level machinery.
2) Makes the ink effect move at a different velocity once the tap has actually
occurred, converging with the spec. We don't have the right speeds yet, but
at least we're approaching the right shape.
3) To support (2), added a primaryPointer attribute to GestureEvents to let
authors coorelate gesturetapdown events with later gesturetap events.
4) To support (2), modernized SplashAnimation to used AnimatedValue and friends.
5) Added more constants to view-configuration.dart that match Android.
I've also removed the cancelling of the ink effect on scroll. The proper way to
do that is to notice that someone in the event chain is listening for
scrollstart and delay the beginning of the ink effect for some period of time.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1019023003
Previously, we weren't scheduling a visual update when our surface was created,
so we'd just continue to show black until the author requested a new animation
frame. After this CL, we schedule a visual update as soon as our surface is
created.
As part of this change, I've removed knowledge of the GPU delegate from
PlatformView. Now, all the calls from PlatformView to the GPU system bounce
through the UI delegate, which serializes the commands with other commands from
the UI engine to the GPU rasterizer.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/974483004
