Hello
This simple pseudo code does not longeur work with 3.0.357; the map is not refreshed
overlay.lock
style.change
overlay.unlock
map.refresh
Please send me a new version with that very simple usecase fixed.
Patrick.
Style refresh regression in 3.0.357
Patrick,
I am not 100% but I have an idea of why this is happening. First we do not use any default caching and because of this in a refresh we do not clear the tilecache as far as I know. This means if you have your own tilecache then you need to call clear on it before you do the refresh. In combination with your other post depending on the kind of cache you are using you may need to set the ReadOnly to false. The idea is that for simple FileBitmapTileCaches you normally do not want to delete these and if you do it might cause really problems. For things like the SessionFileBitmapTileCache these should be cleared and not defaulted to ReadOnly.
What we need to do is to allow the ReadOnly to be an enum first then make it public virtual and override it in our session file cache and not int he filebitmaptile cache. Default the filebitmaptilecach to read only. The big question is if we should call the cache clear on the Refresh. We are not doing this now but I can see how it would make it streamline to do so. The thing that scare me a little is that when you call Refresh() in single threaded mode we refresh all of the overlays. In multi-threaded we use the IsDirty as the guide. We really want people to move towards telling us what overlays they are refreshing and using the Refresh overloads.
Recap:
1. Readonly was to save people why have persistent caches from confidentially clearing them
2. Refresh was made not to clear caches to also help people from not clearing them. I guess point one takes care of that so I think we can put the clear back in
3. Calling Refresh() without an overload should only happen maybe in the form load of the first refresh of the system. After that we want to get people to use the overloads but we are not sure how we can point them to this without making the Refresh() with no overloads generate a warning.
4. The readonly needs to be an enum as bool sucks for extensibility and also we need to allow this to be overridden and we need to override it in caches that are menat to be cleared very often.
Thou it does suck, thanks for your comments on this. We really have to get this right soon. I welcome your constructive feedback on this. We will work on this and get something out in a day or so.
David
David,
First I’m keeping readonly = false and I’m working in multithread.
With 3.0.453, if I have tilecache=on and I want to change the style of one layer;
what I have to do is
lock
change style
unlock
refresh.
I just install 3.0.453 back and I can confirm that this is working.
But with 3.0.457; what I have to do is
lock
change style
cache.clear
unlock
refresh.
worse, I my user is using a built in tool to edit feature; with 453, tiles are reflecting user changes while with 457, tiles are not reflecting the user change.
Even worse; If my user add a layer to an overlay (file/open); with 453, tiles are showing the new layer while with 457, tiles are showing the map without the new layer …
Francky I do not see any reason to call refresh and get the tile not refreshed (unless I use readonly)
Maybe you can set a enum to define readonly/manual/automatic tile refresh … but with 453 the automatic refresh was really what I need.
on another hand, MS is becoming more and more complex;
With most commercial tool I can change a style in a multithread env with 2 lines:
style=new style (the assesor in doing the lock/unlock behind the scene)
refresh
with MS I need 7 lines
overlay.lock
try
style=new stule
tile.clear
finaly
overlay.unlock
map.refresh …
I think that simple is best and you should try to keep your API simple (at least by default)
Hope this helps,
Patrick.
Patrick,
I agree that the caching can be automatic now that we have the read only property. It needs to be extended to support adding new tiles or not adding new tiles. In past releases the caching was hidden so we controlled all of it. People didn’t like that because they didn’t have control. We gave them control but with it came the clear cache. We had a short term version out before the reaodnly but we cleared the cache automatically. People who pre-generated lots of types accidentally locked and refreshed and it blew away their data and the asked for a read-only type of thing. I can understand that for sure. At the same time this made it crappier for those who want the caching short term. We came up with the SessionBitmapTileCahe for those kinds of things but it was not really put center stage and we didnt show anyone how to use it correctly. I think now that we have readonly caches we can do the Clear automatically one a refresh in multi threaded mode when the overlay is known to be dirty and on the single threaded mode as well.
On the second part with the number of lines of code it takes that is more complex for sure. If we remove the clear then we are down to six so that’s good. :-) Beyond that the Try/Finally is really recommended to ensure that if your code fails then the unlock happens. You can do away with those but at your peril I suppose. The idea that we hide the locking lower in the method is a bit optimistic and I think it has to do with the architecture. We expose all of our pieces and parts to the users and we allow people to extend them any way they see fit and we support a threading model where your events are against the real objects and not clones. Many other system for styles don’t even allow events or allow you to subclass the styles in any meaningful way. We have done allot of research on locking schemes and the best for large scale models like ours is to lock large objects in place. Locking at the method level usually results, in models like our, in endless errors. Case in point is that we allow people to extend our classes and if you add a method, property etc there is no way for us to control that at a lower level.
The simple scenario is using SingleThreading mode and there are no issues. We expected multi-threaded mode to be used by people familiar with multi threading and some of the issues around it like locking and unlocking. Our API has so many small pieces that are fully exposed to the developers that the locking in place with locks in methods would have been a nightmare. In my experience when you have systems that have mult-threaded drawing and not have any user locking they are of two varieties. The first is they use cloning extensivly as the clones are separate and there are no threading issues. I think we may want to support that as another option. You give up some power there as in your potential custom code you need to realize you are dealing with a clone. The other method is they are not extensible and you are dealing with objects that simple serialize their styles to a kind of XML, or Json etc to a drawing engine and then the drawing engine is really separate from the objects and when gets fed into the engine is really just some instructions on how to draw. You can still get into problems here but only when they are converting their objects to drawing instructions. This is the system many open source systems use. In our system you have all of the objects live and nestled inside of each other in a live object model and we expose a bunch of virtual methods to overload.
Having said all of that I am open to any way of doing it that is better than what we have. We have research this and it is what we found works best. I have many scenarios that need to be met with our system and they all need to be taken into account with threading. If anyone has a better way I would LOVE to talk with them. We are willing to do whatever it takes to get a better system. What I need is concrete methodologies and proven systems that work and can satisfy our object model and be easy to use for the client.
One other thing that I should throw in. Many times in methods people can do many updates to a layer etc for the expense in lines of code for the lock and unlock can be spread across all of the changes. So if you are going to do three things to the overlay then you only need one try and lock around all three. In many cases 90% of the users of mult threaded mode could go the cloned route and would never have a problem and you would not need to do locking at all at your level. We didn’t do it on the first pass as we thought it wasn’t good for people who heavily use events and for objects that may not be able to serialize. Anyway it is something we are looking at.
Thanks for the posts by the way, you gotta call it how you see it. Know though we are trying to work through these with the resources and time we have.
David
David,
let me give you my point of view.
I do not need multithread specificaly
I do not need tiling specificaly
I do not need preview tiling specificaly
The only thing I need is SPEED.
In other words, I do not care what’s behind the scene to get performance.
The approach you set up with the very first beta in spring was really fantastic; there were an automatic caching with an automatic preview system; this is exactly what we need.
If you cannot provide something simple and automatic; please provide some sample source to implement it as it was in beta1 (automatic cache & preview in multithread)
For your info, here are some measure on my end user computer to display 100,000 point features (with index):
MS2: 8 seconds
MS3 RC2 monothread without caching : 23 seconds
MapInfo: 4 seconds
What I would LOVE is to have MS3 at least as fast as MS2.
Regards
Patrick.
Patrick,
I think the performance of MapSuite3.0 is pretty much the same as MapSuite2.0, the attachment is the files which are the code for test case and create 100000 points feature shp file.
I test the map with 740*528 size, use single thread without caching and three different styles. The detail things you can look at the code. The following is the result:
Unit is second
PointStyles.City1
Simple style
Compound style
MapSuite2.0_3.0.357
12
3
15
MapSuite3.0_2.86.0
10
7
13
So I don’t know why your end user computer has so much different from MS2 to MS3. Can you verify the test result? And if you think my test data or environment is different, you can tell me your environment and send me your shp file. And then I can test like you.
Please let me know if you have questions.
Thanks.
James
1398-TestPerformance.zip (1.91 KB)
James,
you reach the same stats than me, using simple style point (What I do), M3 is 2,3 times slower than MS2
So please, give us easy to use caching/tiling system to work around this lack of performance.
Patrick.
Patrick,
I think we can do some work on that simple case. The other thing to consider is that MS 2.0 was designed solely around shape files. It was really tooled up to do those quickly but could do nothing else. I think there must be something else to explain the speed difference for simple point shapes.
We are working on the tiling stuff as well.
David
Patrick,
Just let you know, we’re investigating this performance issue, and MapSuite3.0 is much different from 2.0, so it need some time, I will let you know when we find the reason.
And we have fixed the tiling issue for ClearCache.
Thanks.
James