Status Update
Comments
cl...@google.com <cl...@google.com>
ro...@gmail.com <ro...@gmail.com> #2
Hi,
I also see my text cut off when I set maxLines = 2
. Is it the same issue?
Box(
modifier =
Modifier.size(
width = 108dp,
height = 34dp,
),
contentAlignment = Alignment.Center,
) {
BasicText(
text = "text text text",
maxLines = 2,
autoSize = AutoSize.StepBased(minFontSize = 1.sp, maxFontSize = 13.sp, stepSize = 0.2.sp),
)
}
ro...@gmail.com <ro...@gmail.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <
Link:
Fix TextAutoSize bug with maxLines = 1
Expand for full commit details
Fix TextAutoSize bug with maxLines = 1
We were overcaching the paragraphIntrinsics in MultiParagraphLayoutCache when mutating the style. For `AutoSizeStepBased` instances with biased windows (more values smaller/bigger than the optimal), this could result in performing layout with outdated intrinsics, and thus an outdated style and font size, without surfacing this in the TextLayoutResult.
Test: New MultiParagraphLayoutCacheTests and manual testing
Relnote: Fixed a bug in BasicText with TextAutoSize and maxLines set to 1.
Fixes: 376834366
Change-Id: Ic0450c763c5d764492995b44ee1fe570246a9689
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/modifiers/MultiParagraphLayoutCacheTest.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/modifiers/MultiParagraphLayoutCache.kt
Hash: e1b712d78cc60384ed67a56c006148291ba146a6
Date: Tue Jan 07 18:52:26 2025
ap...@google.com <ap...@google.com> #4
#2, yeah, that's the same issue.
ro...@gmail.com <ro...@gmail.com> #5
Thanks @jo...@google.com for fixing this! Do you know when the fix would be available for g3 apps?
ae...@google.com <ae...@google.com>
ap...@google.com <ap...@google.com> #6
Moving the internal discussion offline. The bug is fixed and the fix available in snapshot builds. We will comment on this issue when the bug fix is included in a release.
an...@google.com <an...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-beta01
androidx.compose.foundation:foundation-android:1.8.0-beta01
androidx.compose.foundation:foundation-jvmstubs:1.8.0-beta01
androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-beta01
ro...@gmail.com <ro...@gmail.com> #8
Hi, I just tested with Modifiler.drawLayer
added arround a wrappning Column
(tested with Row
/Column
version). This didn't make any difference, but as you mention in your previous post, the big optimization (88%, I read) is about to come in alpha05
, right? And I assume there isn't much difference in performance between using Row
/Column
and ConstraintLayout
(unlike nested LinearLayout
and ConstraintLayout
for views)? Correct me if I'm wrong.
Thanks a lot, looking forward to alpha05! ;)
ro...@gmail.com <ro...@gmail.com> #9
As for re-composition, yes, when I scroll I can see in Logcat
that I'm getting the message I added in the composable body several times (probably it's for each item that's coming into view).
And my Wallpost class is defined like this (you can also check the sample project I attached in the beginning of the discussion -
package com.example.wpcomposable
import com.example.wpcomposable.utils.DateTimeUtils
import java.util.*
import kotlin.collections.ArrayList
import kotlin.time.ExperimentalTime
data class Wallpost(
var id: String = "",
var content: String ="",
var datePosted: Date = Date(),
var username: String = "",
var comments: ArrayList<WallpostComment> = ArrayList(),
var liked: Boolean = false
) {
val headerText: String get() {
return "${this.username} on ${this.datePosted}"
}
val linksText: String get() {
return "Show previous comments (${this.comments.size} of 5) ---- Reply ----"
}
@ExperimentalTime
val timeEllapsed: String get() {
return DateTimeUtils.periodFromNowToString(this.datePosted)
}
}
an...@google.com <an...@google.com> #10
Columns and Row are currently a bit more performant than ConstraintLayout. So I would suggest to keep the version with Columns, add Modifier.drawLayer() on a first layout inside the item and wait for alpha05. Feel free to share you findings once you try it when this version will be released.
Thanks
ro...@gmail.com <ro...@gmail.com> #11
Thanks, for now it seems Modifier.drawLayer
doesn't improve things much - as you suggested I added at the top level of the composable body another wrapper Column
with this modifier. But I'm looking forward to alpha05
and will write back as soon as I've tested with it. :)
ro...@gmail.com <ro...@gmail.com> #12
I tried alpha06
, there's definitely improvement. But still scroll speed is far from that of a RecyclerView
. I can no longer consider it "freezing", but it's laggy when scrolling a little bit faster. I understand it's probably too early to measure the final version's performance, so I can comment again let's say after some last beta or RC version. ;) Thanks!
Description
That original XML view is ConstraintLayout so initially I migrated it to the equivalent ConstraintLayout composable. I also tried Row/Column approach, too. Both versions can be found in the links below. The performance issue is expressed in slow scrolling - the initial scroll seems to freeze for a few seconds before moving just to the second item (in total I have 128 items). So I think there's also a problem with scroll speed too, that is, the amount of views which are scrolled with single finger gesture.
Compared to the RecyclerView approach, even when I do fast scrolling everything is smooth and a single scroll goes through a lot more items in total (arround 20-30 items).
---
Setup information:
Jetpack compose 0.1.0-dev16
Phone: Nexus5X
Android 8.1 Oreo
Android Studio 4.2, latest Canary build
---
Following a discussion on #compose channel in Slack, I'm posting relevant code:
The item which is repeated, here are both ConstraintLayout and Row/Column versions:
ConstraintLayout -
Row/Column -
And the custom composables which are used (button and card image):
---
In the attachments you can find the images uesd: no_avatar.png is used in the RoundedImage composable, whereas user.xml is used with the standard Image composable as vector resource.