Open jonmdev opened 1 year ago
To add to this report, this is not the only abnormal shadow related behavior I am observing in Android. I am also experiencing an issue where some words just simply don't get rendered at all when a Shadow is applied to them.
I posted a separate bug report for that problem here: https://github.com/dotnet/maui/issues/17884
I am not sure if these are related or unrelated.
We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.
Verified this on Visual Studio Enterprise 17.8.0 Preview 2.0(8.0.0-rc.1.9171). Repro on Android 13.0-API33 with below Project: ContentViewGroup Too Big Bug.zip
I have encountered a scenario where viewWidth passed to DrawShadow is equal to 1073741794, which in exchange crashes the app at Bitmap.CreateBitmap. Seems that previously closed PR could fix it, but I can see that it was never merged
Description
When a Border is created and then a shadow is applied, this seems to use a massive amount of resources in Android to the extent that if you make the Border object even slightly larger than the screen, it triggers an error:
[View] ContentViewGroup not displayed because it is too large to fit into a software layer (or drawing cache), needs 10501248 bytes, only 10108800 available
This is when using default Google Pixel 5 Android Emulator.
This does not happen for the same project in Windows/iOS (no errors).
Is there any way to fix this? Is there some problem with how the shadows are rendering?
The bug output seems to suggest it is trying to use 10.5 MB to render the shadow. It claims to only have 10.1 MB available.
I think I understand where the numbers are coming from. The Google Pixel 5 resolution is 1080 x 2340, which at 32 bit depth = 10.1 MB as per calculator: https://www.omnicalculator.com/other/image-file-size
Setting the Border a bit bigger than screen resolution creates a 10.5 MB need which apparently is greater than the device capacity.
So it seems the system is claiming it cannot draw a Shadow on any view larger than the device's native resolution. But does this make sense? It doesn't seem to.
It can clearly draw the Border at a size bigger than the screen resolution, so it is capable of rendering objects bigger than that. If you apply a shadow to a View, is it creating a bitmap object essentially the size of the entire object? Ie. In this case something 10.5 MB big? And if so, is there anyway to fix this? iOS and Windows don't give any error or such limitation.
How does it render the Border itself with no issues but the Shadow has problems?
Is there expected to be a known limitation on Android's Shadow function that all Shadow elements must be kept small or they will use massive resources? It seems if one adds many Shadow elements the resource utilization will be rapidly astronomical. Unless there is an issue that can be fixed.
Does the Android shadow function work somehow different than iOS or Windows?
Thanks for any thoughts.
Steps to Reproduce
Copy and paste to replace all of App.xaml.cs with:
[View] ContentViewGroup not displayed because it is too large to fit into a software layer (or drawing cache), needs 10501248 bytes, only 10108800 available
screenWidth
multiplier of theBorder1
object or removing the shadow stops the error.Link to public reproduction project repository
https://github.com/jonmdev/ContentViewGroup-Too-Big-Bug
Version with bug
7.0.92
Is this a regression from previous behavior?
No, this is something new
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
Android API 33, .NET 7.0
Did you find any workaround?
If this is an intrinsic limitation of Android's Shadow function we must be very careful in how it is used.
However, I suspect it is more of a MAUI problem because when I search "ContentViewGroup not displayed because it is too large to fit into a software layer" I only find 3rd party systems triggering the problem eg. React Native, which to me suggests it is not necessarily a directly Android issue but rather an implementation issue.
Relevant log output