Xterm.js: 터미널이 트루 컬러를 렌더링하지 않음

기다릴 수 없습니다. 나는 트루컬러 지원을 얻으려고 hterm을 해킹해 왔지만 이것이 더 나은 선택이라고 생각합니다.

여기에서 구현해야 합니다. https://github.com/sourcelair/xterm.js/blob/365a9f949cc1acfb6c4649ee1d85da3bbc60f928/src/InputHandler.ts#L1276

까다로운 부분은 캐릭터에 대해 색상을 저장하는 방법과 이를 렌더링하는 방법(아마도 인라인 style 속성)을 결정하는 것입니다. https://github.com/sourcelair/xterm.js/pull/450 과 같은 것이 속성 추가를 단순화할 것입니다.

시간나면 한 번 봐야겠지만 컨트롤 시퀀스에 너무 익숙하다고는 할 수 없습니다.

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html을 살펴보았지만 트루 컬러나 24비트 컬러에 대해서는 아무 것도 찾지 못한 것 같습니다. 내가 뭔가를 놓치고 있습니까, 아니면 이것을 다루는 다른 리소스가 있습니까?

@cnsumner xterm은 현재 트루 컬러를 표시할 수 없지만 제안된 이스케이프 시퀀스 중 하나를 지원합니다. 이에 대한 자세한 내용은 https://gist.github.com/XVilka/8346728 에서 확인할 수 있습니다.
BTW 이것은 ECMA-48 표준에 부분적으로 지정되어 있습니다.

여기에서 해야 할 일에 대한 더 나은 아이디어를 얻기 위해 지저분한 개념 증명을 작성하세요. https://github.com/Tyriar/xterm.js/tree/484_truecolor

해야 할 일:

• 분기는 현재 32비트 정수에 맞는 0x1RRGGBB (fg) 또는 0x0RRGGBB (bg) 형식의 '트루컬러'를 나타내는 각 문자에 다른 숫자를 추가합니다
• fg 및 b 색상을 모두 지원해야 하며 트루컬러와 일반 색상을 혼합할 수 있어야 합니다.
• curTrueColor 정말 못생겼어요
• 지원 역
• 셀을 재사용할 때 색상 플래그를 지워야 합니다.

• 문자가 인코딩되는 방식을 재고해야 할 때입니다. 현재 형식은 다음과 같습니다.

  [attribute, character, width]
  

  • attribute : ASCII fg, ASCII bg 및 플래그(굵게, 밑줄, 깜박임, 반전, 보이지 않음)를 포함하는 32비트 정수로 모든 비트가 사용되는 것은 아닙니다.
  • char : 빈 문자열(넓은 문자를 채우는 너비가 0인 문자의 경우) 또는 단일 문자 유니코드 문자열
  • width : 문자의 너비는 현재 0, 1 또는 2일 수 있지만 여기에는 탭을 제대로 지원하기 위해 더 많이 포함될 수 있습니다. https://github.com/sourcelair/xterm.js/issues/734
• 최종 솔루션은 메모리에 대해 컴팩트해야 하고 액세스도 빨라야 하며 어레이, 바이너리 플래그 및 데이터에 대한 비트 이동을 고수하는 것이 가장 좋은 아이디어일 것입니다.

@티리아르
예, 낮은 소비에 최적화되지 않으면 메모리 사용량이 폭발합니다. width 와 함께 포장될 수 있습니다. 이 필드는 4바이트(일반적으로 탭의 기본값은 4 또는 8)만 사용하는 16보다 크지 않습니다. 이것은 하나의 RGB 정의*를 위한 공간을 남깁니다( width 가 32비트 정수라고 가정). attribute 에 몇 개의 비트가 있는지 확실하지 않은 경우 두 번째 RGB 정의가 있을 수 있습니다 .

속성은 현재 bg에 대해 9바이트, bg에 대해 9바이트, 플래그에 대해 5바이트를 소비하는 것으로 보이며 끝에 너비를 압축할 수 있습니다. RGB 정의에는 각각 24바이트(8*3)가 필요합니다.

다음은 제안하는 (약간 복잡한) 공간 절약 방식입니다.

[char, attr1, attr2]

여기서 attr1은 (29비트):

• 너비: 4비트
• 256색 또는 트루컬러 플래그: 1비트
• bg 색상: 24비트

그리고 attr2는 (30비트):

• 플래그: 5비트
• 256색 또는 트루컬러 플래그: 1비트
• fg 색상: 24비트

더 간단한 접근 방식은 특히 속성에 대해 숫자를 사용합니다.

[char, attr, truecolorBg, truecolorFg]

속성은 다음과 같습니다.

• 너비: 4바이트
• 플래그: 5바이트
• 256bg 색상: 9바이트
• 256 fg 색상: 9바이트

