DisplayInformation.GetForCurrentView().RawPixelsPerViewPixel return a different value on the same device with a different API

[pauldendulk]

We had a Mapsui issue related to the scale of the device. We now have a workaround but I wonder if there is some bug underneath (could be Mapsui, Uno, SkiaSharp or WinUI) because it does not seem logical. Perhaps you have a better understander of the scaling mechanism.

We use SkiaSharp.Views.Windows to draw the map. Like on any other platform/device we need to scale the map to the device using PixelDensity. Every platform has it's own way to request that information. In UWP we used DisplayInformation.GetForCurrentView().RawPixelsPerViewPixel. In WinUI this also worked correctly, but not on all devices.

• On a emulated Pixel 5 with API 30 RawPixelsPerViewPixel is 2.75
• On a emulated Pixel 5 with API 33 RawPixelsPerViewPixel is 2.8125

That is strange in itself since it is the same hardware, but what is stranger is that in order for the map to show correctly we need to scale with 2.0 instead (this is only on API 33 not API 30). We now use the ResolutionScale and divide by 100 to get this to work correctly. But this is the same device I don't see why a different API should have a different scale. If a user upgrades the Android version the map becomes more pixelated. It does not make sense.

Any pointers are appreciated. For instance it is not clear to me where the responsibilities are in the different components. Uno is based in WinUI, but I think the Android implementation is all Uno code. In this case the WinUI SkiaSharp View is used. Is this the regular SkiaSharp WinUI view as it is? How does Uno control this view?

Btw, we also had scaling problem on hardware, it is not just the emulator.

[jeromelaban]

Thanks for the report. If I remember correctly, the density computation on android devices has always been confusing as there are multiple value that are reported by the OS. There's the actual density of the screen (likely the 2.x that you're seeing):

uno/src/Uno.UWP/Graphics/Display/DisplayInformation.Android.cs

Lines 68 to 69 in 96537ad

	public double RawPixelsPerViewPixel
	=> 1.0f * (int)_cachedDisplayMetrics.DensityDpi / (int)DisplayMetricsDensity.Default;

Then there's the user reported density, which includes some sort of manufacturer "subjective" density where same raw DPI devices may report different DPIs depending on whether those are tablets or phone, for instance. That density is the one reported by LogicalDpi:

uno/src/Uno.UWP/Graphics/Display/DisplayInformation.Android.cs

Lines 71 to 74 in 96537ad

	public float LogicalDpi
	// DisplayMetrics of 1.0 matches 100%, or UWP's default 96.0 DPI.
	// https://stuff.mit.edu/afs/sipb/project/android/docs/reference/android/util/DisplayMetrics.html#density
	=> _cachedDisplayMetrics.Density * BaseDpi;

It is the value used by Android views to render themselves on screen.

The SKXamlCanvas/SKSwapChainPanel pixel scaling implementation of SkiaSharp uses LogicalDPI. In theory, you may not need to manipulate the skia render scaling explicitly on your end, but you may want to try disabling IgnorePixelScaling to do the scaling completely in MapsUI.

[inforithmics]

This seems to return the Pixels per View Pixel:
(float)DisplayInformation.GetForCurrentView().ResolutionScale / 100.0f;

This seems not to work:
(float)DisplayInformation.GetForCurrentView().RawPixelsPerViewPixel;

[jeromelaban]

Both are not returning the same value as I explained above, though the interesting bit is that RasterizationScale should not be using RawPixelsPerViewPixel, but rather LogicalDpi.

Let's track in #11944