What is the fastest way to capture a screenshot in Windows? A driver? Using DirectX?
The fastest way would be to read mapped region of video card memory I think... Just an idea, never tried that.
A while back I timed the win32 api and the .net wrapper. Here is the complete blog post:
http://blog.bobcravens.com/2009/04/fastest-screen-capture-using-c-vista-vs-win7/
The upshot is that the .net wrapper in the latest version of Win7 is as fast as the native win32 api. I have never tried DirectX or the other options. The .net wrapper was fast enough for my purpose. I have heard that accessing the video drivers (like VNC does) is the fastest. I have nothing to back that up, but it seems reasonable.
Bob
Related
I obviously don't think it would work as it is. Its more like, does Windows internal architecture allows for some third party SW to integrate in between? From what I read about Compiz, I believe it creates its own window, and somehow mixes graphics from System X to its own. But it still has to catch events like EXIT button and so on.
Does Windows even allow this? Let 3rd program to scan for input of another window? And more, catching output of GUI and replace it?
Does Windows even allow this? Let 3rd
program to scan for input of another
window? And more, catching output of
GUI and replace it? Thanks.
It is certainly possible. See WindowBlinds for an example. Just note that Windows "officially" does not support this, applications like WindowBlinds use API hooking, subclassing etc. to perform their deeds.
Windows does not natively allow it - it has its own compositor framework built in called DWM that does much of the same internal functionality as Compiz. However, glitzy graphics that are systemwide are reserved for the OS to perform, sadly. As other people mention, doing this as a 3rd-party app is going to be really hacky and difficult.
API Hooking:
http://www.codeproject.com/KB/system/hooksys.aspx
Also, look at:
http://yodm-3d.en.uptodown.com/
A free 'Compiz' for Windows.
There was a smbmrx sample code using RDBSS in WDK Vista.
But since WDK 7600 has been released, the sample was removed. -Do you know why?
I'm finding a nice sample code to learn RDBSS.
Is there a good open source better than smbmrx sample?
It was probably removed because it was getting long in the tooth. It was never the full SMB redirector implementation shipped with Windows, it was some subset of the original version. It also uses TDI which is being deprecated in newer Windows in favor of WSK.
I don't know of any good open source examples. A network redirector is a complicated piece of software to write and there's value there for anyone brave enough to go for it. Why do you need this?
-scott
What GUI toolkit does Valve use for Steam? Is it Qt? I am interested in using the same toolkit for a project.
According to Valve itself:
"VGUI is Valve's proprietary Graphical User Interface. All Source and Steam applications use VGUI to draw windows, dialogs and menus. It also handles localization: the displaying of text in the user's preferred language. "
That's interesting, maybe if you guys do some research you can have it working in your programming language. I'll download the SDK to see if I can make it work with Java :)
http://developer.valvesoftware.com/wiki/VGUI_Documentation
Having had experience with the Source engine I know that Valve have an library called VGUI which they use for all their games and many of their tools (when in game the library sits on top of the Source renderer, when in tools it sits on top of the Windows API I believe). Although I can’t answer the question with 100% certainty I suspect that this is what they use for Steam as well (I seem to recall some Steam updates that mentioned VGUI) – I would be surprised if the new beta uses a different library.
Even if it is not using VGUI, given what I know of Valve I would think they will have written something else entirely in-house.
So, it is (almost certainly) proprietary and highly unlikely to ever be available for third party use (unless you have the funds to buy a Source engine license).
Steam only runs on Windows and predates QT for Windows, so I'd have to guess something else.
Since Steam has had the same GUI since 2003, chances are it uses some variant of MFC. It also uses an embedded Internet Explorer web browser for its Store and Community sections.
However, I can't give any guarantees about what the version currently in Beta uses. It looks quite a bit different and includs the Webkit rendering engine instead of using IE. It may use Webkit for everything rather than drawing their own GUIs.
Does this answer the question?
http://games.slashdot.org/story/10/02/25/0640233/Steam-UI-Update-Beta-Drops-IE-Rendering-For-WebKit
I am trying to learn a little about driver development and my question is, which OS has an easier API to develop drivers with? Windows or Linux?
Remember that I am new to this.
Thanks
If you are doing this for learning (I guess its your case), then go for Linux, you will have a more general ideal on how an OS works, you will interact with low level implementation straight to the core.
If you are just writing a driver for a device, I recommend using Visual Studio under Windows, it has a lot of features that will really help on your devel.
I am pretty sure you'll get lots of Windows vs Linux war here, unfortunately.
On Windows, you'll get pretty good development tools, with some awkward stuff, but that you can get along with easily. API is documented provided you have access to a Windows Developer account. Remote debugging is supported and it helps a lot for these kernel stuff that are triggering BSOD so quickly.
On Linux, you'll need to get your hands more dirty. Rubini's "Linux Device Drivers" is a very good starting point. Openness will bring you more flexibility, and more understanding of what is happening.
This tutorial might be helpful.
It is about writing a simple device driver for linux.
My personal idea is Linux. You can see the entire code other than an API.
I think Windows is good.
Because it has a rich set of API's which is easier to use
I'm making an application where I will:
Record from the microphone and do some realtime processing on the input
Play an MP3 file (a regular song), but manipulating the output in realtime
Every now and then I'll need to play additional sounds over this song too, but I guess I can do that by simply adding the buffers.
In short, I need to have circular buffers for both recording and playing, and I need to be "feeding" the output buffer every 20 ms or so with the new data that is just about to be played.
I've been looking at DirectSound, and it doesn't seem to help a lot. The reading and writing to the output buffers seem very similar to Win32, the only place where it seems it'd help is in playing the "additional sounds" over the main song.
Should I use DirectSound, or should I go straight to raw Windows APIs?
Is DirectSound going to do anything for me?
Thanks in Advance!
The Directsound API's give you better realtime control. They are also the supported way to use sound in Windows. I was under the impression that the win32 api's were depracated, but I could be wrong on this.
This question is close to yours
https://stackoverflow.com/questions/314522/what-is-the-best-c-sound-api-for-windows
also
Is DirectSound the best audio abstraction layer for Windows?
last but not least, this is what microsoft has to say http://msdn.microsoft.com/en-us/library/dd370784(VS.85).aspx
Neither? :)
The story is that DirectSound is the replacement for waveOut, but DirectSound joined DirectInput as deprecated APIs in Vista and is replaced with WASAPI. DirectSound and waveOut are implemented on top of the User-Space WASAPI in Vista. On XP, waveOut and DirectSound feed to the same kernel level Mixer API.
To consolidate all of these interfaces take a look at something like OpenAL, it's a well supported audio standard along the same lines as OpenGL.
It sounds like you're going to be quite sensitive to latency. It might pay to look at ASIO
I found Harmony Central - Audio Programming. Also read w:DirectSound.
Windows Vista features a completely
re-written audio stack based on the
Universal Audio Architecture. Because
of the architectural changes in the
redesigned audio stack, a direct path
from DirectSound to the audio drivers
does not exist.
Because of Xbox 360 and Microsoft
Windows integration, Microsoft is
actively pushing developers to migrate
new applications to equivalent Xbox
audio APIs such as XAudio and XACT.
OpenAL looks promising.