[I want to work on] Improving Retro Effects & Enhancing Overall Framerate / Performance

[platypus-winterberry]

Hello,

Windows Terminal version (or Windows build number)

1.12.2931.0

I want to work (code it myself**Contributing.md suggestion) on improving the Retro terminal effects and the general performance

Extending "Retro terminal effects":

Customization

-> Option to have scanlines, glitches, noise or custom shader

Improve the looks

Resources: https://github.com/Swordfish90/cool-retro-term
-> I WOULD LIKE the impact on my PC's resources to feel more lightweight
-> I WANT TO Add options for Frame rate configuration:
-> WITHOUT having shell dependencies that help me to optimize this
-> SO THAT I am able to take it with me anywhere e.g. custom shells, WSL , SSH, VIM etc
-> ADD the following configurable esthetic options:
- Scan lines,
- Burner effect
- CRT Screen-like bezel

I would also like to address one issue which I would like to see in Microsoft's terminal as I've seen it implemented in other terminals, changes which did help:

Frame rate Limitation
-> Frame rate limitation option: Adaptive FPS based on the throughput ( Terminal's memory-shock usage intake from the command that was ran as opposed to reading the computer's resources which may feel more heavy weight)

Performance improvements that are worth trying:
-> Word wrap tends to not go well with terminals, especially when esthetic additions such as Retro mode.
-> Having the option to change to Character Mode so when it reaches the end of a line and searches for a place to break does not take a memory impact
-> The user's custom configuration related to EOL on his computer/terminal/shell may result in a significant performance issue
-> Intel graphics driver may mess with the terminal's performance when the computer that have the battery settings configuration for auto graphics switching, connecting to an external monitor solves the issues( because it forces discrete graphics ) so having an option to force discrete graphics could be of use for users that do not specifically want to optimize battery life

[zadjii-msft]

Thanks for reaching out - lemme see if I can try and distill down some of these requests:

• Option to have scanlines, glitches, noise or custom shader
• configurable scanlines / burner effect
• configurable bezel mode

This sounds like #7013 to me. We already allow you to write custom shaders for the Terminal, and you can do some wild stuff with them.

AND I dont want to have shell dependency

no worries, the pixel shader path is totally separate from the shell.

• Framerate configuration
• Framerate limitation option: Adaptive FPS based on the throughput

Right now the Terminal is hard capped at 60fps - that's something we're working on, I don't really want to spoil the fun. The pr is coming soon^tm, but I'm not sure it's my place to discuss that one more. We won't paint more often than 60fps, and we'll only paint a frame when there's actual output or something that changed on the screen.

You might also be interested in #7147 - right now the Terminal needs to invalidate & redraw everything when pixel shaders are enabled. That definitely causes a noticeable perf hit when they're enabled, especially on laptops. I had a branch where I tried fixing that, just never had the time to drive it home. It might also just be fixed by the secret rendering thing I mentioned above, hence why I shelved it.

Word wrap tends to mess with therminals
Having the option to change to Character Mode
So when it reaches the end of a line and searches for a place to break and depending on the code, every profile should have an option to configure the EOL expectation

This I'm not sure I follow - the console&terminal don't do anything special to "find" a place to wrap a line. We just wrap it at the last character in the line. We're not trying to find a word break or anything, that's silly.

Did I miss anything?

[zadjii-msft]

Also,

we need to talk .... [crutkas: edited]

That comes across as a little derogatory - make sure when you want to contribute here to follow the code of conduct

[crutkas]

@assembly-guy I'm editing your post, you had a clear code of conduct violation.

Our GitHub is a safe spot for everyone and should make everyone feel welcome. Lets be positive and inclusive. Thanks for understanding.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[platypus-winterberry]

Hello @crutkas

I was away for holidays hence my belated response.

Sorry if the wording's reader impact came up as unwelcoming as opposed to what I initially intended which was a friendly dev joke as I was excited to see all the openness from your team's side - I guess it's not the time and place to yet get into jokes.

Should there be anything I still need to revise on my initial post, please let me know. I'm still up to working on the before mentioned improvements.

All the best,
Alex

[zadjii-msft]

I'm still up to working on the before mentioned improvements.

Does #7013 and #7147 cover everything you're looking for? If so, then I'd start there

[platypus-winterberry]

Hello @zadjii-msft

Yep, that's mostly it 🎖️ - tried looking for other open issues but there are way too many and my search queries did not return what I wanted 👍

I take it that #4000 is the current open issue for esthetics? ( As seen in #7013 )

Thank you for this and please don't refrain to give me some feedback on my initial posting so I can improve in the future.

Stay safe,
Alex.

[zadjii-msft]

Meh, #4000 is more for vscode-like extensions to the Terminal, whatever that might mean. At the time, I didn't think it would be so trivial to implement in the Terminal itself, so I was planning on relying on 3rd party code to handle that. Turns out, it was easier than we expected 😅

I'm going to close this as a /duplicate of #7147, since that's the only real remaining open issue for now. If you do figure out a fun way to do cool-retro-term like effects, then we'd probably accept that as a PR to our pixel shader samples.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!