Custom TiledLayer

Discussion created by bsundsbo on Feb 21, 2014
Latest reply on Feb 21, 2014 by bsundsbo

I need to support custom data sources in my map (for reasons that I will not go into here), and the datasource is not natively supported by ArcGis Runtime SDK for WPF. The underlying technology can only handle System.Drawing.Bitmap, and these I convert into BitmapImage. This has been implemented as DynamicLayer, and works great. The images are generated on a background thread, and all is pretty good.

Because the underlying data is sometimes somewhat slow, I would like to turn this layer into a TiledLayer. The way of generating the tiles is identical to when using DynamicLayer, and seems to work just fine.

But wait.... There is a memory leak with both approaches, but it becomes more evident with the tiled approach. There are unmanaged bitmap handles related to the conversion process from Bitmap to BitmapImage. I have not yet found a way to convert the bitmap without getting different unmanaged bitmap handles retained in memory (that might be cleared up eventually, but not fast enough). System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap (and deleting the handle), saving bitmap to memorystream, etc still retains memory.

Since I'm creating tiles and storing them on disk for later requests, I would like to assign the UriSource of the bitmapimage to the file path on disk, but I get an exception saying it can't cast FileWebRequest to HttpWebRequest. Is there a particular reason why this can't is not supported? Loading the BitmapImage from disk using different LoadOption, CacheOptions, etc doesn't seem to help with the memory issue. Any suggestions would be welcome, but I know it is not within the scope of this forum.

I event tried wrapping the export operation inside of a REST service to utilize the existing functionality in TiledLayer/TiledMapServiceLayer, but I lost the background functionality (as far as I came, at least). And adding additional layers to be able to return the image through a memorystream is a bit exessive, in addition to other issues that might arise from this.

I think this issue might be resolved using a FileWebRequest, but I'm not sure. And since I can't wait untill this might be supported in the future, do you have any suggestions for getting rid of the memory leak?