[FEATURE ⭐] Guide for single frame capture on demand

[Elypha]

what i'm looking for

To capture a frame via a method call, which might look like

# init
capture = WindowsCapture(...
)

# call
def my_func():
    image: numpy.ndarray = capture.grab_frame()
    ...

and the use case is an automation script.

more details

I'm using the python lib and the workflow seems to me like starting a worker that streams back data (to the handler) of each frame that the app/window draws, if I'm not mistaken.

I found this issue https://github.com/NiiightmareXD/windows-capture/issues/1 about this topic. For the way you suggested, is it technically that the image bytes still get captured and dumped into a buffer https://github.com/NiiightmareXD/windows-capture/blob/main/windows-capture-python/windows_capture/__init__.py#L234 but just not processed (in the handler)?

If that is the case, I wonder if you could suggest a recommended way to capture a single frame on call, or maybe if we can have a separate method for this purpose, that is optimised for the time after each time the method is called until the image bytes are returned.

-- may I have a separate question that if my image handler requires a long time to run (longer than frame time), will there be multiple instances of handler running (trigger by each new frame drawn), or a running handler will block those coming after?

[NiiightmareXD]

I plan to create a separate function or module to enable capturing a frame on demand, even though it's already possible with the current implementation by storing the latest frame.

As for your second question, the handler will wait until the previous frame is processed and then send the latest available frame.

I will keep this issue open until single frame capturing is implemented in both Rust and Python.

[Cyanide0210]

I plan to create a separate function or module to enable capturing a frame on demand, even though it's already possible with the current implementation by storing the latest frame.

As for your second question, the handler will wait until the previous frame is processed and then send the latest available frame.

I will keep this issue open until single frame capturing is implemented in both Rust and Python.

The question that I have is.. isnt recording the frame buffer from the windows api all the time slow? I think adding a capture frame on demand could reduce the usage, is it even possible?

[NiiightmareXD]

I plan to create a separate function or module to enable capturing a frame on demand, even though it's already possible with the current implementation by storing the latest frame. As for your second question, the handler will wait until the previous frame is processed and then send the latest available frame. I will keep this issue open until single frame capturing is implemented in both Rust and Python.

The question that I have is.. isnt recording the frame buffer from the windows api all the time slow? I think adding a capture frame on demand could reduce the usage, is it even possible?

It doesn't update if I just wait in frame handler until a new frame is needed, so it should be possible