Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 608009" data-attributes="member: 10858">If thread context switch happens during a sleep (most likely it will since sleep is telling system that it is allowed to do it <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />) it could be as high as 10 ms that the sleep will take. And that is already almost the whole frame with 60hz display that the v-sync can &quot;travel&quot; during that time.Causing high CPU usage in that part of code is not a sin, it won't be causing any playback issues like it would be if done in some other places. Also since the v-sync is most likely already in the place the high CPU spike wont be a long one. After all, that part of the code should be doing only a small fine tuning to the paint position.I think the Sleep(1) was a relic, and shouldn't be there in the first place. Also I think I didn't see any CPU usage rise when busy polling in that part of the code.</blockquote>

[QUOTE="tourettes, post: 608009, member: 10858"] If thread context switch happens during a sleep (most likely it will since sleep is telling system that it is allowed to do it :)) it could be as high as 10 ms that the sleep will take. And that is already almost the whole frame with 60hz display that the v-sync can "travel" during that time. Causing high CPU usage in that part of code is not a sin, it won't be causing any playback issues like it would be if done in some other places. Also since the v-sync is most likely already in the place the high CPU spike wont be a long one. After all, that part of the code should be doing only a small fine tuning to the paint position. I think the Sleep(1) was a relic, and shouldn't be there in the first place. Also I think I didn't see any CPU usage rise when busy polling in that part of the code. [/QUOTE]

Verification