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 - 13:40:00 EDT