Xterm.js: لا تجعل المحطة الطرفية اللون الحقيقي

لا استطيع الانتظار لهذا. لقد كنت أقوم بالقرصنة في hterm في محاولة للحصول على دعم truecolor لكنني أشعر أن هذا خيار أفضل.

يجب تنفيذ ذلك هنا 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
راجع للشغل تم تحديد هذا جزئيًا في معيار ECMA-48.

ضع دليلًا فوضويًا على المفهوم للحصول على فكرة أفضل عما نحتاج إلى القيام به هنا https://github.com/Tyriar/xterm.js/tree/484_truecolor

الأشياء التي يجب القيام بها:

• يضيف الفرع حاليًا رقمًا آخر لكل حرف يمثل "truecolor" بالتنسيق 0x1RRGGBB (fg) أو 0x0RRGGBB (bg) ، والذي يناسب عددًا صحيحًا من 32 بت
• فإنه يحتاج إلى دعم كل من جي بي جي والألوان، وتكون قادرة على خلط لون حقيقي ولون العادية
• curTrueColor قبيح للغاية
• دعم معكوس
• يجب مسح علامات الألوان عند إعادة استخدام الخلايا

• قد يكون الوقت قد حان لإعادة التفكير في كيفية تشفير الأحرف ، التنسيق الحالي هو:

  [attribute, character, width]
  

  • attribute : عدد صحيح 32 بت يحمل ascii fg و ascii bg والأعلام (غامق ، وتسطير ، وميض ، وعكسي ، وغير مرئي) ، ولا يتم استخدام جميع وحدات البت
  • char : إما السلسلة الفارغة (لعدد 0 من أحرف العرض التي تحتوي على أحرف عريضة) أو سلسلة أحادية الرمز ذات حرف واحد
  • width : يمكن أن يكون عرض الحرف حاليًا 0 أو 1 أو 2 ولكن هذا قد يتضمن المزيد لدعم علامات التبويب بشكل صحيح https://github.com/sourcelair/xterm.js/issues/734
• يجب أن يكون الحل النهائي مضغوطًا للذاكرة وأيضًا الوصول السريع ، وربما يكون التمسك بمصفوفة وأعلام ثنائية وتحويل البت للبيانات هو أفضل فكرة.

تضمين التغريدة
نعم ، سوف ينفجر استخدام الذاكرة إذا لم يتم تحسينها للاستهلاك المنخفض. ربما يمكن تعبئتها مع width ، من غير المحتمل أن يزيد هذا الحقل عن 16 وتستهلك 4 بايت فقط (الإعدادات الافتراضية لعلامة التبويب هي 4 أو 8 بشكل طبيعي). هذا يترك مجالًا لتعريف RGB واحد * (بافتراض أن width هو عدد صحيح 32 بت). لست متأكدًا من عدد وحدات البت المجانية في attribute ، فربما يمكنك الانتقال إلى تعريف RGB الثاني .

يبدو أن السمات تستهلك حاليًا 9 بايت لـ bg و 9 بايت لـ bg و 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]

حيث يكون Attr:

• العرض: 4 بايت
• الأعلام: 5 بايت
• لون 256 bg: 9 بايت
• 256 fg color: 9 بايت

أرغب بشدة في تلخيص هذه التفاصيل لأنها تعقد الأمور حقًا ، وأتساءل عما إذا كانت الكتابة المطبوعة ستسمح لنا بوضع علامات على مصفوفة بطريقة ما. كان استخدام كائن أبطأ بمقدار 20 مرة من مصفوفة استنادًا إلى معيار دقيق قمت به على jsperf ، وأنا أعلم أنها ليست موثوقة دائمًا ولكن هذا نوع من ما كنت أتوقعه كنوع من النفقات العامة لإنشاء كائن بناءً على نموذج أولي.

مهما فعلنا ، يجب توثيق التنسيق جيدًا. الآن عليك معرفة ذلك بنفسك من خلال النظر إلى InputHandler.charAttributes .

بعض الأفكار الأخرى حول توفير الذاكرة:

• إذا كان عرض الحرف> 1 ، فإننا لا نحتاج حقًا إلى تخزين أي بيانات على الإطلاق للأحرف التالية. توجد "الأحرف الفارغة" كحل بديل ومن المحتمل أن تكون null .
• عادةً ما يتم تصميم مجموعة من الأحرف ، مما يعني أنه يمكن مشاركة السمات بين سلسلة من الأحرف.
• يمكن تخزين السمات مؤقتًا ويستخدم كل حرف مؤشرًا لإحدى القيم المخزنة مؤقتًا ،

نعم ، أعتقد أن معظم مصفوفات محركات JS ذات الوصول إلى الفهرس لا تزال أسرع من الكائنات وحل خصائصها. حصل V8 على بعض التحسينات الإضافية للكائنات بالرغم من ذلك. من ناحية أخرى ، يكون إنشاء المصفوفة وجهاز GC أسرع نظرًا لتخطيط الذاكرة الأبسط بكثير (يمكن حذف هذا العيب عن طريق إعادة استخدام الكائنات الموجودة).

