Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
27 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to General and Gameplay Programming

Rendering freezing when drag/resize Window

Started by
7 comments, last by L. Spiro 10 years, 3 months ago

I am using mixed mode C++/CLI in my game engine to create WPF window, in which DX is rendering.

Everything work fine except one thing - when I move or resize window, rendering freeze until mouse button will released.

I don`t know how to resolve this issue.

For now I even made a hook and attach WndProc to WPF window. I see that there are some messages in WndProc when I press mouse button and then everything hangs until mouse button will be released.

I thinks this is related with Win32 itself, but I don`t know how to hack this.

Does anyone now how to solve this issue and make DX always render even if I move or resize window?

By the wasy, In native WPF, when I resize or move window, there is no rendering issues like on attached image.

How did they do this? and how to do that in my engine???

Advertisement

You have one of two options.

You can either handle WM_SIZE or WM_WINDOWPOSCHANGED and redraw when they get called, or you do your rendering in a separate thread.

OK, i`d prefer to make rendering in other thread, but I don`t know how. If I run function which render content in other thread, main thread and window is blocked and I cannot do with window anything.

How to start rendering in other thread correctly?

Rendering in the main thread or another thread is conceptually the same. You have to take a 'snapshot' of the current renderable information, and render it. By that I mean that users input (for example) comes in at a rate which isn't the same as your frame rate. So therefore you have to conglomerate the information into usable time pieces. The same is true of every bit of information - add it all together and create a snapshot of what's happening.

There is only 1 correct “fix” and it requires both your game loop and rendering to be done on a thread (or 2) other than the thread that handles the messages for that window (which as it just so happens is a good idea to do anyway).

When the user begins resizing or dragging the window it will send WM_SYSCOMMAND with SC_MOVE, after which DefWindowProc() will not return (it is blocking). It runs its own message pump until the mouse is released.
Messages such as WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE somehow still manage to get to your application, probably in some kind of recursive call (but the implementation details inside DefWindowProc() are of course private).
One hack that people have used is to use those to start and stop a timer and handle WM_TIMER to perform a render. This is still a hack; you should have 1 and exactly 1 centralized location where you perform logic and render updates.


As a result, no matter how you handle this via messages, it is always a hack.

But the solution is not to just moving rendering to another thread, you have to move game logic as well. If the game logic isn’t updating, what are you rendering? Unless you want to do something such as render a black screen (to remove artifacts), in which case handling WM_messages is no longer a hack and would be the best way to go for the sake of simplicity.


And as for how, create another thread and do your game logic and rendering from there. Messages are still gathered on the window thread but sent to the game thread on request. You need to know thread safety.
How to handle threading issues on any given rendering API (OpenGL or Direct3D) is a question better asked in that API’s forums.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

L. Spiro, I already tried to make rendering in another thread and faced with the issue that if I create window in main thread and render in other, window get stuck and not responding on any commands.

Does anyone know how to make a correct interop so, that window is not blocking is such case. If I create window also in another thread, it will have no effect as they will in one thread again and rendering will block again as well.

Will be cool if someone give an example of such inteop. I cant get at least one example for now.

I already tried to make rendering in another thread and faced with the issue that if I create window in main thread and render in other, window get stuck and not responding on any commands.

As I said, if you have any questions about OpenGL or DirectX and multi-threading, there are sub-forums for those inquiries.

Does anyone know how to make a correct interop so, that window is not blocking is such case.

Perhaps if we knew where to even begin to address the issue. If your error is in your game logic or your update loop/message handler then you would need to post some code and preferably start another topic for that specific issue.
If the error is in your rendering code it becomes a graphics API question it should be in a new thread in the appropriate section.

Will be cool if someone give an example of such inteop. I cant get at least one example for now.

Of what interaction? A message pump on the window thread with logic on another?
Just rendering on a second thread?


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

Of what interaction? A message pump on the window thread with logic on another?
Just rendering on a second thread?L. Spiro

I mean message pump and rendering on a second thread. For now I have no game logic.

So, need I to start another topic in this thread regarding message pump or in directX subforum?


I mean message pump and rendering on a second thread.

The message pump can’t be on a second thread; it is always on the thread that created the window.

If that does not solve your problem then you will need to ask for specific help in the sub-forum that best suits the problem you are having (general programming for message handlers and multi-threading, DirectX for Direct3D and multi-threading).

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

This topic is closed to new replies.

Advertisement

Popular Topics

Aybe One
How do you manage yourself and your time as years pass on? GDNet Lounge
Jikoob
Too many managers? General and Gameplay Programming
ReignOnU
Do your part to stop global warming and climate change GDNet Lounge
aigan
The promise of freedom in story games Game Design and Theory
robertrobert
Facebook Ads for sales on steam, does it work? Games Business and Law
AliAbdulKareem
Understanding the wavy-like shape in alpha-testing magnification for text rendering Graphics and GPU Programming
Advertisement

Recommended Tutorials

Azaral
Game Crafting Activities in Real Life - Blacksmithing Part 2 Game Design and Theory
kevinharwood
Humble Bundle Distribution Business and Law
doug25
Animating Characters with DirectX Graphics and GPU Programming
mikeshafer
Design of an Indie Action Game Game Design and Theory
Myopic Rhino
High Resolution Timing In Games General and Gameplay Programming

Reticulating splines

About GameDev.net
Community Guidelines
Terms of Service
Privacy Policy
Contact Us
Copyright (c) 1999-2024 GameDev.net, LLC
Back to Top