Accessing screen capture image bytes with MapFlags.DoNotWait for better CPU usage about windows.ui.composition-win32-samples HOT 3 CLOSED

One thing I forgot: I realize the more usual way to use a buffer is to just keep two staging textures and cycle between them. One is being used in the background by the GPU to copy, while the other one should be "ready to go" and I can access the data. Each iteration (frame arrived) I swap them over.

However, I did not manage to make this work, because I don't understand how I can guarantee that the texture will be ready by the time the next frame arrives. And if it isn't ready, then I have no data at all. I started experimenting with 3 or even 4 textures in the buffer but in the end I decided keeping a list of arbitrary size (but always removing the unused ones) was the better choice...

from windows.ui.composition-win32-samples.

This is more of a D3D11 usage question, you'll get better answers from that community. The DirectX folks have set up a Discord server you can join: https://devblogs.microsoft.com/directx/hello-discord/

As for your question, I would use a collection of staging texture with two concurrent queues while moving the encoder/sender to some other thread. I'll refer to the two queues as the 'free' queue and the 'busy' queue. When you receive a frame, pull a staging texture out of the free queue and copy the frame into it. Then put it on the busy queue.

Later, the encoder/sender thread will pull off of the busy queue, map the texture, and then send the bytes across the wire. When it's done, it'll put that texture back onto the free queue.

But this will all be contingent on what scenario you're after, and how you encode and send data. I highly recommend identifying metrics you can measure and profiling your application.

I'm going to close this issue, as it's outside the scope of these samples. Good luck!

from windows.ui.composition-win32-samples.

Hi guys, any progress?

from windows.ui.composition-win32-samples.