ليس لدي أي فكرة عن التصميم الصحيح هنا ، المشكلة هي أن أي أشياء معبأة بشكل كبير ستزيد عقوبة وقت التشغيل بسبب التحولات المطلوبة. (هذا أحد أسباب عدم استخدام حقول البت في لغة سي إذا لم تكن الذاكرة مصدر قلق - عمليات النقل المطلوبة ستلوث ذاكرة التخزين المؤقت للتعليمات مما يؤدي إلى أخطاء في ذاكرة التخزين المؤقت - يعمل الرمز بشكل أبطأ بكثير).
ستظهر اختبارات Imho فقط ما يعمل بشكل أفضل هنا.

jerch مثير للاهتمام ، لدي 4 أرقام للبساطة الآن في https://github.com/sourcelair/xterm.js/pull/756.

لذا من المتوقع أن تكون الذاكرة هنا موجودة: 5 * (1000 التمرير للخلف) * (8 بايت على جهاز 64 بت) * 80 = 3.2 ميجا بايت (قبل الحمل الزائد لصفيف js). العرض الفعلي لمحطة VS Code النموذجية سيشهد ذلك ضعفًا إذا احتفظنا بالتنسيق الحالي. يبدو شديد الانحدار الآن بعد أن نظرت إليه ، خاصة وأن المستخدمين سيكون لديهم غالبًا أكثر من 1000 تمرير للوراء والعديد من المحطات النشطة. المسافة البيضاء الزائدة التي لا تضيف الكثير على الإطلاق ويمكن أن تكون فارغة بنفس السهولة والتي من المحتمل أن تكون فوزًا كبيرًا جدًا.

تبدو فكرة ذاكرة التخزين المؤقت لمجموعة السمات / اللون واعدة أيضًا ، طالما أن هناك طريقة جيدة للوصول السريع. سيكون الهيكل الخفيف الوزن الشبيه بشجرة الفلاش مثاليًا (الوصول السريع لاستخدام السمات بشكل متكرر).

قد يكون من المفيد أيضًا النظر في إعادة استخدام مصفوفات بيانات الخط عند قطعها بدلاً من مجرد التخلص منها (على سبيل المثال ، هنا ).

نعم ومع وضع المحرك في الاعتبار ، فإنه ينمو بشكل أكبر - يتم تخزين كل شيء في مصفوفة أو كائن كمرجع ، بشكل أساسي كمؤشر للمحتوى. تتمتع مصفوفات js الكثيفة بميزة طفيفة هنا ، حيث يتم تشكيلها كمصفوفة مثل C في مكان ما أسفل المسار (جيدًا في الواقع ArrayLists). يتم إنشاء المصفوفات المتفرقة والكائنات الأخرى ببعض سحر الأشجار لحل دقة الملكية.
لذلك بالنسبة لـ 64 بت ، يضيف الشيء المرجعي 5 * 8 بايت لكل خلية (يضاعف أساسًا حساباتك فوق - 6.4 ميجا بايت). يمكن أن يضيف المحتوى المزيد من البايت إلى جانب "المحتوى الحقيقي" ، لكن هذا يعتمد على التنفيذ الفعلي للنوع الصحيح والسلسلة.

ربما يمكن لـ TypedArray حل هذه المشكلة. هناك يمكن للأشياء الصحيحة أن تتواجد مباشرة في موضع الفهرس في الذاكرة دون مراوغة إضافية. asm.js يعمل بشكل أساسي فقط على هؤلاء.

فيما يلي معيار دقيق سريع لمقارنة TypedArray و js-Array للإنشاء وإدراج البيانات: http://jsbench.github.io/#af3ea1056a70df2aa6775699d174df0d

يتم تشغيل TypedArray 10 مرات أسرع مع FF و Chrome على جهازي. قد يكون هذا بسبب التخصيص المسبق ، ولم تختبر هذا باستخدام js-Array لأنه تم تثبيطه. لست متأكدًا مما إذا كانت JITs قد اكتشفت حقيقة أن القيمة تزيد فقط بمقدار 1 كل 8 بايت وحتى تحسين ذلك. ثم المعيار عديم الفائدة على الإطلاق.

يعد الوصول أسوأ قليلاً بالنسبة إلى TypedArray (ربما بسبب التحويل Number ) ، يكون استهلاك الذاكرة أفضل بكثير مع TypedArray.

الجانب السلبي من TypedArray هو الكتلة الثابتة للذاكرة عندما يتعلق الأمر بتخزين البيانات (لن تعمل الحيل لتجنب البيانات على الإطلاق هنا ، أو "تُفقد" الذاكرة على أي حال) أو تغيير الحجم مع التفاف المحتوى. من الصعب فهمها بشكل صحيح ومن المحتمل أن تتضمن نسخ أجزاء كبيرة من البيانات مرارًا وتكرارًا.

