Hey... two quick questions:
Does Desktop Edition support caching yet? And contiuous panning?
Desktop Edition caching and continuous panning
Brendan,
Yes, we have the continuous panning and for every layerOverlay, we support caching. Just set the cache folder within LayerOverlay.ClientCach, it will do the caching automatically.
Ben
Great. Just tested the caching and it works well. Continuous panning isn’t working though. Do I need to enable it? Or has it been removed for now due to the threading issues? Or?
hmm, playing with it now… my map seems slower with caching:/ I’ll do the research and get back to you with values.
It should be a bit slower at the first time but be faster for the rest. Let us know what you get as it might have issues.
Ben.
At the moment i’m working on our custom feature source. I’ll probably get back to caching next week (using the image cache and GeoCache). When I do, hopefully I can take some measurements and get back here with something useful.
Brendan,
Look forward to hearing the results. The cache is a bit slower as Bai mentioned the first time and sometimes all the time depending on the render time versus disk access time. If the are is very fast to draw, with little complexity it might be faster to draw then to read the image from the disk. Because of this I suggest you only cache sets of layers that take a bit to draw. I wouldn’t try and cache single layers or things that are very simple. Another option would be to enhance our caching to keep X many tiles in memory which might speed things up. Of course the images may already be in memory because of the OS and hard drive caches.
David
I think that’s the case. My disk read times are pretty quick, although I expect shape files may be slightly quicker.
I think my caching will center around the data, and not the images. This will also mean a lower memory footstamp.
The one thing I would be looking forward to in a threaded release would be calling the FeatureSources in a threaded manner instead of one at a time like now.’
Thanks for the info.
Brendan,
In the ‘threaded’ release as you put it we will be focusing in on just two threads. The first is the UI thread and the second is a separate thread to draw the images on to keep the UI responsive. This is the first step but there are already a few other idea churning around.
The problem with concurrency and threading in general is that are potentially so many places it could be used or misused. There are also a few different model to get high concurrency but they have some downsides to them. It seems from the research we are doing is that OO programming hit walls when it comes to high level of concurrency. The better model is that of robotics or hardware system. These system are based on independent manager system that coordinate tasks between other independent systems. They then submit lots of requests and then coordinate the results to build up the composited result. The overhead of this approach is high as the message passing takes time however it scales to hundreds of core really effortlessly. The short of this kind of system is that it is inefficient unless you have lots of hardware opportunity for concurrency. I don’t have enough time or room to explain all of this in detail and we can discuss it over the phone faster.
In the short term the plan is to get the two threads working then to look at the objects themselves and look at things like asynchronous patterns for objects such as the FeatureSource, Projection, Style, Layer etc. I believe we could have asyncrous APIs for many of these. So for example if we have a GetFeaturesForDrawingCore we could then also support BeginGetFeaturesForDrawingCore using an asynchronous pattern. Once these objects support it correctly we can start to add support for these asynchronous coordination inside the other objects. Of course there are coordination issues that need to be addressed but I think we can work them out. There is also gains we can make for drawing layers on various threads. There is a bit of a coordination problem with labeling however if we implemented some rules that must be followed by the developers we could minimize these issues.
In the further future I would like to create a new model for the entire API that is based on more of the real time system approach. This is the approach that will scale over the next 3-10 years as we get more and more cores. I heard that in 5 years the average desktop could have more than 32 cores. If this happens application that use 2-3 threads will not scale well. The good new sis that there is allot of research out there and Microsoft has projects the CCR just for these types of system. We are looking into them and will keep you posted.
We can talk in detail about this on the phone sometime.
David
Agreed. You ideally don’t want to have more threads than cores. I think the second thread to keep the UI responsive is a good move for now. I’m doing some threading in the FeatureSource to speed things up internally. It can wait a bit before it goes higher up the chain.
Brendan,
Another approach we are looking at is cloning. We would clone the overlays and everything underneath. The whole framework is serializable and it doesn’t take very long. Then what we could do is have as many clones as we wanted to draw without interfering with the UI thread. Users could also happily set properties, fiddle with collections and it wouldn’t effect the clones. Whenever you make a change to one of the objects in the map when you call the refresh we might have an overload that allows you to respawn the clones. This way whenever you are just moving about the map like zooming in or out we can reuse the clones. The system already has a refresh and refresh dynamic in place so this is just a natural extension of them. We have some other stuff in mind as well but safety first.
David
I won’t lie… that bends my head a bit. This is a thread posting i’m gonna have to read a few times to fully understand. I think i’ll go have another cup of coffee and read it again later:P
Had coffee… makes sense now:P I would be curious about the time taken to serialize and deserialize.
Brendan,
it is pretty fast as the object graph is in memory. As long as everything is marked to be serialized the system makes short work of it. It will not solve my problem after some thought. Back to the drawing lock idea.
David