CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 20 of 20
  1. #16
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,656

    Re: GDI - can i speed up the DIB code?

    Quote Originally Posted by Cambalinho View Post
    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...

  2. #17
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,656

    Re: [RESOLVED] GDI - can i speed up the DIB code?

    Quote Originally Posted by Cambalinho View Post
    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...

  3. #18
    Join Date
    Apr 2009
    Posts
    1,355

    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

  4. #19
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    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.

  5. #20
    Join Date
    Apr 2009
    Posts
    1,355

    Re: [RESOLVED] GDI - can i speed up the DIB code?

    Quote Originally Posted by OReubens View Post
    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

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured