Verified
Status Update
Comments
nu...@gmail.com <nu...@gmail.com> #2
Verified library version is `1.0.0-beta02`
ha...@google.com <ha...@google.com>
bo...@google.com <bo...@google.com>
nu...@gmail.com <nu...@gmail.com> #5
I investigated the sample: https://github.com/marbat87/ScrollingViewPager2.git
See attached video:
1) no scrolling issues as long as angle is kept very close to x or y axis (0 -- 13s)
2) when scroll angle changes during a scroll, that is respected; if you remove NestedScrollView from the layout hierarchy (in fragment_main.xml) and have RecyclerView there directly, scroll orientation locking happens and makes for a better user experience
3) threshold / angle exploration (29s -- end) -- clearly the threshold angle is too narrow (touch slop not respected); it's worse with AppBarLayout collapsed than when it's expanded -- it confirms the issue; we'll investigate further
See attached video:
1) no scrolling issues as long as angle is kept very close to x or y axis (0 -- 13s)
2) when scroll angle changes during a scroll, that is respected; if you remove NestedScrollView from the layout hierarchy (in fragment_main.xml) and have RecyclerView there directly, scroll orientation locking happens and makes for a better user experience
3) threshold / angle exploration (29s -- end) -- clearly the threshold angle is too narrow (touch slop not respected); it's worse with AppBarLayout collapsed than when it's expanded -- it confirms the issue; we'll investigate further
ya...@google.com <ya...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-master-dev
commit fb1c82582399043b149eb2630f524c75de9c88dc
Author: Jelle Fresen <jellefresen@google.com>
Date: Thu Aug 15 11:34:36 2019
Disallow intercept, touch slop and canScroll in nestedPreScroll
* Disallow intercept (requestDisallowInterceptTouchEvent(true))
When scroll delta is consumed by dispatchNestedPreScroll, the parent
should be requested not to intercept subsequent touch events, just as
when scroll is consumed by the widget itself or dispatchNestedScroll.
* Touch slop
NestedScrollingChild implementations should only call
dispatchNestedPreScroll after the delta x/y has exceeded the touch slop.
* canScroll (canScrollHorizontally/canScrollVertically)
The dx/dy values passed to dispatchNestedPreScroll should be zero if the
child can't scroll in that direction.
Fixed in:
- RecyclerView
- NestedScrollView
Bug: 138668210
Bug: 139530818
Test: ./gradlew connectedCheck
Change-Id: I85b327ad096fbbd204adb92f630770ec7fad5990
M core/core/src/androidTest/java/androidx/core/widget/NestedScrollViewNestedScrollingChildTest.java
M core/core/src/main/java/androidx/core/widget/NestedScrollView.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrolling3RequestDisallowInterceptTouchTest.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrollingChildTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/RecyclerView.java
https://android-review.googlesource.com/1105373
https://goto.google.com/android-sha1/fb1c82582399043b149eb2630f524c75de9c88dc
Branch: androidx-master-dev
commit fb1c82582399043b149eb2630f524c75de9c88dc
Author: Jelle Fresen <jellefresen@google.com>
Date: Thu Aug 15 11:34:36 2019
Disallow intercept, touch slop and canScroll in nestedPreScroll
* Disallow intercept (requestDisallowInterceptTouchEvent(true))
When scroll delta is consumed by dispatchNestedPreScroll, the parent
should be requested not to intercept subsequent touch events, just as
when scroll is consumed by the widget itself or dispatchNestedScroll.
* Touch slop
NestedScrollingChild implementations should only call
dispatchNestedPreScroll after the delta x/y has exceeded the touch slop.
* canScroll (canScrollHorizontally/canScrollVertically)
The dx/dy values passed to dispatchNestedPreScroll should be zero if the
child can't scroll in that direction.
Fixed in:
- RecyclerView
- NestedScrollView
Bug: 138668210
Bug: 139530818
Test: ./gradlew connectedCheck
Change-Id: I85b327ad096fbbd204adb92f630770ec7fad5990
M core/core/src/androidTest/java/androidx/core/widget/NestedScrollViewNestedScrollingChildTest.java
M core/core/src/main/java/androidx/core/widget/NestedScrollView.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrolling3RequestDisallowInterceptTouchTest.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrollingChildTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/RecyclerView.java
nu...@gmail.com <nu...@gmail.com> #7
1) N/A
2) Remove NestedScrollView
3) Was due to a bug in RecyclerView with pre-scroll, fix is on it's way
2) Remove NestedScrollView
3) Was due to a bug in RecyclerView with pre-scroll, fix is on it's way
ya...@google.com <ya...@google.com> #8
Correction, the fix is in. Will be released in the coming release of recyclerview (1.1.0-beta04)
ya...@google.com <ya...@google.com> #9
Hi Devki,
would you help to cp aosp/2451107 to next stable and canary releases? Thank you!
would you help to cp aosp/2451107 to next stable and canary releases? Thank you!
de...@google.com <de...@google.com>
ya...@google.com <ya...@google.com> #10
Hi Devki,
Could we cherry-pick it to canary release as well? Thanks!
Could we cherry-pick it to canary release as well? Thanks!
de...@google.com <de...@google.com> #11
@yahan it will be picked up in the next canary since we are doing snaps!
ya...@google.com <ya...@google.com> #12
Thanks!
is...@motorolasolutions.com <is...@motorolasolutions.com> #13
Was able to force the emulator to use the host GPU by opening it via the terminal with
./emulator -avd Resizable_API_33 -gpu host
cs...@google.com <cs...@google.com> #14
I believe this is still happening in 33.1.10
ya...@google.com <ya...@google.com> #15
Chris, would you help to send us the verbose log?
cs...@google.com <cs...@google.com> #16
User on
bo...@google.com <bo...@google.com> #17
do you still have this problem with latest 33.1.20+ ?
cs...@google.com <cs...@google.com>
nu...@gmail.com <nu...@gmail.com> #18
If that question is for me, I've tested changing the config.ini back to "hw.gpu.mode=auto" and it appears to be fine. I have 33.1.2.0.
bo...@google.com <bo...@google.com> #19
with 34.1.x stable already, are there still any performance degradation ?
let us know
let us know
nu...@gmail.com <nu...@gmail.com> #20
Can confirm the flag is correctly set for new emulators on 34.1.18
Description
After updating to Emulator v33.1.1 and SDK Platform Tools 34.0.0, emulator performance took a big hit.
It was working ok on previous version, with Apple M1 chip.
I've tried creating a new emulator, but it's a general issue.
Could you give me instructions on how to downgrade to previous version?
```
Build: AI-223.8214.52.2231.9601041, 202302132341,
AI-223.8214.52.2231.9601041, JRE 17.0.6+0-17.0.6b802.4-9586694x64 JetBrains s.r.o., OS Mac OS X(aarch64) v13.2.1, screens 3456.0x2234.0, 3840.0x2160.0; Retina
AS: Giraffe | 2022.3.1 Canary 5
Kotlin plugin: 223-1.7.21-AS7571.182
Android Gradle Plugin: 7.4.1
Gradle: 8.0
Gradle JDK: JetBrains Runtime version 17.0.6
NDK: from local.properties: (not specified), latest from SDK: (not found)
CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
Source: send_feedback_icon
IMPORTANT: Please read
```