Slow rendering when zoomed in

[Greg Jewell-2]

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

[Don Dietrick]

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@..."
with the following text in the BODY of the message "unsubscribe openmap-users"]

[Greg Jewell-2]

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@..."
with the following text in the BODY of the message "unsubscribe openmap-users"]

[Greg Jewell-2]

I tried re-adding the Environment parameter this morning.  It does seem to help, but performance is still much slower the closer somebody zooms in.

On Fri, Sep 25, 2009 at 5:27 PM, Greg Jewell <greg17@...> 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

[Greg Jewell-2]

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@...> 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

[Don Dietrick]

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@...>  
> 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@..."
with the following text in the BODY of the message "unsubscribe openmap-users"]

[Greg Jewell-2]

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@...> 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@...> 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

[Moe Zakeri]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Don,

 

I need to pass my array of parameters directly to openmap and to display new locations periodically - for example every 5 seconds instead of writing my parameters to the CVS file, set it in the properties file, and reloading the properties file manually. Where is the shortcut to do this in the API?

 

I see that createLocation is responsible to make new locations.  Is this where I have to send my array of parameters to?

protected Location createLocation(float lat, float lon, java.lang.String name, java.lang.String iconURL)

 

Also in LocationLayer, reloadData() can reload my locations periodically when calling doPrepare(), am I right?

 

 

Thank you,

 

Moe

 

[Don Dietrick]

Hi Moe,

Sorry for the delay in getting back to you on this.  You can use a  
TimerLocationLayer instead of LocationLayer that has a timer build  
in.  It will reload the data at the interval you specify:

 From the javadocs:

/**
  * The TimerLocationLayer is a LocationLayer that has a timer to
  * automatically relod data at specified interval.
  *
  * The properties for this layer are the same as a LocationLayer, with
  * the addition of two:
  * <P>
  *
  * <pre>
  *
  *  # Specify the interval (milliseconds) for the timer. Default is  
10 seconds.
  *  layer.updateTimerInterval=10000
  *  # Auto-start/stop the timer when the layer is part of the Default
  *  # is true.  There is a control to start/stop the timer on the
  *  # palette.
  *  layer.automaticTimer=true;
  *
  * </pre>
  */

Hope this helps,

Don

On Oct 27, 2009, at 3:07 PM, Moe Zakeri wrote:

> Hi Don,
>
> I need to pass my array of parameters directly to openmap and to  
> display new locations periodically - for example every 5 seconds  
> instead of writing my parameters to the CVS file, set it in the  
> properties file, and reloading the properties file manually. Where  
> is the shortcut to do this in the API?
>
> I see that createLocation is responsible to make new locations.  Is  
> this where I have to send my array of parameters to?
> protected Location createLocation(float lat, float lon,  
> java.lang.String name, java.lang.String iconURL)
>
> Also in LocationLayer, reloadData() can reload my locations  
> periodically when calling doPrepare(), am I right?
>
>
> Thank you,
>
> Moe
>

--
[To unsubscribe to this list send an email to "majdart@..."
with the following text in the BODY of the message "unsubscribe openmap-users"]

[Don Dietrick]

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@...>  
> 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@...>  
> 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@..."
with the following text in the BODY of the message "unsubscribe openmap-users"]