Previously, any updates to scroll offset on the main thread updated both
scroll offset and layer position. CalcDrawProperties only used position
and ignored scroll offset. This patch changes that to consider scroll
offset equally with scroll delta when computing a layer's tranform.
Although this patch doesn't do anything about it yet, the end result of
this disentangling is that it will become possible to early out in
Layer::SetScrollOffset and not require a SetNeedsCommit when Blink
updates the scroll offset to the value that it already is on the
compositor thread.
This is step 3 of a patch series to disentangle layer position and
scroll offset. This patch depends on both
https://codereview.chromium.org/18405003/ and
https://codereview.chromium.org/18187004/.
R=danakj@chromium.org
BUG=256381
Review URL: https://chromiumcodereview.appspot.com/18400003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@211176 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
So we can have the perf bots run with aura for a while. Depending how red
the waterfall we could leave it on for a long time.
This has happened before and it will happen again.
See for example r204698
BUG=259185
TEST=none
TBR=scottmg
Review URL: https://codereview.chromium.org/18434006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@211007 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When doing a gyp_managed_install, we install APKs to the attached
device. Currently this can fail in many ways (no device attached,
multiple devices attached, device offline, device doesn't have root,
etc.). In addition, we need to detect changes to the attached device
(particularly when the device is switched, when an APK is
uninstalled/updated).
The current approach is to check all this information in the action
interacting with the device. This means that when there is some
problem we print the same warning messages for every APK that is built,
and, in some cases, multiple times for each APK. Also, we have to run
every install/push action every build because we detect changes to the
attached device in that action.
This change creates a new build action, "get device configurations".
This action inspects the attached devices, filters out offline devices,
filters out devices without root, and then writes a configuration
file with the id+metadata for the first non-filtered device. This
configuration is then used by each of the build steps that interacts
with the device. This consolidates all the device checking to a single
place, and the build actions don't need to do any checking. In
addition, to detect changes in the attached device, we only need to run
this single action every build and the install/push actions will only
change when the device/metadata changes.
Also, with this change we can now gracefully handle the case where
multiple devices are attached (currently just write the configuration
for the first valid device and install to that one).
Review URL: https://chromiumcodereview.appspot.com/16831013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@209582 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207516
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@208529 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This breaks the Android component build.
This reverts commit 125e64a9eb6406446fb864aea9fa887521f19616.
>> [Android] Support building standalone APK in component build
>>
>> Many people's workflows assume that they can install the APK created in
>> out/Debug/apks. With the component build that APK is actually an
>> "incomplete" APK that cannot be manually installed (or rather causes
>> obscure errors when manually installed).
>>
>> This change does two things. First, it moves the "incomplete" APK
>> output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
>> accidental installs of the "incomplete" APK. Second, it introduces an
>> option (create_standalone_apk) that when doing a component build, if
>> set, will merge the shared libraries into the "incomplete" APK to
>> create a standalone APK. This standalone APK will be created in
>> out/Debug/apks/.
>>
>> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
>>
>> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207516
BUG=
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/17291013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207587 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207516 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207345 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adds a drop-down menu to the right of the search entry area on the OSX
app launcher. The menu is shown when clicked, and the button responds to
hover effects.
The menu button uses a new class, HoverImageMenuButton, which is derived
from an NSPopUpButton with minor extensions. Notably, it does not have a
dependency on browser themes, as does MenuButton from
chrome/browser/ui/cocoa. It tracks the mouse hover state and updates
the cell, which extends NSPopUpButtonCell and shows only the image in
the control frame -- no border, bezel, label, or dropdown arrow.
HoverImageMenuButtonCell supports a hover image, which behaves much like
an additional 'alternateImage' from NSButtonCell but for the hover
state, rather than the 'pressed' (or 'lit') state.
The menu shows the currently signed-in user, in a custom view as the
first item. It also (currently) shows menu options for Settings, Help, and
Feedback.
BUG=138633
TEST=Added app_list_unittests AppsSearchBoxMenuTest and
AppsSearchBoxMenuTest and tested manually to ensure the items are
launched correctly. Added ui_unittests HoverImageMenuButtonTest.*
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=206237
Review URL: https://chromiumcodereview.appspot.com/15955003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@206930 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Causes memory leaks in AppKit due to some obscure codepaths.
BUG=249630
> Menu for the OSX app launcher, HoverImageMenuButton in src/ui/base/cocoa/controls.
>
> Adds a drop-down menu to the right of the search entry area on the OSX
> app launcher. The menu is shown when clicked, and the button responds to
> hover effects.
>
> The menu button uses a new class, HoverImageMenuButton, which is derived
> from an NSPopUpButton with minor extensions. Notably, it does not have a
> dependency on browser themes, as does MenuButton from
> chrome/browser/ui/cocoa. It tracks the mouse hover state and updates
> the cell, which extends NSPopUpButtonCell and shows only the image in
> the control frame -- no border, bezel, label, or dropdown arrow.
>
> HoverImageMenuButtonCell supports a hover image, which behaves much like
> an additional 'alternateImage' from NSButtonCell but for the hover
> state, rather than the 'pressed' (or 'lit') state.
>
> The menu shows the currently signed-in user, in a custom view as the
> first item. It also (currently) shows menu options for Settings, Help, and
> Feedback.
>
> BUG=138633
> TEST=Added app_list_unittests AppsSearchBoxMenuTest and
> AppsSearchBoxMenuTest and tested manually to ensure the items are
> launched correctly. Added ui_unittests HoverImageMenuButtonTest.*
>
> Review URL: https://chromiumcodereview.appspot.com/15955003TBR=tapted@chromium.org
Review URL: https://codereview.chromium.org/17059002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@206375 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adds a drop-down menu to the right of the search entry area on the OSX
app launcher. The menu is shown when clicked, and the button responds to
hover effects.
The menu button uses a new class, HoverImageMenuButton, which is derived
from an NSPopUpButton with minor extensions. Notably, it does not have a
dependency on browser themes, as does MenuButton from
chrome/browser/ui/cocoa. It tracks the mouse hover state and updates
the cell, which extends NSPopUpButtonCell and shows only the image in
the control frame -- no border, bezel, label, or dropdown arrow.
HoverImageMenuButtonCell supports a hover image, which behaves much like
an additional 'alternateImage' from NSButtonCell but for the hover
state, rather than the 'pressed' (or 'lit') state.
The menu shows the currently signed-in user, in a custom view as the
first item. It also (currently) shows menu options for Settings, Help, and
Feedback.
BUG=138633
TEST=Added app_list_unittests AppsSearchBoxMenuTest and
AppsSearchBoxMenuTest and tested manually to ensure the items are
launched correctly. Added ui_unittests HoverImageMenuButtonTest.*
Review URL: https://chromiumcodereview.appspot.com/15955003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@206237 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
enne@chromium.org
droger@chromium.org
cpu@chromium.org
noamsml@chromium.org
mostynb@opera.com
derat@chromium.org
benm@chromium.org
mnaganov@chromium.org
shashishekhar@chromium.org
thakis@chromium.org
cjhopman@chromium.org
grunell@chromium.org
apatrick@chromium.org
dmikurube@chromium.org
lliabraa@chromium.org
dfalcantara@chromium.org
skyostil@google.com
chrisha@chromium.org
avi@chromium.org
cevans@chromium.org
tapted@chromium.org
apatrick@google.com
kbr@chromium.org
glider@chromium.org
jeanfrancoisg@chromium.org
earthdok@google.com
ilevy@chromium.org
groby@chromium.org