First of all, many thanks for the detailed reply.
Don Dietrick wrote:
> Hi Michael,
>
> On Oct 7, 2005, at 6:35 AM, Dr. Michael Paus wrote:
>
>> Hi all,
>>
>> I am currently struggeling with an OpenMap application with lots of
>> layers
>> which shows a very bad overall performance in the sense that after a
>> projection change all layers are repainted but in such an uncoordinated
>> way that many layers have to be painted several times until the
>> application fianlly comes to a rest. I have seen complaints about this
>> effect from other users before but I still have not found any solution
>> proposal.
>
>
> What kind of layers are you using, and how many OMGraphics are being
> drawn on them. Any information about their behavior, in terms of how
> much work they need to do to react to projection changes? Do you know
> if any of your layers are doing work in their paint() method, other
> than just rendering their map objects?
We use lots of different layers. Most of them show raster maps and different
symbology on top of the maps. I do not yet know all the details but I think
the paint() methods do more or less only painting.
>> I would like to do some of the following things:
>
>
> Just as a general observation, you could achieve these goals by
> modifying the MapBean's MapBeanRepaintPolicy object. The
> StandardMapBeanRepaintPolicy just forwards Layer.repaint() requests on
> to the Swing queue. You can substitute a different policy in the
> MapBean if you like.
I think I will have to have another look at this. On the first glance
I was not sure of how this is supposed to work.
> There are a couple of caveats with your requirements below:
>
>> - Do not redraw until all layers are ready with their prepare().
>
>
> There is no contract that guarantees that a Layer will have a prepare ()
> method. The () method is an OMGraphicHandlerMethod, so you should
> make sure all of your layers have one before you assume that it is there.
That's right but I thought of this in a more general sense and did not
assume that the layer explicitly has a method named prepare(). I just
meant that each layer will probably have to prepare the next repaint
in some way after a projection change and I would like to be able to
find out when it will be ready again to be re-painted.
> Also, there is no contract that binds a Layer to only call repaint()
> when it's ready to react to a projection change. Layers are free to
> call repaint() on themselves when they feel that they have updates on
> the map. This may not apply to your layers.
Again right. But although my maps don't change between projection changes
I still see this flickering which I would like to avoid.
>> - Paint all layers in the correct order so that no layer has to be
>> painted twice.
>
>
> Using a BufferedImageRenderPolicy on an OMGraphicHandlerLayer will
> cause it to paint it's OMGraphics in a buffer, making repaints faster.
> You can set the repaint policy in the properties for a layer.
It just makes the flickering faster but it does not avoid it, right?
>> - Do some more optimizations, e.g. if a raster layer covers the whole
>> window
>> there is no point in preparing and painting any layer below it.
>
>
> There's no real way to ask a Layer if it's a raster layer, in a general
> sense, and there's not really a way to ask it if it covers all layers
> below it. There could be transparency issues that may make this a
> difficult condition to measure in a general way.
Why? The layer itself should be able to find out whether it paints the
whole window or not and if it does, set the opaque flag. Isn't that general
enough or am I missing something here?
> You could write some
> layers that work with the MapBeanRepaintPolicy to handle these
> optimizations for you.
>
> Hope this helps,
>
> Don
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Don Dietrick, dietrick_at_bbn.com
> BBN Technologies, Cambridge, MA
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
>
--
[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 Oct 08 2005 - 03:58:34 EDT