[Poll] Expose present surface object as in Framegrabber as event? (2 Viewers)

[gemx]

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]

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]

Thanks Mr Hipps for teaching my some more details

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

 

[infinite.loop]

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

We also have 24Hz HD content. At least mine is growing fast.

 

[Mr Hipp]

Thanks Mr Hipps for teaching my some more details

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]

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]

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

 

[chemelli]

3 : 3

:sorry:

but rules are rules for everyone.

Simone

 

[tourettes]

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 I'm sure few others will change the mind as well

 

[gemx]

Ok - ok

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