ThinkGeo.com    |     Documentation    |     Premium Support

Performance of Map Control at High Resolutions

#1

Hi,


i was wondering if there was any sort of road map as far as improving the performance of Map Suite map rendering at high resolutions? By high resolution, I mean large dimensions of the control, not necessarily of the users screen even though one would imagine they would go hand-in-hand.


When the control is sized smaller it is very snappy but at high resolutions it is noticably slower. I understand the reasons for this but it is a concern going forward as we look to target any of the issues users are running into in their environments. We want them to experience good performance and as most users are now on wide screen displays, they are by default running high resolutions and so by default are running into slow component rendering. We'd like to offer an idea as to if this is being addressed, and a general time frame or priority for which this issue falls into.


Thanks,


Nelson



#2

Hi 
  
 The issue of performance is also a big concern for us. 
 We have users working with 2 and 3 high res screens.

#3

Nelson & Ofer, 
  
 With tilling technology introduced in Desktop Edition, the performance will decrease with the increase of the map with & height.  
  
 For example, if a map with is 800 * 800, probably it is 4 * 4 tiles each time, while if the map with is enlarge to 1000 * 1000, it now becomes 5 * 5 tiles each time, then its performance will becomes 16/25 of smaller map. 
  
 We are also thinking about how to solve this problem in a decent way. 
  
 Thanks. 
  
 Yale 


#4

Yale, 
  
 Thank you for the detailed answer. I had assumed as much. I am sure this has been thought of, but has increasing the size of the tiles at high resolutions made any difference? 
  
 Thanks, 
 Nelson

#5

Nelson, 
  
 We tested against with different size of tiles and it seemed the difference was very little. The reason for this is that most of the time is spend on the drawing and tiles merge.  
  
 For large tile size case, even though the tile number is less, while it takes more time to merge two tiles, and the time spend total is generally equal. 
  
 Any more questions or ideas just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#6

That makes sense. Thanks.

#7

Nelson, 
  
 Thanks for your post! 
  
 Any more questions please let me know. 
  
 Thanks. 
  
 Yale 


#8

I had a random thought or two on this after working with a mapping application that uses a cache system as well: 



1) at low extents that are 'busy' with features, is there a performance benefit at all with bitmap tiling still? if not, this is one area to look at 



2) this is the more relevant of the two thoughts: obviously I have no idea what goes on in the tiling logic within the map control, but are there tiling related calculation going on during the entire mouse down event? I notice now the way caching works, tiles are only being drawn when the mouse button is release (at least in single-threaded mode). If calculations are being done during mouse down on panning, could those calculations not be moved to mouse-up on pan? This could save a lot of time if this even applies at all... 



I am using a desktop application with the map renderer being almost instantaneously fast with pans also being smooth which sort of proves the point that it can be done. It is an interesting topic to me... The application is almost using next to nothing in resources which is interesting too, but that can be for a whole slew of other reasons. 



Something slightly related to this is that the above mentioned application is not doing much in the way of 'filtering' the image so it doesn't appear to employ much antialiasing and the like. 



I tried to bring the drawing quality settings for Map Suite as low as possible but it seems like no noticeable effect takes place. Are there settings to ramp the draw quality down? They don't seem to have a noticable effect for me when changed from the properties panel. It would probably be acceptable to have draw quality go down in favor of high resolution response. 



Let me know your thoughts on this, if any. 



Thanks.



#9

Actually, after taking a closer look, it seems like when my Map Suite-based application first  loads, my panning and what not is terrible no matter if I clear all my layers and no matter which layer I use or what source (WFS or SHP), but if I use my routine for loading a map file (a file with a list of layers to add and symbology) when that file is done being processed and the map has finished loading, the panning responsiveness is really good even at my high resolution… 
  
 Not sure why this is as it seems I need to narrow it down for myself but I’d have to say the performance is actually quite fast when things are working correctly. 
  
 Just thought I’d throw that corrected info out there.

#10

Nelson,


Thanks for your posts and sorry for the delay because of my vacation for a few days.
 
