-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE ⭐] Guide for single frame capture on demand #50
Comments
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 |
can you please tell me how i can do it? been trying to figure out how to do it |
what i'm looking for
To capture a frame via a method call, which might look like
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 #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?
The text was updated successfully, but these errors were encountered: