HI Michael,
On Oct 8, 2005, at 3:57 AM, Dr. Michael Paus wrote:
>> <snip>
>>
>>> - 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.
I meant this in a general sense, too. When it comes to the
Layer.paint() method, the only thing expected of layers is when that
method is called, they render what they know for the last projection
they have received. They can draw partial solutions if they can, but
they are expected to get themselves updated when they can with a
repaint() call.
We've tried to capture then moment that you're after, that moment
when all layers are ready - this was during the early work for
creating images - but the various natures of Layers makes knowing
when this moment occurs inconsistent. The reason for that varied
(which was part of the problem), but if you have layers that use
timers, or automatically update themselves when they receive new
information, this paradigm breaks. This might be easier for your
specific situation, since you say your layers don't update themselves.
>> 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?
Right - the flickering occurs when faster layers, usually with much
less to draw, call for a repaint before the 'background' layers are
ready. The MapBean doesn't clear out the map when the projection
changes - the clearing occurs when one of the layers is ready.
OMGraphicHandlerLayers also have ProjectionChangePolicy objects -
which dictate how they respond to projection changes. You might want
to test the effect of creating/using one that does not allow a layer
to call for a repaint on a projection change if the response time is
too quick - but then you'd have to know that another layer would be
available to make the repaint() call, or the map would never update.
>>> - 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?
The Layer API isn't set up to enable a query on a layer that asks
that question, and even OMGraphicHandlerLayers only know that
OMGraphics are being used to render stuff on the map. The area those
OMGraphics cover, and the opacity of those OMGraphics, are a mystery
to the layer. Each OMGraphic knows where and how it's going to draw
on the map. As far as the layer goes, they really could care less
what those parameters are, and that's by design.
You could certainly write code that did the bookkeeping for those
parameters, but that's not a general question you can ask a Layer.
I don't mean to sound like I'm stomping on your requirements, I'm
just trying to give you an idea of the background to the roadblocks
in the way. But a lot of these roadblocks where faced before policy
objects were used by the MapBean and Layers, and there might be a way
to create some of those policy objects that work together to get the
effect you want without touching layer/MapBean code.
- 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 - 09:01:53 EDT