Conversation
Conflicts: Software/grab/grab.vcxproj Software/src/Prismatik.vcxproj
Conflicts: Software/grab/grab.vcxproj
Conflicts: Software/grab/grab.vcxproj
Conflicts: Software/grab/grab.vcxproj
|
Excellent work, any progress on this? |
|
It is somewhat sad there is no reaction at all from woodenshark. |
|
Will try this (your fork) as soon as a get my Lightpack on a Window 8 machine, thanks. I hope woodenshark responds... |
|
Bump, Woodenshark. |
|
Given the nonexistent response from Woodenshark, here are my unofficial binary builds: https://github.com/psieg/Lightpack/releases |
|
Thanks a million! (BTW. We you be in the position to make a build for Mac OS X too?)
|
|
Thank you so much, seriously
From: psieg
Sent: Thursday, July 23, 2015 8:58 PM
To: woodenshark/Lightpack
Subject: Re: [Lightpack] Desktop Duplication API Grabber (#41)
Given the nonexistent response from Woodenshark, here are my unofficial binary builds: https://github.com/psieg/Lightpack/releases
—
Reply to this email directly or view it on GitHub.
|
|
@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. |
|
@psieg Ehm, it won't work for me. I have Windows 8.1 64 bit. |
|
@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); |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
Update Checker
|
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. |
7 participants
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.