ThinkGeo.com    |     Documentation    |     Premium Support

TrackShape speed inversely proportional to the screen size

#1

Hi Guys,


When using the TrackOverlay and drawing a single line, the bigger the screen the slower things go, when I reach 2560x1600 the line 'lags behind' the mouse by something close to a second, the smaller you go the faster it gets, 800x600 is acceptable.  As an example, knock off the screen size limitation in the demo, bang it on a big monitor, go full screen and watch what happens.


Seems that there is an awful lot of calculation/refreshing going on behind the scenes.  Is this not a ROP/rubber line thing, although GDI does not directly support this there are some seriously quick ways of emulating it.


Any thoughts?


John



#2

John, 
  
   Are you using WPF or Winforms.  WPF is much slower as they do not expose a BufferGraphics object like Winforms does.  Most of the time is actually throwing bitmaps to the screen.  We are going to be working on high resolutions speed issues soon and you should see quite a bit of speedup.  Other things that are kind of outside of our control are thing like just larger drawing area and more of the screen to paint.  Having said that there is quite a bit we can do to speed up the pan and refresh etc. 
  
 David

#3

Hi David, 
  
 This is Winforms only. 
  
 Anything you can do to speed things up at hig res. would be mauch appreciated. 
  
 John

#4

John,


For now as you said, I think that is true that the performance will becoming worse when the screen size is enlarged, the hidden reason is that much more tiles are concerned when screen size is enlarged.
 
One possible way is to set different drawing quality for layers mentioned in following post:
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/21/aft/6687/afv/topic/afpgj/1/Default.aspx#13158
 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale

#5

John, 
  
   We have some ideas but they fall into different categories such as panning, track shapes etc.  If you use a tile cache then it creates another set of issues.  For example if you run really high res thent he tile sizes should probably be set larger than 256x256 to see a little speed gain. 
  
   Now that the releases are out and the API is set we can focus more on speed relates issues especially in the high resolution scenerios.  The speed items are high on the list. 
  
 David

#6

Hi David, 
  
 We are not using tile caching, the map is far to dynamic. 
  
 Happy to test anything that helps… 
  
 John 


#7

John, 
  
  So you don’t have base maps?  Typically in most applications, even those dynamic ones, there is a set of background data that is fairly static.  For example roads, state and county outlines etc.  Do you have anything like that? 
  
 David

#8

 


Hi David,
Yup we do have base maps. Our base map is a 160mbyte coastline map of the world which is absolutely static. In fact almost all our layers are entirely static, what is not static nor can ever be, are the zoom levels.
One moment we can be looking at an area from the tip of India to the Northern tip of Madagascar, the next at the Inland Sea of Japan, the next the Black sea, the next a dock in an area of Hamburg and so on and so forth.
Constantly zooming in and out to areas globally makes it difficult to enable caching when those cached tiles take time to build and may never ever be used again.
Trying to cache the world at an inch (on screen) to the nautical mile is going to mean an awful lot of tiles is it not?
John

#9

John, 
  
   You still have some options.  First you can cache the scales that are higher up as they take very little space to cache.  These would be zoom levels 1-10 or so.  Next you could have a session type of cache that will expire when the close the program or whenever you wanted.  What this does is to help reduce drawing time when a user zooms to a place and then they pan around a bit.  We will use the tiles already created to make the drawing faster.  If you pan around an area for awhile while working it this can save you quite a bit of time.  You can also have control over what scales this takes effect on.  You can also control when the area’s tiles get deleted.  Don’t just think of the tile cache as one big cache, we can create all kinds of specialized caching schemes to match how your data is used. 
  
   Another thing while I am thinking about it is for your 160meg shape file of the coast how many records are in it?  Does it have one line per coast or does it split up the cost lines into smaller files?  The reason I ask is that it may be possible to create another version of this shapefile for user at close scales that divides the lines into smaller segments.  This will load and draw much faster.  If they are sub divided them it would be good to create a simplified version for when you are zoomed out.  Just some ideas on how to make your drawing times faster. 
  
 David