Mapsui: Xamarin.Android - MapControl is blurry

[hajmajeboss]

Hello,
I just started working on a new project and my MapControl content is blurry/pixelated, including scale bar, zoom in/out and attribution - seems like an issue with canvas rendering.

Tried using different versions of Mapsui without any success.

On the same phone, Xamarin.Forms component is rendered as it should be.
Target SDK 27.

[hajmajeboss]

Issue is not present in 1.4.8, only in 2.0.

[johnpudd]

I’ve seen a similar issue in the past which I tracked down to being the image scaling for higher density screens.
I’ve got a custom implementation currently on our own branch - but haven’t had time to create a PR ready implantation (a lambda was suggested to vary the behaviour depending on requirements).

You’re welcome to look at my fork to see if that is the issue for you too...
https://github.com/EastpointSoftware/Mapsui/tree/ContinuousLineString?files=1

Note: this currently includes a couple of other variations from /Mapsui/ that also need prep for PR.

[johnpudd]

(I would not recommend using my version, but it might help to see if this is also your issue)

[hajmajeboss]

Thank you for the reply.

I tried using your edited MapControl.cs. However - both performance and widget size are an issue for me. I can barely see the scale bar on my device and it's quite laggy. Original Mapsui works like a charm in Xamarin.Forms - map seems to be scaled, but widgets and vector features are resized properly (no blurring/pixelating) - and I believe, this is the best possible compromise to achieve, as raster scaling is almost unnoticeable, but nobody wants to see blurry font or vector graphics.

[charlenni]

Could we see here an image too?

[hajmajeboss]

[johnpudd]

Hi @hajmajeboss, my fork will slow performance - we've decided to trade off super responsiveness for image quality. That's just our choice.
The scale bar issue you mentioned is just because you've only taken one file from the repository (there is a change in the scale bar code too)... but if the resultant performance is too laggy for you, I don't expect that matters :)

[hajmajeboss]

Well, I've just tried installing your fork as a whole and scale bar is still the same. Anyway, as you said - doesn't matter for me.

I propose scaling raster tiles and properly resizing vector features, labels and widgets based on the resolution - hope it will be like that in one of future releases. Thank your for your time.

[pauldendulk]

On the same phone, Xamarin.Forms component is rendered as it should be.
Target SDK 27.

@hajmajeboss So this is with Mapsui.UI.Android while Mapsui.UI.Forms works correct? Do you see the same problem when you run the Mapsui.Samples.Droid sample?

[hajmajeboss]

On the same phone, Xamarin.Forms component is rendered as it should be.
Target SDK 27.

@hajmajeboss So this is with Mapsui.UI.Android while Mapsui.UI.Forms works correct? Do you see the same problem when you run the Mapsui.Samples.Droid sample?

Yes, I do.

Redmi A2, 2160x1080 screen.

[pauldendulk]

I never reproduced this problem myself. There probably is an issue, but I have no other users reporting this. We will probably not fix this before the release of v2.

[hajmajeboss]

Well, there is no issue, it's just the way it works. For example, my resolution is 2160x1080, but the size of the canvas is 720x360 and it's upscaled to fit the screen size. I need it to have the resolution of my screen and only upscale rasters to make vector drawables look sharp. I believe this is the way it works in Xam.Forms.

My colleague will have a look at it the following week and might come up with some solutions, but this probably requires to change almost everything canvas related

[charlenni]

I didn't understand it fully. I know, that you could have problems with raster data, because SkiaSharp hiddes the real resolution of the screen.

But now, you have problems with raster data or vector data? I assume, your raster data is blury, correct?

[hajmajeboss]

Both.

We use own scalebar because the original one is not working correctly with our required CRS and transformation. I would say it's quite visible that both vector and raster data are blurry.

The second picture is the very same WMS layer, svg pin and vector point on Xamarin.Forms canvas.

[charlenni]

You say, the content of the upper image is all vector data? And on the lower image, the scalbar is original?

[hajmajeboss]

The drawing - yes. And on the lower image, the scale bar is original.

[hajmajeboss]

I don't mind the raster data being upscaled, I don't need to show 32 WMS tiles at a time, because the performace is quite slow then. I just want my vector data to look as sharp as they look on Xam.Forms.

[charlenni]

