Terminal: Demande de fonctionnalité : prise en charge des graphiques Sixel

Lors de la mise en œuvre de Sixel, il est important de tester avec des images contenant de la transparence.
La transparence peut être obtenue en dessinant des pixels de différentes couleurs mais en ne dessinant pas certains pixels dans l'une des couleurs Sixel, en laissant la couleur d'arrière-plan telle quelle.
Je pense que c'est le seul moyen de dessiner correctement des Sixels non rectangulaires, et ce serait particulièrement agréable avec la transparence acrylique d'arrière-plan dans le nouveau terminal Windows.

En testant WSL avec Ubuntu par exemple, dans mlterm, ces images sont correctement rendues comme ayant un masque de transparence et la couleur d'arrière-plan est conservée, tandis que dans xterm -ti vt340, les pixels intacts sont dessinés en noir, même si l'arrière-plan est blanc, ce qui semble impliquent qu'ils rendent sixels sur un bitmap mémoire initialisé en noir sans masque de transparence ni alpha avant de les insérer dans la fenêtre du terminal.

Oh. Sixel est un truc très cool.

J'ai décidé que j'en avais besoin. BESOIN.

Je serai heureux de revoir un PR :)

Pris aujourd'hui l'interview de Build 2019 qui mentionnait cette demande. Je maintiens toujours que Xorg sur sixel est tout simplement faux . Donc _très très mal_.

La démo ffmpeg-sixel "Steve Ballmer vend CS50 " ne se lasse jamais. Je dois dire que c'est un peu décevant que la vidéo manque de son (le son fait vraiment la vidéo ). Les consoles ont déjà du son, naturellement. Ils bipent totalement. Ensemble précédent. Ce dont nous avons vraiment _besoin_, c'est d'une nouvelle séquence CSI pour les clips d' opus entrelacés avec les images, amirite ?

Ken, je le mérite vraiment pour avoir mentionné Sixels ;)

De : therealkenc [email protected]
Envoyé : mercredi 8 mai 2019 16:31:31
À : Microsoft/Terminal
Cc : Abonné
Objet : Re : [microsoft/Terminal] Prise en charge des graphiques Sixel (#448)

Attrapé la construction 2019 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmybuild.techcommunity.microsoft.com%2Fhome%23top-anchor&data=01%7C01%7Cduhowett%40microsoft.com %7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=i8rfPCaN%2FxqdF%2F4qRtdN2Py4%2BVRlbPgpwJWtPZSGGHc%3D&reserved=0 aujourd'hui. Je maintiens toujours que Xorg sur sixel est tout simplement faux https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FWSL%2Fissues%2F1099%23issuecomment-248513013&data=01 %7C01%7Cduhowett%40microsoft.com%7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=J%2BwCnn0z70FkI9lDcus1nMXcKz1P0ArL5%2Bmd Donc très très mal.

Le ffmpeg-Sixel https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsaitoha%2FFFmpeg-SIXEL&data=01%7C01%7Cduhowett%40microsoft.com%7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47 %7C1&sdata=G%2F9mvw1EdADkwChSbHZ%2FI54k9xvXagV%2FxD9VbJtyw7g%3D&reserved=0 "Steve Ballmer vend la démo CS50" https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com% 2Fwatch% 3Fv% 3D7z6lo4aq6zc% 26feature% 3Dyoutu.be & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata = 6IVwBHs6% 2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0% 3D et réservé = 0 ne se fatigue jamais tho. Faut dire que c'est un peu décevant la vidéo manque de son (le son rend vraiment la vidéo https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv % 3DEl2mr5aS8y0 & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata = Mm1ICN5KcgrP5YmdAZsUCzUKbVQDtxFE1qAEpkhKiZk% 3D et réservé = 0 ). Les consoles ont déjà du son, naturellement. Ils bipent totalement. Ensemble précédent. Ce dont nous avons vraiment besoin, c'est d'une nouvelle séquence CSI https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FANSI_escape_code%23CSI_sequences&data=01%7C01%7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata = 29pJq5661TXtnn2huLyUMgebTyYMEhTKXpAm19jzqHU% 3D et réservé = 0 pour l'opus https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOpus_ (audio_format) & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata = XOq6Acz4% 2B7gQeTKQBQ2fYJPnoLvx6vUjmLRhgOX1eDo% 3D & réservés = 0 clips intercalées avec les cadres, amirite?

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F448%23issuecomment-490688164&data=01 % 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata = pnXPvsuGF7l5mQfU2htzFwJnqZjEuW4zNuh1HaBJnKM% 3D et réservé = 0 , ou couper le fil https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. com% 2Fnotifications% 2Funsubscribe-auth% 2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata =% 2F4pMmm7bvPa% 2BbFmE1gyN8% 2BoTZDKJyRksBrkJpDh% 2BLug% 3D et réservé = 0 .

Connexe : #120

Besoin.

LOL Je regardais le stream et je me suis juste dit "voici mon patron qui m'assigne du travail en direct devant un public de studio".

Veuillez en faire une priorité pour la v1.0 !

Les animations 3d peuvent être v1.5 😛

OMG

En votant pour cette demande, Sixels serait une chose tellement incroyable à avoir dans le terminal.

Ce week-end, j'ai fini d'implémenter le support de lecture sixel pour ma bibliothèque TUI basée sur Java sous licence MIT, et c'était étonnamment simple. Le code pour convertir une chaîne de données sixel en une image bitmap est ici , et le code client pour la classe Sixel est ici .

J'ai fait très peu pour les performances sur le décodeur. Mais lorsque vous utilisez le backend Swing, les performances sont toujours correctes, comme on le voit ici . (L'image du serpent a l'air mauvaise uniquement parce que byzanz a utilisé une mauvaise palette pour créer le gif de démonstration.) J'ai été un peu surpris de la rapidité avec laquelle il s'est réuni. Il est très juste de dire que la partie "décoder sixel en bitmap" est la partie facile, la partie difficile est le "coller les données d'image dans une cellule de texte, et quand cela est présent, blit l'image à l'écran plutôt que le caractère".

Je veux juste le mentionner à d'autres personnes intéressées par le support terminal pour sixel, et en espérant que cela puisse vous aider.

Je voterai si quelqu'un d'autre écrit un client de bloc-notes Jupyter;)

