RE: [OpenMap Users] How to use the BufferedMapBean

From: Tim Schreiner <tjs_at_ll.mit.edu>
Date: Thu, 27 Sep 2007 10:00:28 -0400

Ben,

 

Sounds like a lot of work to implement the approach you speak of.

 

I'm surprised that the BufferedMapBean does not do what its name implies out
of the box.

 

Thank you for your ideas!

 

 

Tim
  _____


From: Ben Weisburd [mailto:benw_at_ll.mit.edu]
Sent: Wednesday, September 26, 2007 5:45 PM
To: Tim Schreiner
Cc: openmap-users_at_bbn.com
Subject: Re: [OpenMap Users] How to use the BufferedMapBean

 

Hi Tim,

I'm currently working on a display that does mouse dragging with multiple
layers. The solution for us was to extend BufferedMapBean and
ProjectionSupport and change how the projectionChanged() events get
propagated. We had to go against the OpenMap paradigm of having each layer
repaint itself independently, and instead made the map repaint once after
all layers finished processing the event. To do this, we made our layers not
call repaint() at the end of their projectionChanged() method. Also, we
extended ProjectionSupport and made it do

mapBean.setBufferDirty(true)
mapBean.repaint()

after it finished notifying all the layers. (This worked because none of our
layers start separate threads when handling projectionChanged(), and because
we made ProjectionSupport use a single background thread rather than
creating new ones).
I think this approach could be useful when layers generate their graphics
quickly and need to do animation, dragging, etc. There might be a simpler
solution though.

I haven't tried converting the ShapeLayer to this approach, but some of our
layers extend OMGraphicHandler and override its projectionChanged() method
so:

  public void projectionChanged( ProjectionEvent e ) {
    setProjection( e );
    setList( prepare() );
  }

Hope this helps,
-Ben


Ps. The reason we decided to go this route, was that, even though
BufferedMapBean provides an image buffer, a layer calling repaint() on
itself causes the buffer to be invalidated/regenerated. And lets say you had
3 layers on the map. Each projectionChanged() event would result in a total
of 3 calls to repaint(), and each repaint() would cause all 3 layers to be
repainted. Also, if any of the layers started their own threads, then one
layer might finish and call repaint() while another layer is in the middle
of generating its graphics, resulting in the unfinished layer painting
nothing for that repaint(). Even if you had only one layer, I'm pretty sure
the flicker could still occur during dragging because a lot of
projectionChanged() events would be generated and the ProjectionSupport
threads and the AWT event thread could interrupt each other in unexpected
ways (eg. a repaint() would occur in the middle of a projectionChanged()
event being handled).


Tim Schreiner wrote:

Hello,
 
I've got a .shp file layer in my OpenMap application and have replaced the
default PanMouseMode class with one that basically allows the map to be
dragged around in real time. (my mousedragged implementation calculates a
new map center based on the new mouse position and calls
map.setCenter(newCenter)).
 
When I use the standard MapBean and do the dragging, the .shp layer is
simple enough that it can be drawn quickly and everything looks good.
Except! There is this annoying flashing.
 
Traditional graphics systems, ala OpenGL, support the notion of double
buffering to address this very problem.
 
I noticed a BufferedMapBean and the documentation seem to advertise this
does the buffering I want.
 
I tried it, and unfortunately, it behaves rather badly, leaving behind
copies of the last position of the shape file all over the screen.
 
Has anyone successfully use the BufferedMapBean in a mouseDrag operation as
I have described? Isn't this the situation you would normally use this
class?
 
Does this BufferedMapBean actually support 2 Images, rendering the "current"
image in the back buffer and then flipping the back for the front as I would
expect such a buffering scheme to do?
 
Tim
 
 
-----Original Message-----
From: Tim Schreiner [mailto:tjs_at_ll.mit.edu]
Sent: Wednesday, September 26, 2007 10:09 AM
To: 'Don Dietrick'
Cc: 'openmap-users_at_bbn.com'
Subject: RE: [OpenMap Users] How to see RpfCoverage
 
Don,
 
I assume this is the RPF "coverage" property.
I don't see the coverage(s) when I zoom way out. How come?
 
Tim
 
 
-----Original Message-----
From: owner-openmap-users_at_bbn.com [mailto:owner-openmap-users_at_bbn.com] On
Behalf Of Don Dietrick
Sent: Thursday, September 20, 2007 12:51 PM
To: Tim Schreiner
Cc: openmap-users_at_bbn.com
Subject: Re: [OpenMap Users] How to see RpfCoverage
 
Hi Tim,
 
 
The RpfCoverage object is built into the layer. You turn it with a
checkbox on via the layer's palette.
 
- Don
 
On Sep 20, 2007, at 12:28 PM, Tim Schreiner wrote:
 
  

I have some rpf data that I can view quite nicely when I'm zoomed
in on the data. It's a CIB data file. When I zoom way out on the
entire globe, I'd like to draw some form of outline of the coverage
on my map. I tried using RpfCoverage to do this, feeding it my rpf
layer, but I don't see anything on the map. What do I need to do to
see the RpfCoverage data?
 
 
 
Currently I am doing this, in my drawing code:
 
 
 
. /// if s_Layers[i] is a RpfLayer
 
RpfCoverage r = new RpfCoverage(s_Layers[i]);
 
r.allCoveragesOn();
 
r.generate(this.getProjection());
 
r.paint(this.getGraphics());
 
 
 
Tim
 
 
    

 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, dietrick_at_bbn.com
BBN Technologies, Cambridge MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
 
 
--
[To unsubscribe to this list send an email to  <mailto:majdart_at_bbn.com>
"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  <mailto:majdart_at_bbn.com>
"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 Thu Sep 27 2007 - 10:03:24 EDT

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:08 EDT