microsoft/Terminal

Retro Terminal Effect looks bad with 125% screen scaling

Open

#10 132 ouverte le 19 mai 2021

Voir sur GitHub
 (3 commentaires) (0 réactions) (0 assignés)C++ (3 212 forks)batch import
Area-RenderingHelp WantedIssue-BugPriority-3Product-Terminal

Métriques du dépôt

Stars
 (35 764 stars)
Métriques de merge PR
 (Merge moyen 27j 19h) (24 PRs mergées en 30 j)

Description

Windows Terminal version (or Windows build number)

1.7.1033.0

Other Software

No response

Steps to reproduce

The Retro Terminal Effect looks very nice with 100% screen scaling (selected in Windows Screen settings), but looks a little bit off when screen scaling is set to 125% (which is the default on my 1920*1080 laptop screen). With 100% screen scaling, the "scan lines" look evenly distributed, but they do not with 125% scaling. I'm attaching screenshots with both scaling factors in the "Expected behavior" and "Actual behavior" sections for comparison.

Expected Behavior

The expected behavior would be evenly distributed scan lines at any screen scaling setting, as seen on this screenshot at 100% scaling: 100 percent scaling

Actual Behavior

The scan lines look uneven at 125% screen scaling, as seen on this screenshot: 125 percent scaling

Guide contributeur

Direction de recherche
Le problème décrit des lignes de balayage irrégulières dans l'effet de terminal rétro à un zoom d'écran de 125 %. Pour le corriger, localisez le code de rendu pour l'effet rétro, probablement dans le moteur de rendu du terminal ou les fichiers de shader de pixels sous 'src/renderer'. Le facteur de mise à l'échelle doit être intégré au calcul des lignes de balayage pour garantir une distribution uniforme à n'importe quel DPI. Examinez les captures d'écran pour le comportement attendu à 100 % de zoom et vérifiez s'il existe des issues ou PR connexes pouvant fournir un contexte supplémentaire.
Stack technique
cpp
Domaine
frontend
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitC++
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
75