I understand your problems and your ideas are great, and here I just want to mentioned out 2 things:
1) The Overlay which is not base overlay (IsBase setting to false); the drawing of the overlay will be started after Mouse Up event. If the overlay is base overlay (IsBase setting to true), then each tile will be drawn on each Mouse Move event.
 
2) There should be very obvious difference when you set the different quality.

winformsMap1.DrawingQuality = DrawingQuality.HighQuality;
winformsMap1.DrawingQuality = DrawingQuality.HighSpeed;

 

I have added this issue to our working track system and hope it can be fixed soon. If you want, you could reply back to keep it alive.
 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale


#11

This hasn’t been updated in a few months, has there been any progress on this?  I do not like forcing my application into a specific resolution, but at full screen the panning/redrawing is not at an acceptable draw or response time.  Is there another post dealing with this issue that is maybe more current?  I did not find one in my search.

#12

Jake, 
  
 Thanks for your post and questions. 
  
 Recently, there are couple of posts & tickets talking about the performance enhancement, while it seems few mentioned about the resolution. 
  
 Did you try to run the application with tiles already cached to see it is acceptable? 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#13

Yes, we are using the cache, and the drawing of the tiles seems fine.  The issue is the responsiveness of the window.  When I click to drag, I have to click, hold for a second, them move, then wait for the screen to respond.  It acts quite different when using a forced 800x600 resolution and when moving to full screen (1600x1200 in my case).

#14

Jake, 
  
   The issue that you are seeing is because of the way we write the image to the screen.  We are using the buffer graphics which is the recommended way to draw images however it gets very slow at high resolutions.  In our testing what we find is that if when you pan we draw the image to the screen as you move it has the slow response as you noted.  We also tested adding the image to a picture type control inside our control and moving that and the responsiveness is really good.  Microsoft is doing something different in their controls that we cannot do easily using the buffer graphics.  Our next step is to integrate some kind of control to speed up the panning and probably a number of other things.  We have known this for a little while now.  The reason we have not integrated it into the build yet has been two fold, first the end of year saps resources and it is hard to plan allot of development while everyone is off and the second which is more of the issue is the new build system we put in place.  With all of our components released now for 3.0 we got all the teams together to do cleanup of the source code, branches, code hierarchy, source control cleanup, and with this building a new build system.  The build system was automated before we but we enhanced it.  This is going to fit in with a new public issue system an the ability for developers to get daily builds automatically through the website and having all our issues tracked publicly.   
  
 Ok, enough of the excuses on that.  We are pretty sure we understand the problem, we are finishing up all the infrastructure changes and we will be ready to tackle this in a week or so.  I will be personally leading the charge to get this resolved.  I can’t offer you a drop dead date but I would like to get it resolved, and out in peoples hands, by the end of the month. 
  
 David

#15

David, 
  
      I am sure there are other open discussions, but this one came to the top during my search again.  I don’t expect a deadline date or anything, but if possible can you give an update on how this is coming along?  
  
 Jake

#16

Jake,


I am sure we did some enhancement on the panning performance a couple of days ago; I did that with David together.
 
If you want, you could get the latest version to see its effects now, hope it was expected:).
 
Thanks.
 
Yale

#17

Yale, 
  
 Just wanted to say the panning performance seems to be very improved from what I can see! It doesn’t look like it helped track shape performance at hi-res but thats not a concern for us. Great job! 
  
 Thanks, 
 Nelson

#18

Nelson, 
  
   We are working on the track shape performance and I hope to have some improvements soon.   
  
 David

#19

That’s good to hear, David. The performance of trackshapes for me at 1680 x 1050 is quite acceptable so it’s not much of a concern of mine. The only way I could even tell was by trying it out at a lower res and comparing the two and I was only really doing that to test the panning improvements. Thanks again guys.

#20

Nelson, 
  
 Thanks for your sharing, that would be helpful to us. As David said, we are going to enhance the TrackShape performance, hope we can get it soon. 
  
 Let me know if any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale