Re: Expensive OMGraphicHandlerLayer.repaint();

Thanks for the suggestions, George. I wanted to add info about
something I've been playing around with.

I've recently created a BufferedLayer, which has its own internal
BufferedMapBean and is able to add other layers to it. This has a
benefit of providing a buffered image representing a group of layers,
but since it's internally still based on Swing components, the
sub-layers update the BufferedLayer's image when they are ready, so
they appear to act normally - you can't tell that they are grouped
together.

Secondly, I created a new BufferedLayerMapBean extending the
BufferedMapBean which has a BufferedLayer inside it, and added a
property to Layer to let it be designated as a 'background' layer.
When Layers get added to this BufferedLayerMapBean, all Layers
designated as background layers get added to the internal BufferedLayer
automatically and dynamically. I also modified the
BufferedLayerMapBean to fire it's layer property changes with all of
the real layers, so you don't know which layers are part of the
BufferedLayer (for the status lights, etc). I had to create the
BufferedLayerMapBean to avoid a cyclical MapBean creation (via the
BufferedLayer), and BufferedLayerMapBean is what is used in the
application.

The problem I still need to attack is the management part of the layers
in the LayersPanel. I added a check box for each Layer to make it a
background layer, but then you end up with maps that don't reflect the
layer order in the LayersPanel and LayersMenu, since background layers
get diverted to the bottom. The status lights do end up being accurate
showing the actual location of the layers. I think the
BufferedLayerMapBean needs to have a LayersPanel that can visually
control the background layer grouping, and I have some ideas about that.

The improvement in performance is remarkable.

On a 770x530 pixel map,

1 moving sprite at 19 Hz
21 at 16 Hz
50 at 12 Hz
100 at 8.5 Hz
160 at 6 Hz