But I assume, that there isn't any other chance. You could have all in high resolution (and than need much more WMS tiles) or you couldn't have high resolution vector data.

A description of the problem could found here.

[hajmajeboss]

Can't open the link.

You could have a PixelDensity property in your IViewport and upscale only raster data, while rendering vector data in native resolution. But this would effectively require to rewrite almost every single method working with canvas positions etc and in the end, the performance would probably still be pretty terrible.

I assumed you did this in Xam.Forms, because the other option would be "rendering" your data as XAML elements. I do this with pins and geolocation indicator in Xam.Android - they are Android ImageViews on top of the map, reacting to map events. Sadly, you can only set integer position on the screen, which makes it look out of sync with the map when zooming or moving the viewport.

So, maybe a middle-ground would be the best solution - not upscaling it three times like now, but only by 150% would already make it look much better, because right now, most of new phones have at least full hd resolution and then it looks just bad.

[charlenni]

Sorry for the link. Here is the correct one. And here is a blog post from SkiaSharp about this issue.

[charlenni]

Do you check the Mapsui.Forms regarding this problem? Do you get the same results?

[hajmajeboss]

Which problem?

[charlenni]

The problem with the low quality images.

[hajmajeboss]

No, as you can see in the picture above.

[charlenni]

So you would say, that the upper image is a Mapsui.UI.Forms.MapView?

[hajmajeboss]

[hajmajeboss]

This one is.

[charlenni]

But for this, the drawing is perfect, isn’t it? So you have only problems with the Mapsui.UI.Android.MapControl?

[hajmajeboss]

Yes, but we made the switch to Xamarin.Android with MvvmCross because our app is quite a complex one and we felt that native development would be a better platform for our needs. Knowing how it looks on Forms, we spent a few hours trying to find the problem before I started the issue back in August.

[charlenni]

Ok, if you could create your own Mapsui packages, than try to replace the SKCanvasView with a SKGLView. There isn’t a IgnorePixelScaling, but I assume, that it works.

[hajmajeboss]

OK, so Xam.Forms uses SKGL instead of SKCanvas?

[charlenni]

Yes, see here

[charlenni]

At the beginning, there where problems with GLViews. But I think, they now work as expected.

[hajmajeboss]

Ok, will give it a try, but not sure it will work, as it's a XF library.

[charlenni]

Than use a Xamarin.Android implementation. See here.

[hajmajeboss]

Thanks, but there is no SKGLView there - I assume I have to use SKGLSurfaceView.

[charlenni]

Yes, I would say. Not sure, if this works, but worth a try.

[hajmajeboss]

Works, performance-wise -> AMAZING!!!. But then, 32 tiles are displayed on my screen, drawables and widgets are too small etc. -> everything needs to be upscaled, while keeping the quality for vector drawables and losing it for raster drawables.

But the OpenGL thing probably made this solution viable, as it was too slow to do with plain canvas.

Thank you.

[hajmajeboss]

Ok, almost solved ->looked at XF code and it scales in OnPaintSurface method. Did it, works quite well, only problem is with zoomed out map, would probably have something to do with limitedviewport, guess it's solvable.

Thanks one again!

[charlenni]

Perfect. Nice to hear this.

I assume, that you have to scale only once when drawing.

If change more, it would be nice to see a PR 😉

[hajmajeboss]

Takes forever to show the drawing, don't know why, editing or adding the points is much faster than before. Scalebar is definitely wrong (or is it?). But the picture above is the way I wanted it to look.

Will do a PR once we sort everything out.

[hajmajeboss]

I have one additional question - XF uses Skia renderers as well? I see XAML renderers and wonder, where they are used.

[charlenni]

Takes forever to show the drawing, don't know why, editing or adding the points is much faster than before. Scalebar is definitely wrong (or is it?). But the picture above is the way I wanted it to look.

The scalebar looks good. Compare the length with the length of the 0,098 km line you made. Should be the same. I would expect, if it is wrong, than it should be a third of this line. But they are nearly the same.

And yes, it looks much better than the last images.

I have one additional question - XF uses Skia renderers as well? I see XAML renderers and wonder, where they are used.

I would say, they are historical. Even on WPF you could decide, which renderer to use. But the Skia renderer are much faster than the WPF ones. So I assume, that the most use Skia.

[hajmajeboss]

I would say that the line metrics are wrong as well though.

