I'm currently using the Silverlight Map control for WP7, and am trying to visualize driving directions on the map. In order to highlight the route needed, I am using a MapLayer with a MapPolyline. The problem is that even with CacheMode set to BitmapCache, the MapPolyline area gets redrawn whenever the user pans or zooms the map. I've used other controls such as Ellipses or Pushpins, and with BitmapCache on, none of them redraw and give the same performance hit as MapPolyline.
Here's a quick example
<maps:Map ZoomLevel="3">
<maps:MapPolyline Name="line" Stroke="Red" StrokeThickness="9">
<maps:MapPolyline.CacheMode>
<BitmapCache/>
</maps:MapPolyline.CacheMode>
<maps:MapPolyline.Locations>
<maps:LocationCollection>
<geo:GeoCoordinate Latitude="33" Longitude="33"/>
<geo:GeoCoordinate Latitude="36" Longitude="33"/>
<geo:GeoCoordinate Latitude="33" Longitude="36"/>
</maps:LocationCollection>
</maps:MapPolyline.Locations>
</maps:MapPolyline>
</maps:Map>
If you set App.Current.Host.Settings.EnableRedrawRegions = true; you can see the redrawing that occurs. The performance is particularly bad when you have a larger polyline and zoom in closer.
Is there anything that can be done to help? The native Bing Maps has pretty smooth route drawing, so I would think that there should be a way to solve this?
Thanks!
Can you explain a bit more what the problem is?
I've got an app - RunSat - in which I draw polylines with several hundred points (e.g. I just looked at a 3 hour long bike ride) and this draws fine - including during zoom operations.
I don't understand the problem - even using the sample code above. To help - are you testing on a phone or on the emulator?
As for CacheMode and BitmapCache, I'm really not sure about using these settings for the map - I don't use them in RunSat if that helps - I just leave the phone alone to work out its own GPU drawing.
Related
I have a WPF application showing a large image (1024x1024) inside a ZoomableCanvas. On top of the image, I have some 400 ellipses. I'm handling touch events by setting IsManipulationEnabled="True" and handling the ManipulationDelta event. This works perfectly when zooming slowly. But as soon as I start zooming quickly, there is a sudden frame-rate drop resulting in a very jumpy zoom. I can hear the CPU fan speeding up when this occurs. Here are some screenshots from the WPF Performance Suite at the time when the frame-rate drops:
Perforator
Visual Profiler
Software renderer kicks in?
I'm not sure how to interpret these values, but I would guess that the graphics driver is overwhelmed by the amount of graphics to render, causing the CPU to take over some of the job. When zooming using touch, the scale changes by small fractions. Maye this has something to do with it?
So far, I have tried a number of optimization tricks, but none seem to work. The only thing that seems to work is to lower the number of ellipses to around 100. That gives acceptable performance.
Certainly this is a common problem for zoomable applications. What can I do to avoid this sudden frame-rate drop?
UPDATE
I discovered that e.DeltaManipulation.Scale.X is set to 3.0.. in the ManipulationDelta event. Usually, it is around 1.01... Why this sudden jump?
UPDATE 2
This problem is definitely linked to multi-touch. As soon as I use more than one finger, there is a huge performance hit. My guess is that the touch events flood the message queue. See this and this report at Microsoft Connect. It seems the sequence Touch event -> Update bound value -> Render yields this performance problem. Obviously, this is a common problem and a solution is nowhere to be found.
WPF gurus out there, can you please show how to write a high performance multi-touch WPF application!
Well I think you've just reached the limits of WPF. The problem with WPF is that it tesselates (on CPU) vertex grafics each time it is rendered. Probably to reduce video memory usage. So you can imagine what happens when you place 600 ellipses.
If the ellipses are not resized then you could try to use BitmapCache option. In this way ellipses will be randered just once in the begining and then will be stored as textures. This will increase memory usage but should be ok I think.
If your ellipses are resized then previous technic won't work as each ellips will be rerendered when resized and and it will be even slower as this will rewrite textures (HW IRTs in perforator).
Another possibility is to design special control that will use RenderTargetBitmap to render ellipses to bitmaps and then will render it through Image control. In this way you can control when to render ellipses you could even render them in parralel threads (don't forget about STA). For example you can update ellipse bitmaps only when user interaction ends.
You can read this article about WPF rendering. I don't agree with the author who compares WPF with iOS and Android (both use mainly bitmaps compared to WPF). But it gives a good explanation about how WPF performs rendering.
We have a Canvas control that we have set to be very large such that when a user pans or zooms around they (very rarely) see the edge of the control.
This poses a number of issues. Firstly we have to render a very large surface with a lot going on which makes things slow. It also means a user could still accidentally "fall off" the edge of the ground plane.
I have tried creating any paths using StreamGeometries to make things faster and, where I can, I have frozen assets and set various objects to IsHitTestVisible = false. These have helped matters but at the end of the day we are still drawing a massive Canvas and WPF doesnt seem to be doing anything clever given the viewport
Can anyone offer some advice?
I'm working on a WP7 app that uses bing maps to display ~600 pushpins. When i add them to the map using map.Children.Add(pushpin) the UI freezes for ~200 ms. I've seen that in silverlight you can use Microsoft.Maps.EntityCollection to add pins to a map but unfortunately I couldn't find how to use the assembly on WP7. Does anyone know a solution to this?
Maybe you're looking at the problem the wrong way round. WP7 is a compact (though powerful) that excels at showing the user what they want to know quickly (when the apps are written properly).
The user can't possibly see 600 pushpins in one go on a device that small, so why not just show them pushpins that are in the viewable area (or close to it) and add pushpins as the user pans around the map?
Alternatively you could "trickle" feed the pushpins by adding them one (or more) at a time using the DispatcherTimer so that the user sees pushpins being gradually added without drastically affecting performance.
Another possibility (which is what I usually do) is to add a MapItemsControl with the DataTemplate set to a Pushpin and to bind the collection to your collection of pushpin locations. If the binding is to an ObservableCollection you can "trickle" feed it as mentioned above if perf is an issue.
In a viewpoint similar to Derek's, I find it highly unlikely that you seriously want to put 600 pins on the screen at the same time. I'm guessing that they span a large geographic area and the user is unlikely to see more than a handful at a time.
If this is the case, you can trivially apply a cliprect to cull your points, then add the resultant modest list to a layer, and Presto! High performance.
In addition, there is the issue of what to do when the user zooms a long way out, bringing so many pins into view that they merge into one big useless but brightly coloured blob. This is a more complex problem traditionally solved with a quadtree, and I have a suspicion that you just said "a what?" but luckily Google is your friend.
Oh, and to address your stated problem - don't add the pins directly to a map. Add them to a MapLayer and then add that.
There is an example of two-way binding to Center property from Micrsoft guys.
You can find it here.
Its sample works fine, but they disabled full animation. When I set AnimationLevel="Full" and use the Compass I get trembling picture.
I really like aminations effects and don't want to turn it off.
Are there any ways to get working Compass and keep full animation?
This is a known problem and as far as i know, it hasn't been fixed. I too would very much like it to be fixed.
When full animation is on and the map is moved, it will move the map in an arch (zooms out and then back in). However, small distance movements still use the arch and this creates the shaking.
I have searched extensively (4 months ago) for a good work around for this problem.
I didn't find anything other than turning off the full animation.
I'm working on SEM image processing application, written in WPF. I have an image display control, derived from Canvas, which displays image & overlays using DrawingVisuals (one for each "layer"). It also implements Zoom & Pan using scale & translate transform, applied on DrawingVisuals.
When I zoom in the image to see individual pixels, they are displayed smooth, evidently using bilinear filtering to stretch the bitmap (no surprise, as WPF is rendered through Direct3D). However, for my use case, I would rather see individual pixels as sharp boxes, as usual in any image editor like Photoshop. That's why user of my app zooms the image -> to be able to operate on pixel level.
Is there such option in WPF (other than manually stretching the bitmap before displaying it)? I was not able to find anything.
thanks in advance,
Zbynek Vrastil
Czech Republic
Finally found an answer, with some help from Experts Exchange. Class RenderOptions defines attached property BitmapScalingMode, which can be set to NearestNeighbor. So,
RenderOptions.SetBitmapScalingMode(imageDisplay, BitmapScalingMode.NearestNeighbor);
does the trick.
Zbynek Vrastil
Hate to put a dampener on things, but if NearestNeighbor works like GDI+, then this will give you a limited success. As you increase magnification in areas of high contrast you might not get the desired results. In GDI+ you find blacks becoming blue, and whites becoming red - again I stress in areas of high contrast! If this isn't the case in WPF, think yourself lucky!
Perhaps a WCF developer could confirm that?
I've found that there are more options to consider, but I can only speak for the GDI+ Graphics class, which might be useful to someone.
Graphics graph = e.Graphics;
graph.InterpolationMode = InterpolationMode.NearestNeighbor;
graph.CompositingQuality = CompositingQuality.AssumeLinear;
graph.SmoothingMode = SmoothingMode.None;
This works for me. I think the SmoothingMode is the trick. Hope this helps someone else out there.