محطات طرفية مُسرَّعة بالـ GPU: من TTY إلى أطلس الرموز

في عام 1978 شحنت شركة Digital Equipment Corporation جهاز VT100. كان أقرب إلى قطعة أثاث: شاشة CRT في غلاف بيج، موصولة بحاسوب مصغّر عبر كابل تسلسلي. لم يكن يشغّل برامج، ولم يكن قادرًا على عرض الرسوميات. كان يعرض النص في شبكة ثابتة بحجم 80 عمودًا في 24 سطرًا، وكانت هذه هي الواجهة الكاملة بين الإنسان والنظام العامل. وبعد قرابة خمسين عامًا، ما زال ما يحدّق فيه المطورون طوال اليوم هو نفس الشبكة من الناحية المفاهيمية. لكن البنية التحتية تغيّرت بطرق لم يكن مصممو VT100 ليتخيلوها. الجيل الأحدث من محاكيات الطرفية، مثل Ghostty وAlacritty وKitty وWezTerm، يمرّر النص عبر خطوط عرض تعتمد على GPU، وكانت أصلًا مبنية لألعاب الفيديو. والفرق في الأداء ليس تحسنًا تدريجيًا، بل هو فرق بنيوي.

لماذا تشكّل الطرفية الافتراضية عنق زجاجة

تطبيق Terminal على macOS وGNOME Terminal على Linux وWindows Console Host، هذه تأتي مع نظام التشغيل، وهي تعمل. ولسنوات كان ذلك كافيًا: تكتب الأوامر، تقرأ المخرجات، ثم تمضي. لكن أسلوب عمل المطورين لم يعد كذلك. نحن نبث سجلات بناء مطوّلة، ونشغّل تطبيقات TUI مثل lazygit وbtop التي تعيد رسم الشاشة كاملة مع كل ضغطة مفتاح، ونمرّر مخرجات منظمة من أدوات البرمجة بالذكاء الاصطناعي، وندير عدة لوحات من المخرجات المتزامنة. الطرفيات القديمة لم تُصمَّم لهذا أصلًا.

السبب الجذري بسيط: عرض يعتمد على المعالج المركزي. الطرفيات القديمة ترسم النص باستخدام واجهات برمجة النصوص الخاصة بالمنصة، وهي تعالج الأحرف بالتسلسل. عندما تُفرغ مجموعة اختبارات عشرة آلاف سطر دفعة واحدة، تضطر الطرفية إلى تحويل كل رمز إلى صورة نقطية على المعالج، ثم تركيبها داخل الإطار، ثم إرسالها إلى الشاشة، وكل ذلك على الخيط الرئيسي. فتتساقط الإطارات، ويرتفع زمن استجابة الإدخال، ويصبح التمرير للخلف بطيئًا. وأنت تشعر بذلك فعلًا، ذلك التقطّع الذي يستمر نصف ثانية عندما تعرض ملفًا كبيرًا بالأمر cat.

هذه ليست مشكلة بسيطة. زمن استجابة الإدخال يؤثر مباشرة على سرعة تفكيرك. تشير الدراسات حول الزمن الذي يفصل بين ضغط المفتاح وظهوره على الشاشة إلى أن التأخير الذي يتجاوز 10 ملّي ثانية يُلاحَظ، والتأخير الذي يتجاوز 50 ملّي ثانية يُبطئ الكتابة بشكل قابل للقياس. فإذا أضافت طرفيتك 20 إلى 30 ملّي ثانية فوق عرض المحرر نفسه، فأنت فعليًا تفكر ببطء أكبر مما ينبغي.

كيف يعمل عرض الطرفية المُسرَّع بالـ GPU فعليًا

إرسال النص إلى GPU يبدو كاستخدام مطرقة لتثبيت دبوس. أحرف أحادية العرض في شبكة ثابتة، فما الصعوبة في ذلك؟ لكن الفكرة وراء الطرفيات المسرّعة بالـ GPU ليست أن عرض النص صعب. بل أن معالجات GPU بارعة بشكل مذهل في تنفيذ العملية الصغيرة نفسها آلاف المرات بالتوازي، وهذا بالضبط ما يتطلبه عرض الطرفية: ختم نسيج بحجم الرمز نفسه داخل الشبكة، آلاف الخلايا في كل إطار.