أهلا. أي تحديثات على هذا؟ لا استطيع الانتظار للحصول على هذا العمل

هل أي شخص يعمل بنشاط هذه القضية؟ هل تتم مناقشتها في أي مكان آخر؟ تضمين التغريدة هل تساعد Microsoft في إعطاء الاستخدام في VS Code؟

هذه هي آخر مشكلة متأخرة لاستخدام hyper in WSL على نظام التشغيل Windows 10 لتوفير سير عمل CLI مطور لائق يدعم tmux و vim / neovim. المحاكيات الطرفية الأخرى المتاحة للاستخدام مع WSL ليس من اللطيف النظر إليها ، wsltty قريب ، لكن دعم علامات التبويب ودعم البرنامج المساعد مفقودان ...

vastbinderj لماذا لا يمنحك دعم اللون الحقيقي المفقود سير عمل CLI

تضمين التغريدة
لا تزال هذه المشكلة على جدول الأعمال ، ولكن تم حظرها بسبب الاستخدام العالي للذاكرة التي ستقدمها مع تصميم المخزن المؤقت للطرف الحالي. سوف يحظى بمزيد من الاهتمام عندما يجلب لنا # 791 تخطيطًا مؤقتًا أكثر كفاءة.

rfgamaral simple - أنا أعمل عبر العديد من خوادم يونكس / لينكس المختلفة يوميًا على أنظمة مؤسسات كبيرة جدًا مع العديد من الخدمات المصغرة وعدم وجود دعم لائق للألوان في المضيف الرئيسي هو أمر معطّل. التعامل مع الألوان غير المتشابهة سواء كنت على rhel أو centos أو debian ، أمر مؤلم. أيضًا ، الجلوس لمساعدة مطور jr أو نظير على windows يعني أنه يجب علي تبديل السياق إذا لم تعمل الأشياء بشكل موحد. ومع ذلك ، فإنني معجب للغاية بمدى تقدم wsl بهذه السرعة مع التحسينات التي تم إصدارها على أساس شهري تقريبًا ونفس الشيء مع VS Code ، فهو رائع.

jerch شكرًا على التحديث ، سأنتظر بصبر حتى يتم حل # 791 ...

أتطلع إلى هذا أيضًا.

تجدر الإشارة إلى أن أرقام JavaScript يمكن أن تمثل أعدادًا صحيحة تصل إلى 53 بتًا. لذلك لديك 21 بت بالإضافة إلى 32 بت "ملائمة". يمكنك "أو" قليلاً عن طريق إضافة بسيطة ، إذا لم يتم تعيينها بالفعل. لقراءة البتات عالية الترتيب ، ما عليك سوى القسمة على عدد صحيح مناسب مكون من اثنين ، ثم استخدام عمليات البت العادية.

بالطبع هناك القليل من النفقات العامة للعمل مع وحدات البت ذات الترتيب الأعلى ، ولكن في تقسيم وحدات المعالجة المركزية الحديثة حسب الطاقة أو اثنين يعتبر رخيصًا نسبيًا - أرخص من الوصول إلى الذاكرة.

أقترح استخدام رقم واحد مع 50 بت: 25 بت لكل من المقدمة والخلفية. بت واحد إذا كانت المجموعة تشير إلى أننا نستخدم لونًا "حقيقيًا" 24 بت ؛ إذا لم يتم تعيينها ، فنحن نستخدم ألوانًا "منطقية" (قابلة للتخصيص) أو 8 بت. يجب أن تكون بتات المؤشر 2 بت ذات الترتيب الأدنى ؛ إذا قمت بإلغاء ضبط الألوان المنطقية / 8 بت ، يمكن أن تكون في الـ 30 بت التالية ، لذلك نحن نستخدم البتات 32-50 فقط إذا كنا نستخدم لونًا حقيقيًا.

PerBothner قررنا استخدام Uint32Array للمخزن المؤقت الجديد ، ولتوفير الراحة لوضع الألوان في هذه المجموعة أيضًا. لم يتم ذلك بعد لأننا نريد تطهير الضمير الجديد أولاً قبل دعم truecolor.

كما أجريت بعض الاختبارات / الحسابات حول التخطيطات الممكنة (انظر https://gist.github.com/jerch/27c2cf91ad313a25415873e4047b2900). قصة قصيرة طويلة - تدور الأفكار حول توفير ذاكرة المقايضة مقابل عقوبة وقت التشغيل. أعطى الانتقال إلى المصفوفة المكتوبة بالفعل توفيرًا ضخمًا للذاكرة (يطبق حاليًا الفكرة الثانية من أعلى ، على الرغم من عدم تطبيق قيم الألوان الحقيقية بعد).