-
July 24th, 2015, 09:02 AM
#16
Re: GDI - can i speed up the DIB code?
Originally Posted by Cambalinho
with more search, i found 1 code much more faster:
That's cool, but I wonder if it will be any faster than my last posted code.
This example does pretty much the same thing, but it manipulates region data directly.
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
July 24th, 2015, 09:03 AM
#17
Re: [RESOLVED] GDI - can i speed up the DIB code?
Originally Posted by Cambalinho
VladimirF : i'm sorry, but i can't rate you
but thanks for help me
you are welcome
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
July 24th, 2015, 09:06 AM
#18
Re: [RESOLVED] GDI - can i speed up the DIB code?
i prefared to use my last code with your correction(not so confusing). thanks for all
-
July 27th, 2015, 07:50 AM
#19
Re: [RESOLVED] GDI - can i speed up the DIB code?
Reading pixels (or bitmaps) from the screen is a very slow process. This happens because for reading to happen, the actual video memory must be fully updated and synchronised. This can't be resolved since part of the video rendering pipeline is entirely hardware based, and windows itself can't know what pixels will be there until the video hardware has done all the screen writes, has blocked updates and allowed access of video memory to windows GDI. (there's also a DRM issue in there, but that typically doesn't impact performance much).
Typically speaking, you won't be able to go anywhere beyond 50-60 something reads per second. on a typical machine however, it could be as low as 10 reads per second max.
What's worse is that screen reads impact the entire system, and you will notice the FPS rate of other programs like games/videoplayback slow down to the same update rate (again, this happens because video access needs to be "locked").
There's no easy way around it... It's entirely dependant on the videodriver and it's integration into the WDM. From my experience it appears that nVidia cards tend to be "bad" at this, and ATI radeon cards are "worse". THere's a handfull of videocards that perform wonderfully, but they do not offer 3D hardware acceleration. I have PC with an older nVidia card that does "ok" at this and I still use that machine for screen capture for that reason alone.
You may be able to get around it by not reading from the entire screen DC, but instead reading from a particular Window DC. This may not help at all however.
- DirectX and OpenGL tend to not go via a window DC and instead their canvas/surface is rendered directly to screen (this gives extra speed since no system memory needs to be updated and the WDM compositing remains entirely inside the video memory.
- The same is true for many videoplayback mechanisms even if they don't use DirectX/OpenGL but use accelerated DIB's instead.
- Video that is rendered by the videocard such as a TV tuner, or a external signal (hdmi/RGB/composite video/...) displayed in a window also never makes it to system memory.
- ...
If you have the knowledge and time and stamina for it, you can create your own virtual video driver that allowes capture at full speed and that streams it's output into the actual videocard/driver. This gives full speed capture, but slows down actual rendering to screen a bit since you may need to skip frames towards the videocard.
Last edited by OReubens; July 27th, 2015 at 07:53 AM.
-
July 27th, 2015, 08:07 AM
#20
Re: [RESOLVED] GDI - can i speed up the DIB code?
Originally Posted by OReubens
Reading pixels (or bitmaps) from the screen is a very slow process. This happens because for reading to happen, the actual video memory must be fully updated and synchronised. This can't be resolved since part of the video rendering pipeline is entirely hardware based, and windows itself can't know what pixels will be there until the video hardware has done all the screen writes, has blocked updates and allowed access of video memory to windows GDI. (there's also a DRM issue in there, but that typically doesn't impact performance much).
Typically speaking, you won't be able to go anywhere beyond 50-60 something reads per second. on a typical machine however, it could be as low as 10 reads per second max.
What's worse is that screen reads impact the entire system, and you will notice the FPS rate of other programs like games/videoplayback slow down to the same update rate (again, this happens because video access needs to be "locked").
There's no easy way around it... It's entirely dependant on the videodriver and it's integration into the WDM. From my experience it appears that nVidia cards tend to be "bad" at this, and ATI radeon cards are "worse". THere's a handfull of videocards that perform wonderfully, but they do not offer 3D hardware acceleration. I have PC with an older nVidia card that does "ok" at this and I still use that machine for screen capture for that reason alone.
You may be able to get around it by not reading from the entire screen DC, but instead reading from a particular Window DC. This may not help at all however.
- DirectX and OpenGL tend to not go via a window DC and instead their canvas/surface is rendered directly to screen (this gives extra speed since no system memory needs to be updated and the WDM compositing remains entirely inside the video memory.
- The same is true for many videoplayback mechanisms even if they don't use DirectX/OpenGL but use accelerated DIB's instead.
- Video that is rendered by the videocard such as a TV tuner, or a external signal (hdmi/RGB/composite video/...) displayed in a window also never makes it to system memory.
- ...
If you have the knowledge and time and stamina for it, you can create your own virtual video driver that allowes capture at full speed and that streams it's output into the actual videocard/driver. This gives full speed capture, but slows down actual rendering to screen a bit since you may need to skip frames towards the videocard.
seems that the DirectX is the key for Audio and\or Video code.
but it's comples, now, for me. maybe, in time, i will learn it.
thanks for all
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|