[Poll] Expose present surface object as in Framegrabber as event?

Add the patch to SVN?


  • Total voters
    7

gemx

Retired Team Member
  • Premium Supporter
  • October 31, 2006
    1,972
    113
    Yes, you are right.
    I changed it to LockFlags.ReadOnly with measurable effect though.

    I noticed that i measured the time it takes to copy the screenshot the wrong way and now i get different results:

    It's about 0 ms mostly with some peaks were it is ~16 ms but just for 1 frame. Then 0 ms again.

    What surprises me is the fact that this is the same regardless if i have 1080i or SD TV or i am grabbing the whole screen or just a small portion of it.

    How can that be?
     

    Mr Hipp

    Retired Team Member
  • Premium Supporter
  • April 2, 2006
    1,261
    63
    52
    Malmö
    LockRectangle is like a mutex for the texture. And when you are inside lockrectangle you can access the textures private data. Then you create a bitmap that has no
    bitmap data of its own, only a pointer to the private data of the texture. That is why you can't return a bitmap. You must do any processing (reading) within the lock /unlock pair.
    I guess you sometimes get 16 ms because some other part is locking and updating the texture.
     

    gemx

    Retired Team Member
  • Premium Supporter
  • October 31, 2006
    1,972
    113
    Thanks Mr Hipps for teaching my some more details :) :D

    I think we can close this thread now as it doesn't lead anywhere.
    It's not really worth to change it since GetCurrentImage() doesn't block the rendering process because of the lock... statements the current implementation shouldn't be a problem.

    Also all other known plugins which use this function call it with 1 sec delay so it's not that important if takes 10 ms or 50 ms.

    Regarding the Atmolight plugin i again played with the backbuffer and also applied the optimized techniques we discovered in this thread to resize an image in GPU mem (stretchrect) and to copy it to sysmem (lockrect).
    The result is that i get a framerate of ~ 27 fps regardless of HD or SD because the framegrabber only gets the image from the evr renderer thus only video but the backbuffer contains the whole desktop.

    Since we only have 50 Hz and 60 Hz content ~ 27 fps grabbing rate is absolutely fine for Atmolight and CPU usage is also hardly measurably, so i am fine now without the need of a patch :)

    Although the result of this thread is that we drop the request and i think we all learned a bit more about using DirectX in an efficient way.

    Thanks to all we gave their 5 cents :)
     

    Mr Hipp

    Retired Team Member
  • Premium Supporter
  • April 2, 2006
    1,261
    63
    52
    Malmö
    Thanks Mr Hipps for teaching my some more details :) :D

    I think we can close this thread now as it doesn't lead anywhere.
    It's not really worth to change it since GetCurrentImage() doesn't block the rendering process because of the lock... statements the current implementation shouldn't be a problem.

    Also all other known plugins which use this function call it with 1 sec delay so it's not that important if takes 10 ms or 50 ms.

    Regarding the Atmolight plugin i again played with the backbuffer and also applied the optimized techniques we discovered in this thread to resize an image in GPU mem (stretchrect) and to copy it to sysmem (lockrect).
    The result is that i get a framerate of ~ 27 fps regardless of HD or SD because the framegrabber only gets the image from the evr renderer thus only video but the backbuffer contains the whole desktop.

    Since we only have 50 Hz and 60 Hz content ~ 27 fps grabbing rate is absolutely fine for Atmolight and CPU usage is also hardly measurably, so i am fine now without the need of a patch :)

    Although the result of this thread is that we drop the request and i think we all learned a bit more about using DirectX in an efficient way.

    Thanks to all we gave their 5 cents :)
    One more thing :) If you are going to use stretchrect make sure alpha blend is off before you call stretchrect. There is quite a bigg difference in performance.
     

    Marvman

    Retired Team Member
  • Premium Supporter
  • November 14, 2007
    1,163
    83
    Bavaria
    I'm using the the Framegrabber in IFC. I have no problems with stuttering even on my "new" desktop (GT 8500) nor on my old dev laptop (Intel onboard GRAKA).
    But some user reported, that they have stuttering with HD stuff, when they use IFC. And we figured out that the stuttering comes from grabbing the frame not from the analyzing of the grabbed picture. So if we know better solutions to grab a frame we should use it/implement it.
     

    gemx

    Retired Team Member
  • Premium Supporter
  • October 31, 2006
    1,972
    113
    Well, the proposed solution is based resizing the surface in the GPU so that you only have to copy the resized image from GPU to CPU which is a time/cpu cycle saver.

    So if IFC and such really cause stutter than this patch will certainly cure it given the fact that IFC uses the new function :)

    So, i guess, the votes have changed 3 for yes and 2 for no.

    I think we need a decision :)
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    113
    I think we need a decision :)
    I'm willing to change my vote to yes if there suddenly happens to be a patch for that multiseat skip step issue so that we don't have to fall back that SMB hack for 1.1.0 release :D I'm sure few others will change the mind as well :D
     

    gemx

    Retired Team Member
  • Premium Supporter
  • October 31, 2006
    1,972
    113
    Ok - ok :oops:

    So, the question is - do we totally drop this request or open a mantis with target 1.1 final ?
     
    Top Bottom