Bug: graphics update rate slowly drops over time

[kcbrown]

Start a cool-retro-term instance with the glow line enabled (this makes it easiest to see the problem) and let it run for a couple of weeks or so.

What you'll find is that the glow line will move very smoothly initially, but eventually the glow line will start to stutter, as the effective graphical update rate drops over time. It's not just the glow line, it's other graphical updates (such as the blinking cursor due to the burnin effect). Yes, it'll start at whatever you define it as (I have it set at 24 frames/second), but over time it'll apparently diminish.

This is reproducible on multiple GPU types in different environments. The amount of GPU power you start with may play a role. I've seen the issue in a VMware virtual machine with the 3D graphics driver enabled, as well as on a bare metal system with Intel graphics. It is reproducible at will as long as you're willing to wait long enough, though "long enough" might wind up being quite some time (on my systems it takes weeks). It may be easiest to reproduce in a virtual machine with the 3D graphics driver enabled.

The effect of this is that if you tend to leave your terminals running for extended periods of time, you'll eventually have to take action in order to restore the graphical refresh characteristics to what they should be.

There are a couple of things you can do to restore the update rate to what it should be. Obviously the first thing you can do is close the terminal and re-open it. But another thing you can do is, apparently, to change the effects FPS. This seems to "reset" the things involved in the pipeline and the result is restoration of smooth updates.

I've attempted to profile cool-retro-term in an attempt to discover where the additional time is going that ultimately causes this, to no avail. It's not clear to me how to discover the cause of this, given that.

[shmerl]

May be it eats all VRAM? Did you try monitoring it?

[kcbrown]

I doubt this is a VRAM issue. VRAM is (as far as I know) a shared resource and excessive usage by CRT would cause failures in other things. That's not the case at all, nor is there any activity in the system logs indicating any sort of problem there. So whatever this is, it appears to be purely internal to CRT.

[bradtchapman]

This doesn't strike me as an issue of running out of VRAM. It does appear to be sensitive to the Effect FPS setting, especially if you crank it to "Max." No one should be doing this except those with the flex of having a high refresh rate display. It's more likely that there is some internal timer for the effects that's getting screwed up by "max."

@kcbrown : you have discovered, as I did while testing for #836, that modifying the Effect FPS "restarts" the timing of effects like the rolling glow line, and the persistence ('burn-in').

[kcbrown]

This doesn't strike me as an issue of running out of VRAM. It does appear to be sensitive to the Effect FPS setting, especially if you crank it to "Max." No one should be doing this except those with the flex of having a high refresh rate display. It's more likely that there is some internal timer for the effects that's getting screwed up by "max."

@kcbrown : you have discovered, as I did while testing for #836, that modifying the Effect FPS "restarts" the timing of effects like the rolling glow line, and the persistence ('burn-in').

This issue occurs even if you have the FPS set to a value. I usually use a value of 24 FPS.

So there doesn't seem to be any avoiding it, near as I can tell. And this clearly means that "max" has nothing to do with it. It may be a problem with the internal timer or it may be something else. I can't say, and haven't figured out how to determine what's behind it. If root cause determination was something I could figure out how to do then I'd have already done it.