Hi Brian,
This isn't a bug, it's the cost of doing business. Layers only expect
to be rendered into the last projection they receive, so if the layer
is attached to a MapBean and you call renderDataForProjection() on it
with a different projection than the MapBean has, you need to reset the
projection on the Layer and regenerate the OMGraphics on the layer for
that projection. The easiest thing to do might be to reset the
projection on the MapBean, and let the layers reset themselves
normally, regenerating their OMGraphics to the MapBean's projection
before paint() gets called on them.
Removing the setProjection() line in that method would result in
unexpected behavior for layers. It breaks the projection-rendering
'contract' that layers are under. While some layers would handle it
OK, others would not.
- Don
On Sep 24, 2004, at 3:35 PM, Sperlongano Brian M NPRI wrote:
> Hello all,
>
> I believe I have found a bug in the way layer rendering is
> implemented. I was using the ImageServer class to generate off-screen
> images for printing, and what I discovered was that the way
> ImageServer works is to call the renderDataForProjection() method on
> each of a set of layers onto a Graphics object.
>
> One of the things that these implementations do (at least for
> OMGraphicHandlerLayer and GraticuleLayer, probably all of them) is to
> set the passed in projection as the new projection.
>
> As an example of this, here is a clip from OMGraphicHandlerLayer:
>
> public synchronized void renderDataForProjection(Projection proj,
> Graphics g) {
> if (proj == null) {
> Debug.error("Layer(" + getName() +
> ").renderDataForProjection: null projection!");
> return;
> } else if (!proj.equals(getProjection())) {
> setProjection(proj.makeClone());
> setList(prepare());
> }
> paint(g);
> }
>
> Note the line that says "setProjection(proj.makeClone())".
>
> Now, if were were only using the layers on a MapBean, this would be
> fine. The problem comes when we use existing layers to render to
> projections other than the ones on the current map. Thus, say I have
> a 200x200 MapBean, but I wish to (off-screen) render a 400x400 version
> of the same map. I would create a Projection object with those
> parameters, and then pass it through renderDataForProjection. The
> Layer would then render my 400x400 map no problem. However, it would
> also store my 400x400 projection as the current projection. This
> results in display artifacts being shown in the container containing
> the MapBean.
>
> It seems to me that the offending setProjection() lines should be
> removed. I commented out those lines in the layers I use and the bug
> seems to go away AND the map seemed to function all the same.
>
> The other option would be to make sure that any class that used Layer
> in this manner (such as ImageServer) be modified to save the current
> Projection, render, and the set the old projection back, but this is
> clearly a less-desireable solution.
>
> -Brian
>
> Brian Sperlongano
> Computer Engineer
> NUWCDIVNPT
>
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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 Fri Sep 24 2004 - 16:44:43 EDT