The problem is with viewport's center - I have my GPS position set as Home and once I return to home, I'm quite a bit away from the expected position. Also, when zooming, there are some glitches and flickering of WMS tiles and sometimes those tiles take forever to render. Maybe those were the issues you encountered when trying to use SKGL on Android.

[charlenni]

I assume, that behind the scene, the Forms implementation of Skia uses the same object than the Android implementation. So I’m not sure, where the problem is.

And if you don’t get the right position on the map, than I assume, that there is some other problem. How do you calculate the distance between two points? And if you mark a known point, do you get the correct coordinates for this point?

[hajmajeboss]

Got it working now - I had my viewport size set to full resolution (2160x1080) and scaled the canvas 3 times. Once I divided my viewport size by pixel density and then scaled the canvas, it started to work as needed. This actually makes the whole fix a two-liner.

I will do further checks and tests and if everything works properly, I will do a PR. I have some problems with graphical glitches when rotating the map,, which I as I remember had on XF version as well. Those glitches are not present with OSM, but are quite visible with our provider ČUZK's (Czech Geodetic Office) maps.

Also rendering of vector features is delayed a bit and not reacting quickly enough to some changes (like adding a point to a drawing - the linestring underneath will rerender, but it will take a while to rerender the point) - but this is subject for another issue I guess, I had mostly similar problems with old canvas.

[hajmajeboss]

So the whole fix is changing datetype from SKCanvasView to SKGLSurfaceView, changing event args type in CanvasOnPaintSurface() to SKPaintGLSurfaceEventArgs type and adding this line to the method

args.Surface.Canvas.Scale(PixelDensity, PixelDensity);

before calling Render().

That's it. But you need SkiaSharp 1.68 to do it as there is no OnPaintSurface event handler in 1.60.3. You dropped back to 1.60.3 lately so I guess there were some problems with 1.68.

[charlenni]

There was a change from 1.68 to 1.60, because rotating was slow. But this problem in Skia is solved, so I see no problem here.

[pauldendulk]

We use skiasharp 1.68 since 2.0.0-beta.30.

[pauldendulk]

@charlenni You mentioned in another thread that this problem exists on all platforms with high dpi? But @hajmajeboss indicates that this problem does not exist in Mapsui Forms. What am I missing?

[hajmajeboss]

Mapsui.Forms uses SKGL while Mapsui.Android uses SKCanvas. I changed two lines of code, replacing canvas with SKGL and scaling the canvas to fit the screen and the problem is solved.

[charlenni]

@pauldendulk If you use a normal (CPU) canvas, than all things are drawn in a display independent coordinate system. On iOS ist is the old format was 320x480. This was kept for new versions. If you now draw a line from 5/5 to 6/6 you get on the old display 2 pixels. If you draw the same on new displays with scale 2 you get a upscaled bitmap of this 2 pixels, not 4 pixels as you expect.

If you us the GPU canvas, this is handled correct in the background for you.

[charlenni]

By the way, the same problem as the blury callouts ;-). They are drawn on, say a 32x32 canvas and than, when drawn on a 64x64 canvas get blury. See the MyLocation bitmap that I use in the Add Pin Sample. It is the same SVG picture for the MyLocationLayer and the callout.

[pauldendulk]

@hajmajeboss I added the changes exactly as you specified and the problem is now solved in the Mapsui.UI.Android MapControl.

old:

new

[hajmajeboss]

OK, so I don't have to make a PR?

All the credit goes to @charlenni though, I planned on upscaling the map while rendering vectors in full resolution and rewriting every method working with screen positions, which would take forever and be very very slow performance-wise.

[pauldendulk]

@charlenni It does not depend GL rendering. We need to use a denser coordinate system (move raw pixels per device pixel) to maintain readable text. This is possible with bitmap and GL. The image below is an example of the CanvasView but this time scaled with args.Surface.Canvas.Scale(PixelDensity, PixelDensity); instead of IgnorePixelScaling. Apparently IgnorePixelScaling is the culprit. Is is also used in UWP, I will look at that next.

I am fully aware that drawing vector to bitmap and than canvas can reduce the quality. This is an issue very relevant for the BruTile tiling library that I started writing many years ago. Sometimes it is a necessity for performance to rasterize though. Some things that could improve the quality:

