Status Update
No update yet.
Comments
si...@google.com
May I ask why P3? This is blocking for me to go to prod, I'd really like some inputs about what is going on so I can either fix or build a repro to have this fixed.
si...@google.com
si...@google.com
si...@google.com
For the ideas on what to take a look, how do you use LazyListState.layoutInfo in your app? Will it continue growing if you comment out such usages?
si...@google.com
It happens even on screens that does not use the layoutInfo it just require many up / down flings.
LazyColumn(state = rememberLazyListState())
The only thing all screen have in common in that they have multiple item {} item{} block :(
Just in case the app is in open beta at
My main question before trying to do complex repro, is how much will it be relevant with all the recent changes in alpha 8 about Lazy stuff? And side question when
si...@google.com
I can't guarantee as I don't understand the issue yet, but I assume this issue is still not fixed, changes in alpha 8 were about different things.
si...@google.com
Ok so the good news is that the other issue is really fixed :) But this one not at all.
It seems 100% of the LazyInfo versions are kept in memory see new attachement.
I've sent you the full prof by mail as you probably can more easily find the root of the reference in the states to have some clues about what I need to do to reproduce.
ap...@google.com
Ok so I speak too soon. There's an insane performance issue with 8506895 a simple lazycolumn with a few lazyrow now lags insanely.
Got lots of
Davey! duration=842ms; Flags=0, FrameTimelineVsyncId=30733, IntendedVsync=721976611111, Vsync=722518277756, InputEventId=0, HandleInputStart=722523309190, AnimationStart=722523309963, PerformTraversalsStart=722808544297, DrawStart=722808615383, FrameDeadline=722001544444, FrameInterval=722523205186, FrameStartTime=8333333, SyncQueued=722811912136, SyncStart=722812117702, IssueDrawCommandsStart=722812801825, SwapBuffers=722816362046, FrameCompleted=722819089423, DequeueBufferDuration=23560, QueueBufferDuration=2647257, GpuCompleted=722818621812, SwapBuffersCompleted=722819089423, DisplayPresentTime=0, in logcat that I don't remember having seen before.
I guess that'll make a lot of repro to make :(
si...@google.com
According to profiler most is spent in compose:lazylist:prefetch:measure anything changed about that ?
Sorry for all the questions, but since huge time zone difference I try to gather the most info to be efficient tomorrow on both repro, as poor indie dev this is 100% unpaid time and I hate repro without any idea what to look after as it can take many hours.
Description
CoreTextField(EditorValue, (EditorValue) -> Unit) (in ui.text)
TextField(EditorValue, (EditorValue) -> Unit) (in ui.foundation)
TextField(TextFieldValue, (TextFieldValue) -> Unit) (in ui.foundation)
FilledTextField(TextFieldValue, (TextFieldValue) -> Unit) (in ui.material)
FilledTextField(String, (String) -> Unit) (in ui.material)
EditorValue is the most powerful API, where every aspect of the text field is controllable, but also more cumbersome to use.
TextFieldValue is middle-weight, with only string value and selection controllable, but still a bit cumbersome to use
String is the least powerful API, but also the most convenient and powerful enough to satisfy the overwhelming majority of use cases.
My suggestion is to refactor these overloads to have each one fit into one of two overloads:
1. EditorValue-based (cumbersome, powerful)
2. String-based (convenient, useful)
The string-based variants would have an `onSelectionChanged: (Selection) -> Unit` parameter, but would not allow for a selection to be *controlled* (hence the past tense on the parameter name).
It seems to me like the need to control or listen to the selection state are both somewhat rare, but the need to control it is even more so. On the other hand, the need to control the text value is virtually 100% of the time. As a result, adding the overhead of the selection controllability in the common case feels wrong, since the times you might want to do that, the more powerful EditorValue API might be something you need to reach for anyway.
As a result, my proposal is to have the following APIs:
in ui.text:
fun CoreTextField(value: EditorValue, onValueChange: (EditorValue) -> Unit) (unchanged)
in ui.foundation:
fun TextField(EditorValue, (EditorValue) -> Unit) (unchanged)
fun TextField(value: String, onValueChange: (String) -> Unit, onSelectionChanged: (Selection) -> Unit)
in ui.material:
fun FilledTextField(EditorValue, (EditorValue) -> Unit)
fun FilledTextField(value: String, onValueChange: (String) -> Unit, onSelectionChanged: (Selection) -> Unit)