I have a win32 application which updates a lot of rectangles in a dialog quite fast. (now via bitblt(a bit of double buffering), before it was a different method - it doesnt matter).
And after random time passed - random dialog(from that application, with updating rectangles) just hangs on my PC. And by hanging i mean its redrawing hangs, if i push a menu button which popups something it works, but dialog doesnt shows anything just stays stuck. And it stays stuck until resized ! Or application restarted, ofc.
This only happens on my 'fast' PC with 3 desktops(controlled via different gpus).
My 'slow' laptop doesn't reproduce this, or maybe it would need more time to reproduce this(not a night, lets say) since its slower ?
I am really new in c++, windows dialogs programming - i may misused something or done something wrong. i checked everything i can, revisited microsoft tutorials on dialogs(and every drawing function) usage, checked everything - didnt quite found anything.
Maybe someone can offer me something smarter than disabling random functionality and waiting will it hang or not ? I would like to understand why it crashes(hangs), and why like this.
OS: Microsoft Windows 7 64
Compiler: Visual studio 2013
Addition: The debugger when stopped: Main thread shows only entrance of main dialog. DialogBox function, that's all. Ofc that thread is running all the other dialogs, but those dialogs are ran from main dialog called by DialogBox. Drawing is done by different thread, and it doesnt even notice that dialog hanged. The main thread doesn't 'hang' since other dialogs runs quite fine. and that 'hanged' dialog is fixed if resized, so strange.
Drawing by different thread means: dialogs are ran by main thread, other thread(actually couple of them and lower priority than other threads) is responsible for biblt and other drawing logic operations on those dialogs(since up to 600 rectangles can be updated up to 100Hz, it draws CPU quite well). I did addressed critical section problems and resources freeing when not used quite well but first thing i will do will be - rechecking those.
You're simply not supposed to draw from other threads.
It is however safe for a single thread to draw to a bitmap (i.e. in memory), and then hand off that bitmap to the main thread for bitblt'ing. That can scale in the sense that you can have multiple threads prepare multiple bitmaps, and have the main thread bitblt each of those in turn.
Related
I am working on an old C++ project on Windows, where I am upgrading the app's DirectX rendering engine (using DX11). The new engine that I made currently coexists with the old one, but it runs in a different thread and has its own DX device and context. Until now, I've been using two separate windows to display the results of the old and new rendering processes at the same time, which allows me to verify that the new engine correctly replicates the behavior of the old one.
Now I want to merge these windows and swap between them at runtime, i.e I would hook a button press, or some other control to pause one render thread and (re)start the other. Both would draw their results to the same window (i.e using the same HWND to create the render target and swap chain), but only one thread would be active at any one time. A good analogy would be some remastered games where they let you swap between the old and new graphics.
What is the most ideal way to achieve this? I was thinking of doing a "hot swap", i.e letting one thread start rendering without even waiting for the other thread to finish, since we know it will stop in the next frame, and I don't need them to be working together. Does this carry the risk of crashing, or any other problems? If all it would cause is a few incorrect frames during the swap, then I don't mind.
I tested it, no ill effects as far as I can tell, besides some flickering if both threads happen to try to draw at the same time.
I'm currently working on a game where I wanted to create a loading screen that basically shows the process of loading all the resources. To do this, I decided to create a separate thread that handles the window. I'm aware that there could be more efficient solutions, but I wanted to create a special mouse cursor and that way was the only way that allowed me to do that without having a buggy mouse when the application is loading a big file.
I read up on the threads on the SFML tutorial page and I learned that I have to do window.setActive(false) in the main thread and then window.setActive(true) in the separate thread in order to have access to the window in the separate thread without getting any problems. This works fine, it doesn't throw any errors and it displays the loading screen very nicely. However, I can't move the window around or interact with it in any way. The mouse cursor is covered by the blue ring from the mouse when it's loading, and I can neither close nor move nor resize the window even though I used sf::Style::Default, so it should be possible.
Can anyone help me out here?
You have it backwards. You blocked the main thread with loading your resources and created a new thread to keep the UI responsive. Not only is that not going to go well in the long term, but in the short term, your operating system still thinks your app is blocked, because the main thread is unresponsive. The OS does not know you created a second thread to keep the user entertained.
You should instead keep the responsive UI on the main thread and create an extra thread for doing the heavy lifting and blocking work. This way you don't have to struggle with your graphics library all the way (and it does not matter whether that's SFML, because they all do this) plus your operating system will not behave as if you blocked your application.
Came across a problem which google searches could not help me with. I have a little SDL application that runs at 60 fps. Everything is working fine, however, it pauses/stops running when the window is dragged ( 640 X 480 window ). Is there a flag or something that can be set in the SDL window to prevent this from happening? Or is this unavoidable?
Windows uses a modal event loop for dragging windows, which blocks your main UI thread.
More discussion (and suggested workarounds, such as drawing from a second thread): http://www.sfml-dev.org/forum/viewtopic.php?p=8384&sid=632116a07a569edee43331076e028071
OpenTk apparently has code designed to address this, maybe you can reuse some of it: http://www.opentk.com/node/1218
I am writing a game in C++ using SDL 1.2.14 and the OpenGL bindings included with it.
However, if the game is in fullscreen and I Alt - Tab out then back into the game, the results are unpredictable. The game logic still runs. However, rendering stops. I only see the last frame of the game that was drawn before the Alt-tab
I've made sure to re-initialize the OpenGL context and reload all textures when I get an SDL_APPACTIVE = 1 event and that seems to work for only one Alt - Tab, then all subsequent Alt - Tabs will stop rendering (I've made sure SDL_APPACTIVE is properly being handled each time and setting the context accordingly.)
I'd hazard a guess that SDL does something under the hood when minimizing the application that I'm not aware of.
Any ideas?
It's a good pratice to "slow down" your fullscreen application when it looses the focus. Two reasons:
User may need to Alt-Tab and do something important (like closing a heavy application that's hogging the resources). When he switches, the new application takes control, and the OS must release resources from your app as needed
Modern OS uses a lot of GPU - this means it needs to release some graphics memory to work.
Try shutting down every GL resource you use when APPACTIVE=0 and alloc them again on APPACTIVE=1. If this solves, it was "your fault". If it does not solves, it's SDL (or GL or OS) bug.
EDIT: s/SO/OS/g
I have written a 3D-Stereo OpenGL program in C++. I keep track of the position objects in my display should have using timeGetTime after a timeBeginPeriod(1). When I run the program with "Start Debugging" my objects move smoothly across the display (as they should). When I run the program with "Start without debugging" the objects occationally freeze for several screen refreshes then jump to a new position. Any ideas as to what may be causing this problem and how to fix it?
Edit: It seems like the jerkiness can be resolved after a short delay when I run through "Start without debugging" if I click the mouse button. My application is a console application (I take in some parameters when the program first starts). Might there be a difference in window focus between these two options? Is there an explicit way to force the focus to the OpenGL window (in full screen through glutFullScreen();) when I'm done taking input from the console window?
Thanks.
The timeGetTime API only has a precision of something like 10ms. If the intervals you're measuring are less than 50ms or so, you may simply be seeing the effects of the expected variance in the system timer. I have no idea why the debugger would have an effect on this, but then the whole workings of the system are a black box. You could use the QueryPerformanceCounter to get higher-resolution timings, which may help.
The most common thing that causes any program to behave differently while being debugged and not being debugged is using uninitialized variables and especially reading uninitialized memory. Check that you're not doing that.
Something more OpenGL specific - You might have some problems with flushing of commands. Try inserting glFinish() after drawing every frame.
It might also be helpful to somehow really make sure that when the freeze occurs there are actually frames being rendered and not that the whole application is frozen. If there are its more likely that you have some bug in the logic since it seems that OpenGL does its job.