useGUILayout preventing calls to Graphics.DrawTexture?

I’ve been looking for ways to increase the performance of my game. I’ve been doing some pretty expansive work with the GUI, making it resolution-idependant and so on, but it’s started to become pretty intense.

It seems that OnGUI is being called a ludicrous number of times a second, so I read up on how to reduce the number of calls. Apparently, setting useGUILayout to false cuts the calls by half (and, indeed, my own tests shows this to be the case). However, I have an effect at one point of the GUI, which is the pause menu, where this causes problems.

My pause menu structure is quite simple. Since I don’t have Unity Pro, I sample the screen to a texture using SetPixel. I then draw it at a quarter of the resolution, and blur it, using Graphics.DrawTexture. I then sample this smaller image again, and draw it across the whole screen, scaled up (again blurred) using another call to Graphics.DrawTexture. This gives a nice, blurred screen effect in the pause menu, and it all works find if useGUILayout is enabled.

If useGUILayout is disabled, though, neither of these called to Graphics.DrawTexture actually works, and I end up with an effect that is certainly not what I was looking for.

This is extremely odd to me, because this doesn’t seem like it should happen. As far as I understand it, useGUILayout should have no effect on the Graphics class, and is solely designed to deal with built-in GUI functions (the only GUI methods I use are DrawTexture and DrawTextureWithTexCoords, both are working fine either way). I’m quite concerned by this, because it doesn’t seem to make sense. Could anyone perhaps shed some light on what is actually going on?

Actually, I’m wrong here. Only the FIRST call to Graphics.DrawTexture does not work. The second one gets through fine. That is, if anything, even MORE confusing.

Fixed it! It seems that, with useGUILayout enabled, waiting for the end of a frame to draw a texture is valid. My guess would be because it allows the draw call to happen at the end of a layout phase, so it can be drawn during the repaint phase, or vice versa. I fixed this by moving a draw call out of a coroutine, and instead implemented it as a two-step draw, so that the preparation happens on one frame, and the execution on the next, rather that using WaitForEndOfFrame.

So, in short, don’t use coroutines for drawing stuff, kids!