الحيلة هي أطلس الرموز (glyph atlas). عندما يظهر حرف للمرة الأولى، تحوّله الطرفية إلى صورة نقطية (باستخدام FreeType أو CoreText أو DirectWrite حسب المنصة)، ثم تخزن الصورة في نسيج أطلس على GPU، وهو عبارة عن ورقة صور كبيرة تحتوي على رموز مُعدّة مسبقًا. في كل إطار لاحق، عرض ذلك الحرف ليس أكثر من البحث في النسيج ورسم مستطيل. لا تحويل، ولا تدخّل للمعالج المركزي إلا لتغذية بيانات الشبكة. وهذه هي التقنية نفسها التي تستخدمها محركات الألعاب منذ عقود لعرض النص في المشاهد ثلاثية الأبعاد.

Terminal Rendering Pipeline:
PTY byte stream
→ VT parser (interprets ANSI escape sequences)
→ Cell grid (char + fg color + bg color + attributes per cell)
→ Glyph atlas lookup (GPU texture coordinates for each character)
→ Batch draw calls (one draw per distinct texture/color combination)
→ GPU compositing (text + cursor + selection + background effects)
→ Displayed frame
The expensive step in legacy terminals — per-glyph CPU rasterization —
becomes a cache hit in the atlas. That's the whole trick.

تختلف واجهة العرض حسب المنصة. تستخدم Alacritty وWezTerm مكتبة OpenGL على Linux وMetal على macOS. ولدى Ghostty واجهة Metal مخصصة على macOS وتدعم Vulkan على Linux. وتستخدم Kitty مكتبة OpenGL في كل مكان. الاختيار مهم للتوافق مع المنصات وتعريفات التشغيل، لكن كل هذه المقاربات تشترك في الميزة الجوهرية نفسها: تحوّل التحويل إلى صورة نقطية في كل إطار إلى مسألة أخذ عينات من النسيج بشكل مجمّع، وهي مسألة تحلّها GPU تقريبًا بلا تكلفة.

مقارنة الطرفيات المُسرَّعة بالـ GPU: Ghostty وAlacritty وWezTerm وKitty

تشترك هذه الطرفيات الأربع في فلسفة عرض واحدة، لكنها تختلف جذريًا في كل شيء آخر. كل واحدة منها تعكس إجابة مختلفة عن السؤال: ما المسؤوليات التي يجب أن تتولاها الطرفية؟

Ghostty: واجهة أصلية دون تنازلات

كُتب Ghostty لميتشل هاشيموتو بلغة Zig، مع تكامل واجهة أصلية مع المنصة: AppKit وMetal على macOS، وGTK على Linux. فبينما تبدو معظم الطرفيات متعددة المنصات متشابهة على كل نظام (وهذا يعني أنها تبدو غريبة على كل نظام)، يحترم Ghostty أعراف كل منصة في إدارة النوافذ واختصارات لوحة المفاتيح والتنسيق البصري. يبدو كتطبيق macOS على macOS، وكتطبيق GNOME على GNOME. قد يبدو هذا شأنًا شكليًا، لكن عندما تكون الطرفية هي التطبيق الذي تقضي فيه معظم وقتك، فإن الإحساس الأصلي يتراكم تأثيره على مدى شهور.

Alacritty: افعل شيئًا واحدًا وافعله بسرعة

بدأ Alacritty حركة الطرفيات المُسرَّعة بالـ GPU. كُتب بلغة Rust، ويتعمد حذف علامات التبويب والتقسيم والتعدد المدمج. والفلسفة هنا روح يونكس: افعل شيئًا واحدًا جيدًا، ودع الأدوات الأخرى تتولى الباقي. إذا كنت تستخدم tmux أو مدير نوافذ بتقسيم البلاط بالفعل، فسيمنحك Alacritty أسرع عرض خام وأقل بصمة للموارد. لن يفوز في مقارنة الميزات، وهذه هي النقطة.

WezTerm: كل شيء في مكان واحد، ومُنفَّذ جيدًا

يتخذ WezTerm الموقف المعاكس. تعدد مدمج، وتكامل مع SSH، وإعداد بلغة Lua، ودعم للربط (ligatures)، وعرض للصور. إنه طرفية شاملة بالكامل. ومحرك Lua النصي فيه قوي فعلًا؛ يمكنك كتابة روابط مفاتيح شرطية، وعناوين تبويب ديناميكية، ومنطق للتنقل بين مساحات العمل كان سيتطلب ثلاث أو أربع أدوات منفصلة في إعدادات أخرى. إذا أردت تطبيقًا واحدًا يحل محل الطرفية، ومُعدِّد الجلسات، ونصف سكربتات ملفات الإعداد لديك، فـ WezTerm هو الخيار الذي يستحق التجربة.

Kitty: الرائد في البروتوكولات

إسهام Kitty الأبقى ليس محرك العرض، بل البروتوكولات. يتيح بروتوكول رسومات Kitty للتطبيقات عرض الصور النقطية داخل النص. ويحل بروتوكول لوحة المفاتيح الخاص به مشكلة عمرها عقود في الإبلاغ الغامض عن المفاتيح (جرّب التمييز بين Ctrl+I والجدولة Tab في طرفية قديمة، لن تستطيع). وقد تبنّت طرفيات أخرى هذه البروتوكولات، كما تبنتها أطر عمل TUI مثل Textual وRatatui. دفع Kitty المنظومة كلها إلى الأمام، والأدوات التي تستخدمها اليوم أفضل بفضله.

اختبارات أداء الطرفيات: ما الذي يهم وما الذي لا يهم

اختبارات أداء الطرفيات سهلة، لكن إجراءها بشكل خاطئ أسهل. عرض ملف ضخم بالأمر cat وقياس الوقت يقيس الإنتاجية، لكن هذا ليس المقياس الذي يؤثر في تجربتك اليومية. ثلاثة أرقام فقط هي المهمة فعلًا.

• زمن استجابة الإدخال: المدة بين ضغط المفتاح ورؤيته على الشاشة. الطرفيات المُسرَّعة بالـ GPU تحقق باستمرار 2 إلى 5 ملّي ثانية، أما الطرفيات القديمة فتبقى عند 15 إلى 30 ملّي ثانية. وأنت تشعر بذلك في كل مرة تكتب فيها.
• اتساق الإطارات: ليس متوسط عدد الإطارات في الثانية فحسب، بل التباين أيضًا. طرفية تعرض 60 إطارًا في الثانية لكنها تهبط إلى 15 أثناء المخرجات الكثيفة تبدو أسوأ من طرفية تحافظ على 30 إطارًا ثابتًا. ويتفوق التركيب بالـ GPU هنا لأن تكلفة العرض تبقى شبه ثابتة مهما تغيّر حجم ما على الشاشة.
• استهلاك الموارد في وضع الخمول: يجب ألا تستهلك طرفية مفتوحة عند موجه الأوامر قدرًا معتبرًا من المعالج. عانت بعض الطرفيات المُسرَّعة بالـ GPU في البداية من استهلاك طاقة في الخمول بسبب إعادة رسم غير ضرورية، لكن هذه المشكلة حُلّت إلى حد كبير. ويستقر Alacritty وGhostty عادةً عند 30 إلى 60 ميغابايت من الذاكرة. أما WezTerm فيستهلك 80 إلى 150 ميغابايت بسبب بيئة تشغيل Lua.

# Quick throughput test — not the most important metric,
# but reveals rendering architecture differences
time seq 1 1000000 | head -c 10M > /dev/null  # baseline
time seq 1 1000000                              # terminal-limited
# Measure input latency with Typometer (Java) or similar
# https://github.com/pavelfatin/typometer
#
# Typical results on modern hardware:
#   Ghostty:      2-4ms
#   Alacritty:    2-4ms
#   Kitty:        3-5ms
#   WezTerm:      4-6ms
#   Terminal.app: 15-25ms
#   GNOME Term:   20-30ms
# For frame consistency, vtebench is the best tool:
# https://github.com/alacritty/vtebench
vtebench --benchmark scrolling --iterations 100

الطرفية الأسرع ليست بالضرورة الطرفية الأفضل. الأفضل هي التي تتوافق مبادلاتها مع طريقة عملك الفعلية. يحتاج مستخدم tmux المتمرس إلى أشياء مختلفة عن شخص يعتمد على التقسيمات الأصلية، وكلاهما يحتاج أشياء مختلفة عن شخص يعيش داخل الطرفية المدمجة في VS Code.

التعدد المدمج مقابل tmux: نظرة عملية

هذا هو السؤال الذي يبدأ الجدل. هل ينبغي لطرفيتك أن تتولى التقسيم والتبويب، أم تترك ذلك لـ tmux؟ لن أضيع وقتك بالتحفظات: كلا النهجين جيد، والإجابة الصحيحة تعتمد على متغير واحد: هل تحتاج إلى استمرارية الجلسات؟

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

لكن في التطوير المحلي، للتعدد المدمج ميزة حقيقية. التقسيمات الأصلية مُركّبة بالـ GPU، إذ تعرض الطرفية جميع اللوحات مباشرة في إطار واحد. أما تشغيل tmux داخل طرفية مُسرَّعة بالـ GPU فيعني عرضًا مزدوجًا: يرسم tmux شاشته الافتراضية في مخزن أحرف، ثم تعيد الطرفية عرض ذلك المخزن على GPU. تدفع ثمن أداء إضافي، وتفقد الوصول إلى ميزات الطرفيات الحديثة مثل الصور المضمّنة وبروتوكول لوحة المفاتيح الخاص بـ Kitty، لأن tmux يقع بين تطبيقك والطرفية ولا يمرر هذه البروتوكولات بشكل سليم.

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

بروتوكولات الطرفية الحديثة التي تفتح سير عمل جديدًا

عرّف VT100 مجموعة من تسلسلات الهروب (escape sequences) التي دعمتها الطرفيات لعقود. وتوسّع الطرفيات الحديثة هذه التسلسلات ببروتوكولات جديدة تتيح سير عمل لم يتخيله المصممون الأوائل.

يتيح عرض الصور المضمّنة عبر بروتوكول رسومات Kitty أو Sixel لأدوات سطر الأوامر عرض المخططات والفروقات (diffs) والرسوم التخطيطية دون فتح متصفح أو نافذة منفصلة. يمكن لأدوات تحليل البيانات رسم المخططات مباشرة في الطرفية، ويمكن لمساعدي البرمجة بالذكاء الاصطناعي عرض المخرجات المرئية داخل النص. يبدو هذا كأنه لعبة شكلية حتى تجربه، وعندها يبدو بديهيًا.

المخرجات المتزامنة (الوضع 2026، بالمصادفة) تتيح للتطبيقات تجميع تحديثات الشاشة في إطارات ذرية. ومن دونها، يسبب تطبيق TUI يعيد رسم واجهته بالكامل، مثل مدير الملفات أو لوحة المتابعة أو محرر النصوص، وميضًا مرئيًا، لأن الطرفية ترسم كل تسلسل هروب فور وصوله. مع المخرجات المتزامنة، تخزّن الطرفية كل شيء بين علامة البداية وعلامة النهاية، ثم ترسمه دفعة واحدة. وتفعّل أطر عمل مثل Ratatui وTextual هذه الميزة تلقائيًا عندما تدعمها الطرفية.

# Test Kitty keyboard protocol support
printf '\e[?u'  # Query keyboard protocol flags
# Test Kitty graphics protocol support
printf '\e_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA\e\\'
# Synchronized output — bracket your screen updates
printf '\e[?2026h'  # Begin synchronized update
# ... application writes to screen ...
printf '\e[?2026l'  # End — terminal renders everything at once

يستحق بروتوكول لوحة مفاتيح Kitty اهتمامًا خاصًا. تعاني معالجة لوحة المفاتيح في الطرفيات من مشاكل منذ أربعين عامًا. كان VT100 يرمّز Ctrl+I والجدولة Tab بالبايت نفسه (0x09)، وتبدأ مفاتيح Escape ومفاتيح Alt كلها بالبايت 0x1b. يستبدل بروتوكول Kitty ذلك بإبلاغ واضح ولا لبس فيه عن أحداث المفاتيح: الضغط والإفلات والتكرار، مع معلومات كاملة عن مفاتيح التعديل. وتدعمه Neovim وHelix ومحررات أخرى بالفعل. وبمجرد أن تستخدم طرفية يعمل فيها Ctrl+Shift+Enter كاختصار مستقل فعلًا، لن تستطيع العودة.

إعداد طرفية مُسرَّعة بالـ GPU للإنتاجية الحقيقية

تثبيت طرفية سريعة وتشغيلها بالإعدادات الافتراضية يمنحك نحو 30% من الفائدة فقط. أما الباقي فيأتي من الإعداد. إليك ما يهم فعلًا.

يؤثر اختيار الخط على سهولة القراءة وحجم أطلس الرموز وسلوك الربط (ligatures). خطوط JetBrains Mono وFira Code وMonaspace من الخيارات الشائعة التي تدعم الربط. وإذا استخدمت نسخة من Nerd Font، ستحصل على أيقونات في موجه الصدفة ومدير الملفات وأدوات git. تدعم Ghostty وWezTerm وKitty الربط كلها، أما Alacritty فيتعمد عدم دعمه، بحجة أنها تشتّت الانتباه بصريًا في الكود.

# Ghostty config (~/.config/ghostty/config)
font-family = "JetBrains Mono"
font-size = 14
adjust-cell-height = 2
font-feature = "calt"
font-feature = "liga"
background-opacity = 0.95
theme = "catppuccin-mocha"
scrollback-limit = 100000
# Shell integration — Ghostty auto-injects on macOS,
# but you may need this on Linux:
# source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"

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

