DrawingView.GetImageStream Size has no affect

[dapug]

Is there an existing issue for this?

• [X] I have searched the existing issues

Did you read the "Reporting a bug" section on Contributing file?

• [X] I have read the "Reporting a bug" section on Contributing file: https://github.com/CommunityToolkit/Maui/blob/main/CONTRIBUTING.md#reporting-a-bug

Current Behavior

Size of an image cannot be set using DrawingView.GetImageBytes(). No matter what value you give in the Size param, the behavior is the same. The image stream does not size the image to the given size, and it is ALWAYS "shrink-to-fit" the actual dimensions of the drawn lines (whatever that size is), rather than the specified size.

Expected Behavior

EXPECTED: Here is the 200x200 control with a small dark blue shape drawn in the middle. The image stream (or saved file) should appear like this:

Actual: Here is the result of the stream (or saved file) after GetImageBytes() is processed:

Steps To Reproduce

1. Add a DrawingView onto a Xaml page
2. Set HeightRequest="200" WidthRequest="200"
3. Add a DrawingLineCompleted method
4. In the method, capture the lines that were drawn, and specify the same 200x200 size var dvStream = await DrawingView.GetImageStream(drawView.Lines, new Size(200,200), Colors.LightBlue);
5. Add code to stream that image back to another control on page, or save to an image file on disk
6. Run the app and draw a small shape on the canvas (something only 10-20px wide)
7. Look at the resulting image

Link to public reproduction project repository

https://github.com/dapug/DrawingDemo

Environment

- .NET MAUI CommunityToolkit: 5.2.0 and 5.3.0
- OS: Win 10 Build 19045.3324
- .NET MAUI: 
runtimes-windows           7.0.5/7.0.100          VS 17.7.33711.374
android                    33.0.46/7.0.100        VS 17.7.33711.374
maui-windows               7.0.86/7.0.100         VS 17.7.33711.374
maui-maccatalyst           7.0.86/7.0.100         VS 17.7.33711.374
maccatalyst                16.4.7060/7.0.100      VS 17.7.33711.374
maui-ios                   7.0.86/7.0.100         VS 17.7.33711.374
ios                        16.4.7060/7.0.100      VS 17.7.33711.374
maui-android               7.0.86/7.0.100         VS 17.7.33711.374

Anything else?

There is a detailed discussion about this here: https://github.com/CommunityToolkit/Maui/discussions/729

Supposedly, a fix was made in toolkit v5.0.0, however, I am finding that NOT to be the case, no change. Issue still persists. See commit: https://github.com/CommunityToolkit/Maui/commit/48e7831761f48851501bf960499037ee277a9357

[VladislavAntonyuk]

it is not the size of the image. you specify Maximum image size. The image will be resized proportionally.

[dapug]

OK, can you please explain how it is possible then, to specify the actual size the resulting image should be? The way it is implemented right now makes it pretty much useless, as the resulting image dimensions will never be defined or able to be set (and very much needs to be).

The goal is not to capture only the minimum area containing the actual drawn lines, but the total area that the user was given to draw the lines in the first place.

[nourben]

I agree with @dapug. By providing a size, it make sense that the goal is to get the size is the total area that the user was given to draw the lines in the first place.

Resizing the image to get only the minimum area containing the drawn line looks like a very specific case. Not a common use case for an app using a drawingview.

[bijington]

It does look like we have an inconsistency in our XML documentation that would lead to this confusion:

DrawingView.shared.cs

https://github.com/CommunityToolkit/Maui/blob/02896d32571af05ede9df8d6b10b32db174e15f6/src/CommunityToolkit.Maui/Views/DrawingView/DrawingView.shared.cs#L218

DrawingViewService.macios.cs

https://github.com/CommunityToolkit/Maui/blob/02896d32571af05ede9df8d6b10b32db174e15f6/src/CommunityToolkit.Maui.Core/Views/DrawingView/Service/DrawingViewService.macios.cs#L16

I can personally see a benefit for both use cases. I will reopen this and we can discuss it later during the standup

[VladislavAntonyuk]

The keyword here is Desired. So to make it clear size 200x200 is the maximum size of the image. but because drawing image may differ (e.g. 100x300), we proportionally change your size to this. So the final size is approximately 66x200.

[dapug]

The keyword here is Desired. So to make it clear size 200x200 is the maximum size of the image. but because drawing image may differ (e.g. 100x300), we proportionally change your size to this. So the final size is approximately 66x200.

I have no problem with that functionality, BUT...

The API provides NO way to access the 66x200 resulting dimensions, and therefore one cannot, ever, reconstitute the 200x200 (or 100x300, etc) original image and place the lines appropriately in it as it was when drawn. So the result does indeed do as you said, but ultimately is useless in real life application because one cannot ever retain the original backdrop/canvas size, nor can we even know what the dimension result was so that we can reconstruct an image back to original ourselves.

The user of the API needs the option to: 1 - request the output to adhere to a specified size and position within that size (200x200 in this example) 2 - get the actual size output result (66x200 in the example being discussed)