Fixed
Status Update
No update yet.
Comments
ae...@google.com
ke...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 08725c384cd274d22d57429dcf509c379712bca9
Author: Kevin Truong <kevinctruong@google.com>
Date: Thu Feb 22 10:19:59 2024
[Slider] Adding tolerance to the require calculation
Doing equalities of floating number can be inaccurate, adding an appropriate tolerance.
Bug: 324934900
Test: N/A
Relnote: Adding SliderRangeTolerance for the require calculation since Float rounding can be inaccurate.
Change-Id: Ic918adc77cd76bd1e988e0b3e7aa92c54cf19ade
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/Slider.kt
https://android-review.googlesource.com/2974112
Branch: androidx-main
commit 08725c384cd274d22d57429dcf509c379712bca9
Author: Kevin Truong <kevinctruong@google.com>
Date: Thu Feb 22 10:19:59 2024
[Slider] Adding tolerance to the require calculation
Doing equalities of floating number can be inaccurate, adding an appropriate tolerance.
Bug: 324934900
Test: N/A
Relnote: Adding SliderRangeTolerance for the require calculation since Float rounding can be inaccurate.
Change-Id: Ic918adc77cd76bd1e988e0b3e7aa92c54cf19ade
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/Slider.kt
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha02androidx.compose.material3:material3-android:1.3.0-alpha02androidx.compose.material3:material3-desktop:1.3.0-alpha02
lo...@gmail.com
Unfortunately, this fix is not sufficient. We got the first crash with the updated version:
java.lang.IllegalArgumentException: start(3467.0002) must be <= endInclusive(3467.0)
Note that our slider usually has to take care of 4 to 5 digit numbers (prices). I think there will probably always be a case where the selected tolerance is not large enough if you increase the slider value range accordingly.
ty...@gmail.com
I am encountering this crash as well. In our case we use the range slider for a min and max year selector. When sliding the min or max to be equal to the other then it crashes. This is what our slider code looks like.
Column(modifier = Modifier.padding(horizontal = 16.dp)) {
var sliderRange = (state.minYear.toFloat())..state.maxYear.toFloat()
var cachedMin by remember { mutableIntStateOf(YearEstablishedFilterState.MIN_YEAR) }
var cachedMax by remember { mutableIntStateOf(Year.now().value) }
RangeSlider(
value = sliderRange,
valueRange = YearEstablishedFilterState.MIN_YEAR.toFloat()..Year.now().value.toFloat(),
steps = Year.now().value - YearEstablishedFilterState.MIN_YEAR,
colors = SliderDefaults.colors(
thumbColor = ExtendedTheme.colors.secondaryText,
activeTrackColor = ExtendedTheme.colors.secondaryText,
inactiveTrackColor = ExtendedTheme.colors.divider,
activeTickColor = ExtendedTheme.colors.secondaryText,
inactiveTickColor = ExtendedTheme.colors.divider
),
onValueChange = { range ->
sliderRange = range
val minYear = range.start.roundToInt()
val maxYear = range.endInclusive.roundToInt()
if (minYear != cachedMin || maxYear != cachedMax) {
haptic.performHapticFeedback(HapticFeedbackType.TextHandleMove)
cachedMin = minYear
cachedMax = maxYear
}
onRangeChanged(
minYear,
maxYear
)
}
)
}
lo...@gmail.com
I already created a follow up ticket:
Description
Jetpack Compose version: 2024.01.00
Jetpack Compose component(s) used:
RangeSliderAndroid Studio Build: Build #AI-231.9392.1.2311.11330709, built on January 19, 2024
Kotlin version: 1.9.22
Material 3 version : 1.2.0-beta02
Steps to Reproduce or Code Sample to Reproduce:
RangeSliderSliderRangeis failing therequire(isUnspecified || start <= endInclusive )check on line 2120 due to rounding error as can be seen in the first line of the stack trace, wherestartis only 0.00005 of a pixel greater than theendInclusiveSuggestion of a solution to fix this error
It is a known issue that floating point calculation is inherently imprecise in a sense that the resulting value is correct up to a specific decimal position. I suspect that the same is happening here when the start point and end point coordinates are being calculated. The
startpoint may have gotten593.6667500000000000000000...rounded to593.66675andendInclusivemay have gotten593.66674999999999999999....rounded to593.6667.When doing floating point calculations for UI it is imperative to have a consistent cut off strategy for how many decimal places should be considered system-wise for rendering. In my experience 2 decimal places are ample for pixel-related arithmetics; anything beyond makes no visual difference.
So trim pixel values to only carry 2 decimal positions and discard everything from 3rd decimal position onwards. (Do NOT round the values!)
Following the strategy above system-wide for UI pixel-related arithmetics, will make sure that elusive errors like this do not happen.
Stack trace: