Re: [OpenMap Users] Slow rendering when zoomed in

From: Greg Jewell <greg17_at_jewell.net>
Date: Tue, 27 Oct 2009 14:42:46 -0400

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 - 14:44:56 EDT

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:09 EDT