# Shell integration for Ghostty in .zshrc
if [[ -n "$GHOSTTY_RESOURCES_DIR" ]]; then
source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"
fi
# For Kitty, add to .zshrc:
if [[ -n "$KITTY_INSTALLATION_DIR" ]]; then
autoload -Uz -- "$KITTY_INSTALLATION_DIR/shell-integration/zsh/kitty-integration"
kitty-integration
fi

الواقع متعدد المنصات: macOS وLinux وWindows

تطوير محاكيات الطرفية من المجالات التي يكون فيها دعم المنصات المتعددة صعبًا فعلًا، لا مملًا فحسب. لكل نظام واجهات GPU مختلفة (Metal وVulkan وOpenGL وDirectX)، وأنظمة عرض خطوط مختلفة (CoreText وFreeType وDirectWrite)، وأنظمة نوافذ مختلفة (Cocoa وX11 وWayland وWin32)، وتوقعات مختلفة من المستخدمين لطريقة تصرف التطبيقات.

على macOS التجربة هي الأفضل في كل الجوانب. Metal واجهة حديثة وأنيقة، وCoreText يتعامل مع عرض الخطوط بكفاءة، ونظام النوافذ متّسق. وتعمل الطرفيات الأربع الكبرى المُسرَّعة بالـ GPU بشكل جيد هنا.

Linux أكثر تشتتًا. الانقسام الأكبر هو X11 مقابل Wayland، فبعض الطرفيات تدعم الاثنين وبعضها لا يدعم إلا أحدهما. وتتفاوت جودة تعريفات GPU بين تعريفات NVIDIA الخاصة وحزمة Mesa من AMD ورسومات Intel المدمجة. ويريد مستخدمو مديري النوافذ ذوي تقسيم البلاط سلوكًا مختلفًا عن مستخدمي GNOME أو KDE. الأمر يعمل، لكنك قد تحتاج إلى بعض التعديل.

قطعت ويندوز شوطًا طويلًا. Windows Terminal خيار قوي مُسرَّع بالـ GPU من البداية. ويتيح WSL2 وWSLg تشغيل طرفيات Linux الأصلية على ويندوز بأداء معقول. ويتمتع Alacritty وWezTerm بدعم من الدرجة الأولى لـ Windows. أما Ghostty فهو أحدث في منظومة ويندوز، لكنه يتوسع في دعمه.

إلى أين تتجه تقنية الطرفيات

أصبح عرض GPU أمرًا أساسيًا اليوم. والجبهة التالية هي ما تفعله الطرفيات بالفهم الدلالي الذي تملكه أصلًا. فالطرفية المُسرَّعة بالـ GPU لا تدفع البكسلات فقط، بل تحتفظ بنموذج منظم للشاشة: أي خلية تحتوي على أي حرف، وما الألوان والسمات المضبوطة، وأين تقع حدود الأوامر. وهذا النموذج أساس لميزات أذكى.

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

إمكانية الوصول تحظى باهتمام متأخر. تستطيع الطرفيات المُسرَّعة بالـ GPU عرض نموذج الشاشة الدلالي الخاص بها عبر واجهات إمكانية الوصول في المنصة، وهذا أفضل محتمل من الطرفيات القديمة التي لا تعرض إلا البكسلات الخام. وقد جعلت عدة مشاريع هذا أولوية في عام 2026، والنتائج واعدة.

هناك أيضًا اهتمام متزايد بامتدادات الطرفية المبنية على WASM، أي نموذج إضافات موحّد يسمح للميزات التي يبنيها المجتمع (عارضات مخصصة، ومعالجات بروتوكولات، ومعالجات مدخلات) بالعمل بأمان عبر طرفيات مختلفة. المشروع في مراحله المبكرة، لكن فكرة منظومة امتدادات للطرفية، شبيهة بامتدادات المتصفح ولكن لسطر الأوامر، تحمل جاذبية واضحة.

صدر VT100 قبل قرابة خمسين عامًا. التجريد الأساسي الذي أرساه، أي شبكة من الأحرف تتحكم فيها تسلسلات الهروب، أثبت متانة لافتة. ما تغيّر ليس هذا التجريد، بل طريقة تنفيذه: عرض GPU، وبروتوكولات حديثة، وتكامل أصلي مع المنصات. لم تكن الطرفية بحاجة إلى إعادة اختراع، بل كانت بحاجة إلى إعادة هندسة. وهذا العمل، أخيرًا، جارٍ على قدم وساق.