Hi Gregg,
Its a good question, and we've taken a look at that. You actually
have to consider all of the points off screen, because they might be
connected by great circle lines that intersect the map window, it's
hard to know for the general case. Then, suppose you just take out
those points that are off screen and are connected by off screen lines
- you have to make sure that the line you insert to replace those
points and reconnect the polygon doesn't cut across the map window,
creating a hole at the corner or something. There are a lot of
special cases.
- Don
On Oct 27, 2009, at 2:42 PM, Greg Jewell wrote:
> Hi Don,
>
> Thanks for the clarification. I realized after I hit send that I
> neglected to mention that of course this would also be dependent on
> the length of individual lines, and not just the scale. I also
> realized that the method is Proj.forwardGreatPoly(), and not
> Poly.forwardGreatPoly(). :)
>
> I haven't looked closely at the method, so forgive me if this is
> already being considered, or if it's not even possible. Since the
> performance slows down as things are zoomed in, is it possible to
> streamline the algorithm so that it doesn't consider most of the
> points that aren't currently displayable? For example, if points 1
> - 5 are not visible, could only points 1 and 5 be considered before
> calculating points 6 through whatever?
>
>
> Thanks,
> Greg
>
>
> On Tue, Oct 27, 2009 at 2:01 PM, Don Dietrick <dietrick_at_bbn.com>
> wrote:
> 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 - 15:34:26 EDT