Fix Android TextView being truncated under some conditions

[albyrock87]

Detailed Issue information

Android emulators (e.g., with a display density multiplier of 2.625) expose an issue when arranging views.
Consider this label arrangement:

X = 112.00000000000001dp
Y = 318.66666666666669dp
Width = 187.42857142857142dp
Height = 22.095238095238095dp

When converted to pixels (Math.Ceiling used by MAUI):

X = 294.00000000000006 => 295px
Y = 836.5 => 837px
Width = 491.99999999999994 => 492px
Height = 58px

Expected platform rectangle width: 492px.
Actual width due to rounding error: 491px, causing content to be cut off.

Issues Identified

1. Rounding Error
   The calculation of X + Width involves independent conversion of dp values to px, e.g.:

   (187.42857142857142 + 112.00000000000001) * 2.625 = 786px
   

   Here, 786px - 295px = 491px, which is 1px short of the expected width.
2. Layout Calculation
   The use of dp instead of px for layout leads to inaccuracies when scaling.
   A DeviceTest has been added to show what I'm talking about (failing Assert has been commented):
   
   When converting a Rect to a px one we basically have two possible strategies
   • [current MAUI strategy] Slightly truncate content by converting left and right.
     Less visually disruptive, except for text as explained by @kubaflo here.
   • Allow overlap by 1px to match desired size by converting left and width.
     Undesirable for grid layouts like ColumnDefinitions=",,," where content is positioned side by side.

Proposed Fixes

To prevent truncation:

1. Apply a better rounding strategy by verifying if the value is close enough to the lower integer.
   For example, 294.00000000000006 should round to 294px instead of 295px because 0.00000000000006 is less than a given Epsilon = 0.0000000001.
2. Account for the missing pixel in the measure pass for TextView by adding 1px to its measured size:

   internal static Size GetDesiredSizeFromHandler(this IViewHandler viewHandler, double widthConstraint, double heightConstraint)
   {
       // ...
       if (viewHandler.PlatformView is TextView)
       {
           measuredWidth += 1;
       }
   }

Description of Change

We can fix this specific issue by using any of these solutions, so I decided to keep only the first one and defer the second one in case the issue reappears under some special conditions.

Issues Fixed

Fixes #17884
Fixes #26619

[veikkoeeva]

@albyrock87 Just a random person here, but that looks like a solid explanation to add also in the code so it's easily discoverable also later to whoever reads the code.

[albyrock87]

I've added the comments in the code.

That said, I'm afraid this PR will generate UITests failures everywhere and it'll take forever to capture all the screenshots.

[albyrock87]

We have another option to not break all the UI tests: keep the Ceiling rounding for coordinates too, and change this behavior only with .NET10.

[rmarinho]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[rmarinho]

In theory it should generated the needed screenshots and we can just replace, or we can ask for help to finish that tedious work of updating the screenshots.

[PureWeen]

I've added the comments in the code.

That said, I'm afraid this PR will generate UITests failures everywhere and it'll take forever to capture all the screenshots.

once we see the screenshots that'll give us an idea of the magnitude of change. There's definitely a lot :-)
We'll see how subtle/large it is once those are uploaded

[PureWeen]

I think this change makes sense...

I'm a little curious about the initial conversion from px to dp and if we should be rounding that

Like, if a DP value is 294.0000000000001 it seems like we should just convert that to 294 when doing the PX to DP conversion

I'm also wondering if we should midpoint round the width and height also. It seems like that's how Android suggests always doing the rounding https://developer.android.com/training/multiscreen/screendensities#dips-pels

[albyrock87]

Like, if a DP value is 294.0000000000001 it seems like we should just convert that to 294 when doing the PX to DP conversion

I'm afraid that value comes from the centering algorithm (in this specific example) and not from PX to DP conversion.

Obviously the centering algorithm uses DP coming from a measure pass which is in PX, but that's a plain px / density without any kind of rounding and that seems correct to me.

I also wonder why we're going through float while converting DP double to PX int.

[jsuarezruiz]

Apart from the UITest, could be nice to include some device tests checking conversions.

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[rmarinho]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jonmdev]

Proposed Fixes

To prevent truncation:

1. Apply a better rounding strategy by verifying if the value is close enough to the lower integer.
   For example, 294.00000000000006 should round to 294px instead of 295px because 0.00000000000006 is less than a given Epsilon = 0.0000000001.

2. Account for the missing pixel in the measure pass for TextView by adding 1px to its measured size:
   cs internal static Size GetDesiredSizeFromHandler(this IViewHandler viewHandler, double widthConstraint, double heightConstraint) { // ... if (viewHandler.PlatformView is TextView) { measuredWidth += 1; } }

Description of Change

We can fix this specific issue by using any of these solutions, so I decided to keep only the first one and defer the second one in case the issue reappears under some special conditions.

Thanks @albyrock87 as always for looking into this and explaining it so succinctly. This adds more information to something that has puzzled me now for 14+ months.

I think it's interesting that fix # 2 appears to a variation of the same "fix" (workaround) I posted back in June 2024 (8 months ago now), while this issue has been entirely ignored by Microsoft formally since report in Oct 2023 (14 months ago).

My "workaround" posted here was to override the platform view type and then apply this same +1 you are doing to the width there:

#if ANDROID
            LabelHandler.PlatformViewFactory = (handler) => {
                return new CMauiTextView(handler.Context); //Create custom MauiTextView for CLabelHandler
            };
#endif 

#if ANDROID
class CMauiTextView: MauiTextView {
        
        bool applyFix = true; //TO APPLY FIX FOR TEXT CLIPPING IN ANDROID

        protected override void OnMeasure(int widthMeasureSpec, int heightMeasureSpec) {

            var measured = Paint.MeasureText(Text);

            int widthSize = widthMeasureSpec.GetSize();
            Android.Views.MeasureSpecMode widthMode = widthMeasureSpec.GetMode();

            if (applyFix) {
                widthSize += 1;
            }

            int newWidthSpec = Android.Views.View.MeasureSpec.MakeMeasureSpec(widthSize, widthMode);
            base.OnMeasure(newWidthSpec, heightMeasureSpec); 
        }
}
#endif 

At the time I frankly thought this was the wrong approach as it felt so crude and dumb to just add a pixel to the width. I felt like the rounding errors should be fixed intrinsically in how Maui handles things so that we don't have to do this.

i.e. I feel like Maui should not be rounding things that it cannot safely be rounding.

Thanks as always for adding clarity to such things.

[PureWeen]

/rebase

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[albyrock87]

Failing tests look unrelated