What’s the meaning of gfx.WaitForPresent? How can I resolve this performance matter?
Best regards
I was experiencing this too actually, and to be quite honest. I found that having the profiler open every play test was causing me performance issues inside the unity player. Probably due to the constant draw calls to that GUI window. I close it and everything is smooth again. And I just ran a test, I am experiencing a lot of gfx.waitforpresent too. I think it maybe a vsync thing. But I could be wrong. Do you experience poor performance with profiler closed?
I am profiling from my computer to another computer running my application connected to a TV
Ah, well even still. I never liked the performance of a tool that’s supposed to help performance 
1 Like
I’m having a similar issue. In my case, it takes up to 50 ms.
1 Like
Similar issue in my case. VSync seems to be causing it because my game is extremely smooth without it on but when it is I get the same WaitForPresent spikes. The strange thing with my game is that after adding a LOT more objects to the scene it runs extremely smooth again.
Same here, what is it? VSync is disabled.
I think it has to do with swapping around the active RenderTexture. Normally the lag induced by having the profiler open would show up as RenderTexture.setActive, but I think they tried to detect this and instead display it as Gfx.WaitForPresent.
Though, the RenderTexture.setActive still seems to show up for DigitalAperture (the purple section).
2 Likes
Same problem here. So is it only linked to the fact the Profiler is open and running then?
Bumping this for more attention, My application also suffers from this
I think we need to open a bug report and than vote it here: http://issuetracker.unity3d.com/
This is 4.3 related. Anyone? I’m curently out of office.
Same here. Uses 20-65 ms on the CPU when profiling connected to my OUYA.
Gfx- waitforpresent use to be called device.present.
According to the old forum post (http://forum.unity3d.com/threads/86312-Device-Present-in-profiler-what-the-deal) two reasons it would show up:
“you are too fast - refresh rate is 60hz and you are ready after 10ms - 6ms you need to just wait
you are slightly too slow - same as before - but you are ready after 20 ms - you will wait 13 ms (up to 33ms = 30 fps)”
4 Likes
Same issue here. This was not present in 4.2.x
waitforpresent, that should be the device.present as suggested, is actually a good thing…it means you are GPU bound and the CPU at a given point (usually 3 fames ahead) must wait for the GPU to finish. (IT also could mean that you need to optimize your rendering 
)
ah btw, today I noticed that profiling inside the editor gives completely wrong results! Try to build your application and profile your application externally instead!
1 Like
Ok, i opened a bug report (Case 579069).
I was playing with a simple empty project and some balls bouncing around with diffuse shaders and no fancy post effects → 1900/2000 fps. Then i started to add a secondary camera, a rendertexture, and some post effects. Unity started to drop fps to 120/130, and showing in the profiler a 99% cpu usage by Gfx.WaitForPresent. I removed everything: cameras, post effects, rendertargets, etc. I have ONE ball bouncing. Still at 130 fps with WaitForPresent at 99%.
I think there is something broken about rendertargets in 4.3 …
I’m having a similar problems, and it is very frustrating. Does Unity not have a list of profiler stat names to find out what this is? It’s hard to fix an issue if I don’t know where to look 
1 Like
Same problem, Just appeared since 4.3. Wish I could share more light on the situation but I got nothing