• Draw the bitmap top left location exactly the pixel start so that one pixels in the source matches 1 pixel in the target. If you do not do that the library uses some kind of pixel color interpolation which can have weird affects.
• Use the most appropriate pixel interpolation.
• Don't upscale. Skia has all options to use which ever combination of pixeldensity and coordinate system you would like.

[pauldendulk]

@hajmajeboss No, PR needed. It will fix it today.

[charlenni]

@charlenni It does not depend GL rendering. We need to use a denser coordinate system (move raw pixels per device pixel) to maintain readable text. This is possible with bitmap and GL. The image below is an example of the CanvasView but this time scaled with args.Surface.Canvas.Scale(PixelDensity, PixelDensity); instead of IgnorePixelScaling. Apparently IgnorePixelScaling is the culprit. Is is also used in UWP, I will look at that next.

I don't understand? Do we have any problems with sizes or text when using the GL version in Android?

I am fully aware that drawing vector to bitmap and than canvas can reduce the quality. This is an issue very relevant for the BruTile tiling library that I started writing many years ago. Sometimes it is a necessity for performance to rasterize though.

When? I think GPU systems are much faster in rendering vactors than bitmaps. So why convert vector to bitmap and than reder this?

Some things that could improve the quality:

* Draw the bitmap top left location exactly the pixel start so that one pixels in the source matches 1 pixel in the target. If you do not do that the library uses some kind of pixel color interpolation which can have weird affects.

* Use the most appropriate pixel interpolation.

* Don't upscale. Skia has all options to use which ever combination of pixeldensity and coordinate system you would like.

So you would say, we could make things better than modern GPU GL graphics?

[hajmajeboss]

Image quality looks better in the last picture in compare with the previous GL one.

[pauldendulk]

I don't understand? Do we have any problems with sizes or text when using the GL version in Android?

Yes, we have. When you draw pixel on pixel on high dpi device the font will be too small to read. IgnorePixelScaling was a solution for this but apparently it used the low resolution bitmap in the background. Now we use canvas.Scale instead.

When? I think GPU systems are much faster in rendering vectors than bitmaps.

This depends on the number of features that need to be rendered and the complexity of those features.

[hajmajeboss]

No, the font size is absolutely okay on my side.

[hajmajeboss]

[charlenni]

I thought this. I couldn't remember, that I did any rocket science in the Forms implementation.

With canvas you draw to a memory bitmap with device independent coordinats and than scale this bitmap to the canvas. With GL you render to a canvas and all values adjusted to the correct size before drawing. Thats the way I thought things work.

[charlenni]

@hajmajeboss Nice interface

[pauldendulk]

No, the font size is absolutely okay on my side.

Yes, that is because we actually scale with canvas.Scale.

[hajmajeboss]

Thank you. We do all imaginable forestry-related software and the map functionality is quite complex, as we need to display around 10-15 different WMS layers, mbtiles layer with forest map which will display a related feature on click - there would be around 10-50k features in memory at a time otherwise. And then, the whole drawing functionality, with ability to select a point and move it to desired location, snap it to another feature and so on... We have pretty much the same app done in Cordova with OpenLayers but wanted to make a switch to native development because the old web app was very hard to maintain. OpenLayers had most of this drawing functionality out-of-the-box, but it wasn't hard to implement it in Mapsui. I hope we will be able to do something to improve vector features rendering, as it's a bit delayed now (takes around 500ms between click in the map and the vector point being shown). I'm really happy with the look once the canvas drawing issue has been resolved.

[pauldendulk]

This is how it looks when we don't scale and those fonts are not readable.

Now you might think that the scaling is needed because the map is too small for the screen but the map is not that small by coincidence. It is that small because I also took the DeviceDensity into account when determining the map size outside we would needlessly draw outside of the visible map.

[pauldendulk]

Image quality looks better in the last picture in compare with the previous GL one.

hmm, I had not seen that. It is actually a significant difference.

[hajmajeboss]

Image quality looks better in the last picture in compare with the previous GL one.

hmm, I had not seen that. It is actually a significant difference.

And what did you change between those two shots?

[pauldendulk]

With canvas you draw to a memory bitmap with device independent coordinats and than scale this bitmap to the canvas.

No, I just tried to explain to you that this is not the case an proved it with the screenshots above. The image quality in the CanvasView is even better. What will make you stop saying that?

