Answered by:
Stopping Slow Layers

Question
-
I've been connecting to ESRI layers and using them with great success in the WPF version of the Bing map control. I have noticed a problem with slow layers, however. It seems like, once the map system has a request, there's no way to stop it.
For instance, I'll open up a window with a map control in it, set it to use a layer, and start returning URLs as the map control requests them. (I'm overriding the GetUri in a Microsoft.Maps.MapControl.WPF.TileSource class.) If the requests come in slowly then, obviously, it's going to take quite a while before the map can draw. What isn't obvious is that I can close the window, open up a new window with a completely new instance of the map control that has no layers at all, and the new map control will still go slow for a while. It seems like there's a single-thread going on that's pulling down info.
As near as I can tell, though, there's nothing I can do to stop it. I've even taken the map control out of the visual tree and disposed it but still the next control is slow. The only thing I can do is quit out of the entire application and start it up again.
Has anyone found a work-around for this issue? Would the UWP control help out with this?
Friday, January 10, 2020 4:30 PM
Answers
-
The UWP control will definitely request raster tiles quickly. It's heavily multithreaded and will use multiple background threads to request and process the raster tiles while the UI thread remains responsive.
The older WPF control used the Multi-scale image control to request tiles and the request behavior is a bit non-deterministic. One other thing you might try is rather than overriding the GetURI method, try the custom tile layer option where you supply the image directly. You can make the tile request and decode in your app code. That might perform better but it's difficult to say for sure. I'd avoid doing anything that blocks the thread in a callback like GetURI as that may cause further requests to be stalled.
- Marked as answer by Zloth X Thursday, January 16, 2020 7:18 PM
Monday, January 13, 2020 11:40 PM
All replies
-
I would definitely look into using the UWP control if you can - all current and future development is focused on the UWP control and the WPF control hasn't been updated in years.Friday, January 10, 2020 9:45 PM
-
There seem to be two ways that WPF is being implemented. One is the WPF control the other is a WPF wrapper around the UWP control. There has been some issues with the wrapper on the UWP control, do you know which you are using? Does the call stack tell you anything about where the delay lies?
I agree with the prior advice, go straight UWP and you will get direct access through the latest control with the latest features.
Friday, January 10, 2020 10:47 PM -
It's the normal WPF that's been around for eons.
The application it's in is pretty large so converting it to UWP would be a big task. I'm hoping to use the UWP control inside the WPF program some day but that requires Windows updates that are still a year or two away for us. If UWP was able to handle this situation better, it would give me a way to push for the "a year" side of that. Does it?
Monday, January 13, 2020 10:46 PM -
The UWP control will definitely request raster tiles quickly. It's heavily multithreaded and will use multiple background threads to request and process the raster tiles while the UI thread remains responsive.
The older WPF control used the Multi-scale image control to request tiles and the request behavior is a bit non-deterministic. One other thing you might try is rather than overriding the GetURI method, try the custom tile layer option where you supply the image directly. You can make the tile request and decode in your app code. That might perform better but it's difficult to say for sure. I'd avoid doing anything that blocks the thread in a callback like GetURI as that may cause further requests to be stalled.
- Marked as answer by Zloth X Thursday, January 16, 2020 7:18 PM
Monday, January 13, 2020 11:40 PM