My experience is that waitkey(1) waits AT LEAST a millisecond, when I use it to display an image in my code I see a delay of about 5 ms. Currently looking for a way around using waitkey to display an image and avoid that delay.
that’s why I’ve introduced pollKey. currently only works properly on win32 because I don’t care about (or can build/test) other GUI libraries.
“at least” comes from the granularity of the OS scheduler and how it treats sleep calls.
“at most” means it’ll wait less, if a key was hit.
you probably can’t. waitKey() will trigger the blitting, no update without it
(@crackwitz , pollKey() just drains the msg queue, but does not trigger any drawing messages, right ? (and that only on win32, else it will call waitKey(1)))
wrong. it absolutely handles messages, which causes drawing. it works until the queue is empty and then exits, instead of waiting/sleeping for new messages to arrive.
and yes, that’s win32. everywhere else (Qt, gtk, …) it’s a waitkey(1) because nobody came along and implemented this for other GUI toolkits that I can’t build or test.
yes, those things are misnomers. the choices were (1) stick with the naming scheme (2) keep it consistent but rename (then waitKey disappears/is deprecated) (3) be inconsistent.
1 Like