이러한 세부 사항을 매우 복잡하게 캡슐화하고 싶습니다. typescript를 사용하여 어떻게든 배열에 getter를 넣을 수 있는지 궁금합니다. 객체를 사용하는 것은 jsperf에서 수행한 마이크로 벤치마크를 기반으로 하는 어레이보다 20배 느렸습니다. 항상 신뢰할 수 있는 것은 아니지만 프로토타입을 기반으로 객체를 생성하기 위한 오버헤드로 예상했던 것입니다.

우리가 무엇을 하든 형식은 매우 잘 문서화되어야 합니다. 지금 당장은 InputHandler.charAttributes 를 보고 스스로 알아내야 합니다.

메모리 절약에 대한 몇 가지 추가 생각:

• 문자의 너비가 1보다 크면 다음 문자에 대한 데이터를 전혀 저장할 필요가 없습니다. "빈 문자"는 해결 방법으로 있으며 null 잘 작동할 것입니다.
• 일반적으로 일련의 문자에 스타일이 지정되므로 일련의 문자 간에 속성을 공유할 수 있습니다.
• 속성을 캐시할 수 있고 각 문자는 캐시된 값 중 하나에 대한 포인터를 사용합니다.

예, 대부분의 JS 엔진에서 인덱스 액세스가 있는 배열이 객체 및 해당 속성 확인보다 여전히 빠릅니다. V8은 객체에 대한 몇 가지 추가 최적화를 얻었습니다. 구성 및 GC 현명한 배열은 훨씬 단순한 메모리 레이아웃으로 인해 더 빠릅니다(이 단점은 기존 개체를 재사용하여 생략할 수 있음).

여기서 올바른 레이아웃에 대한 단서가 없습니다. 문제는 너무 많이 포장된 항목이 필요한 변환으로 인해 런타임 페널티를 높일 것이라는 것입니다. (이것이 메모리가 문제가 되지 않는 경우 C에서 비트 필드를 사용하지 않는 한 가지 이유입니다. 필요한 시프트 연산이 명령어 캐시를 오염시켜 캐시 누락을 유발합니다. 코드가 훨씬 느리게 실행됩니다.)
Imho 전용 테스트는 여기에서 가장 잘 작동하는 것을 보여줍니다.

@jerch 흥미롭습니다. 저는 지금 https://github.com/sourcelair/xterm.js/pull/756 에 단순성을 위해 4개의 숫자 버전을 가지고

따라서 여기의 메모리는 약 5 * (1000 스크롤백) * (64비트 시스템의 경우 8바이트) * 80 = 3.2mb(js 배열의 오버헤드 전) 정도가 될 것으로 예상됩니다. 일반적인 VS Code 터미널의 실제 너비는 현재 형식을 유지하면 두 배가 됩니다. 특히 사용자가 종종 1000개 이상의 스크롤백과 여러 활성 터미널을 사용하기 때문에 지금 보니 꽤 가파르게 보입니다. 실제로는 별로 추가되지 않고 쉽게 null이 될 수 있는 후행 공백은 아마도 꽤 큰 승리가 될 것입니다.

속성/색상 세트 캐시 아이디어도 빠른 액세스를 위한 좋은 방법이 있는 한 유망해 보입니다. 가벼운 스플레이 트리와 같은 구조가 이상적입니다(속성에 대한 빠른 액세스가 가장 자주 사용됨).

라인 데이터 배열을 그냥 버리는 대신 트리밍할 때( 예: 여기 ) 재사용하는 것도 고려해 볼 가치가 있습니다.

예, 엔진 오버헤드를 염두에 두고 크기가 더 커집니다. 배열이나 개체의 모든 항목은 기본적으로 콘텐츠에 대한 포인터인 참조로 저장됩니다. 조밀한 js-array는 약간의 이점이 있습니다. 경로 어딘가에 C와 같은 배열로 형성됩니다(실제로는 ArrayList). 희소 배열 및 기타 객체는 속성 확인을 해결하기 위해 일부 트리 마술로 빌드됩니다.
따라서 64비트의 경우 참조 항목은 셀당 5 * 8바이트를 더 추가합니다(기본적으로 위 계산의 두 배인 6.4mb). 콘텐츠는 "실제 콘텐츠" 외에 더 많은 바이트를 추가할 수 있지만 이는 Integer 및 String 유형의 실제 구현에 따라 다릅니다.

아마도 TypedArray가 이것을 해결할 수 있습니다. 거기에서 정수 항목은 추가 간접 참조 없이 메모리의 인덱스 위치에 직접 상주할 수 있습니다. asm.js는 기본적으로 이들에서만 작동합니다.

다음은 생성 및 데이터 삽입을 위해 TypedArray와 js-Array를 비교하는 빠른 마이크로 벤치마크입니다. http://jsbench.github.io/#af3ea1056a70df2aa6775699d174df0d

TypedArray는 내 컴퓨터에서 FF 및 Chrome을 사용하여 10배 더 빠르게 실행됩니다. 이것은 사전 할당 때문일 수 있으며 권장되지 않으므로 js-Array로 테스트하지 않았습니다. JIT가 값이 8바이트마다 1씩 증가하고 이를 최적화한다는 사실을 발견했는지 확실하지 않습니다. 그러면 벤치마크는 전혀 쓸모가 없습니다.

