I am using BitBlt heavily in my project. I create a number of threads and in each thread I capture the screen by BitBlt. It works great and as expected for now except the following problem.
The problem happens when the user clicks on a running program or for example already opened explorer on the taskbar. You know when you click on the running program on the taskbar, it either minimizes or appears on the screen. The issue that I am talking about happens just in this transition. At that moment, something like an interrupt, all threads stop capturing the screen for a fraction of a second and then they continue capturing. The same thing happen when you move down or up the thing on the volume control window. Could you please shed some light why this is happening and how I can prevent this happening?
Thanks.
Jay
It could be a scheduling issue. When you activate an app, it gets a small, momentary boost in its priority (so that it can seem responsive in the UI). This boost might last about as long as the animation and momentarily pre-empt your screen capture threads.
It's also possible that the desktop manager is serializing stuff, and your bitblts are simply stalled until the animation is over. Even if you've turned Aero off, I believe the desktop window manager may still be in compositing mode, which has the effect Hans Passant was describing in the comments.
If you're trying to make a video from the screen, I think it's going to be impossible to rely on GDI. I strongly suggest reading about the Desktop Window Manager. For example, this caveat directly applies to what you're trying to do:
Avoid reading from or writing to a display DC. Although supported by DWM, we do not recommend it because of decreased performance.
When you use GDI to try to read the screen, DWM has to stop what it's doing, possibly render a fresh copy of the desktop to video memory, and to copy data from video memory back to system memory. It's possible that the DWM treats these as lower-priority requests than an animation in progress, so by the time it responds to the BitBlt, the animation is over.
This question suggests that DirectShow with a screen capture filter might be the way to go.
Related
When Im debugging my app in VS2012 and it crashes, the input (mouse and keyboard) starts to lag extremely, the fps drops to about 0.3 or less and I can't even move my mouse without waiting 3 seconds... The only solution is to do Shift-F5 which will end the debugging, and everythng is fine then again.
Whats more interesting, the only lagging thing is the input, the whole background works perfectly fine, text caret is blinking at normal rate and tooltips are nicely animated when mouse gets over a button.
Im compiling the project with allegro 4.2 (I have to use it, it would take too long to explain why).
I have no extensions, a pretty fast pc which should be able to handle debugging...
Im interested in any solution, it may be dirty/hackish... I can of course provide more information if needed.
Thanks for any help.
EDIT: Reading through forums I found some information about the "Auto" window or something like that (don't remember exactly and can't find it anymore), which is doing some "background tasks" and that causes lags... Do you think running it on separate core would fix that?
A tale of multi-second stalls when hitting a breakpoint, related to the raw input API: http://the-witness.net/news/2012/12/finding-and-fixing-a-five-second-stall/ (archived)
It's a very long time since I last saw this sort of thing myself, but I seem to remember that the culprit in my case was DirectInput. (This makes some sense, given the tale above, as DirectInput has long been a wrapper over the raw input API.) And I think the solution was to use the emulated keyboard and mouse devices rather than the default ones, which you do this by passing in one of the emulated device GUIDs to IDirectInput8_CreateDevice. Discussed briefly here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416845%28v=vs.85%29.aspx
(I don't remember whether cooperative and exclusivity levels made a difference - it might be worth trying changing these too.)
I recently experienced the following similar issues while debugging a game:
Hit a breakpoint, halting the program for debugging.
Pressing any key now takes around 1 second to "process". It will be buffered and sent slowly one after another to whatever window is now active.
In my case, the application installed a low level keyboard hook with SetWindowsHookEx(WH_KEYBOARD_LL, ...). After removing this (for !NDEBUG builds only as you wish), the input lag was gone.
I suppose the hook cannot respond at all while your application is halted, and eventually the system skips it after a timeout, which length can be configured in milliseconds under HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout:DWORD as mentioned here. In fact, the link in the accepted answer mentions this issue, but I thought I explain the core of it right here, also because the link went dead before I fixed it.
Try to find such a hook in your application or dependencies, and check if removing it helps. Since you mentioned this happens to your mouse too, check for a (low level) mouse hook (WH_MOUSE_LL) aswell. The available hooks are listed on MSDN.
In my OpenGL application I switch between windowed and fullscreen mode using
Raymond Chen's solution:
http://blogs.msdn.com/b/oldnewthing/archive/2010/04/12/9994016.aspx
This works apart from two very annoying side effects when used in a
multi-monitor setup (only):
After the window mode was switched BOTH screens flicker/flash just in the
moment glViewport is called to accommodate the changed window dimensions.
Windows on the desktop from other applications are not painted correctly
after the switch until I e.g. minimize/maximize them (or do something similar
to force a refresh).
Does one know these effects and maybe also knows a solution?
ps: further tests showed that this only happens on my PC with an AMD card but not with my Nvidia card. If only one monitor is active it doesn't happen at all.
I am programmatically animating a window to make it bounce around the desktop, using MoveWindow.
It's leaving a temporary ghosting effect of the previous portion of the desktop the window that
it occupied.
How does one prevent this happening ?
That's somewhat inevitable on older versions of Windows. The processes whose windows you overlap need time to update the part of the window that got revealed when you moved your window. Do check that your program isn't burning 100% core with taskmgr.exe, that would make it much more noticeable.
A real solution for this problem requires Aero, available on Vista and up.
This library does exactly what I am talking about on Linux systems: http://ichi2.net/pyosd/
My knowledge of Win32 API is limited but it seems to me that unless you create a window and enter the win32 main loop, you cannot do it. Some Googling also confirmed that.
Even so, are they newer GUI frameworks or technologies that would make it happen on windows?
Thanks
You don't need no stinkin' GUI frameworks. You can either:
Draw directly on the desktop. Of course, this is not generally considered a good idea, since it's mucking around with the internals of another application. Drawing this way is also quite fragile because your changes are erased each time the desktop repaints itself.
Create a transparent, layered window that you draw onto, which will appear over the desktop. If you specify that this window should be a top-level window, you could also have it appear over all of the other windows on the desktop.
There is absolutely nothing that forces windows to be rectangular gray-colored boxes, and since each window provides a device context that you can draw into, you can let your imagination run wild.
I've noticed that the running times of my CUDA kernels are almost tripled the moment the screensaver kicks in. This happens even if it's the blank screensaver.
Oddly enough, this appears to have nothing to do with the power settings. When I disable the screen saver and let the screen power off, the performance stays the same. When I set the "Turn off monitor" to "Never" and lets the screen saver kick in, it happens.
Why does this happen?
Is there a way to counteract this phenomena?
Is there a way to tell windows not to kick in the screen saver? (How do media players do it?)
I'm working on XP SP2 x64
Firstly, its interesting that CUDA is so impacted.
But here is the recipe in win32 for avoiding the screensaver kicking in:
A normal approach is to send yourself 'fake' key presses occasionally using the SendInput API, to reset the inactivity timer that triggers the screensaver.
It is possible to stop applications doing this, however, using the SPI_SETBLOCKSENDINPUTRESETS parameter for SystemParametersInfo.
Another approach is just to turn the screensaver off programmatically, using SPI_SETSCREENSAVEACTIVE for SystemParametersInfo. However, this is a global setting for the whole user - what if two programs use this overlapping? Try to avoid this!