Dear developers, I discovered that in backend_wx.py in _onPaint(), the callback function for repainting a matplotlib figure, every time a repaint is done also the bitmap is rerendered: backend_wx.py/_onPaint(): ... # Render to the bitmap self.draw(repaint=False) ... This also affects the behaviour of the wxagg backend. Rerendering and therefore also repainting gets quite slow if, e.g., images are included in the figure. I can see this by simply dragging another window across the matplotlibfigure. Commenting out the rerendering I get a much smoother behaviour. I could not observe problems except that sometimes some parts of the figure are not properly repainted if the matplotlib figure is in the background (I only tested the wxagg backend). Therefore it seems that this rerendering every time a repaint is performed is not really necessary and should be avoided. I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I checked that in the current svn version the _onPaint() function is unchanged. Gregor
I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found that when I bring up a new window, I see a black canvas and it doesn't draw any of the matplotlib objects until I do something like resizing that must explicitly call a draw at some point. This may be why it's in there... perhaps some sort of checking to see if any draw has been performed yet? On Mon, Mar 31, 2008 at 7:58 AM, Gregor Thalhammer <gre...@gm...> wrote: > Dear developers, > > I discovered that in backend_wx.py in _onPaint(), the callback function > for repainting a matplotlib figure, every time a repaint is done also > the bitmap is rerendered: > > backend_wx.py/_onPaint(): > ... > # Render to the bitmap > self.draw(repaint=False) > ... > > This also affects the behaviour of the wxagg backend. Rerendering and > therefore also repainting gets quite slow if, e.g., images are included > in the figure. I can see this by simply dragging another window across > the matplotlibfigure. Commenting out the rerendering I get a much > smoother behaviour. I could not observe problems except that sometimes > some parts of the figure are not properly repainted if the matplotlib > figure is in the background (I only tested the wxagg backend). Therefore > it seems that this rerendering every time a repaint is performed is not > really necessary and should be avoided. > > I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I > checked that in the current svn version the _onPaint() function is > unchanged. > > Gregor > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 4155B Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2996 Cell: (651)307-9409 eto...@uc...
Erik Tollerud wrote: > I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found > that when I bring up a new window, I see a black canvas and it doesn't > draw any of the matplotlib objects until I do something like resizing > that must explicitly call a draw at some point. yup, same here. I'm using wxAgg, and FigureCanvas.draw() just doesn't seem to be getting called when I call Figure.draw() It looks like it's designed to work the other way -- the Window needs to call self.figure.draw(self.renderer) when it wants the image drawn. There is an efficiency to this, as the figure doesn't get rendered until the GUI toolkit needs it. However, having it re-render on every Paint call isn't right either. So how should this work? I'd like to be able to call Figure.draw(), and have the figure re-draw itself - but then it needs to be able to tell the backend Canvas that it needs to be drawn. It seems that the figure needs to keep a flag that indicated when it is "dirty", then the paint handler could check that, and call draw if need be. Is there one already? This all seems a bit awkward though. I've written a bunch of double buffered code, and I try to do it like this: The Paint handler only blits. There is a draw routine that actually draws the off-screen bitmap. It is called: - when the bitmap is new, like in a Re-size event - when the drawing changes. In the MPL case, then, it seems that figure.draw() should call that draw routine, but maybe it doesn't know anything about its canvas. Ah -- ye sit does - figure.canvas. OK, so a draw_event is getting called, which I guess is where the drawing should happen, but I'm getting lost now! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
I continued to work on this issue. Thanks for Chris Barker for pointing
me into the right direction. I also had a look at other gui backends,
and, among other, backend_qtagg.py seems to contain a proper (more or
less, see other postings of Ted Drain) implementation of double buffered
drawing that avoids unnecessary rerendering of the bitmap. Following
this example, I applied following changes to backend_wx.py and
backend_wxagg.py
backend_wx.py:
in __init__(...) added line:
self._need_rerender = True
changed _onPaint(...) to following (note: removed evt.Skip() at end!)
def _onPaint(self, evt):
"""
Called when wxPaintEvt is generated
"""
DEBUG_MSG("_onPaint()", 1, self)
if not self._isRealized:
self.realize()
#only recreate bitmap if needed
if self._need_rerender:
self.draw(repaint=False)
self._need_rerender = False
#repaint only damaged parts of window
dc = wx.PaintDC(self)
source = wx.MemoryDC(self.bitmap)
box = self.UpdateRegion.Box
dc.Blit(box.X, box.Y, box.Width, box.Height,
source,
box.X, box.Y)
source.SelectObject(wx.NullBitmap) #needed?
By these change in onPaint a rerendering of the bitmap is done only if
needed (in fact, this is needed only once after the figure is shown
for the first time). I moved code from gui_repaint() into
_onPaint. Calls to gui_repaint() in other methods (e.g., draw) might now be
replaced by
self.Refresh()
self.Update() #this is optional, leeds to an immediate repaint
in backend_wxagg.py I changed the draw and blit methods in this sense:
def draw(self, repaint=True):
"""
Render the figure using agg.
"""
DEBUG_MSG("draw()", 1, self)
FigureCanvasAgg.draw(self)
self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
if repaint:
self.Refresh(eraseBackground = False)
self.Update()
def blit(self, bbox=None):
self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
if bbox is None:
self.Refresh(eraseBackground = False)
else:
l, b, w, h = bbox.get_bounds()
x = int(l)
y = int(self.bitmap.GetHeight() - (b+h))
w = int(w)
h = int(h)
self.RefreshRect(wx.Rect(x, y, w, h),
eraseBackground = False)
self.Update() #needed?
I tested these changes with WinXP, python2.5, matplotlib 0.91.2,
wxWidgets2.8.7 with several scripts from the matplotlib/examples and I
could not observe a misbehaviour.
I had to add some calls to figure.canvas.draw in my mpl-embedded-in-wx
application, e.g., after changing a colormap range, to give a
immediate change on screen. Before due to the frequent rerendering I
didn't notice that these statements were missing.
As Chris Barker noticed, Figure.draw() does not lead to a repainting
of the window on screen. This seems to be intended. Instead one should
use pylab.draw() or Figure.canvas.draw().
I thought about a more substantial rewrite of the Wx/WxAgg backend,
similar to the QtAgg backend, but (for the moment) I wanted to try
only simple changes. Anyhow, the Wx backend seems to be in some
aspects outdated (uses old style wx methods, e.g. ToolBar.AddTool) and
is even not fully functional (image support missing). What are the
plans for the future? What about the politics of supporting older
versions of wxWidgets?
Gregor Thalhammer
Christopher Barker schrieb:
> Erik Tollerud wrote:
>
>> I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found
>> that when I bring up a new window, I see a black canvas and it doesn't
>> draw any of the matplotlib objects until I do something like resizing
>> that must explicitly call a draw at some point.
>>
>
> yup, same here.
>
> I'm using wxAgg, and FigureCanvas.draw() just doesn't seem to be getting
> called when I call Figure.draw()
>
> It looks like it's designed to work the other way -- the Window needs to
> call self.figure.draw(self.renderer) when it wants the image drawn.
> There is an efficiency to this, as the figure doesn't get rendered until
> the GUI toolkit needs it. However, having it re-render on every Paint
> call isn't right either.
>
> So how should this work? I'd like to be able to call Figure.draw(), and
> have the figure re-draw itself - but then it needs to be able to tell
> the backend Canvas that it needs to be drawn.
>
> It seems that the figure needs to keep a flag that indicated when it is
> "dirty", then the paint handler could check that, and call draw if need
> be. Is there one already?
>
> This all seems a bit awkward though. I've written a bunch of double
> buffered code, and I try to do it like this:
>
> The Paint handler only blits.
> There is a draw routine that actually draws the off-screen bitmap. It is
> called:
> - when the bitmap is new, like in a Re-size event
> - when the drawing changes.
>
> In the MPL case, then, it seems that figure.draw() should call that draw
> routine, but maybe it doesn't know anything about its canvas. Ah -- ye
> sit does - figure.canvas.
>
> OK, so a draw_event is getting called, which I guess is where the
> drawing should happen, but I'm getting lost now!
>
> -Chris
>
Here I attached diff files of my changes, compared to matplotlib-0.91.2 release. Gregor Thalhammer
Hi Christopher,
thanks for your valueable feedback. I am proceeding slowly, but steadily.
>
> > backend_qtagg.py seems to contain a proper (more or
>> less, see other postings of Ted Drain) implementation of double
>> buffered drawing that avoids unnecessary rerendering of the bitmap.
>
> It still feels a bit kludgy to me -- a paint event should simply copy
> the bitmap to the screen, any re-rendering should be triggered by
> other events -- either a re-size, or explicitly by
> figure.canvas.draw() or something. Anyway, given the current
> structure, this looks like the way to go.
I agree, this is currently more a workaround for some missing
rererenderings. It seems to me, that rendering the figure is avoided as
much as possible. Possibly this is due to the support for the vector
graphic backends (postscript, pdf, svg)? I guess that with these
backends rendering means actually creating the output file, but I didn't
have a look at the source code.
>> self._need_rerender = True
>
> Where does this get set to True again? On a Figure.canvas.draw() call?
Actually nowhere else. In the QtAgg backend, in Figure.canvas.draw this
is set to True, and then a repaint event is triggered, but no explicit
rerendering. I didn't get this fact from the beginning. As stated above,
this command is essentially a workaround for a missing initial
rerendering after creating the FigureCanvas.
>
>> changed _onPaint(...) to following (note: removed evt.Skip() at end!)
>> def _onPaint(self, evt):
>
>> #repaint only damaged parts of window
>
> I don't know that this is needed, bitting the whole Window is
> blazingly fast anyway -- but if it works, why not?
Actually, this code repaints the bounding box containing all damaged
regions. I did it because the QtAgg backend also did it like this. If I
quickly move another window in front of a matplotlib figure, than I can
see I small difference.
>> By these change in onPaint a rerendering of the bitmap is done only if
>> needed (in fact, this is needed only once after the figure is shown
>> for the first time).
>
> Well, it's needed whenever the figure changes -- on each
> figure.canvas.draw() call, I guess.
You are right. To express it more clearly: In my changed code a
rererendering of the bitmap is done on each figure.canvas.draw() (as
before). In the onPaint event callback no rerendering is done except the
very first it's get callad after the figure has been created (changed
behaviour).
>
> > I moved code from gui_repaint() into
>> _onPaint. Calls to gui_repaint() in other methods (e.g., draw) might
>> now be
>> replaced by
>>
>> self.Refresh()
>> self.Update() #this is optional, leeds to an immediate repaint
>
> Maybe -- I've found (at least on OS-X) that using a ClientDC is still
> required sometimes to get instant response. This is key if you're
> doing anything like animation.
Initially I thought this is optional and might avoid some unnecessary
repainting. Later I discovered that it is crucial for interactive
panning. And for animation.
>
>> def draw(self, repaint=True):
>> """
>> Render the figure using agg.
>> """
>> DEBUG_MSG("draw()", 1, self)
>> FigureCanvasAgg.draw(self)
>> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(),
>> None)
>> if repaint:
>> self.Refresh(eraseBackground = False)
>> self.Update()
>
> I think maybe these should be calls to gui_repaint, which will get you
> to a ClientDC instead of waiting for a paint event -- Update is not
> always instant.
Didn't know this. The wxWidgets documentation states about Update():
"Calling this method immediately repaints the invalidated area of the
window..."
>> I had to add some calls to figure.canvas.draw in my mpl-embedded-in-wx
>> application, e.g., after changing a colormap range, to give a
>> immediate change on screen. Before due to the frequent rerendering I
>> didn't notice that these statements were missing.
>
> I agree -- I think I'm going to need to add a few of those too. The
> problem is that this is a change, and other folks' code is going to
> break too.
At least for my case I would say that these changes to the wx backend
didn't break my code, they revealed mistakes in my code (I used
Refresh() instead of figure.canvas.draw() calls to get a rerendering of
the matplotlib figure).
>> As Chris Barker noticed, Figure.draw() does not lead to a repainting
>> of the window on screen. This seems to be intended. Instead one should
>> use pylab.draw() or Figure.canvas.draw().
>
> I think you're right -- I should have looked at the pylab.draw code to
> see what it did. Though I think Figure should have a method that does
> do an instant update...DrawNow??
For GUI backends I would even expect that Figure.draw() should update
the figure on screen. However, I don't know how this should be
implemented for not breaking code which uses other backends.
>> What about the politics of supporting older versions of wxWidgets?
>
> I wouldn't bother, but I'm a bleeding-edge kind of guy. It seems that
> we could at least make sure not to break anything by keeping the old
> code around for older versions, and go all 2.8 for new code, with one
> big 'ol version test at the top of the modules.
Did I understand you correctly: This means to drop support for ancient
versions of wx in newly added code? This makes developing much easier.
Gregor
Just a note about the speed of blitting:
Generally speaking, blitting on a local machine is VERY fast. However, if
you log in to a remote machine and display the window locally (remote
machine to local X server), blitting can be the slowest part of the whole
operation. Profiling of the QtAgg backend shows the following items as the
slowest parts:
1) Convert the QImage (agg RGB) to QPixmap (display depth and resolution)
2) blitting the pixmap to the screen
3) Agg drawing calls
Of course the relative speeds here depend a lot on what's being drawn (agg
calls), how many pixels there are (converting and blitting), how fast the
network is (blitting), how close the screen is to the agg buffer in terms of
resolution and depth (RGB conversion) so timings between these components
can vary a lot.
In short: there are definitely cases where blitting the smallest part of the
image that's necessary is a big help.
Ted
> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...] On Behalf Of
> Gregor Thalhammer
> Sent: Monday, April 14, 2008 1:03 AM
> To: Christopher Barker; mat...@li...
> Subject: Re: [matplotlib-devel] Unnecessary rerendering in wx/wxagg
> backends
>
> Hi Christopher,
>
> thanks for your valueable feedback. I am proceeding slowly, but
> steadily.
> >
> > > backend_qtagg.py seems to contain a proper (more or
> >> less, see other postings of Ted Drain) implementation of double
> >> buffered drawing that avoids unnecessary rerendering of the bitmap.
> >
> > It still feels a bit kludgy to me -- a paint event should simply copy
> > the bitmap to the screen, any re-rendering should be triggered by
> > other events -- either a re-size, or explicitly by
> > figure.canvas.draw() or something. Anyway, given the current
> > structure, this looks like the way to go.
> I agree, this is currently more a workaround for some missing
> rererenderings. It seems to me, that rendering the figure is avoided as
> much as possible. Possibly this is due to the support for the vector
> graphic backends (postscript, pdf, svg)? I guess that with these
> backends rendering means actually creating the output file, but I
> didn't
> have a look at the source code.
> >> self._need_rerender = True
> >
> > Where does this get set to True again? On a Figure.canvas.draw()
> call?
> Actually nowhere else. In the QtAgg backend, in Figure.canvas.draw this
> is set to True, and then a repaint event is triggered, but no explicit
> rerendering. I didn't get this fact from the beginning. As stated
> above,
> this command is essentially a workaround for a missing initial
> rerendering after creating the FigureCanvas.
> >
> >> changed _onPaint(...) to following (note: removed evt.Skip() at
> end!)
> >> def _onPaint(self, evt):
> >
> >> #repaint only damaged parts of window
> >
> > I don't know that this is needed, bitting the whole Window is
> > blazingly fast anyway -- but if it works, why not?
> Actually, this code repaints the bounding box containing all damaged
> regions. I did it because the QtAgg backend also did it like this. If I
> quickly move another window in front of a matplotlib figure, than I can
> see I small difference.
> >> By these change in onPaint a rerendering of the bitmap is done only
> if
> >> needed (in fact, this is needed only once after the figure is shown
> >> for the first time).
> >
> > Well, it's needed whenever the figure changes -- on each
> > figure.canvas.draw() call, I guess.
> You are right. To express it more clearly: In my changed code a
> rererendering of the bitmap is done on each figure.canvas.draw() (as
> before). In the onPaint event callback no rerendering is done except
> the
> very first it's get callad after the figure has been created (changed
> behaviour).
> >
> > > I moved code from gui_repaint() into
> >> _onPaint. Calls to gui_repaint() in other methods (e.g., draw) might
> >> now be
> >> replaced by
> >>
> >> self.Refresh()
> >> self.Update() #this is optional, leeds to an immediate repaint
> >
> > Maybe -- I've found (at least on OS-X) that using a ClientDC is still
> > required sometimes to get instant response. This is key if you're
> > doing anything like animation.
> Initially I thought this is optional and might avoid some unnecessary
> repainting. Later I discovered that it is crucial for interactive
> panning. And for animation.
> >
> >> def draw(self, repaint=True):
> >> """
> >> Render the figure using agg.
> >> """
> >> DEBUG_MSG("draw()", 1, self)
> >> FigureCanvasAgg.draw(self)
> >> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(),
> >> None)
> >> if repaint:
> >> self.Refresh(eraseBackground = False)
> >> self.Update()
> >
> > I think maybe these should be calls to gui_repaint, which will get
> you
> > to a ClientDC instead of waiting for a paint event -- Update is not
> > always instant.
> Didn't know this. The wxWidgets documentation states about Update():
> "Calling this method immediately repaints the invalidated area of the
> window..."
>
>
> >> I had to add some calls to figure.canvas.draw in my mpl-embedded-in-
> wx
> >> application, e.g., after changing a colormap range, to give a
> >> immediate change on screen. Before due to the frequent rerendering I
> >> didn't notice that these statements were missing.
> >
> > I agree -- I think I'm going to need to add a few of those too. The
> > problem is that this is a change, and other folks' code is going to
> > break too.
> At least for my case I would say that these changes to the wx backend
> didn't break my code, they revealed mistakes in my code (I used
> Refresh() instead of figure.canvas.draw() calls to get a rerendering of
> the matplotlib figure).
>
> >> As Chris Barker noticed, Figure.draw() does not lead to a repainting
> >> of the window on screen. This seems to be intended. Instead one
> should
> >> use pylab.draw() or Figure.canvas.draw().
> >
> > I think you're right -- I should have looked at the pylab.draw code
> to
> > see what it did. Though I think Figure should have a method that does
> > do an instant update...DrawNow??
> For GUI backends I would even expect that Figure.draw() should update
> the figure on screen. However, I don't know how this should be
> implemented for not breaking code which uses other backends.
> >> What about the politics of supporting older versions of wxWidgets?
> >
> > I wouldn't bother, but I'm a bleeding-edge kind of guy. It seems that
> > we could at least make sure not to break anything by keeping the old
> > code around for older versions, and go all 2.8 for new code, with one
> > big 'ol version test at the top of the modules.
> Did I understand you correctly: This means to drop support for ancient
> versions of wx in newly added code? This makes developing much easier.
>
> Gregor
>
>
> -----------------------------------------------------------------------
> --
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save 100ドル.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/
> javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Gregor,
Thanks for working on this.
> backend_qtagg.py seems to contain a proper (more or
> less, see other postings of Ted Drain) implementation of double buffered
> drawing that avoids unnecessary rerendering of the bitmap.
It still feels a bit kludgy to me -- a paint event should simply copy
the bitmap to the screen, any re-rendering should be triggered by other
events -- either a re-size, or explicitly by figure.canvas.draw() or
something. Anyway, given the current structure, this looks like the way
to go.
> self._need_rerender = True
Where does this get set to True again? On a Figure.canvas.draw() call?
> changed _onPaint(...) to following (note: removed evt.Skip() at end!)
> def _onPaint(self, evt):
> #repaint only damaged parts of window
I don't know that this is needed, bitting the whole Window is blazingly
fast anyway -- but if it works, why not?
> dc = wx.PaintDC(self)
> source = wx.MemoryDC(self.bitmap)
> box = self.UpdateRegion.Box
> dc.Blit(box.X, box.Y, box.Width, box.Height,
> source,
> box.X, box.Y)
> source.SelectObject(wx.NullBitmap) #needed?
no, it goes away at the end of the method, anyway.
> By these change in onPaint a rerendering of the bitmap is done only if
> needed (in fact, this is needed only once after the figure is shown
> for the first time).
Well, it's needed whenever the figure changes -- on each
figure.canvas.draw() call, I guess.
> I moved code from gui_repaint() into
> _onPaint. Calls to gui_repaint() in other methods (e.g., draw) might now be
> replaced by
>
> self.Refresh()
> self.Update() #this is optional, leeds to an immediate repaint
Maybe -- I've found (at least on OS-X) that using a ClientDC is still
required sometimes to get instant response. This is key if you're doing
anything like animation.
> def draw(self, repaint=True):
> """
> Render the figure using agg.
> """
> DEBUG_MSG("draw()", 1, self)
> FigureCanvasAgg.draw(self)
> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
> if repaint:
> self.Refresh(eraseBackground = False)
> self.Update()
I think maybe these should be calls to gui_repaint, which will get you
to a ClientDC instead of waiting for a paint event -- Update is not
always instant.
> self.Update() #needed?
Same as above.
> I had to add some calls to figure.canvas.draw in my mpl-embedded-in-wx
> application, e.g., after changing a colormap range, to give a
> immediate change on screen. Before due to the frequent rerendering I
> didn't notice that these statements were missing.
I agree -- I think I'm going to need to add a few of those too. The
problem is that this is a change, and other folks' code is going to
break too.
> As Chris Barker noticed, Figure.draw() does not lead to a repainting
> of the window on screen. This seems to be intended. Instead one should
> use pylab.draw() or Figure.canvas.draw().
I think you're right -- I should have looked at the pylab.draw code to
see what it did. Though I think Figure should have a method that does do
an instant update...DrawNow??
> I thought about a more substantial rewrite of the Wx/WxAgg backend,
> similar to the QtAgg backend,
I think it does kind of need it.
> Anyhow, the Wx backend seems to be in some
> aspects outdated (uses old style wx methods, e.g. ToolBar.AddTool) and
> is even not fully functional (image support missing). What are the
> plans for the future?
Well, I think most folks use wxAgg, rather than the straight wx
back-end. As for other updating -- it's not a matter of plans so much as
someone needing to step up and do it!
> What about the politics of supporting older versions of wxWidgets?
I wouldn't bother, but I'm a bleeding-edge kind of guy. It seems that we
could at least make sure not to break anything by keeping the old code
around for older versions, and go all 2.8 for new code, with one big 'ol
version test at the top of the modules.
Thanks for working on this,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
Ted Drain wrote: > Just a note about the speed of blitting: Your points are well taken. I had forgotten about remote X sessions, and yes, if you need to convert to a different type of pixmap, that can take time too, so keeping it to just what's needed does make sense. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...