Hi Johann; I got your message about wanting to meet on IRC - I am afraid I was very asleep.
Johann Sorel wrote: > You're right that's how it works ... for the streaming renderer. And > this is stateless renderer that doesnt store the link : > Feature <> Symbolizers > > Our statefull renderer creates a graphic object for each feature. And > this object has a list of symbolizers. > This mean when a feature change there is only one unique graphic to > repaint. So this is my question; what do you do when the Rule changes? But yes I understand the concept of Graphic = Java Shape + Feature + Styling. And agree that no matter what we need Symbolizer to be immutable for this solution to be happy. Since we missed each other on IRC I am going to have to assume that when a Rule changes (or a FeatureType style changes) you will regenerate the list of assigned symbolizers? > If featuretypeStyle and rules are mutable. I just have to listen to > the changes and fix the list of symbolizers of each graphic object. Ah cool - yeah I guessed right. > So what do we call a method like that? > - FeatureTypeStyle.copyBeforeUse(); // very obvious; return a copy > before use > - FeatureTypeStyle.toPrepairedStyle(); // returns a copy of the > provided Style; implementations may optimize > - do you have any ideas? > could you come on IRC ? I would like to talk about this. Yeah I was just trying to really make it obvious that the FeatureType style information is not safe to use in the middle of a loop (even when you are making your stateless renderer it is not safe to loop through the Features assigning groups of Symbolizers - you will need to copy the FeatureType style before you go). Since this is a subtle point (as is all thread-safety issues) I would like to make a method to a) help fix the problem and b) help communicate that there is a problem. Martin has a similar method in his MetadataObjects called freeze? Imagine this is something different that creates a copy. The good news is that this method can also perform a few simplifications (evaluate expressions that are made of literals; that sort of thing...). I think that is a *very* good idea. I can think of lots of nice optimizations to do at this stage... So here is the proposal: 1. Symbolizer is immutable; if you want to change something do so as you make a copy; look at StyleVisistor based examples. 2. FeatureTypeStyle / Rule / List<Symbolizer> are all mutable (note you will need to make a custom List that sends events) and send events. 3. Before you use FeatureTypeStyle / Rule / List<Symbolizer> you should call the "toPrepairedStyle()" method. The method starts with *to* indicating that this is creating a separate object; the javadocs say that some optimizations can occure but we do not implement anything crazy like that for the first cut (wait until the profiler shows it is useful). Thanks for the discussion on this one Johann; we have arrived at (well you have arrived at) a great balance that will perform well and be accessible to people writing style editors. Back to the proposal so I can vote: - Jira number? We should be collecting comments on this as we go; I have created it for you here: http://jira.codehaus.org/browse/GEOT-1870 (there was no 2.6 tag so I needed to make one!) - add/remove listener for FeatureTypeStyle / Rule (so the user interface can be made); this should be added to the GeoAPI interfaces should it not? - FeatureTypeStyle.toPrepairedStyle() - Link to the javadocs are fine; you focused on a few new methods; I will do a quick BEFORE / AFTER section showing how we intend to update the existing code to implement the new interfaces > Remember I only have 2weeks left, sending mails and waiting for > answers is too slow. Good thing we are sending emails at all hours of the day and night. I am going to have a *break* tomorrow afternoon - my customer has a meeting or something from 3 until 5. I think we have made the decision here; but we can get together on Skype (do you have that?) or IRC (if I can get out of the firewall) if you have any more questions. Jody ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
