Hi Greg,
Scale is not the proper differentiator when choosing if
LINETYPE_STRAIGHT can work for you instead of LINETYPE_GREATCIRCLE -
it depends more in the distance between points. When you really zoom
in on a coordinate that must be joined to a coordinate far away (earth-
wise), the direction of the connecting line from that point is
different depending on line type.
And that's why great circle lines take longer to project - the code
has to figure out where the line goes, and it does that by creating a
bunch of intermediate points between the end points that portray a
curved line. Calculating all of those points and then projecting them
takes the extra projection calculation time for those line types.
forwardGreatPoly is a known performance hog, consistently under
scrutiny and we're always open to suggestions for improving it.
Cheers,
Don
On Oct 27, 2009, at 1:37 PM, Greg Jewell wrote:
> I know it's been a while since we started talking about this, but I
> just discovered something that tremendously improved performance.
> For my lines and polys, I was setting the line type to be
> LINETYPE_GREATCIRCLE. On a hunch, I changed it to
> LINETYPE_STRAIGHT. The difference is amazing.
>
> While I know that there are a lot more calculations in the great
> circle line types, I would have never expected this type of
> improvement. Looking through the code, it appears that
> Poly.forwardGreatPoly(float[], int, boolean) is the ultimate source
> of the slowdowns. I don't know whether there is any way to improve
> the performance of this method, but it may be worth investigating
> for future releases.
>
> With that said, OMPoly defaults to LINETYPE_UNKNOWN if no line type
> is specified. In terms of rendering the polygon, it appears that
> this follows the same path as LINETYPE_STRAIGHT. Is there any kind
> of rule of thumb the map scale and line type? At large (zoomed out)
> scales, I would expect great circle to be more appropriate. At
> small scales (zoomed in), straight lines probably are sufficient.
>
>
> Thanks again,
> Greg
>
>
> On Fri, Sep 25, 2009 at 5:27 PM, Greg Jewell <greg17_at_jewell.net>
> wrote:
> Hi Don,
>
> The only layer that I am using is a single instance of a slightly
> modified (subclassed) OMGraphicHandlerLayer. I did try setting the
> Environment.doingXWindowsWorkaround flag because I saw it mentioned
> in the forums. I seem to remember having difficulty with it,
> though. I thought that the code wanted a Unix/Linux OS before it
> did any special processing based on the flag. I even tried to force
> use of OpenGL, but that actually caused other problems for me so I
> abandoned it.
>
> I will try the environment flag again on Monday. I may have been
> doing something silly before.
>
> Thanks for your help!
>
>
> Greg
>
>
> Don Dietrick wrote:
> Hi Greg,
>
> I've been playing around with this to see if I can reproduce the
> behavior you describe, and I think I've seen it in certain
> situations where there are OMGraphics being projected in pixel space
> very far away from the window space. I haven't had a chance to
> really take a look at it yet past that.
>
> Do you notice if it occurs when certain layers are being used?
>
> There is an Environment flag that might help, setting
> Environment.doingXWindowsWorkaround == true, if that's not already
> being set.
>
> - Don
>
> On Sep 14, 2009, at 10:55 AM, Greg Jewell wrote:
>
> Hi All,
>
> I'm experiencing very significant slowdowns in rendering when zoomed
> into the map at a scale of 1:100,000 or closer. The closer I get,
> the slower the rendering becomes. I've searched the archives for
> similar problems, and discovered a few people mention it. However,
> the only things that I've seen all say that it's probably a Windows
> clipping issue. Is there any more detail to this, or can somebody
> point me in a direction to resolve the problem?
>
> Possibly pertinent information:
>
> Windows XP SP2 with 3 GB RAM
> OpenMap 4.6.4
> It appears that this is related to OMLine, OMPoly, etc., and not to
> OMRaster-based graphics.
>
>
> Thanks,
> Greg Jewell
>
>
>
>
>
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Tue Oct 27 2009 - 14:03:01 EDT