> > I have a thought Emily; the "last" renderer was sometimes stored in > > the layer properties; it always messed up the training course where > > you swap between renderers. > > > > Could you check (in a debugger) if it is still being stored (i.e. for > > speed) or if uDig is training to determine renderers again each > > time. > > > > > Thanks Jody - > > Do you know when/where the layer properties were set? (Or perhaps you > can point me to the commit log for this change). > >
Let me find the "key" that was used to store the previous value. Then we can see where it is used. The "magic" override that keeps getting in the way (and is apparently responsible for performance): - RendererCreator.PREFERRED_RENDERER_ID - ProjectBlackboardConstants.MAP__PREFERRED_RENDERER (copy of above) - ProjectBlackboardConstants.LAYER__PREFERRED_RENDERER (copy of above) Related: - RendererCreator.LAST_RESORT_RENDERER_ID - ProjectBlackboardConstants.MAP__LAST_RESORT_RENDERER - ProjectBlackboardConstants.LAYER__LAST_RESORT_RENDERER It looks like these are only being used when sorting the available renderers; so not quite the smoking gun I was looking for. > From what I can tell uDig is trying to determine which renderers to use > each time it re-draws the map. Every time the map is drawn it calls > this line from RendererCreatorImpl (line 225): > Collections.sort(layerfactories, new RenderMetricsSorter(layers)); > > Okay so it sounds like we both have the same idea (and checking the render metrics can be expensive as they need to look at the style blackboard to see what is going on). > I believe this is the slow part. I will try to get a profiler installed and > confirm this is the case. > > Do you see the same performance issues when rendering maps in your version? > To me, this is a pretty big deal and makes the application almost > non-useable, especially if I have multiple layers. I want to ensure that it > is not some weird or incorrect configuration I have. I have been very focused on getting a release out and have not kept an eye out for any regressions in performance. Jesse also had some performance optimisation work that was expected to land for this release. Another thing you can keep an eye out for when profiling (i.e. change since January) was an update to the EMF model (to support the creation of a legend). We took a couple runs at this; and while the current solutions should not overlap with the list of layers used for rendering; there is a chance that it has caused more notification events to be sent out. Jody
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