with one layer (PluginLayer being driven by a GraphicLoader forcing a
location recalcuation/repaint every .001 seconds) drawning the sprites
and other layers in the background layer (number and content type
doesn't matter, since they are buffered into an image). You can make
those numbers dip a little if you do mouse movements over the map,
causing the NavMouseMode to butt in on calculations of cursor location.
Also, this is on a 400Mhz Apple Ti PowerBook.

More polishing needs to be done to the components and their APIs before
this stuff can be put into the OpenMap release. The bad news is that
this stuff is all unfunded, and we're busy on a different OpenMap
project, so no time is being set aside for this in September. We would
like to make a 4.5.4 bug fix release in the next week or so, with
thanks to everyone who mailed in reports and fixes. This other stuff
is about a week old, though, so it probably won't be included.

Cheers,

Don

On Thursday, September 5, 2002, at 01:52 PM, George Uecker wrote:

> Hi Sunny,
>
> I have a similar application that repaints a number of layers at 8 Hz
> on a 500 MHz Intel x86 PC and it works OK. I use several techniques
> to optimize performance:
>
> 1. Since I have multiple dynamic layers, I included another invisible
> layer whose main job is to synchronize repaints for the other layers.
> This minimizes the number of calls to repaint().
>
> 2. My application is a radar display, and since the radar sweep is
> only active in one area of the screen at a given time, I use clipping
> areas to minimize the portion of the screen that has to be repainted.
> You can do this using repaint( x1, y1, x2, y2 ) instead of plain old
> repaint().
>
> 3. Make sure you are using the BufferedMapBean instead of the plain
> MapBean. BufferedMapBean forces layers to draw their graphics into an
> image buffer that gets blitted to the screen all at once when the AWT
> does the next redraw.
>
> 4. If you have a lot of dynamic objects, you might consider using an
> OMPoly for your triangles instead of an OMBitMap, but I don't know
> exactly how much difference that would make - just a suggestion.
>
> 5. Make sure that you only call generate() on your OMGraphics A.) when
> they are created and B.) when the projection changes. If you have
> lots of OMGraphics and you call generate() every time you call
> render(), it really slows things down, and it's unnecessary.
>
> You can take all of this with a grain of salt since I don't use the
> OMGraphicHandlerLayer and I don't know anything about it.
>
> You could also try running your app on a Windows PC to see how it
> performs on different hardware running a different Java VM.
>
> I also recommend that you download a trial version of OptimizeIt
> <http://www.borland.com/optimizeit/> and profile your application for
> performance bottlenecks. It's a great tool.
>
> Hope this helps,
>
> George
>
>
> Shih-Hung Lin wrote:
>
>> I finally have my application up and running. I appreciate Don's
>> hint to make my
>> work easy. I, however, couldn't tune up the performance. The real
>> time back end,
>> a propitiatory legacy system written in C, provides a set of data
>> through a socket
>> every 200 ms in my current design. In other words, my application
>> need to update
>> the layer at the rate of 5 Hz to provide satisfactory smooth
>> movement. In two
>> simple case experiments, a dynamic object moving around and none at
>> all, the
>> method OMGraphicHandlerLayer.repaint() consumes almost all CPU time
>> (I have a Sun
>> workstation running at 450 MHz). Did I do anything wrong? Or, is
>> that the nature
>> of repaint()?
>>
>> This is my current setup. The layer is a subclass of
>> OMGraphicHandlerLayer. I
>> use a triangle (OMBitmap) with a label (OMText) to represent the
>> location and
>> direction for each dynamic object. These two were stored in an
>> OMGraphicList.
>> Repaint() is called in every 200 ms to update the layer. Is there
>> any more
>> efficient way to achieve the same goal?
>>
>> -Sunny
>>
>> Don Dietrick wrote:
>>
>>> Hi Sunny,
>>>
>>> You have a number of options here, and most of them involve getting
>>> access to the MapHandler. Once you have the MapHandler, you can
>>> pretty
>>> much get to any component.
>>>
>>> Using the MapHandler, you can location the LayerHandler, get it's
>>> layers, and iterate through them to find your layer.
>>>
>>> Alternatively, the Layer class has a property, addToBeanContext, that
>>> is false by default (layers are isolated from the MapHandler by
>>> default). If you set that to true in the properties file, the layer
>>> will be added directly to the MapHandler, and you can iterate through
>>> the MapHandler objects to find your layer.
>>>
>>> You could have your back-end create the layer and add it to the
>>> MapHandler, where the LayerHandler will pick it up to add it to the
>>> map
>>> (if it's visible). You wouldn't need to define layer properties for
>>> it
>>> at all in that case.
>>>
>>> Lastly, with the next version of OpenMap due out shortly, the
>>> com.bbn.openmap.plugin.graphicLoader.GraphicLoader interface has been
>>> formally defined as an object that provides OMGraphics on it's own
>>> schedule (the graphicLoader package and pilot package have been
>>> adjusted accordingly). If a GraphicLoader (which is what your
>>> back-end
>>> basically is) gets added to the MapHandler (say, by defining it in
>>> the
>>> openmap.components property or whatever), the LayerHandler has been
>>> updated to create a GraphicLoaderPlugIn/PlugInLayer combination to
>>> display its graphics.
>>>
>>> Hope this helps,
>>>
>>> Don
>>>
>>> On Wednesday, September 4, 2002, at 11:28 AM, Shih-Hung Lin wrote:
>>>
>>>> Hi, Group,
>>>>
>>>> I am new to OpenMap development and wish someone here would help me
>>>> with some basics. I am currently working on a new layer with
>>>> dynamic
>>>> objects which reflects the state of a real-time back end. So far I
>>>> have those objects static displayed on the layer. I use
>>>> "openmap.properties" as following to define the layer and it show up
>>>> as I expected.
>>>>
>>>> openmap.layers=..... dynamic .....
>>>> :
>>>> :
>>>> dynamic.class=com.xyz.layer.DynamicLayer
>>>> dynamic.prettyName=Dynamic Objects
>>>> :
>>>>
>>>> In order to move them, I need to grab a reference to the layer. I
>>>> wonder if there is a standard way to get references to individual
>>>> layers defined in property file.
>>>>
>>>> -Sunny
>>>>
>>>>
>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>> Don Dietrick, BBN Technologies, dietrick@bbn.com
>>> 10 Moulton Street, Cambridge, MA 02138
>>> 617-873-3031 [fax]-2794
>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> --
>>> [To unsubscribe to this list send an email to "majdart@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@bbn.com"
>> with the following text in the BODY of the message "unsubscribe
>> openmap-users"]
>>
>> .
>>
>
>
> --
> George Uecker george.uecker@dot21rts.com
> Software Engineer (410) 480-7236
> Dot21 Real-Time Systems Inc. (410) 313-7515 fax
>
>
>
>
> --
> [To unsubscribe to this list send an email to "majdart@bbn.com"
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]
>
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, BBN Technologies, dietrick@bbn.com
10 Moulton Street, Cambridge, MA 02138
617-873-3031 [fax]-2794
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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