Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Desktop Duplication API Grabber #41

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

psieg
Copy link

@psieg psieg commented Dec 23, 2014

Use the Windows 8 Desktop Duplication API to capture the Desktop on Windows.
Up to 4x FPS compared to WinAPIGrabber, no DWM-stuttering and lower CPU usage.

see http://msdn.microsoft.com/en-us/library/windows/desktop/hh404487%28v=VS.85%29.aspx

I've built with qmake-generated vcxproj's, not tested with msys or other OSes.

@tkhduracell
Copy link

Excellent work, any progress on this?

@psieg
Copy link
Author

psieg commented Jan 16, 2015

It is somewhat sad there is no reaction at all from woodenshark.
For the time being I can only recommend my fork's master which includes all my improvements or the feature branch. If you are looking for binaries, I have not tried building installers (and actually hoped I would not have to)

@tkhduracell
Copy link

Will try this (your fork) as soon as a get my Lightpack on a Window 8 machine, thanks. I hope woodenshark responds...

@Boost9898
Copy link

Bump, Woodenshark.

@psieg
Copy link
Author

psieg commented Jul 23, 2015

Given the nonexistent response from Woodenshark, here are my unofficial binary builds: https://github.com/psieg/Lightpack/releases
Please let me know whether they work for you, I haven't tested on a non-developer PC.

@valentijnvenus
Copy link

Thanks a million!

(BTW. We you be in the position to make a build for Mac OS X too?)
On 22 Jul 2015 10:42 pm, "Boost9898" [email protected] wrote:

Bump, Woodenshark.


Reply to this email directly or view it on GitHub
#41 (comment).

@S3RgY
Copy link

S3RgY commented Jul 23, 2015 via email

@psieg
Copy link
Author

psieg commented Jul 23, 2015

@valentijnvenus I don't have a mac and short googling says it's rather hard to build OS X packages on Windows or Linux, so that doesn't look good. For the same reason my changes don't affect OS X at the moment, so there wouldn't be much difference anyway.

@Boost9898
Copy link

@psieg Ehm, it won't work for me. I have Windows 8.1 64 bit.

@psieg
Copy link
Author

psieg commented Jul 24, 2015

@Boost9898 can you be more specific? What does not work? Since that will probably blow this PR, please create a issue at https://github.com/psieg/Lightpack/issues and provide log files (C:\Users\YourName\Prismatik)

size_t sizeNeeded = desc.Height * desc.Width * 4; // Assumes 4 bytes per pixel
if (screen.imgData == NULL)
{
screen.imgData = (unsigned char*)malloc(sizeNeeded);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@psieg , how do you think, is it possible to avoid allocating our buffer for the texture pixels?
It seems, that simple copying of the texture data to our buffer can eat a lot of CPU.
For example, see PR in my own fork for MacOS, https://github.com/dreamer-dead/MyLightpack/pull/2/files#diff-bb7f091bc59772f2f10989d037e6866cL139
It lowered CPU consumption on my machine.
For systems with 4K display resolution unpacked texture data can take a lot of memory.

Copy link
Author

@psieg psieg Aug 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some point, some color information needs to get back from GPU to main memory. Currently, this is the entire image. That's screen.imgData. Note this alloc happens only once, not every time a grab happens. By changing the interal interfaces, it might be possible to avoid the memcpy from map.pBits to screen.imgData, but I don't believe that is necessary.

The memcpy you removed in the Mac grabber was another unneeded one (I believe, I haven't read everything), which does not exist in the DDupl grabber. Could you post that PR against my fork, too, please?

The larger problem is getting data back from the GPU through the PCI bus, because GPUs are designed to work the other way around. With DirectX 10/11 this got way better (asynchronously), which is why Desktop Duplication works only on newer systems.
I run DDupl on my setup with 6000x1080 pixels and Prismatik takes 2% CPU use. Also note Desktop Duplication sends updated frames only when something changed. In Desktop mode that is roughly 15 FPS.

The only way of avoiding to send the full (4K) image data from GPU back to main memory is to do the average color computation on the GPU. Depending on which API is used, this may or may not be possible. I don't know whether that's possible with Desktop Duplication.

dreamer-dead pushed a commit to dreamer-dead/MyLightpack that referenced this pull request Aug 29, 2016
@Quetzacoalt91
Copy link

Not sure if this branch is still up to date, but I have tested your latest release on your fork @psieg, and I'm impressed by the performance improvement provided by the Windows 8 API on a UHD resolution.

Thank for your work, hope this feature will be brought on the main repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

7 participants