Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 608400" data-attributes="member: 10858">If it were high CPU usage, it should have that stuttering / bad timing during the whole file, not just some parts. Stats collecting itself is not CPU hungry (modern CPUs can handle such load with ease) but the stats drawing code itself is GPU hungry, it takes many ms to draw those (at least on lower end GPUs). In any case, I would assume that it is more an issue with the algorithm than the CPU/GPU usage.The jumpy yellow line (which is basically the raster position when PresentImage(...) returns) is because it's hovering around the end/beginning of the raster - the 'SOP line:' number is the scanline when 'painting' starts after the vsync correction delay, 'EOP line:' is the scanline when it finishes - when PresentImage() returns.</blockquote>Ok, so mainly that is caused by the inaccurate &quot;entry&quot; to the :<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue&nbsp; &nbsp; :p" loading="lazy" data-shortname=":p" />aint() or in other words the inaccurate scheduling (scheduling is not v-sync accurate, only frame accurate and with 1:2 material it is not even that accurate <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />). So safe to ignore with your algorithm? (it isn't with the SVN / RC2, thats why I'm wondering).[/QUOTE]

[QUOTE="tourettes, post: 608400, member: 10858"] If it were high CPU usage, it should have that stuttering / bad timing during the whole file, not just some parts. Stats collecting itself is not CPU hungry (modern CPUs can handle such load with ease) but the stats drawing code itself is GPU hungry, it takes many ms to draw those (at least on lower end GPUs). In any case, I would assume that it is more an issue with the algorithm than the CPU/GPU usage. The jumpy yellow line (which is basically the raster position when PresentImage(...) returns) is because it's hovering around the end/beginning of the raster - the 'SOP line:' number is the scanline when 'painting' starts after the vsync correction delay, 'EOP line:' is the scanline when it finishes - when PresentImage() returns.[/QUOTE] Ok, so mainly that is caused by the inaccurate "entry" to the ::Paint() or in other words the inaccurate scheduling (scheduling is not v-sync accurate, only frame accurate and with 1:2 material it is not even that accurate :)). So safe to ignore with your algorithm? (it isn't with the SVN / RC2, thats why I'm wondering). [/QUOTE]

Verification