I’m asking for core developers to give a yay or nay on the following before I open an “issue” and pull request about it. other voices would be good to hear too, but I’m most interested in core developers’ opinions on this because that decides if I’m going to the trouble. Let me know if I should “just open an issue” on github for the discussion.
so I just noticed the big “5.0” issue pinned on github. since it contains an invitation to fix old warts, I have one or two.
at least on win32 (GDI or OpenGL), the imshow window has a gutter, i.e. thin gray border between window decoration and client area (the image shown). I fixed some off-by-ones a while ago, but didn’t outright remove that gutter. I think it should be removed. when using the full-screen option, the gutter causes the client area to be less than true screen size. any picture you try to show that’s screen-sized would be resized either by nearest neighbor (rows/columns removed) or resampled into a blurry mess.
the source for waitKey() (on win32 at least) does have the capability of event processing without having to sleep a single millisecond. I want that millisecond! a millisecond of mandatory wait, not even abortable by events/key presses, in some straight forward processing of video, is A SIZABLE FRACTION when you’re hoping to process at 60 fps or so (16 ms per frame).
In a first step, I would like to change the signature of waitKey (and waitKeyEx) to use
delay=-1 as the default argument (and maybe introduce a name like
WAIT_INFINITY for the value). that shouldn’t bother anyone because the source has always understood
delay <= 0 as infinity. it will take a while for people to notice that they shouldn’t pass anything to get infinity wait, or pass -1/WAIT_INFINITY.
various (example) code out there would be affected by the next step, so… if someone calls waitKey with
delay=0, maybe print a warning once to nudge people to change their code.
In a second step, I would like to change behavior such that
delay=0 actually doesn’t delay (instead of waiting infinitely as before). I think
waitKey(1) should still be implicitly propagated as the normal “least” delay because it keeps the CPU idle with little loss, while the newly facilitated
waitKey(0) has the potential for busy looping, if no other processing is done. the behavior and consequences should definitely be documented clearly.
for both issues I have (or will have) patches. I’d only need to know what to base against (assuming master branch).
Is that level of breaking backwards compatibility something that’s within the realm of consideration for OpenCV v5 or v6?