Hi Ruben,
The ListResetPCPolicy just takes the current OMGraphicList set on the
layer and generates it, and calls repaint on the layer, then the paint
method will get all of the OMGraphics on that list and paint them, no
matter where they are (on or off the viewable area of the map).
Basing your filtering on pixel positioning is a mistake if you want to
save CPU cycles, for the simple reason that you have to generate an
object to find out where its pixel position is. It's faster to do
your filtering based on the lat/lon position of each object - you know
what the lat/lon bounds are for the viewable map, it's better to use
the lat/lon values of your points to determine if the points should be
generated. If you organize your points in groups that represent
general areas, you can do one check for the group to determine if
those points should be generated and painted - you don't have to check
every point if you use OMGraphicLists for grouping like this - the
OMGraphicList, like any OMGraphic, has an attribute table that you can
use to hold a bounding box object to use for this check.
There are a lot of ways you can organize your points - you can create
your own OMGraphicList structure, like above, where the lists are
modified/extended so they figure out if their contents should be
generated and rendered. You can use the QuadTree class to organize
your points, and ask it for points within a bounding box. You can
also use the SpatialIndex code in the com.bbn.openmap.geo package.
The benefit of using OMGraphicLists is that you can also extend them
to override the render method if the scale becomes small enough
(zoomed out) that all of the objects are moving to one point. Then,
that OMGraphicList can be smart enough to draw one symbol at that one
general location, instead of rendering all of it's children at the
same location. That saves on generating and rendering times.
Regarding your first paragraph when you state that you only draw
objects that have moved pixel-wise, I don't know how well that will
work in the long term. In general, you always want the Layer.paint()
method to render all of your OMGraphics for the current projection.
Drawing a moving object requires that you redraw the lower layers and
then draw the moving object at its new location. You should be
rendering moving and unmoving objects, since the background layer
paints will cover up all objects, whether they are moving or not. The
trick is making that list as small as possible, and having each object
require as little work as possible to render it.
Hope this helps,
Don
On Wed, Sep 21, 2011 at 8:14 AM, Ruben DF <rdocasalf_at_gmail.com> wrote:
> Hi all,
>
> Don, after some months, I came back to the project and implemented the ideas
> you suggested me. To improve the performance I'm only generating and drawing
> the objects which pixels position have changed, instead of checking lat/lon
> position. I've also coded a new BufferedRenderTrace class where I'm only
> generating and writing the new points as soon as they are received while I
> draw a buffer with the old points. This let me to draw a huge amount of
> points with no performance rendering in a non-movement map way. Now, the
> problem appears when a zoom or pan is done, where points must be generated
> and rendered. This causes latences and delays problems, increasing the cpu
> usage (specially java process).
>
> I was trying to use ListResetPCPolicy since I thought the list would be
> reset and it would take automatically the points that I can see on the map.
> However it does not work because points are not appeared on the screen (even
> with no "projection changed" event)....and i don't know how do it. Is there
> any way to catch the points from a OMGraphicList that are showed in a
> specific moment in the map? thus I'd only generate and render those points
> instead all of them. I know the points must be always on the OMGraphicList,
> but I only want to generate and render those points that appears in the
> screen of the map when I zoom or pan it..
>
> Thanks in advance!
>
> 2011/6/6 Don Dietrick <dfdietrick_at_gmail.com>
>>
>> Hi Ruben,
>>
>> On Mon, Jun 6, 2011 at 12:39 PM, Ruben DF <rdocasalf_at_gmail.com> wrote:
>> > Hi Don,
>> >
>> > 2011/5/23 Don Dietrick <dfdietrick_at_gmail.com>
>>
>> >> You might want to check to see if the map
>> >> location of your objects have changed before deciding to repaint,
>> >> instead of checking whether the objects have moved geospatially.
>> >
>> > I'm afraid I don't understand this...what is the difference between
>> > checking
>> > whether the objets have moved geospatially or checking whether have
>> > changed
>> > their map location??
>>
>> Map pixels cover a certain amount of area, so lat/lons that are
>> projected onto the map may be resolved to the same pixel. It's
>> possible, depending on the map scale, where objects are moving (their
>> lat/lons change) but their pixel position on the map doesn't change.
>> If that's the case, you don't have to redraw the map.
>>
>>
>> >> If
>> >> you are changing how things look (vibrating map objects to highlight
>> >> them, changing their color, etc), I can understand why you would want
>> >> the update rate to be something higher. In that case, you might want
>> >> to buffer several maps together with different rendering parameters,
>> >> and then loop that set.
>> >
>> > I think the problem is on a layer which contains the trace of the
>> > plains,
>> > i.e, contains a set of OMPoints which is growing each second (36 points
>> > are
>> > created per second, so after 10 minutes, there are more than 20000
>> > points
>> > and cpu is collapsed). I generate only the 36 new points which are
>> > created
>> > per second, but I have a problem on the render method, since I need to
>> > render all of them if I want to see them on the map...is it possible to
>> > make
>> > a layer and set Background as true and only render the last point? If
>> > backgroud is true there are no movement (only when zoom or pan since
>> > projectionchanged() is called) and right now I must render all the
>> > points to
>> > see them on the map...
>>
>> I don't think I'd mess with the Background setting of the layer, since
>> that drops the layer below any other layer not marked as a background
>> layer. You could do something similar - by writing a new RenderPolicy
>> similar to the BufferedImageRenderPolicy, or by managing a
>> BufferedImage in your layer and drawing old points into that, and then
>> just draw that image.
>>
>> You don't have to generate older points/OMGraphics if the map doesn't
>> change and their position doesn't change. If the zoom level, window
>> size or position of the map changes, you'll have to generate all the
>> points and you'll lose any image buffering savings for one render
>> cycle. But if you are watching a non-moving map, drawing the latest
>> points into an image buffer and simply rendering that buffer should
>> work well.
>>
>> - Don
>>
>> >
>> >>
>> >> - Don
>> >>
>> >> On Mon, May 23, 2011 at 7:25 AM, Jesper Berglund
>> >> <jesper.berglund_at_pertexo.se> wrote:
>> >> > Has the map changed during the 40ms, like panning or zooming?
>> >> > Is there objects on the map which has changed?
>> >> >
>> >> > Don't repaint all layers, only those who might have changed.
>> >> >
>> >> > Repaint only on changes of data.
>> >> >
>> >> > If there is a burst of events, coalesce during a timeperiod and then
>> >> > repaint
>> >> > using javax.swing.Timer .
>> >> >
>> >> > These are the measures that I have made in my Openmap app.
>> >> >
>> >> > HTH
>> >> >
>> >> > /Jesper
>> >> >
>> >> > Ruben DF skrev 2011-05-23 11:30:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I'm afraid I cannot repaint each 500 ms or longer...it's a
>> >> >> customer's
>> >> >> requirement... :(
>> >> >>
>> >> >> Thanks anyway!
>> >> >
>> >> > --
>> >> > [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"]
>> >> >
>> >
>> >
>
>
--
[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 Sat Sep 24 2011 - 16:02:50 EDT