[pauldendulk]

And what did you change between those two shots?

I used CanvasView in the very last one, but removed IgnorePixelScaling and added canvas.Scale.

[hajmajeboss]

I might try it as well, but performance is also an important factor for us. Wouldn't it be quite slower compared to GL?

[charlenni]

@hajmajeboss Your problem is line 59 of MapControl.cs of Android. Here is SingleTapConfirmed used. It has to wait some time to check, if this tap could be getting a double tap. See here. Normally this is around 200 - 250 ms. If you use OnSingleTapUp (see here), you get the result immediately. No waiting.

[pauldendulk]

Actually I always had in mind to move to SKGLView. I had already done so in the past but the skiasharp implementation crashed now and then so we had to revert. This last screenshots shows their might be reasons not to go to SKGLView which is unfortunate. Still, I think performance is more important.

[hajmajeboss]

Wow, amazing, will try. We don't need to use double taps, because in the old cordova app, we had quite a hard time registering it correctly, so we replaced the "double tap to delete point" with delete icon in toolbar functionality.

[charlenni]

@pauldendulk Which sample do you used to create the above images?

[pauldendulk]

Mapsui.Samples.Droid -> Demo -> Map Info.

I just pushed the SLGLView version to master (through a PR so you saw that). If you replace it with CanvasView and remove the 'GL' from the args you get the very last screenshot.

[charlenni]

There is something strange. Look on the image below

The curves on text and the circle on the right (which is a SVG button) is much better than the blue circle in the middle, which is also a SVG image. I try to find the problem.

[hajmajeboss]

@charlenni replacing Confirmed with Up event worked, now it's much faster, but still, the line is rendered immediately and the point rendering is still delayed around 250ms.

[charlenni]

@hajmajeboss Thats sounds good.

For the delay I should have a little bit mor informations. I assume, that you use a LineString and independent Points? Or you have a special style for your LineString?

[hajmajeboss]

Independent points.

[charlenni]

Don't be shy ;-) Could you some code where you create the LineString and the Points?

[pauldendulk]

2.0.0-beta.35 was released with the fixes discussed above. SKGLView is now used in Android. I also added it to iOS while we were working on the subject. This was it for me for today.

[hajmajeboss]

`
....
if (type == DrawingType.Polygon)
{
var g = geom as Polygon;
for (int i = 0; i < g.ExteriorRing.NumPoints; i++)
{
points.Add(g.ExteriorRing.Point(i));
}

            for (int i = 0; i < g.NumInteriorRing; i++)
            {
                var ring = g.InteriorRing(i);
                for (int j = 0; j < ring.NumPoints; j++)
                {
                    points.Add(ring.Point(j));
                }
            }
        }

        List<Feature> features = new List<Feature>();
        foreach (var pt in points)
        {

            if (pt == SelectedTahloPoint && pt == points.Last())
            {
                features.Add(new Feature()
                {
                    Geometry = pt,
                    Styles = new List<Mapsui.Styles.IStyle> {new FeatureOverlayStyle().GetSelectedLastPointStyle()}
                });
            }
            else if (pt == SelectedTahloPoint)
            {
                features.Add(new Feature()
                {
                    Geometry = pt, Styles = new List<Mapsui.Styles.IStyle> {new FeatureOverlayStyle().GetSelectedPointStyle()}
                });
            }
            else if (pt == points.Last())
            {
                features.Add(new Feature()
                    {Geometry = pt, Styles = new List<Mapsui.Styles.IStyle> {new FeatureOverlayStyle().GetLastPointStyle()}});
            }
            else
            {
                features.Add(new Feature() {Geometry = pt});
            }
        }

        if (FeatureOverlay.DataSource == null) FeatureOverlay.DataSource = new MemoryProvider();
        ((MemoryProvider) FeatureOverlay.DataSource).ReplaceFeatures(features);`

"Tahlo" means the "hand" icon, "Nacrt" = Drawable.
Recreating the points everytime something changes is probably not the best way, maybe I could try to optimize it. I haven't touched the code since August and it was kind of concept if it will be possible to draw those sketches with Mapsui.

[charlenni]

2.0.0-beta.35 was released with the fixes discussed above. SKGLView is now used in Android. I also added it to iOS while we were working on the subject. This was it for me for today.

@pauldendulk Geniet ervan. Een goede rust zondag.

