Is setting the render target back to backbuffer supposed to take long?

Question

I am creating a game in Monogame (XNA extension). I draw to a render target to display menu items for my game. Everything works fine, however... Whenever I set the render target back to the back buffer of my graphics device

graphicsDevice.SetRenderTarget(null);

it takes a long time (more than a second). This would be fine if I just needed my menu items at the beginning of the game. However if the game resets due to player input I have to re-initialize some of the menu items using the render target this lengthy process gets annoying.

Before I try to debug this, has anyone else experienced time delay with setting the render target back to the graphics back buffer? It works just fine when I set the render target to a created render target.

graphicsDevice.SetRenderTarget( new RenderTarget2D( device, width, height) );

That works just fine.

Edit:

I tried debugging this (C# is not my greatest language), and reached the line GL.BindFramebuffer( GLFramebuffer, this.glFramebuffer); inside ApplyRenderTargets inside GraphicDevice.cs of the Monogame Framework (Not my code).

The delay is occuring when you are trying to bind a framebuffer to a specified frame buffer target inside the OpenTK library. Debugging further requires I get OpenTK. I have to go out right now, but when I get back I'm going to test this on an XNA project (I have tested this in another monogame project with the same results) and attempt to debug further.

Edit 2:

The problem Setting the Render target back to the device back buffer after drawing to a large render target ( 8000 X 8000 ) causes the delay. I don't know the reason why I thought the buffers just swapped out.

Edit 3:

I am going to have to look into how setting render targets actually works. For now the time delay is fine, since I will have loading screens / asynchronous loading as the player progresses in the game to deal with these delays. In the end the the render target swapping the render target from a very large one causes a small delay, this seems to be expected behaviour.

Edit 4: Looking into a better solution than using a large render target.

Edit 5: Check answer

Answer 1

Thanks to Adam and Sean for helping find the most likely cause of the slow load being large frame buffers and the regular buffer can't both sit in video memory, so when the buffers switch the large buffer probably has to be copied into main memory and the device back buffer copied from main memory back to video memory.