[LinearProgressIndicator] Adding track radius causes incorrect progress in the start of the indicator

[OxygenCobalt]

Description:

Say I set a LinearProgressIndicator to have the following traits:

progressIndicator.progress = positionInMs / 100 // Deci-seconds
progressIndicator.max = durationInMs / 100

This results in a very fine position for the progress indicator.

When there is no track radius set, very low progress amounts (say, 10) look fine:

When there is a track radius however, the shown progress is much larger than it should be, presumably to accommodate the track radius (In this example, the track radius is 16dp):

Expected behavior:

The progress when there is a track radius should be the same as the progress when there is no track radius. If the progress extent cannot contain the whole track radius, just clip the drawn progress a bit so that it does correctly fit.

I've attached a picture below of what I want:

Source code: See above.

Android API version: 33

Material Library version: 1.7.0-beta01

Device: OnePlus 7T running LineageOS

[pekingme]

In the current implementation, the rounded corners are draw as "decoration". The "real" progress is the rectangle between the left corners and the right corners. The clipping way was also considered. But it becomes tricky for circular progress indicator, since there are no "ends" on the track.

What's your use case? Why do you need the progress look comparatively in the same length between indicators with and without rounded corners?

[OxygenCobalt]

I just think it looks nicer @pekingme. Since my progress indicator progresses with the playback of audio, it looks strange to have that initial "jump" from 0 to the corner radius, and then have the typical small increments afterwards.

If this is not possible, could it at least be possible to round the track background, but not round the track progress? Sort of like what occurs in the the media notification when there is no seek thumb.

[pubiqq]

0849.mp4

[OxygenCobalt]

Theoretically, couldn't you add a parameter to the base progress class that determines whether to clip like this? That way, the circular indicator can still work properly, while the linear indicator can progress smoother. I might look around and see if I can PR this. @pekingme @pubiqq.

[pubiqq]

I guess it's a design flaw and it just needs to be fixed, no additional parameters need to be introduced.

[OxygenCobalt]

Eh, I was just inferring that from what pekingme said about how the library does not clip the progress due to how the base progress class needs to accommodate the circular progress indicator as well, which has no defined "start" or "end" and makes such clipping more difficult.