[charlenni]

Very strange. Made some more test. The easiest was to use the SvgButton from Mapsui.Forms. If you use the SKCanvasView with scale = 3 then you get the following image

When you than replace the SKCanvasView with a SKGLView and do nothing else, than you get this image

For me it is a Skia problem with the GL view. It is fast bad the quality isn't so good. The SKCanvasView has good quality, bat bad performance.

[charlenni]

@hajmajeboss I assume, that points is a List<Point>. But even than I could not see, where there should be such a time consuming part.

Do you checked, which is the time consuming part of this function?

[hajmajeboss]

I noticed, that when some of the points get out of viewport and I move the map so the points should be visible, they take awful lot of time to appear again. Linestrings and polygons are rendered immediately

[charlenni]

Extremly strange. Do you think you could made a sample to look at this?

[hajmajeboss]

Just create a layer and on click and add a point to the layer, my logic for adding - meaning replacing features in a memory provider - is in the sample above.

I won't have the time to create runnable sample today, might do it tomorrow at work. I believe it might be, because I set the point style while creating every feature instead of using the "default" one - that's because we need to distinguish between selected point, last point and normal points.

[charlenni]

Just create a layer and on click and add a point to the layer, my logic for adding - meaning replacing features in a memory provider - is in the sample above.

I won't have the time to create runnable sample today, might do it tomorrow at work. I believe it might be, because I set the point style while creating every feature instead of using the "default" one - that's because we need to distinguish between selected point, last point and normal points.

No Problem. I'm travelling tomorrow, so it would Tuesday until I could take a look.

[hajmajeboss]

Tried creating a style in constructor and then using the reference instead of creating a new style everytime I refresh the feature overlay, but there is no visible performance benefit.

[johnpudd]

This is looking really good for me, thanks to everyone involved!!!

One thing I noticed that I'm unsure about: CanvasOnPaintSurface is firing a lot... 20+ times per second even when nothing is happening on the map (no changes seem to be triggering this).

I've tried with our app, but also with the sample app.

Does anyone know SkiaSharp well enough to know if that's expected, or if it should be a concern?

Performance seems ok, but I'm sensing that battery usage maybe affected, and also if that app was under more load, performance may be affected by the high frequency of redrawing.

[charlenni]

I saw this too, but don’t investigate this further.

Do you use the GL version or the normal canvas?

[pauldendulk]

@charlenni Did you notice this in the forms implementation?

[charlenni]

@pauldendulk Don’t know. To much testing in the last days. You could see it by your own. Use the special style sample from yesterday. The symbols change the color when redrawn.

[charlenni]

Found the problem of low resolution on Android. It seems, that a SKPaint is needed, when drawing an SKPicture to a canvas. I assume, that the scale on Android is the problem, but don't know it.

Try to make a PR for this.

[charlenni]

See PR #840

[hajmajeboss]

About the vector drawables rough edges -> updating to latest preview release of SkiaSharp looks like a possible fix. I didn't notice it, as we were on Skia 1.68.0 in our fork, updated to latest stable version 1.68.1.something and the antialiasing was not present. However, the performance was much better. Updated to preview version afterwards and antialiasing is working again and the performance looks almost the same.

[hajmajeboss]

But the GL canvas has one quite a big issue with WMS tiles rendering - when zooming in and out on rotated map, there is some flickering of white space between the tiles. It is present in samples and it is present in Forms version. However, it's harder to simulate in samples as it's more visible with our map provider (ČUZK), but you can definitely see it when zooming in/out in samples.droid.

[pauldendulk]

This flickering was not on the non GL canvas?

[hajmajeboss]

I didn't notice it previously on non GL, but did notice it in Forms before we made the switch to native.

[hajmajeboss]

About the issue with delayed points rendering - I solved it by using MemoryLayer instead of Layer. This also solved the problem, that the drawings were not rendered until WMS tiles were fetched.

Now, only the flickering stays as a problem.

[charlenni]

That sound good.

About the problem with flickering: I assume, that you have to live with this. I see this too, when using satellite tiles. Always, when the tiles are darker than the background, you get this problem. When you rotate the map, the image has to be recalculated and this could take some time. So draw light beckground, rotate image and draw image. Try to make the background darker.

[hajmajeboss]

Couldn't limiting FPS help?

[pauldendulk]

