Question about UI rendering disparity in certain playback scenarios.

[Sneakpeakcss]

This might not be a bug so i figured that i'll try asking about this here.

While using a display script to show play/pause indicator on playlist column:

$if(%ispaused%,$rgb(255,255,255,255,255,255)$char(10074)$char(10074),$if(%isplaying%,$rgb(255,255,255,255,255,255) $char(9654),))

Whenever a song is switched manually by either: forward/backward buttons, hotkeys or clicking on playist, the mentioned indicator visibly flashes like it's being re-rendered again, but this doesn't happen at all while the next track is played when it's being automatically switched on track-end:

2023-05-04_15-09-24.mp4

 
And as seen on video… This isn't exclusive to this display script, since the Seekbar Thumb also flashes, Status Bar also has additional "Loading Track.." flash, and neither of that happens on the mentioned "track-end".

Out of curiosity i've checked CUI v1.6 and the behaviour seems to be the same so this doesn't look like something new:

2023-05-04_15-10-47.mp4

Additionally in v1.6 the Volume Thumb also flashes, which doesn't happen anymore in v2.
 
 
So my question is… Is this a bug ? An oversight ? Or is it simply working as intended.

The only thing that comes to my mind is something similiar i've encountered in Jscript, where in case of those actions (buttons/hotkeys/clicking) there's a chance that they activate playback from full stop so it re-paints the whole thing, which seems to be impossible in case of switching during track-end since it has to be already playing for that to happen.

[reupen]

So my question is… Is this a bug ? An oversight ? Or is it simply working as intended.

The answer is a bit of a 'yes and no'. When playback automatically advances to the next track, it is buffered before the previous track finishes. So playback is continuous. When you manually play a track, that buffering has not happened, so there's a gap. In that short gap, the UI isn't told which track is being opened – it only knows that a track is loading. Hence, you see the 'Loading track...' message in the status bar.

The title bar, seekbar and status bar behaviour are modelled on a very old foobar2000/Default UI version. The playlist view is essentially re-rendering whenever foobar2000 says it should.

So it is intentional, but at the same time glitching like that is also undesirable. It is probably difficult to do much about it in the playlist view, but in the other areas it could only show the loading state if it persists for e.g. more than 50ms.

It might be useful for you to check what behaviour you see in the current Default UI. As far as I can see, it behaves similarly, but with the glitching less obvious (perhaps it uses a delay like I mentioned).

[Sneakpeakcss]

It might be useful for you to check what behaviour you see in the current Default UI. As far as I can see, it behaves similarly, but with the glitching less obvious (perhaps it uses a delay like I mentioned).

That's the main reason i even noticed this. While i don't care much about the status bar, or thumbs flashing, the delay / flash on the play/stop indicator is annoyingly noticeable compared to DUI:

2023-05-04_18-39-38.mp4

At the beginning the indicator flashes few times while spamming LMB, but at some point it just stops.
During normal use(not spamming) when manually switching tracks with LMB, it renders the switch so fast that it's not noticeable at all.

The status bar seems to also have similar behaviour, but it's fast enough that it's impossible to notice in normal use, but like i've mentioned, my interest is mainly in avoiding that indicator flash/delay, which might not be possible.

[reupen]

Okay, I created an issue to reduce the flashing: #713