Closed ababo closed 3 years ago
To answer your question: No, I dont believe anyone would use it. Whats your use-case? Your asking for a blocking version of this. This sounds good on the surface, but the time to retrieve the frames would vary widely due to the Waiting which must occur, and on both windows and mac these versions consume a significantly higher amount of CPU as well -- a difference between 5% and like 30% usage so I didn't implement them. This again is due the synchronization which occurs in the OS and in this library while it waits for the data from the OS.
If u want to do a PR for this, i'd be open to it!
Gonna close this soon if we cant start a dialog on this
The problem is that my code base is based on maintaining threads and timers itself instead of relying on a third party. So I have added a workaround at the cost of excess copying. Feel free to close the issue, but I'm still confident the library should provide direct access to screen capture instead of (or in addition to) passing callbacks.
I hear you... Ill create a blocking version of this, its actually not too bad to write the code. Ill see what I can do in the next few days.
If you want to take a stab at it and do a PR that would be cool too 👍
Im gonna close this as trying to grab a screen shot on demand is beyond the scope of this project. This library is event driven which gives the greatest performance. If a blocking version is required. PR's are accepted!
I would like to capture frames on demand, without using your timer and callbacks under the hood. Is that supported? Thanks.