Nous avons déjà un exemple de support Sixel dans mintty qui est écrit en C (vice java). La seule chose nécessaire est une refactorisation en C++ (au moins pour le support initial). Toujours bon de voir comment cela a été mis en œuvre dans d'autres projets.

Nous avons déjà un exemple de support Sixel dans mintty qui est écrit en C (vice java). La seule chose nécessaire est une refactorisation en C++ (au moins pour le support initial). Toujours bon de voir comment cela a été mis en œuvre dans d'autres projets.

Des problèmes avec la licence de mintty (GPLv3 ou ultérieure) ?

https://github.com/mintty/mintty/blob/master/LICENCE

https://github.com/mintty/mintty/blob/master/LICENCE

A partir de ce lien :

Le code Sixel (sixel.c) est sous licence GPL comme mintty avec le
autorisation de son auteur (kmiya@culti)

Si vous translittérez ce code exact en C++, l'œuvre dérivée devra être sous licence GPLv3 ou ultérieure, conformément à ses termes, ou ne pas être distribuée du tout. (On pourrait également demander à kmiya @culti s'ils sont prêts à proposer sixel.c sous une autre licence, ou s'il était autrefois disponible sous autre chose, trouvez une copie de cette source.)

Je ne sais pas ce qui est acceptable ou non pour l'inclusion dans Windows Terminal - mon rapide coup d'œil sur Windows Terminal indique qu'il est sous licence MIT, donc selon la façon dont il est lié/chargé à l'aide d'un descendant direct de GPLv3 + sixel.c de mintty pourrait conduire à un problème de licence.

Quoi qu'il en soit, désolé de déranger le projet de quelqu'un d'autre ici, je retourne à la grotte maintenant...

Il existe un humble émulateur de terminal capable de sixel écrit en C/C++ pour Windows/Linux, et il a une classe SixelRenderer que vous pouvez utiliser (bien qu'il nécessite une certaine optimisation), et il a une licence BSD-3. Son plus gros inconvénient est sans doute qu'il est écrit pour un framework C++ spécifique. Pourtant, le code de l'OMI SixelRenderer est traduisible avec peu d'effort. (Je le sais parce que j'en suis l'auteur. :) )

https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Terminal

Lors de la mise en œuvre de Sixel, il est important de tester avec des images contenant de la transparence.
La transparence peut être obtenue en dessinant des pixels de différentes couleurs mais en ne dessinant pas certains pixels dans l'une des couleurs Sixel, en laissant la couleur d'arrière-plan telle quelle.
Je pense que c'est le seul moyen de dessiner correctement des Sixels non rectangulaires, et ce serait particulièrement agréable avec la transparence acrylique d'arrière-plan dans le nouveau terminal Windows.

En testant WSL avec Ubuntu par exemple, dans mlterm, ces images sont correctement rendues comme ayant un masque de transparence et la couleur d'arrière-plan est conservée, tandis que dans xterm -ti vt340, les pixels intacts sont dessinés en noir, même si l'arrière-plan est blanc, ce qui semble impliquent qu'ils rendent sixels sur un bitmap mémoire initialisé en noir sans masque de transparence ni alpha avant de les insérer dans la fenêtre du terminal.

