Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualiedoc

Posted 22 January 2013 - 07:28 AM

Its not the message loop locking the screen actually, its the present call. When you call present(0, 0), no vsync, it will swap buffers and write the front buffer to the window as fast as possible. Since present needs to access the window, and your render loop is pretty much only the present call, the window has no time to process the windows messages, so basically the message queue gets backed up since none of the messages have time to get processed, and that's why you can't do anything with the screen, like closing or resizing or moving it, those are all windows messaged that have to wait for the window to process them, but the window is too busy processing the present call. I can't remember if the present call will be put into a message queue (probably not because that would cause the game to become really unresponsive I think) or if it just stalls the thread until it has access to the window. But either way, your render thread will call present so fast so the window just doesn't have time to do anything else but render the front buffer to the screen.


When you call present(1,0), vsync, the window will have a little time to process other window messages while the present call waits for the signal from the monitor or however vsync actually works.the point is you are giving a little time for the window to process other messages.


Remember directx needs a window handle to know which window to draw on. The windows message system sends messages to windows via handles, so if directx is using the window it has the handle to (present), then the messages sent by the windows OS (close, resize, move)will have yo wait to be processed by that window until directx lets go of it. Obviously (maybe not so obvious) directx and windows use some sort of internal mutex or locking system so when a window is being used, everything else that needs to access that window must wait, and we can't assume they wait in line, because if that was the case, then at least some of your windows messages would be processed between each time the window rendered the front buffer for directx. But we know none of the windows messages are being processed by the window, and only the present call being processed, which means the present call cuts in line and will be processed by the window before the messages in the windows message queue.


That last paragraph has a lot of assumptions though, so don't take it as correct without some research if you could even follow that, I could be wrong

#2iedoc

Posted 22 January 2013 - 07:22 AM

Its not the message loop locking the screen actually, its the present call. When you call present(0, 0), no vsync, it will swap buffers and write the front buffer to the window as fast as possible. Since present needs to access the window, and your render loop is pretty much only the present call, the window has no time to process the windows messages, so basically the message queue gets backed up since none of the messages have time to get processed, and that's why you can't do anything with the screen, like closing or resizing or moving it, those are all windows messaged that have to wait for the window to process them, but the window is too busy processing the present call. I can't remember if the present call will be put into a message queue (probably not because that would cause the game to become really unresponsive I think) or if it just stalls the thread until it has access to the window. But either way, your render thread will call present so fast so the window just doesn't have time to do anything else but render the front buffer to the screen.


When you call present(1,0), vsync, the window will have a little time to process other window messages while the present call waits for the signal from the monitor or however vsync actually works.the point is you are giving a little time for the window to process other messages.


Remember directx needs a window handle to know which window to draw on. The windows message system sends messages to windows via handles, so if directx is using the window it has the handle to (present), then the messages sent by the windows OS (close, resize, move)will have yo wait to be processed by that window until directx lets go of it. Obviously (maybe not so obvious) directx and windows use some sort of internal mutex or locking system so when a window is being used, everything else that needs to access that window must wait, and we can't assume they wait in line, because if that was the case, then at least some of your windows messages would be processed between each time the window rendered the front buffer for directx. But we know none of the windows messages are being processed by the window, and only the present call being processed, which means the present call bushes in line and will be processed by the window before the messages in the windows message queue.


That last paragraph has a lot of assumptions though, so don't take it as correct without some research if you could even follow that, I could be wrong

#1iedoc

Posted 22 January 2013 - 07:19 AM

Its not the message loop locking the screen actually, its the present call. When you call present(0, 0), no vsync, it will swap buffers and write the front buffer to the window as fast as possible. Since present needs to access the window, and your render loop is pretty much only the present call, the window has no time to process the windows messages, so basically the message queue gets backed up since none of the messages have time to get processed, and that's why you can't do anything with the screen, like closing or resizing or moving it, those are all windows messaged that have to wait for the window to process them, but the window is too busy processing the present call. I can't remember if the present call will be put into a message queue (probably not because that would cause the game to become really unresponsive I think) or if it just stalls the thread until it has access to the window. But either way, your render thread will call present so fast so the window just doesn't have time to do anything else but render the front buffer to the screen. When you call present(1,0), vsync, the window will have a little time to process other window messages while the present call waits for the signal from the monitor or however vsync actually works.the point is you are giving a little time for the window to process other messages. Remember directx needs a window handle to know which window to draw on. The windows message system sends messages to windows via handles, so if directx is using the window it has the handle to (present), then the messages sent by the windows OS (close, resize, move)will have yo wait to be processed by that window until directx lets go of it. Obviously (maybe not so obvious) directx and windows use some sort of internal mutex or locking system so when a window is being used, everything else that needs to access that window must wait, and we can't assume they wait in line, because if that was the case, then at least some of your windows messages would be processed between each time the window rendered the front buffer for directx. But we know none of the windows messages are being processed by the window, and only the present call being processed, which means the present call bushes in line and will be processed by the window before the messages in the windows message queue. That last paragraph has a lot of assumptions though, so don't take it as correct without some research if you could even follow that, I could be wrong

PARTNERS