search

unoplatform / uno

Open-source platform for building cross-platform native Mobile, Web, Desktop and Embedded apps quickly. Create rich, C#/XAML, single-codebase apps from any IDE. Hot Reload included! 90m+ NuGet Downloads!!
https://platform.uno
Apache License 2.0
9.08k stars 736 forks source link

[Android] `AcrylicBrush` on top of SkiaSharp content renders incorrectly #7255

Open TopperDEL opened 3 years ago

TopperDEL commented 3 years ago

Current behavior

An AcrylicBrush renderes SkiaSharp-Images wrong on Android (and probably iOs, could not try yet). On UWP it works as expected. I've created a sample repo here.

If you run the app on UWP, it show three times the similar sample image and a small AcrylicBrush-Bar in the middle. Scrolling the images shows a correct AcrylicBrush. running the app on android shows the image behind the AcrylicBrush "very small". I catched the behaviour in a video here, too:

https://user-images.githubusercontent.com/1833242/135516450-3b786360-6abc-4d87-b6fc-f8e196714533.mp4

I'm not sure if I could render images in a better way. My main problem is, that I need to render images from a Stream (instead of from an URL as most apps do) and that has heavy impacts on the performance using the normal Image-Control. Rendering with SkiaSharp is much quicker and works as expected except for that AcrylicBrush. Unfortunately that Brush is an important style-thing for an App I have to develop.

I've mentioned the error already in this issue.

Expected behavior

The AcrylicBrush renders the same as on UWP.

How to reproduce it (as minimally and precisely as possible)

No response

Workaround

Currently I can only disable the AcrylicBrush on Android and provide a white background - but the app looks odd without the effect.

Works on UWP/WinUI

Yes

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia

NuGet package version(s)

SkiaSharp 2.80.2 Uno.UI 3.10.11

Affected platforms

iOS, Android

IDE

Visual Studio 2019

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

No response

jeromelaban commented 3 years ago

Thanks for the report.

Does it happen with normal images ?

TopperDEL commented 3 years ago

No, it only happens with the SkiaSharp-Rendered-Images. I think it might be due to different DPI or what on UWP and Android, so my Skia-Image-Control might need to respect that in any way. Not sure where to start here, though, as I do not understand how the AcrylicBrush works under the hood.

Here the extended sample. Left is my control, right is the normal images-control.

https://user-images.githubusercontent.com/1833242/135576567-8212d497-8df4-4a7a-abc5-78be187a8c29.mp4

TopperDEL commented 2 years ago

May I ask if there is any chance that this issue might get be solved? I cannot help very much unfortunately, but would everything I can to bring this further. I want to release a nice app, soon, that would look weird with that issue still active. Let me know if I can help in any way. Thank you!

TopperDEL commented 2 years ago

@MartinZikmund May you help me out here? Sorry for pushing, though.

jeromelaban commented 2 years ago

@TopperDEL It could be related to the way SkiaSharp creates its image or similar. Have you tried changing the way the image is generated? You may also ask in the SkiaSharp repository, as you're using the SKCanvas control.

TopperDEL commented 2 years ago

Thanks @jeromelaban - I've created an issue on the SkiaSharp-repo linking to this one. My main problem is that the image itself is rendered correctly on UWP and Android, The AcrylicBrush is correct on UWP, but wrong on Android. So I would rather expect the error on the AcrylicBrush or the way it interacts with SKXamlCanvas.

jeromelaban commented 2 years ago

Sure. You can also try rendering the image inside of a WriteableBitmap and see if it behaves differently.

TopperDEL commented 2 years ago

Can you elaborate on this? I just switched my implementation to SkiaSharp as the performance with a "standard image" was too bad. Is there a sample rendering multiple images from a stream in a listview quickly? SkiaSharp did a much better job than the normal Image-control, but it is still stuttering the list until the images are loaded. Interestingly I have this requirement for nearly all of my apps (load async images from a custom-service in an async way with buffer) and have not yet found a good and simpley way to do. All samples mostly rely on http-URLs and have buffering for that - but loading images from my own service via an API-call - that is not so easy to do in a performant and memory-saving way.

jeromelaban commented 2 years ago

Try it out and see if the result is different. It may give a clue on where the issue resides, it's not necessarily a solution to the issue.

TopperDEL commented 2 years ago

Hm, I don't get a version working with WriteableBitmap or any other way. I managed to get a workaround for that specific app by loading the images from a URL. But this does not really solve this issue - though for me I'm fine now. I leave it up to you to decide whether or not this issue should stay open. It is still a bug, though.