Hmm. le VT340 je suis devant honore le paramètre P2 dans le DCS P1 ; P2 ; P3 ; q séquence qui initie la séquence SIXEL. Xterm, en revanche, semble l'ignorer. Mais si vous utilisez la séquence d'attributs raster (" Pan ; Pad ; Ph ; Pv ) et lui donnez une hauteur et une largeur, cela effacera l'arrière-plan pour obtenir un pixel noir.

Je pensais obtenir l'essai gratuit de l'émulateur ttwin et vérifier en quoi son comportement diffère du VT340 et du Xterm agissant comme un VT340.

Mais... +1 à l'idée de soutenir SIXEL en général et +10 à l'idée de proposer des tests de compatibilité.

Nous pourrions ajouter la prise en charge du protocole d' images en ligne iTerm2 une fois que nous y serons... Au moins, cela devrait être plus facile à mettre en œuvre, il n'a besoin que d'un chemin vers l'image et fait tout par lui-même.

Un doute que j'ai avec les deux systèmes est, que se passe-t-il avec l'alignement ? Si la largeur ou la hauteur des images est un multiple de la largeur ou de la hauteur des caractères, tout va bien, mais sinon, un rembourrage doit-il être ajouté uniquement en bas et à droite, ou l'image doit-elle être centrée en ajoutant un rembourrage à tous les côtés?

Hey voici quelques liens pertinents pour la recherche:

• "Bases pour un bon protocole d'image" sur terminal-wg (et une discussion précédente liée )
• ce fil massif sur le support sixel

Nous pourrions ajouter la prise en charge du protocole d' images en ligne iTerm2 une fois que nous y serons... Au moins, cela devrait être plus facile à mettre en œuvre, il n'a besoin que d'un chemin vers l'image et fait tout par lui-même.

Cela devrait probablement être une tâche différente. Sixel et ReGIS sont explicitement destinés aux données graphiques ou de caractères intrabande. Je ne dis pas que c'est une mauvaise idée, je dis simplement que cela devrait être traité comme une fonctionnalité différente.

Un doute que j'ai avec les deux systèmes est, que se passe-t-il avec l'alignement ? Si la largeur ou la hauteur des images est un multiple de la largeur ou de la hauteur des caractères, tout va bien, mais sinon, un rembourrage doit-il être ajouté uniquement en bas et à droite, ou l'image doit-elle être centrée en ajoutant un rembourrage à tous les côtés?

L'alignement des données graphiques Sixel et ReGIS est décrit (mal) dans divers manuels. Les images Sixel sont alignées sur les limites des cellules de caractères. Si vous voulez une bordure noire autour d'une image, vous devez ajouter ces pixels noirs vous-même ; il n'y a aucun concept de quelque chose comme la marge ou le rembourrage HTML. Chaque ligne de données sixel décrit une bande de six pixels de haut. Si vous essayez d'aligner des données d'image sixel avec des caractères de texte sur un émulateur de terminal, cela peut être frustrant car le logiciel générant les données sixel peut ne pas savoir de combien de pixels la hauteur de chaque glyphe de caractère est. Si vous avez un xterm de la vieille école à portée de main, vous pouvez le voir en le démarrant en mode vt340, en spécifiant différentes tailles de police (pour vous donner différentes tailles de cellules de caractères), puis en imprimant des données sixel qui tentent d'aligner les données d'image avec texte Les données. (Voici un fichier de test simple qui semble correct lorsque je dis au serveur de polices d'utiliser 96 DPI et que je spécifie une police de 15 points. La modification de la taille de la police entraîne un désalignement croissant des images avec le texte. https://gist.github. com/OhMeadhbh/3d63f8b8aa4080d4de40586ffff819de )

Les vt340 d'origine n'avaient pas ce problème car (bien sûr) vous ne pouviez pas spécifier de taille de police lors de la mise sous tension du terminal.

L'autre chose que vous pouvez voir à partir de cette image, qui n'est pas bien décrite dans la documentation sixel, est que l'impression d'une ligne de données sixel établit une "marge gauche virtuelle" pour les données d'image. Si vous faites l'équivalent moral d'un CR ou d'un CRLF en utilisant les caractères '$' ou '-', la ligne suivante est imprimée par rapport à cette marge gauche virtuelle, et non à la marge gauche réelle sur le côté gauche du terminal.

J'espère que cela t'aides.

Enfin, revenez en arrière pour lire ceci. Désolé pour la réponse tardive.

En testant WSL avec Ubuntu par exemple, dans mlterm, ces images sont correctement rendues comme ayant un masque de transparence et la couleur d'arrière-plan est conservée, tandis que dans xterm -ti vt340, les pixels intacts sont dessinés en noir, même si l'arrière-plan est blanc, ce qui semble impliquent qu'ils rendent sixels sur un bitmap mémoire initialisé en noir sans masque de transparence ni alpha avant de les insérer dans la fenêtre du terminal.

Il ne devrait pas être trop difficile de prendre en charge la transparence dans xterm. J'ai fouillé dans le code pour d'autres raisons. Je crains que quelqu'un, quelque part, dépende de ce comportement de Xterm, je recommanderais donc de le placer derrière un indicateur de compatibilité, qui devrait également être simple. Mais ensuite, il y a la question de la valeur par défaut. Quelle devrait être la valeur par défaut ? Noir ou transparent.

Savons-nous ce que faisaient les VT240, 241, 330 et 340 d'origine ? Puis-je suggérer d'essayer de représenter fidèlement l'expérience d'un VT réelcomme comportement par défaut ? Vous pouvez tester cela en imprimant des caractères d'espacement inversés, puis en superposant des graphiques sixels au-dessus d'eux et en voyant la couleur de rendu des pixels non spécifiés.

Je ne sais pas si je me soucie trop de la valeur par défaut du terminal msft tant qu'il est possible de se comporter comme Xterm émulant un VT340. Le code que j'ai écrit pour faire des loglines sur ssh dans le terminal suppose en quelque sorte le comportement "les pixels non spécifiés sont noirs" décrit ci-dessus. Je devrais réécrire ce code si nous apportons ce changement.

Si vous essayez d'aligner des données d'image sixel avec des caractères de texte sur un émulateur de terminal, cela peut être frustrant car le logiciel générant les données sixel peut ne pas savoir de combien de pixels la hauteur de chaque glyphe de caractère est.

Les vt340 d'origine n'avaient pas ce problème car (bien sûr) vous ne pouviez pas spécifier de taille de police lors de la mise sous tension du terminal.

Y a-t-il une raison pour laquelle un émulateur de terminal ne pourrait pas simplement redimensionner l'image pour qu'elle corresponde exactement au comportement des terminaux DEC d'origine? Donc, si la hauteur de ligne sur un VT340 était de 20 pixels, une image de 200 pixels de hauteur devrait couvrir exactement 10 lignes, quelle que soit la taille de la police. Cela me semble la seule façon de rester raisonnablement compatible avec les logiciels hérités, ce qui est en quelque sorte le but d'un émulateur de terminal.

Je peux comprendre que je veuille étendre ce comportement pour rendre les images à une résolution plus élevée, mais cela devrait être une extension facultative, je pense (ou simplement utiliser l'un des formats propriétaires existants). Donc, idéalement, j'aimerais que la valeur par défaut de Sixel soit aussi proche que possible de ce que vous auriez obtenu sur un terminal DEC réel.

Hey voici quelques liens pertinents pour la recherche:
"Les bases d'un bon protocole d'image" sur terminal-wg

Sixel est cassé car il ne peut pas être pris en charge par tmux avec des volets côte à côte.

Cela a demandé du travail (en fait beaucoup de travail ), mais avec sixel, on peut effectuer presque toutes les astuces "images dans un terminal" que l'on peut imaginer :

• Images masquées par cellule en couches dans un terminal : https://jexer.sourceforge.io/images/sixel_many_images.png

• Une fenêtre de terminal flottante (multiplexée) dans un terminal qui utilise sixel pour la prise en charge double largeur de style VT100 : https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• Terminaux en mosaïque "de style tmux" avec images : https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• Session de terminal partagé à plusieurs têtes avec différentes tailles de cellules de texte affichant le même tracé : https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• L'utilisation de sixel pour rendre CJK et emoji qui ne sont pas présents dans la police du terminal principal : https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

J'ai inclus quelques autres remarques dans le "bon" fil de protocole référencé qui pourraient être intéressantes.

Si rien d'autre, sixel est un bon tremplin pour élaborer l'infrastructure côté terminal d'images et de textes mixtes. Parlant d'expérience directe, le côté terminal (stockage/affichage des images) est environ 1/4 aussi dur que le côté multiplexeur/application (tmux/mc et al).

sixels sont en effet la solution idéale pour les graphiques intrabande (par exemple via ssh) : comme ils sont pris en charge par de nombreux outils existants, ils sont prêts à être utilisés à des fins pratiques comme le traçage des problèmes de synchronisation d'horodatage en déplacement.

Comme illustré par therealkenc et expliqué plus en détail par klamonte dans 640292222, tout peut être géré avec sixels, même des images côte à côte, mais cela nécessite un certain travail.

Il y a quelque temps, je travaillais avec quelques autres personnes sur un mode de secours pour tmux, en utilisant des graphiques Unicode avancés pour représenter des images sixel dans des terminaux qui ne prennent pas en charge sixel.

C'est un peu comme l'art ANSII automatisé, tirant parti des caractères de bloc spéciaux qui sont présents dans la plupart des polices : cette représentation unicode couleur équivalente pourrait être remplacée par les sixels, puis plus tard écrasée par l'image sixel réelle (ou non !). Cela résoudrait également le problème de conserver toutes les images sixel pour le défilement arrière, en les remplaçant par des espaces réservés Unicode basse fidélité (par exemple pour économiser de la mémoire), et d'avoir des espaces réservés pour les images sixel lorsqu'elles ne peuvent pas être affichées pour une raison quelconque.

Le code était du domaine public. Il pourrait être utilisable immédiatement comme première étape vers le support sixel :

• détecter quand la séquence de sixels est transmise, puis calculer le remplacement du texte unicode

• afficher cette séquence unicode, qui est déjà prise en charge par Windows Terminal

• plus tard, lorsque les sixels sont implémentés, affichez par dessus la séquence de sixels.

Serais tu intéressé?

BTW je reconnais ici mes tracés familiers gnuplot x ^ 2 sin et 10 sin (x) Je suis heureux que cela m'ait inspiré 😄

S'il te plaît.

@DHowett Acac350 est-il une première étape vers le rendu des graphiques sixel? Je reçois des demandes de support sixel dans Microsoft Terminal de la part de personnes utilisant ssh et souhaitant afficher des répertoires d'images à l'aide de mon programme lsix .

En quelque sorte. Nous avons maintenant la capacité de gérer les séquences DCS entrantes. Nous n'avons pas encore connecté de gestionnaires, mais avoir l'infrastructure pour le faire était assez important. :le sourire:

Voici quelques mises à jour. J'ai une branche de travail ici . Une première capture d'écran ressemble à ceci :

Contrairement à ce que je pensais à l'origine, la partie la plus difficile du rendu des images sixel est en fait la couche conpty. Les images Sixel sont censées être des objets en ligne. Le rendu des images sixel dépend de la taille de rendu d'un caractère. Cependant, en raison de la couche conpty supplémentaire, nous ne pouvons pas obtenir la taille de rendu d'un caractère lors du traitement de séquences sixel. Cela semble très abstrait et vague. Toute personne intéressée par cela peut consulter ma succursale et voir comment cela se passe.

Dans l'ensemble, la couche conpty rend très difficile la gestion du défilement et du redimensionnement des images sixel. Dans ma branche, cela fonctionne si vous avez seulement besoin de l'afficher. Mais le défilement et le redimensionnement sont complètement cassés.

Je n'ai pas encore regardé, mais pouvez-vous utiliser le mode pass-through pour l'implémenter dans le terminal lui-même ? Je l'ajouterais toujours dans OpenConsole, mais il semble que le partage de code ne soit pas possible. Étant donné que Windows Terminal doit être découplé d'OpenConsole à un moment donné, il vaut mieux simplement dupliquer le code pour les deux. Vous basez-vous également sur les vôtres et sur les relations publiques de j4james pour les paramètres ? Cela aiderait probablement aussi.

@WSLUser Merci pour l'attention. Cette capture d'écran date en fait d'il y a environ un mois, lorsque les fantastiques paramètres PR de j4james n'existent même pas. Mon travail est entièrement à l'intérieur du terminal Windows, pas conhost. J'ai montré ce PR à l'équipe de la console en interne et j'ai fait quelques progrès depuis. Mais je suis bloqué à cause du problème de conty.

Ouais, je rebaserais hors du maître et ajouterais https://github.com/microsoft/terminal/pull/7578 et https://github.com/microsoft/terminal/pull/7799. À partir de là, voyez peut-être ce qui manque dans ConPTY pour le mode pass-through. Je me demande si Mintty utilise le pass-through pour le mode ConPTY.

Je me demande si Mintty utilise le pass-through pour le mode ConPTY.

Mintty n'utilise pas du tout conpty 😜

L'astuce ici avec conpty est que la console (conpty) devra connaître les cellules remplies de contenu sixel, afin de ne pas effacer accidentellement ce contenu du terminal connecté. Peut-être que conpty pourrait être éclairé pour ignorer les cellules de peinture avec des graphiques de taille, et supposer simplement que le terminal connecté laissera ces cellules seules.

Cela pourrait gâcher certaines de nos optimisations (comme nous ne pouvons pas effacer les lignes qui ont des données sixel), mais cela pourrait être un bon début

\

Peut-être que conpty pourrait être éclairé pour ignorer les cellules de peinture avec des graphiques de taille, et supposer simplement que le terminal connecté laissera ces cellules seules.

C'était aussi mon plan initial, et c'est peut-être la meilleure solution avec l'architecture actuelle du contty, mais il y a un certain nombre de complications.

1. Comment cela interagirait-il avec le streaming DCS (pour lequel je ne pense pas que nous ayons encore de solution). Je suppose que nous aurions besoin d'une sorte de concept de flux divisé qui transmet le flux d'octets à conpty en même temps qu'il est envoyé au tampon conhost, mais cela semble ajouter beaucoup de surcharge inutile au processus.
2. Cela ne fonctionnerait que si vous connaissiez la taille de cellule en pixels du terminal conpty. J'ai déjà mentionné que je pense que la meilleure solution pour Sixel est de faire correspondre la taille de cellule des terminaux VT d'origine, et si nous faisions cela, cela ne serait pas un problème. Cependant, pour autant que je sache, aucun autre émulateur de terminal ne le fait, donc cela ne fonctionnerait avec personne d'autre.

Le deuxième problème soulevé par @j4james devient encore plus compliqué avec la prise en compte de polices différentes, de tailles de police différentes et de redimensionnement de police. Donc, généralement, je pense qu'il y a 3 aspects du problème:

• Tout d'abord, conpty devra connaître les cellules remplies de contenu sixel. Sans cela, le tampon de sauvegarde dans conpty et le tampon de dessin dans WT seront inévitablement désynchronisés.
• Pour ce faire, conpty devra connaître la taille de la cellule de pixel dans le contexte de dessin, qui est gérée par la couche de dessin dans WT. Il y a un énorme écart entre conpty et le DXRenderer réel, ce qui rend cette tâche difficile.
• En outre, lorsque la police ou la taille de la police change, idéalement, l'image sixel devrait changer en conséquence.
• Et enfin traiter d'autres choses comme le volet, le tampon alternatif, le dessin différentiel, le défilement, etc.

Le deuxième problème soulevé par @j4james devient encore plus compliqué avec la prise en compte de polices différentes, de tailles de police différentes et de redimensionnement de police. Donc, généralement, je pense qu'il y a 3 aspects du problème:

Juste pour être clair, mon point était que rien de tout cela ne serait un problème si nous correspondions exactement au comportement d'un VT340, donc une image de 10x20 pixels occuperait exactement une cellule de caractère, quelle que soit la taille de la police. Ce n'est un problème que si nous voulons faire correspondre le comportement d'autres émulateurs de terminaux, et cela pourrait toujours être une option laissée pour plus tard. Il y aurait toujours des complications avec cette approche, mais je pense personnellement qu'elles sont moins préoccupantes.

Ma plus grande préoccupation est que vous semblez ignorer le problème de streaming DCS, qui, je pense, pourrait changer fondamentalement l'architecture de la solution. Les étapes que j'aurais aimé voir sont : 1. Résolution #7316 ; 2. Convenez d'une solution pour la taille des pixels des cellules ; 3. Obtenez quelque chose qui fonctionne dans conhost ; 4. Une fois que toutes les complications ont été résolues dans conhost, réfléchissez ensuite à la manière dont nous le ferons fonctionner sur conpty.

Désolé d'avoir laissé le problème de streaming DCS. Dans mon implémentation actuelle, je stocke simplement la chaîne entière et la transmets au moteur. Cela introduit un problème de performances lorsque la séquence est plus grande. Mais au moins ça marche. Donc mes commentaires ci-dessus sont largement basés dessus.

Mais vous avez raison. Le problème de streaming DCS est en fait la priorité absolue si quelqu'un d'autre veut se salir les mains à ce sujet.

获取 Outlook pour iOS https://aka.ms/o0ukef

Par discussion dans https://github.com/microsoft/terminal/issues/57 , je pensais que conpty ne se souciait pas du tout des polices?

wrt redimensionnement Je pense que la façon la plus naturelle de le faire est "d'ancrer" l'image dans les cellules de caractère une fois l'image arrivée, et de recalculer la taille de l'image en fonction de la géométrie de l'ancre. Tout le reste entraînera une incohérence entre les cellules d'image et de caractère.

@yatli Oui. C'est aussi ce qui rend la question délicate.

Une image de 10 x 20 pixels occuperait exactement une cellule de caractère

C'est malheureusement faux, du moins pour mon réglage de police actuel.

Corrigez-moi si je me trompe, mais pour un affichage d'image au pixel près, je pense que nous devons nous soucier des polices.

@ skyline75489 pls voir mon commentaire mis à jour sur "l'ancre"

La structure de données de la cellule doit être mise à jour en tant que char | sixel anchor

L'ancre Sixel doit contenir des informations sur :

• Un pointeur vers l'objet image
• La région de cellule char qu'il occupe, en nombres flottants (par exemple 5,2 lignes x 7,8 cols)

C'est une bonne idée mais les détails d'implémentation me tuaient, à cause de la traduction supplémentaire dans la couche conpty. Pour éviter de spammer les gens avec des e-mails, n'hésitez pas à me contacter sur Teams @yatli si vous êtes intéressé.

Une image de 10 x 20 pixels occuperait exactement une cellule de caractère

C'est malheureusement faux, du moins pour mon réglage de police actuel.

Ce que je suggère, c'est que vous devriez en faire le cas. Si vous créez une image 10x20 pixels et que vous la sortez sur un vrai terminal DEC VT320, cela prendra exactement un caractère (au moins en mode 80 colonnes). Donc, si nous essayons d'émuler ce terminal, nous devrions faire la même chose. Si votre police actuelle est de 30x60, vous devez agrandir l'image. Si votre police est plus petite, vous réduisez l'échelle de l'image.

Cela garantit que vous pouvez produire une image Sixel dans n'importe quelle taille de police et obtenir toujours la même mise en page. Si vous voulez qu'elle couvre une certaine zone de l'écran, ou si vous voulez tracer une bordure autour avec des caractères de texte, vous savez exactement combien d'espace l'image occupera.

Corrigez-moi si je me trompe, mais pour un affichage d'image au pixel près, je pense que nous devons nous soucier des polices.

Il est vrai que vous n'obtiendrez pas des images "en pixels parfaits" de cette façon, mais je ne pense pas que cela devrait être l'objectif principal. De nombreux ordinateurs modernes ont des écrans à haute résolution où il est courant que les images soient agrandies, donc ce n'est pas comme si c'était un concept étrange. Et si nous voulons garder la mise en page cohérente lorsque l'utilisateur modifie la taille de sa police, nous allons de toute façon devoir mettre à l'échelle l'image à un moment donné, donc autant le faire dès le début et profiter de tous les avantages d'un prévisible Taille.

Et bien sûr, l'autre avantage de faire les choses de cette façon est qu'il pourrait être mis en œuvre de manière réaliste sur le conpty. Je ne vois pas comment vous pouvez faire fonctionner conpty si la zone occupée par l'image dépend de la taille de la police, ce que vous ne pouvez pas savoir.

Je ne vais pas prétendre que cette approche n'aura aucun inconvénient, mais je pense que les points positifs l'emportent sur les points négatifs.

Que se passe-t-il si la police a un rapport d'aspect différent de 10:20 ?

Que se passe-t-il si la police a un rapport d'aspect différent de 10:20 ?

Puis-je suggérer de lire cette longue discussion - et quelque peu "brutale" - sur les problèmes généraux concernant les images en ligne dans les émulateurs de terminaux .

Cela peut vous donner une idée générale.

Cordialement

Que se passe-t-il si la police a un rapport d'aspect différent de 10:20 ?

L'image est peut-être un peu étirée ou écrasée, mais je ne pense pas que ce soit la fin du monde.

Permettez-moi de démontrer avec un exemple du monde réel. Imaginez que je suis un méchant de Bond et que j'ai un ancien système de sécurité utilisant un VT340 comme interface. Maintenant, à cause du coronavirus, je suis confiné et je travaille à domicile, donc je me connecte au système à distance avec Windows Terminal. Si nous correspondons exactement au VT340, ce n'est pas un problème - le terminal ressemble à ceci :

Mais peut-être que je préfère les polices avec un rapport d'aspect bizarre. Voyons donc à quoi cela ressemblerait avec _Miriam Fixed_, qui est plus large que la plupart. L'image de Bond semble maintenant un peu écrasée, mais il est toujours facilement reconnaissable.

L'alternative serait d'aller avec une image parfaite en pixels (pas actuellement réalisable avec conpty, mais faisons semblant une seconde). Bond n'a plus l'air écrasé, mais maintenant l'image n'est qu'une fraction de la taille qu'elle était censée avoir. Et plus la résolution de votre moniteur est élevée, pire cela va paraître.

C'est peut-être une question de préférence personnelle, mais je sais que je choisirais certainement l'option 1 plutôt que l'option 2.

Notez également qu'il n'y a aucune raison pour que nous n'ayons pas d'options pour modifier le comportement exact lorsque le rapport d'aspect de la police n'est pas de 1:2. Une option pourrait être de centrer l'image dans les cellules qu'elle était censée occuper. Ou nous pourrions agrandir l'image afin qu'elle couvre toute la zone, mais couper les bords qui dépassent les limites. N'importe lequel de ces choix serait mieux qu'un rendu pixel exact à mon avis.

C'est peut-être une question de préférence personnelle, mais je sais que je choisirais certainement l'option 1 plutôt que l'option 2.

Moi aussi, il serait juste préférable de savoir que la police a un rapport d'aspect différent, afin que l'image puisse s'ajuster et conserver la bonne.

Une option pourrait être de centrer l'image dans les cellules qu'elle était censée occuper. Ou nous pourrions agrandir l'image afin qu'elle couvre toute la zone, mais couper les bords qui dépassent les limites

Je pense qu'il vaut mieux les centrer.

Peut-être que je lis mal ce fil. Parlons-nous réellement du terminal simulant des caractères 10:20 pour l'image sixel ? Je pense que cela causera de nombreux problèmes comme la distorsion de Bond. Le faire correctement peut être plus difficile, mais, à mon humble avis, un terminal moderne devrait être indépendant des polices et laisser aux programmeurs d'applications le soin de gérer les sixels et les cellules de caractères.

À l'aide de séquences d'échappement, un programme exécuté par l'utilisateur peut déterminer la taille de la cellule de caractère en pixels et décider comment traiter intelligemment la distorsion pour cette application. Le programme de visualisation d'images que j'utilise fonctionne exactement comme ça. Au fur et à mesure que je change de famille ou de taille de police, la vignette affichée se met à jour pour avoir exactement cinq lignes de texte de haut. La largeur est mise à l'échelle proportionnellement pour l'image, à moins qu'elle ne soit plus grande qu'un certain maximum (dans ce cas, plutôt grand). En basant la taille de l'image sur la cellule de caractère, cela fonctionne automatiquement sur les écrans à haute résolution.

Bien que le VT340 soit un objectif noble à imiter, fixer la résolution des cellules de caractères à 10:20 (et donc limiter la résolution pour l'ensemble de l'écran) est une erreur. Le VT340 n'était qu'une des nombreuses implémentations sixel, donc sa taille de police n'est pas nécessairement plus correcte.

Forcer 10h20 conduira également à de vilains gâchis. (Par exemple, comment répondre à une demande de taille de la fenêtre du terminal en pixels. Dites la vérité, en supposant qu'ils positionneront des fenêtres sur l'écran ? Ou, retournez toujours 800x480, en supposant que l'utilisateur redimensionne les images pour une sortie sixel ? )

Parlons-nous réellement du terminal simulant des caractères 10:20 pour l'image sixel ?

Oui.

un terminal moderne devrait être indépendant des polices

Cette proposition est indépendante des polices. L'application n'a pas besoin de savoir quoi que ce soit sur la police. Exactement.

À l'aide de séquences d'échappement, un programme exécuté par l'utilisateur peut déterminer la taille de la cellule de caractère en pixels et décider comment traiter intelligemment la distorsion pour cette application.

Je ne sais pas exactement quelle méthode vous utilisez, mais la façon dont j'ai déjà vu cela est avec une requête propriétaire XTerm pour obtenir la taille de pixel de la fenêtre, et une autre requête pour obtenir la taille de la cellule de la fenêtre, puis en utilisant cela données pour calculer la taille réelle des pixels de la cellule. Les inconvénients d'une telle approche sont :

1. Il est propriétaire, il ne fonctionnerait donc pas sur un vrai terminal ou sur tout émulateur de terminal correspondant exactement à un vrai terminal.
2. Si l'utilisateur modifie la taille de la police pendant que votre application est en cours d'exécution, vos calculs ne seront plus corrects et les images seront rendues à la mauvaise taille (sauf si vous recalculez continuellement la taille de la police, ce qui semble peu pratique).
3. Si l'utilisateur dispose d'un écran haute résolution et/ou d'une grande taille de police, vous êtes obligé d'envoyer une image massive pour essayer de correspondre à cette résolution. Compte tenu de l'inefficacité de Sixel au départ, cela peut représenter beaucoup de bande passante.

Cela dit, je comprends que c'est un mode que certaines personnes peuvent souhaiter utiliser, et je pense que nous devrions au moins avoir une option pour le supporter un jour (pour les raisons évoquées ci-dessus, ce n'est tout simplement pas possible pour le moment). Mais à mon avis, ce n'est pas la meilleure approche pour Sixel.

J'ai plus de 300 VT340 dans des centrales nucléaires que j'aimerais éventuellement
remplacer.

Il existe des packages commerciaux d'émulation de terminal que nous pourrions utiliser, mais je pense
tous sauf un ont été EoL'd.

Nous avons remplacé certains d'entre eux par des PC Linux exécutant XTerm (ou moins
fréquemment, Win10 + Hummingbird + WSL exécutant XTerm), car il a un
implémentation sixel open source à moitié décente et une sorte de mauvaise, mais
Implémentation de ReGIS open source.

La probabilité que nous écrivions un nouveau logiciel pour la partie de ce
système qui génère le flux d'octets sixel est NIL.

Si votre objectif est d'envoyer des graphiques sur un flux d'octets en ligne, il
sont d'autres options. Mais si vous souhaitez prendre en charge les graphiques sixel, vous devez
prend en charge les graphiques sixel d'une manière à peu près similaire à la précédente
implémentations. Cela signifie malheureusement que vous devez imiter le
comportement des systèmes exemplaires (c.-à-d. VT240, VT241, VT330 et VT340
terminaux), même lorsqu'il s'agit d'intégrer des graphiques avec du texte.

C'est une maquette du genre de chose dont je parle. Ce serait très
bien si une nouvelle implémentation Sixel maintient la compatibilité avec l'existant
implémentations afin que les images ne sortent pas du bord de l'écran ou seulement
remplir la moitié de l'écran.

https://vimeo.com/user32814426/review/467991744/ac5892fa7e

un terminal moderne devrait être indépendant des polices

Cette proposition est indépendante des polices. L'application n'a pas besoin de savoir quoi que ce soit sur la police. Exactement.

Je voulais dire que le _terminal_ devrait être indépendant des polices au lieu d'imposer 10:20 sur chaque police. L'application doit être en mesure de connaître la taille de police réelle, si elle le souhaite, car c'est l'application qui connaît le domaine de ce qu'elle essaie d'afficher et peut trouver la meilleure façon de présenter le texte et les graphiques ensemble.

À l'aide de séquences d'échappement, un programme exécuté par l'utilisateur peut déterminer la taille de la cellule de caractère en pixels et décider comment traiter intelligemment la distorsion pour cette application.

Je ne sais pas exactement quelle méthode vous utilisez, mais la façon dont j'ai déjà vu cela est avec une requête propriétaire XTerm pour obtenir la taille de pixel de la fenêtre, et une autre requête pour obtenir la taille de la cellule de la fenêtre, puis en utilisant cela données pour calculer la taille réelle des pixels de la cellule.

Ouais, c'est à peu près ça. Il y a aussi une requête pour obtenir directement la taille de la cellule de caractère, mais je ne pense pas que ce soit aussi largement pris en charge que d'obtenir simplement la taille de l'écran et de diviser par ROWS et COLUMNS.

Les inconvénients d'une telle approche sont :

1. It's proprietary, so wouldn't work on a real terminal, or any terminal emulator that exactly matched a real terminal.

Ce n'est pas un inconvénient. Cela signifie seulement que le programme doit se rabattre sur ce qu'il aurait fait de toute façon : supposons que $TERM=="VT340" signifie que les cellules de caractères sont à 10:20, "VT240" signifie 10:10, "mskermit" signifie 8:8, etc.

De plus, ce n'est pas une séquence propriétaire xterm. L'obtention de la taille de l'écran s'appelle une séquence d'échappement "dtterm", mais elle a en fait été implémentée pour la première fois dans SunView (SunOS, 1986). Je crois que cela a été documenté plus tard dans le manuel de programmation PHIGS (1992). Essayez d'envoyer "\e[14t" à quelques émulateurs de terminaux et vous verrez qu'il est largement implémenté.

2. If the user changes their font size while your application is running, then your calculations will no longer be correct, and images will be rendered at the wrong size (unless you're continuously recalculating the font size which seems impractical).

Ce n'est pas un problème. Le programme piège simplement SIGWINCH et ne recalcule que si la fenêtre a réellement changé.

3. If the user has a high resolution display, and/or large font size, you're forced to send through a massive image to try and match that resolution. Considering how inefficient Sixel is to start with, that can amount to a lot of bandwidth.

Oui, sixel est extrêmement inefficace. Mais sur les ordinateurs modernes, l'envoi d'images en plein écran est tout à fait utilisable, même via ssh. Le terminal Microsoft a-t-il une sorte de limitation de débit en bauds ?

Soit dit en passant, je crois que sixel a un mode "haut DPI" où chaque point est doublé en largeur et en hauteur. Je ne l'ai jamais utilisé et je ne pense pas que xterm l'implémente même, mais peut-être que cela atténuerait les problèmes de bande passante.

Cela dit, je comprends que c'est un mode que certaines personnes peuvent souhaiter utiliser, et je pense que nous devrions au moins avoir une option pour le supporter un jour (pour les raisons évoquées ci-dessus, ce n'est tout simplement pas possible pour le moment).

Ce "mode" consiste simplement à aligner les caractères et les graphiques, tout comme les différents terminaux Sixel historiques et les émulateurs actuels. J'avoue, je ne comprends pas pourquoi il n'est pas possible de faire la même chose dans Microsoft Terminal. Si vous dites que ce truc de 10h20 est le mieux que l'on puisse faire, j'espère que vous avez raison et je vous remercie de l'avoir fait. Une image déformée vaut mieux que rien.

À l'aide de séquences d'échappement, un programme exécuté par l'utilisateur peut déterminer la taille de la cellule de caractère en pixels et décider comment traiter intelligemment la distorsion pour cette application.

@ hackerb9 , quelle est la séquence d'échappement réelle pour obtenir les dimensions de la police ?

Les séquences XTerm pertinentes peuvent être trouvées ici : https://invisible-island.net/xterm/ctlseqs/ctlseqs.html -- recherchez XTWINOPS.

De plus, sous Unix, vous pouvez généralement obtenir la taille de pixel interne du terminal ainsi que la taille de cellule à l'aide de l'ioctl TIOCGWINSZ. Avec openssh, cela fonctionne aussi à distance.

Tout comme un point de données, la branche sixel pour libvte emprunte la voie indépendante de la taille de la cellule dont @hackerb9 parle. Il traite les données Sixel entrantes comme "pixels parfaits" et redimensionne les images précédemment reçues à travers les niveaux de zoom et les tailles de police pour couvrir une étendue de cellule cohérente. Une fois fusionnée, cette implémentation sera disponible pour une grande partie des émulateurs de terminaux Linux, y compris GNOME Terminal, le terminal XFCE, Terminator, etc. Superficiellement, cela semble être interopérable avec au moins XTerm et mlterm.

Étant donné que libvte enregistre une taille de cellule virtuelle par image, il serait trivial de faire fonctionner cela avec une taille de cellule virtuelle fixe de 10x20 également pour l'interopérabilité. Cependant, nous aurions besoin d'un moyen pour les programmes de communiquer leurs rapports pixel:cellule attendus au terminal (par exemple en étendant les paramètres DCS). Cela pourrait être très utile en général, car cela fournirait également une forme de contrôle de la densité de pixels dans les environnements à bande passante limitée, comme vous l'avez évoqué ci-dessus.

De plus, sous Unix, vous pouvez généralement obtenir la taille de pixel interne du terminal ainsi que la taille de cellule à l'aide de l'ioctl TIOCGWINSZ. Avec openssh, cela fonctionne aussi à distance.

La console Linux renvoie toujours 0... ils devraient corriger cela, mais ne semblent pas vouloir aussi :-/