1
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ SetRenderTarget(null); shouldn't be producing this type of issue. Have you tried any sort of profiling? \$\endgroup\$ – user39686 Jan 2 '14 at 13:11
  • \$\begingroup\$ Thanks for the reply! Check my edit, got any idea why its happening? \$\endgroup\$ – Ben Cheng Jan 2 '14 at 17:13
  • \$\begingroup\$ I'm not familiar enough with MonoGame or OpenTK to know. Try to see if some good 'ol fashion Google might be able to pull something. I'll try to get a test project on my test bed later if you haven't got it by then. \$\endgroup\$ – user39686 Jan 2 '14 at 17:27
  • \$\begingroup\$ Haha its ok, when I get back I'm going to download the latest OpenTK version and try to debug this. Thanks for your help! \$\endgroup\$ – Ben Cheng Jan 2 '14 at 17:29
  • \$\begingroup\$ The general rule of thumb is that if you must debug a specific library, you're most likely doing something wrong in your own code. \$\endgroup\$ – user39686 Jan 2 '14 at 17:31
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.