ThinkGeo.com    |     Documentation    |     Premium Support

Improving MultiGeoRasterLayer

#1

Hi, 


I looked into MultiGeoRasterLayer and it seems there is space for improvement. I plan to load a mixture of .bmp, .gif, .jpg files.
If I undertand right, files are loaded from disk each time they are about to be rendered. I was thinking of keeping in cache (some array or similar) in memory loaded all files that intersect with current extent, and as user pans, unload unneeded files and load new files into memory. To do that, I would need to know *exactly* in which moment GdiPlusRasterLayer loads file from disk into memory, and when are files unloaded. It looks like that is related to GdiPlusRasterLayer.Open()and GdiPlusRasterLayer.Close() methods?

#2

Mark, 
  
 Yes, you’re right. When GdiPlusRasterLayer.Open() calling it load image file from disk to memory, and when GdiPlusRasterLayer.Close() calling, it dispose in memory object of image file. When you call map.Refresh() or pan/ zoom in out, it will first Open the layer, and then call layer.Draw() to draw image to mapcontrol and finally close it. 
  
 Thanks, 
 James

#3

So, I implemented the above idea. I keep in cache 15 open files and on draw reuse them if they fit, or retrieve new ones from the disk. I think I see improvement in speed over regular MultiGeoRasterLayer, but the gain is not spectacular, as I expected. Even if all files in refresh are pulled from cache, there is still noticeable wait. It seems that redraw itself ( without pulling files from the disk) takes time. Since all is happening in the memory, I expected better result.


Maybe someone could give a comment or two on raw draw performance of GdiPlusRasterLayer.

#4

I found this post. It could be usefull: 
 --------------------------------------------- 
 09-20-2010 08:38 AM Quote Reply Alert   
 Jan,  
  
 We are working on the GdiPlusRasterLayer performance issue. Just give you an update how we did it and where we are.  
  
 We found now GdiPlusRasterLayer is slow because no matter how far we zoom in or out, we need to stretch or condense the original whole image and if the image is big, it takes time. So what we are doing is 2 parts. First while we zooming out the image get smaller and smaller, if it is smaller than its original size, we start to look if we can create some smaller images as cache so the target image can be condensed from that one instead of the original big one. For example, I have a 4000*4000 image, I keep zooming out and now the image on map is 2000*2000. I then condense the original image to 2048*2048, save it to memory as cache and condense this one to 2000*2000. If I keep zooming out and the image now is 800*800, I then create another copy with the size of 1024*1024 and condense this one to the size I want. In this way we take some more memory but the speed is much faster. Second, how about when zooming in? The original big image is tiled in memory and if we zoom in, we only need to get the tiles we need to draw, stretch them and draw it on the map. This also improves the performance a lot.  
  
 It is almost ready and we will keep you updated on this.  
  
 Thanks,  
  
 Ben  
  
  
   


#5

Hello mark, 
  
 Yes, what’s the product version you are using now? Ben said this at 2010, so I think we have fixed this already, but you still meet the problem. 
  
 Regards, 
  
 Gary

#6

I am using Desktop Evaluation version 6.0 . Files are .bmp ~3.2MB each. It needs maybe 9 of them to render screen. So, all are in cache. I move screen left-right a bit to test the thing.



#7

Here are some results I got with above described custom layer for raster files. Test system was Intel Dual Core 2.0Ghz, 4GB, SATA2 Disk, WinXPSP3, MapSuite6.0. All images were 3.2MB .bmp files. 


05:50:07 LayerTK50 rendered 9 images (0 from Cache) for 3.000 seconds
05:50:25 LayerTK50 rendered 12 images (0 from Cache) for 3.391 seconds
05:50:40 LayerTK50 rendered 9 images (0 from Cache) for 3.047 seconds
05:51:01 LayerTK50 rendered 9 images (6 from Cache) for 2.078 seconds
05:51:11 LayerTK50 rendered 12 images (10 from Cache) for 1.953 seconds
05:51:20 LayerTK50 rendered 9 images (9 from Cache) for 1.672 seconds
05:51:33 LayerTK50 rendered 12 images (12 from Cache) for 1.938 seconds
05:52:11 LayerTK50 rendered 20 images (12 from Cache) for 3.781 seconds
05:52:38 LayerTK50 rendered 101 images (15 from Cache) for 16.984 seconds
05:53:57 LayerTK50 rendered 400 images (15 from Cache) for 59.828 seconds
 

#8

Here is more. Results are not always consistent. In listing below Cache refers to my custom cache as I described above. But it seems there are other levels of caching in system (File system caching, MapSuite caching) that cause results to be not consistent. 


06:14:17 LayerTK50 rendered 12 images (9 from Cache) for 1.234 seconds
06:14:37 LayerTK50 rendered 12 images (0 from Cache) for 1.813 seconds
06:15:38 LayerTK50 rendered 108 images (13 from Cache) for 8.094 seconds
06:16:06 LayerTK50 rendered 117 images (13 from Cache) for 8.719 seconds
06:16:25 LayerTK50 rendered 108 images (14 from Cache) for 8.125 seconds
06:16:50 LayerTK50 rendered 247 images (15 from Cache) for 16.844 seconds
06:17:14 LayerTK50 rendered 274 images (15 from Cache) for 18.500 seconds
06:18:03 LayerTK50 rendered 475 images (15 from Cache) for 34.156 seconds
06:18:51 LayerTK50 rendered 515 images (15 from Cache) for 38.328 seconds
06:19:44 LayerTK50 rendered 520 images (15 from Cache) for 33.125 seconds

#9

 Hello mark,


 
Thanks for your further information, I did some test but I can't recreate your problem, I can’t find the “MultiGeoRasterLayer” class on “MapSuiteCore” or “DesktopEdition” as the your mentioned, could you please provide a self-contained sample to me?
 
Also I just append serial raster layer into a LayerOverlay and test it, please get the attached file and have a try.
 
Regards,
 
Gary

WindowsFormsApplication3.zip (11 KB)

#10

Hi Gary, 


This topic is about MultiGeoRasterLayer class from your example wiki.thinkgeo.com/wiki/Map_S...ster_Layer  and how to improve it. That is the same class recommended in discussion gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/21/aft/10413/afv/topic/Default.aspx 



#11

Hello mark, 
  
 We were able to recreate the and it will be reviewed and assigned to our development team during the next week.  Once the problem has been resolved I will post here so that you will be aware of the resolution.  If you ever need a status update, please feel free to let us know. 
  
 Regards, 
  
 Gary