[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] UDig Rendering Performance
|
The "real" plugin that is the source of the render slow down is the
net.refractions.udig.tool.info plugin.
The reason I thought the WMS render is the problem is because the
net.refractions.udig.tool.info requires the WMS renderer plugin so when
I removed the WMS renderer plugin I also removed this info plugin. This
requirement doesn't make sense to me but that is another issue.
The info tool plugin causes rendering problems because it adds catalog
resolvers.
As a part of rendering each IGeoResource is "resolved" to something.
This resolving process uses the ResolveManager.java class. The
ResolveManager goes through all catalog resolvers and tries to resolve them.
The majority of the time is spent in the isTargetTypeSupported(...)
methods on this line (196):
Class< ? > resolvedClass = classLoader.loadClass(resolveType);
I think these are new resolveTypes added in the info plugin:
net.refractions.udig.catalog.document.IHotlinkSource
net.refractions.udig.catalog.document.IDocumentSource
net.refractions.udig.catalog.document.IAttachmentSource
If you comment out the first try/catch section of that function (which
is supposed to "optimize" the code), the performance improves.
So it seems to me there are a few solutions to this problem:
1) figure out why classLoader.loadClass() is so slow
2) remove the first try/catch "optimizer" section.
Thoughts?
On 27/08/2012 11:30 AM, Emily Gouge wrote:
Okay I spoke too soon - this helps a bit but does not seem to be the
actual source of the problem.
On 27/08/2012 10:43 AM, Emily Gouge wrote:
I've tracked this down with something to do with the WMS renderer. If
you remove the WMS plugins from the application rendering if fast again.
From looking at github it looks like some changes were made to the
BasicWMSMetricsFactory2 which I think may be causing the problem. I'll
see if I can pinpoint what here is causing the issue.
Emily
On 27/08/2012 12:36 AM, Jody Garnett wrote:
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.
Thinking more clearly; if they are only referenced when sorting - we
may have our smoking gun. After all they would need to be set somewhere
to be useful.
Jody
