Improved loging in case of clamping visual position

[daschuer]

It turns out that the log spam discovered by @m0dB in #12470 is actually a bug.

This PR improves the log output and the negative side that is not a transport issue but a vsync issue.

It happens if the rendere requests a position of an already missed vsync cycle.

A solution is to detect that and advance to the next vsync cycle that has not yet passed.

[daschuer]

The problematic function is

https://github.com/daschuer/mixxx/blob/f610d58a25b6f97172b097fb2a7a79147d863f7d/src/waveform/vsyncthread.cpp#L188

Here we need to advance to the next interval if we have missed the vsync interval the values are prepared for.

@m0dB
What was the reasoning for the combined sync and render step in the PLL case. I have good results with the combined timer and pll version when I start the timers after swap.

I think it depends on the drivers implementation of vsync. When I remember correctly, the rendering waits to not introduce tearing for two reasons:

1. Swap is delayed just after the previous picture has been displayed.
2. rendering waits, when both buffers are occupied. One is in use for display, the other has already a pending swap.

Maybe macOS has a workaround for 1. and constantly hits 2.

I have seen both with different drivers.

Idea: Maybe we can use the PLL everwhere and just make the sync moment an option?

Next I will contribute a PR that moves the position request into the right interval in case of vsync misses.

[daschuer]

Requesting the right position was easy, I have added it here. Even the free mode is now working properly with ~500 Hz.

[ronso0]

Is there something missing in the first line?
Please fix the typos.

[daschuer]

Done.

[ywwg]

works fine on my machine

[m0dB]

Works fine here too, with both ST_TIMER and ST_PLL.

[JoergAtGithub]

Works for me too! Thank you!