Quote:
Originally Posted by madshi
So I don't see any problem with a large subtitle queue.
|
It's helpful to layer & stagger even different types of CPU queues in my experience. With the first/top queue in a display chain being the largest, while the ones which follow being progressively smaller but with higher CPU thread priority than the prior queues in an attempt to ensure they stay full in real-time under heavy load. The logic is that the largest fast-filling queue have enough of a buffer to prevent the slower-filling queues below from emptying below 100% full, if you temporarily become bottlenecked.
Though my main concern that I thought you'd catch on to, was cases where you need to re-request and re-alphablend your entire subtitle queue instantly because of that change you made in 0.86.2 to decrease update delay on resolution change. I already saw this as barely acceptable with a CPU queue of 24. But now with a queue of 128, I end up with ~80 dropped frames (i5-3570K @4.4Ghz) as the subtitle queue attempts to refill, which could take a couple seconds if something computationally heavy is being displayed for the entire queue size. It would only be worse with slower CPUs. With a smaller queue, this effect would be minimized or eliminated. If you don't want to separate the CPU and Subtitle queues, maybe you should consider expanding the "delay playback" option to wait for subtitle queue to be completely full for "playback start", "seek", and "window resizing".
IMHO, you need to make one change or the other, otherwise user experience will suffer with large CPU queue + Subtitle queue size.