I still haven't resolved this issue, although I also haven't fully absorbed Pablo's suggestions. That goes a bit beyond my level perhaps. I'm starting to think though, that it's not any issue with my code, and that the spriteBatch or device simply isn't doing it's job at resizing as I expect it should be (I see that Pablo was saying this basically). To demonstrate that my back-buffer, client bounds and viewport are all in sync immediately before the spriteBatch draw call, I am outputting the width values to the window title.
Here is a screenshot of how the window looks at startup. This is the good result.
screenshot showing good result http://users.tpg.com.au/gavinw77//Issue_good.JPG
Here is a screenshot of how the window looks after a few re-size's, I bring it back to the
original width of 800 to emphasize the difference. This is not desirable.
screenshot showing bad result http://users.tpg.com.au/gavinw77//Issue_bad.JPG
Clearly the rectangle that the spritebatch is drawing in the second example is larger than 792 pixels, as it clearly consumes the entire client bounds.
Here's the code that gather's the info and sends the spriteBatch draw call
game.Window.Title = "spriteBatch.gd.pp.BackBufferWidth="+spriteBatch.GraphicsDevice.PresentationParameters.BackBufferWidth.ToString();
game.Window.Title += " | windows.ClientBounds= " + game.Window.ClientBounds.Width;
game.Window.Title += " | Viewport.Width" + spriteBatch.GraphicsDevice.Viewport.Width;
game.Window.Title += " | sb draw rect=" + rectangle.Width;
spriteBatch.Draw(pixel, rectangle, color);
I just feel like either I'm doing something fundamentally wrong with my resize handling to cause it to glitch out like that, or else xna is glitching out, I simply cant locate any problem in code. As the numbers above demonstrate, everything actually looks ok. I have two different frames, both with back-buffers of 800, both with window client bounds of 800, both rendering a rectangle of 792, but they are different !