I'm trying to get a screenshot of windows using PrintWindow. Windows using hardware rendering are not captured. For example Chrome, Edge. In Windows 7 they are captured, but in Windows 10, 11 they are no longer there. There is a suspicion that this is due to the version of WDDM. Is there any possibility:
capture hardware rendering?
disable hardware rendering for the whole system?
Disable or otherwise affect WDDM?
I 've made a simple capture library here. Code is here and it's based on Desktop Duplication API. Microsoft sample is here. It uses hardware capturing.
My work primarily captures video with sound, but there is a frame callback you can use to capture a frame. Apparently it's the same API that is used to capture games etc.
Related
I'm wondering if anyone has any idea that capture audio from the device's microphone on the new Windows Phone 7 in background (Silverlight, not XNA)
or any code to do it?
Even in a Silverlight application, the Microphone is accessed via libraries in the Microsoft.Xna.* namespaces.
The use of such namespaces is not supported in a Background Task. See http://msdn.microsoft.com/en-us/library/hh202962(v=vs.92)
This is not possible and would break the security principle of not allowing apps to do something that the user isn't aware of.
I am developing a security related windows phone application. I need to disable/block screen capture for my application.
In Android, we used to set a flag FLAG_SECURE to the window of which we want to block the screen capture. Is there anything similar in wp7 also??
Thanks
You can't do screen captures on Windows Phone unless you use homebrew apps, so I wouldn't worry too much about it.
And even if there were screen capture apps on the marketplace, you would have no way to be safe. Even if you found a way to prevent screen captures, how would you prevent users from taking a picture of the phone with a camera, or sideloading the app on the emulator then making screen captures of the emulator?
There's currently no API available to developers that allows you to perform screen captures with a locked device.
The alternatives are as follows:
Unlock your device and sideload one of the homebrew based screen
capture apps.
Take a picture of the screen itself (Crude but it
would do the job).
Microsoft have stated that they do not intend to change this in the near future (CNET Article)
I have created a Flash game which plays at 60 frames per second. It plays fine in all browsers except Internet Explorer 8 and 9; in these cases, it seems to be half (or less than half) the intended frame rate.
I have tried embedding it even by using Flash Authoring Tool's own html code, as well as the swfobject method, but to no avail. In all cases, GPU acceleration is enabled.
It's also not a matter of CPU performance, since it is tested on the same computer with all other applications closed. The problem only rises with IE.
One final peculiarity to consider : I have loaded FRAPS to count the actual rendering frame rate and it shows it to be 60 fps (inside IE), although it's crystal clear that this is not the actual speed achieved.
sounds like flash isn't properly installed on your IE browser
Try the following (assuming you have Adobe Flash Player v10.2 installed):
• Restart your computer.
• Open Internet Options (located in the Control Panel).
• Click on the Advanced tab.
• Click on the Reset button, place a check next to Delete Personal Settings and then click Reset.
• Launch IE9 and Adobe Flash Player will be properly enabled.
then try your tests again
GPU acceleration is not always the best solution. It depends on the way you have code the app.
Try another wmode value.
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.
I'm looking for writing virtual camera drivers. Does anybody has idea?
Any book that would be helpful or any link.
Adding more details:
I have developed a device driver which saves the image to disk and the display uses the device driver to display the image. The performance does not seem good.
The fns. that I have used are:
//to capture
GetDesktopWindow()
CreateCompatibleBitmap()
Save()
//to display
WM_MOUSEMOVE
giving a call to capture and display every time
but the display is not continuous and appears only after window goes out of focus and comes in focus again
Should I use some other technique to record or display images, what will give fruitful results, please help.
Thanks,
-mitesh
What do you mean by virtual camera driver?
It is possible to write a virtual capture device using DirectShow. Such a virtual capture device can then be used by applications such as skype, etc. If that suffices for your needs, you can download vcam from http://tmhare.mvps.org/downloads.htm under the "Capture Source Filter" link.
Edit:
In order to use that capture device in the link I posted you need to download the Windows SDK. The Windows SDK has a tool called "GraphEdit" If you search online, I'm sure you can find a quick GraphEdit tutorial. Basically GraphEdit allows you to construct a multimedia pipeline by connecting a bunch of filters. (This is what happens in the background for instance when you play a movie on your computer. ) This could be something like
web cam -> renderer
or
file source -> some decoder -> renderer
and would result in you seeing the video captured by the web cam or the content of the file. The example download shows how you can construct a virtual capture device i.e. it looks like media is coming from a 'real' capture device, but actually you can generate any video you want if you adapt the code to your specific means i.e. take a screengrab and output that. Applications like skype can pick up you virtual capture device if it is registered correctly.
The easiest way to find out if this is sufficient for your needs is to download the capture source filter, register it with the regsvr32 command, and then to use GraphEdit to insert the capture source into a graph, connect the source to a video renderer and hit the play button. A lot of the above mentioned concepts/keywords might seem new to you, but you can do some reading on each topic, and perhaps this will give you a point to get started.
Edit 2:
Is the capture source filter approach not sufficient for your requirements?
1) AFAIR you stated in your (now deleted) answer that you would like to take a screen grab, and use that as a virtual camera device for use in applications such as skype.
If that is all you require, you do NOT have to write a device driver. DirectShow can do that perfectly well by means of the capture source filter. You would then need to
learn some basic DirectShow
modify the source code of the capture filter to take screen grabs etc.
As far as books are concerned to write device driver to accomplish the same, I have no idea. The point I'm trying to make, is that you need to determine whether you actually need to write a device driver or whether simply modifying the open source capture filter is sufficient.