TypedArray의 경우 액세스가 약간 더 나쁩니다( Number 변환으로 인한 것일 수 있음). 메모리 소비는 TypedArray에서 훨씬 더 좋습니다.

TypedArray의 단점은 예비 데이터(데이터를 피하기 위한 트릭이 여기에서는 전혀 작동하지 않으며 메모리는 어쨌든 "손실"됨) 또는 콘텐츠 래핑으로 크기를 조정할 때 정적 메모리 블록입니다. 이를 올바르게 수행하기 어렵고 많은 양의 데이터를 계속해서 복사해야 할 가능성이 높습니다.

안녕하세요. 이에 대한 업데이트가 있습니까? 😃이 작업이 완료되기를 기다릴 수 없습니다.

이 문제를 적극적으로 해결하는 사람이 있습니까? 다른 곳에서 논의되고 있습니까? @chabou @

이것은 tmux 및 vim/neovim을 지원하는 적절한 dev CLI 워크플로를 제공하기 위해 Windows 10의 WSL에서 하이퍼를 사용하는 마지막 지연 문제입니다. WSL과 함께 사용할 수 있는 다른 터미널 에뮬레이터는 보기에 좋지 않고 wsltty가 가깝지만 탭 지원 및 플러그인 지원이 누락되었습니다...

@vastbinderj 누락된 트루 컬러 지원이 적절한 dev CLI 워크플로를 제공하지 않는 이유는 무엇입니까? 솔직한 질문.

@szmarczak 및 @vastbinderj
이 문제는 여전히 의제에 있지만 현재 터미널 버퍼 설계에 도입될 높은 메모리 사용량으로 인해 차단되었습니다. #791이 더 효율적인 버퍼 레이아웃을 가져오면 더 많은 관심을 받을 것입니다.

@rfgamaral simple - 저는 마이크로서비스가 많은 초대형 엔터프라이즈 시스템에서 하루에 다양한 유닉스/리눅스 서버에서 작업하며 메인 호스트에서 적절한 색상 지원이 없으면 문제가 발생합니다. 내가 rhel이든 centos이든 데비안이든 상관없이 색상이 동일하지 않은 것을 처리하는 것은 고통스럽습니다. 또한 Windows에서 주니어 또는 피어 개발자를 돕기 위해 앉아 있다는 것은 일이 균일하게 작동하지 않으면 컨텍스트 전환을 해야 한다는 것을 의미합니다. 그러나 거의 월 단위로 릴리스된 개선 사항과 VS Code의 동일한 개선 사항으로 wsl이 얼마나 빨리 발전했는지 매우 인상적입니다.

@jerch 업데이트 감사합니다. #791이 해결될 때까지 참을성 있게 기다리겠습니다...

이것도 많이 기대됩니다.

JavaScript 숫자는 최대 53비트의 정확한 정수를 나타낼 수 있음을 기억할 가치가 있습니다. 따라서 32개의 "편리한" 비트 외에 21비트가 있습니다. 아직 설정되지 않은 경우 간단한 추가로 조금 "또는"할 수 있습니다. 상위 비트를 읽으려면 적절한 2의 거듭제곱 정수로 나눈 다음 일반 비트 연산을 사용하면 됩니다.

물론 고차 비트로 작업하는 경우 오버헤드가 조금 더 있지만 최신 CPU에서는 2승으로 나누는 것이 메모리 액세스보다 상대적으로 저렴합니다.

전경과 배경에 대해 각각 25비트인 50비트의 단일 숫자를 사용하는 것이 좋습니다. 설정된 경우 1비트는 24비트 "트루" 색상을 사용하고 있음을 나타냅니다. 설정하지 않으면 "논리적"(테마 가능) 또는 8비트 색상을 사용합니다. 표시기 비트는 2개의 하위 비트여야 합니다. 설정되지 않은 경우 논리/8비트 색상이 다음 30비트에 포함될 수 있으므로 실제로 트루 컬러를 사용하는 경우 비트 32-50만 사용합니다.

@PerBothner 우리는 새로운 버퍼에 Uint32Array를 사용하기로 결정했고 편의를 위해 해당 배열에도 색상을 넣습니다. 트루컬러를 지원하기 전에 먼저 새로운 impl을 살균하고 싶기 때문에 아직 완료되지 않았습니다.

또한 가능한 레이아웃에 대한 몇 가지 테스트/계산을 수행했습니다(https://gist.github.com/jerch/27c2cf91ad313a25415873e4047b2900 참조). 간단히 말해서 아이디어는 메모리 절약과 런타임 패널티의 절충점에 관한 것입니다. 형식화된 배열로의 전환은 이미 엄청난 메모리 절약을 제공했습니다(현재 트루 컬러 값은 아직 적용되지 않았지만 위에서 두 번째 아이디어를 구현함).