TileAsyncLayer background imgae lock problem

Topics: Algorithms, SharpMap v0.9 / v1.x
Dec 29, 2011 at 2:29 PM


I tried to use the TileAsyncLayer for displaying background maps. First observation was, that the EventHandler of the  SharpMap MapBox (HandleMapNewTileAvaliable) caused an Error due to a thread problem of the _imageBackground. I edited the function "GetImagesAsyncEnd" and added there another lock for _imageBackground to protect the g.DrawImageUnscaled call. This solved the problem. 

  if (_imageBackground != null) {

             lock (_imageBackground) {



I'm not aware if anybody else had the same problem, but if you guys could check if that is ok and does not brake anything it would be good to get this in the current version.

Another point, which is not clear to me, is the handling of file cache. I created the source with 

 tileSource = new GoogleTileSource(req, new FileCache(@"c:\tmp\google\sat", "png"));

But _fileCache of TileAsyncLayer is null. However the tiles are saved to the cache, so i'm not sure if that is done by BruiTile and how this interacts with SharpMap. The pictures seem to be not taken from the cache...???

Thanks for any Hints..-



Dec 29, 2011 at 4:33 PM

Well, I realized unfortunately that is doesn't solve the problem but improves it only. Especially when two TileAsyncLayer layers are added to the background map (Goggle Satellite & Google Labels)  more tiles are not drawn.  One probhably needs to rethink from the start how to handle the _imageBackground alltogether. Can anybody reproduce this problem?

Dec 30, 2011 at 6:44 AM


I will try to reproduce your error.
When using the ASync layers there are MANY events flying around everywhere accessing the GDI+ environment leading to threading-problems...

Regarding the FileCahce, SharpMap does not read the Cache-object from Brutile, however you can also tell sharpmap to initialize a filecache by suppling the path to the cache in one of the constructors for TileAsyncLayer