Did you try to sample 'WMS called tiled'? How is that different from what you see?

Could you show us a recording of the flickering?

[hajmajeboss]

Happens in tiled WMS sample as well - what's even the difference in WMSC sample and TiledWMS sample, can't find any?

[hajmajeboss]

The flickering is visible even in Bing maps sample, however changing to canvas makes the problem disappear. Can't find a way to record it for you right now. @charlenni already confirmed the issue.

[hajmajeboss]

https://www.youtube.com/watch?v=JHmmFRwgh1I&feature=youtu.be

There's the recording.

[pauldendulk]

Thanks. I had not seen it before. Can reproduce it now. No ready explanation.

You only see it during movement, right?

[hajmajeboss]

Yes, only during movement and gets much worse with rotated map. I even see the tiles getting moved a bit around when I move the map slowly - couldn't there be some floats/doubles rounded to ints?

[charlenni]

I assume, that it is a problem with the GPU memory bandwidth. When we draw a raster image, than this is always new for the GPU and has to be transferred to the GPU memory. This is time consuming.
A workaround would be to save the raster image as texture. But there ends my knowledge of OpenGL.

[charlenni]

Here is a issue about this.

If I understand it correct, on GPU it would be better to make a SkImage from the bitmap and draw this again and again. So on Skia renderer we have to save the SKImage instead of the bitmap. But when I look into the code, than we do this. We create a SKImage in BitmapHelper.Load(). Perhaps we have to do something else. Have to look into this.

[hajmajeboss]

I don't know anything about OpenGL anyway. I hope fix would be available soon and that's probably all I can do at the moment :-D

If it can help - when using two or more layers, it's the layer underneath flickering, not the white background. I can pretty much see both the tiles and the drawing moving slightly "out of sync" when moving the map - like if it needed a bit more precision when handling floats, because the same happens for my GPS indicator, which could even be positioned only by ints.

[charlenni]

@pauldendulk I checked this. If you look in BitmapHelper, than the image in line 30 has image.IsTextureBacked the value false. With this, the raster image has each time, it is drawn, to be transfered to the GPU memory, what is time consuming. So it would be better, to create a texture beacked image and save this as bitmap. Should look like

            var image = SKImage.FromEncodedData(SKData.CreateCopy(stream.ToBytes()));

            // Create a texture backend image from bitmap
            var info = new SKImageInfo(image.Width, image.Height);
            using (var surface = SKSurface.Create(grContext, false, info))
            {
                surface.Canvas.DrawImage(image, 0, 0);
                image = surface.Snapshot();
            }

            return new BitmapInfo {Bitmap = image};

Should work, but we haven't the GRContext in this place. If we have, than it should be faster to draw raster tiles. Perhaps we should do this conversation much earlier? Or we have to set the GRContext into the renderer from MapControl?

[charlenni]

First shot ;-)

[hajmajeboss]

That's when using the code above?

[charlenni]

Yes. It seems, that there is something wrong ;-)

I tested it on a real Android device and get again white flicker. So it seems, that this isn't the solution or I doing something wrong. I make a PR with my changes, so you (@hajmajeboss) could test it. Ok, the tiles are not correct, so look only to the flicker.

I now have to start with work, so I could look into this perhaps tomorrow.

[hajmajeboss]

Yes, I ran the test myself and flickering is not gone.

[hajmajeboss]

I didn't test it anywhere else, but is it only Android-related problem?

[charlenni]

The problem is, that you need a device, where you could rotate and move the map at the same time. Perhaps I should activate my Mac?

[hajmajeboss]

You don't need to rotate the map, just need to zoom and move at the same time.

I still believe this has nothing to do with the way the bitmaps are rendered, but more with the way the bitmaps are positioned. The tiles are drawn, there is some wihte space between them, then they reposition correctly after a while. And this happens all the time again and again.

[charlenni]

Btw. if it would a int/float problem, you should see it also in still images, shouldn't you?

[hajmajeboss]

True. But I can see the tiles move around a bit when moving with the map and then reposition correctly.

[hajmajeboss]

Anyway, wouldn't it be better to create an issue and already close this one, as the initial problem has been resolved by switching to OpenGL.

[charlenni]

Good point. Could you do this?

[hajmajeboss]

849

[pauldendulk]

ah, time for closing our most commented issue.