ระดับการปรับปรุงความเร็วของ Terminal ใน GNOME 46

 (bxt.rs)
3 คะแนน โดย GN⁺ 2024-04-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในรอบ GNOME 46 terminal ที่ใช้ VTE มี input latency ลดลงอย่างมาก และในการทดสอบบน Fedora 40 เข้าใกล้ Alacritty ซึ่งใช้เป็น baseline ที่รวดเร็วมาก
  • การวัดใช้วิธีวัด input latency แบบ end-to-end ตั้งแต่การกดแป้นจนถึงการเปลี่ยนแปลงของพิกเซลบนหน้าจอด้วยเซนเซอร์ฮาร์ดแวร์ จึงสะท้อนเวลาตอบสนองของ kernel, compositor, แอป และจอภาพรวมกัน
  • ทั้งการป้อนข้อมูลแบบง่ายด้วย cat > /dev/null และ การเลื่อนใน neovim ที่ซับซ้อน Console, VTE Test App และ GNOME Terminal ต่างปรับปรุงชัดเจนเมื่อเทียบกับ GNOME 45
  • การเปลี่ยนแปลงหลักน่าจะเป็นการที่ VTE เปลี่ยนจาก 40Hz repaint timer เดิม ไปเป็นการวาดใหม่ทุกเฟรมโดยซิงก์กับจอภาพ
  • Terminal ของ GNOME 46 ที่ใช้ VTE 0.76 มี latency ที่รับรู้ได้ลดลง ทำให้ผู้ใช้ที่เคยหลีกเลี่ยง terminal ที่ใช้ VTE เพราะรู้สึกว่าช้า น่าลองกลับมาใช้อีกครั้ง

สิ่งที่เปลี่ยนไปใน terminal ที่ใช้ VTE

  • VTE คือ Virtual TErminal library ที่เป็นพื้นฐานของ terminal emulator หลายตัวใน GNOME
  • ตลอดรอบ GNOME 46 มีการใส่ การปรับปรุงประสิทธิภาพ จำนวนมากลงใน VTE และ input latency ที่ผู้ใช้รู้สึกได้จริงกลายเป็นประเด็นหลักที่ต้องตรวจสอบ

วิธีวัด input latency

  • input latency คือเวลาตั้งแต่ขณะที่กดปุ่มบนคีย์บอร์ดจนถึงขณะที่สีของพิกเซลบนจอภาพเปลี่ยนไป
    • ยิ่ง latency ต่ำ แอปก็ยิ่งรู้สึกเหมือนตอบสนองทันทีมากขึ้น
    • ความแตกต่างจะเห็นชัดขึ้นเมื่อสลับเทียบระหว่าง latency ต่ำกับ latency สูง
  • การวัดใช้ เครื่องทดสอบ input latency แบบฮาร์ดแวร์ ไม่ใช่การจับภาพหน้าจอด้วยซอฟต์แวร์
    • เชื่อมต่อเซนเซอร์แสงเข้ากับบอร์ด Teensy และบอร์ดเชื่อมต่อกับคอมพิวเตอร์ผ่าน USB
    • เซนเซอร์มองไปยังพื้นที่เล็ก ๆ บนหน้าจอที่ความสว่างเปลี่ยนจากการกดแป้น เช่น เซลล์อักขระเฉพาะใน terminal
    • บอร์ดส่งการกดแป้น เช่น Space และตรวจจับการเปลี่ยนแปลงของปริมาณแสง จากนั้นส่งปุ่มที่สอง เช่น Backspace เพื่อคืนสถานะเดิม
    • ใส่เวลารอแบบสุ่มระหว่างรอบ เพื่อหลีกเลี่ยงไม่ให้การวัดถูกตรึงอยู่กับ refresh rate ของจอภาพ
  • วิธีนี้วัด latency แบบ end-to-end ที่รวมเวลาตอบสนองของ kernel, compositor, แอปพลิเคชัน และจอภาพ
    • ไม่รวม latency ของ firmware คีย์บอร์ด
    • ด้วยบอร์ดและ firmware ปัจจุบัน สามารถบันทึกค่าจากเซนเซอร์แสงได้ประมาณ 35,500 ค่าต่อวินาที
  • การทดสอบแต่ละครั้งทำซ้ำ 120 รอบ
    • รูปแบบที่คาดหวังคือจุดต่าง ๆ กระจายอย่างสม่ำเสมอราวหนึ่งรอบการรีเฟรชของจอภาพ
    • รอบการรีเฟรชของจอ 144Hz อยู่ที่ประมาณ 6.94ms และจุดในกราฟตัวอย่างกระจายในช่วง 7–8ms
    • outlier ที่สูงหรือการกระจายที่กว้างกว่าอาจบ่งชี้ถึง latency หรือการประมวลผลที่ช้าของแอปที่ทดสอบ

สภาพแวดล้อมทดสอบและรายการที่นำมาเปรียบเทียบ

  • ระบบทดสอบคือโน้ตบุ๊ก Lenovo Legion 7 Gen 7 AMD
    • CPU คือ Ryzen 7 6800H
    • GPU คือ Radeon RX 6700M dGPU และใช้เฉพาะ dGPU ผ่าน MUX switch
    • จอภาพคือ Acer Nitro XV320QU, 2560×1440, 144Hz, scale 100%
    • โฮสต์คือ Fedora 40 Silverblue Beta, Mesa 24.0.4
    • compositor คือ raw Mutter 46.0
  • raw Mutter คือสภาพแวดล้อมทดสอบแบบเรียบง่ายที่รันเฉพาะ Mutter โดยไม่มี GNOME Shell
    • สามารถรันด้วยคำสั่งอย่าง mutter --display-server -- alacritty ได้
    • ใกล้เคียงกับเงื่อนไขในอุดมคติที่แทบไม่มี overhead จาก GNOME Shell
  • terminal ที่เปรียบเทียบมี 4 ตัว
    • Alacritty: ไม่ได้ใช้ VTE และในทดสอบก่อนหน้านี้เป็น terminal ที่เร็วอย่างสม่ำเสมอ จึงทำหน้าที่เป็น baseline
    • Console: terminal เริ่มต้นของ GNOME ที่ใช้ GTK 4
    • VTE Test App: terminal สำหรับทดสอบ GTK 4 ที่อยู่ใน repository ของ VTE
    • GNOME Terminal: ใน GNOME 46 เป็นแอป GTK 3 และถูกติดตั้งมาเป็นค่าเริ่มต้นในหลาย distribution
  • การเปรียบเทียบ GNOME 45 กับ GNOME 46 ใช้ container toolbox ของ Fedora 39 และ Fedora 40
    • terminal แต่ละตัวติดตั้งตามแพ็กเกจ Fedora เดิม ๆ และรันโดยไม่มีการปรับแต่งเพิ่มเติม
    • วางหน้าต่างไว้ที่มุมซ้ายบนของจอภาพ และวางเคอร์เซอร์เมาส์ไว้นอกหน้าต่างเพื่อไม่ให้ logic ตรวจจับลิงก์บิดเบือนผลลัพธ์

ผลลัพธ์ของการป้อนข้อมูลแบบง่ายและการเลื่อนใน neovim

  • การทดสอบแรกคือรัน cat > /dev/null แล้ววัดเวลาที่ block cursor ขยับไปทางขวาหนึ่งช่องจากการกด Space
    • เป็นสถานการณ์ที่มี overhead ขั้นต่ำ ไม่มีการประมวลผลเพิ่มเติมอย่าง readline
    • Alacritty ไม่มีการเปลี่ยนแปลงตามคาด แม้จะเปลี่ยนจาก Fedora 39 เป็น Fedora 40
    • terminal ที่ใช้ VTE ปรับปรุงอย่างมากใน GNOME 46 เมื่อเทียบกับ GNOME 45 และเข้าใกล้ระดับเดียวกับ Alacritty
    • GNOME Terminal ที่ใช้ GTK 3 ก็ให้ผลลัพธ์ใกล้เคียงมากเช่นกัน
  • สาเหตุหลักของการปรับปรุงครั้งใหญ่น่าจะเป็น การเปลี่ยนแปลง VTE โดย Christian Hergert
    • หลุดออกจาก VTE repaint timer แบบ 40Hz เดิม
    • เปลี่ยนเป็นวิธีวาดทุกเฟรมโดยซิงก์กับจอภาพ ตามลักษณะของ GTK widget
  • Console มี outlier อยู่บ้าง และอาจเกิดจากการติดตาม process
    • outlier เหล่านี้ไม่ใช่ปรากฏการณ์ใหม่
    • ยังคงเป็นประเด็นที่สามารถไปดูต่อใน GNOME 47
  • การทดสอบที่สองใช้ การตั้งค่า neovim ที่สมจริงกว่า
    • เปิด Ptyxis README จาก snapshot ของการตั้งค่า neovim และเปลี่ยนข้อความบางส่วนเป็นอักขระ Unicode full-block เพื่อให้เซนเซอร์แสงตรวจจับได้
    • ทำซ้ำ Ctrl+D และ Ctrl+U เพื่อเลื่อน text buffer ขึ้นลง
    • terminal ต้องวาดองค์ประกอบบนหน้าจอ เช่น เส้นใต้, undercurl, gutter icon และ status line
  • ในการทดสอบ neovim การปรับปรุงของ terminal บน GNOME 46 ก็ชัดเจนเช่นกัน
    • terminal ที่ใช้ VTE บน GNOME 46 ยังคงอยู่ในระดับเกือบเท่า Alacritty
    • หากดูเฉพาะผลของ Fedora 40 การทดสอบ neovim ทำให้ latency เพิ่มขึ้นเมื่อเทียบกับการทดสอบ cat แบบง่าย แต่ระดับการเพิ่มใกล้เคียงกันใน terminal ทุกตัว

ความแตกต่างที่เหลือซึ่ง vtebench แสดงให้เห็น

  • vtebench เป็น benchmark อัตโนมัติที่วัด ประสิทธิภาพการอ่านและ parse PTY ไม่ใช่ input latency
    • เพราะไม่ได้ครอบคลุมองค์ประกอบสำคัญอย่าง framerate หรือ latency จึงยังไม่เพียงพอสำหรับการเข้าใจประสิทธิภาพของ terminal ทั้งหมด
    • กดดันอย่างหนักเฉพาะความเร็วที่ terminal อ่านจาก PTY
  • เวลา repaint สามารถส่งผลต่อผลลัพธ์ของ vtebench ได้เช่นกัน
    • โดยเฉพาะใน terminal อย่าง VTE ที่รัน logic การอ่าน·parse PTY และ repaint บน thread เดียวกัน
  • VTE ของ GNOME 46 ปรับปรุงขึ้นใน vtebench ด้วย
    • ขนาดการปรับปรุงหลากหลายกว่าการทดสอบ input latency
    • ยังไม่ถึงระดับของ Alacritty ซึ่งทำการอ่านและ parse บน thread แยกจาก rendering
    • การปรับปรุงนี้ดูเหมือนมาจาก optimization หลายอย่างที่ถูกใส่ลงใน VTE ระหว่างรอบ GNOME 46
  • benchmark dense_cells และ unicode ถูกตัดออกจากกราฟผลลัพธ์พื้นฐาน
    • ทั้งสองรายการเป็น stress test หลักของ vtebench
    • VTE ยังให้ผลลัพธ์ที่แกว่งมาก ทำให้กราฟอ่านยาก
  • เมื่อดูตามกรณีทดสอบ ความแตกต่างที่เหลือแทบอยู่ในระดับที่มองข้ามได้
    • ความแตกต่างบางส่วนอธิบายได้จากการที่ VTE ทำงานเพิ่มเติมเพื่อ accessibility, การคำนวณ scrollbar และฟีเจอร์อื่น ๆ
    • accessibility เปิดใช้งานใน GNOME Terminal และปัจจุบันปิดใช้งานใน terminal ที่ใช้ GTK 4
    • หากใช้ VTE 0.76 จะได้ประสิทธิภาพที่รวมการปรับปรุงของ GNOME 46

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-09
ความคิดเห็นใน Hacker News

  • การเปลี่ยนแปลงนี้ทำให้ค่ามัธยฐานของ input latency ในชุดทดสอบที่ลอง ในที่สุดก็ต่ำกว่า Apple //e แล้ว โดย Console อยู่ที่ราว 12ms ส่วน Apple //e ปี 1983 อยู่ที่ 30ms เท่ากับว่าใช้เวลา 41 ปี
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    แต่ benchmark นี้ใช้ raw Mutter 46.0 ซึ่งเป็น compositor ไม่ใช่ GNOME Shell และ raw mutter ก็เป็นสภาพแวดล้อมพื้นฐานมากที่ใกล้เคียงกับการใช้ทดสอบเท่านั้น อีกทั้งยังไม่รวม keyboard latency จึงไม่ใช่การวัดแบบ end-to-end ด้วย ในการทดสอบนี้บอร์ดส่งคีย์อินพุตผ่าน USB ซึ่งแค่ latency ภายในคีย์บอร์ดเองก็อาจสูงได้ถึง 60ms
    https://danluu.com/keyboard-latency/
    สิ่งที่อยากรู้จริง ๆ คือค่าจริงแบบ end-to-end ของชุดตั้งค่าพื้นฐานที่คนใช้งานกัน ซึ่งน่าเสียดายที่บทความไม่ได้วัดส่วนนั้น งานของทีม GNOME และผู้เขียน benchmark นั้นยอดเยี่ยม แต่คำถามสำคัญยังคงค้างอยู่ Apple //e ใช้ hardware acceleration และไม่ได้จัดการ Unicode จึงมีความต่างกันมาก แต่ถึงอย่างนั้นก็น่าจะดีถ้ากลับไปได้ถึงระดับการตอบสนองที่เป็นมิตรกับมนุษย์ของเครื่องอายุเกิน 41 ปีแบบนั้น

    • กลับกัน ผมว่าการที่ผู้เขียนตัด keyboard latency ออกเป็นเรื่องที่ถูกต้องแล้ว เพราะแต่ละคนใช้คีย์บอร์ด, USB interface, คอมพิวเตอร์ และเวอร์ชันระบบปฏิบัติการต่างกัน แถมยังอาจมี hub หรือ KVM เข้ามาเกี่ยวอีก
      ถ้า latency ขององค์ประกอบพวกนั้นแกว่งมากระหว่างทดสอบ ก็จะวิเคราะห์การปรับปรุง latency ของ VTE ซึ่งเป็นประเด็นหลักของบทความนี้ได้ยาก ถึงจะคงที่สมบูรณ์ มันก็แค่บวกค่าคงที่เข้าไปในค่าจริง ทำให้ข้อสรุปไม่เปลี่ยน ดังนั้นจึงไม่ควรแสดงความต่างของ latency เป็นเปอร์เซ็นต์ เพราะในกลุ่มตัวอย่างมีค่าคงที่ที่พอ normalize ได้ แต่ในกลุ่มผู้ใช้ทั้งหมดมีค่าคงที่ที่ normalize ไม่ได้อยู่มาก ประเด็นเรื่อง Mutter น่าสนใจ เพราะ GNOME ทำงานอยู่บน Mutter จึงดูมีโอกาสที่การปรับปรุง latency แบบสัมบูรณ์จะออกมาใกล้เคียงกัน เพียงแต่ GNOME เองก็อาจสร้างความแปรปรวนที่ไม่ต้องการได้เหมือน keyboard latency จึงอยากเห็นการตรวจสอบกับสภาพจริง
    • ถ้าอย่างนั้นก็ใช้ Apple 2e ไปเลยแล้วสละความสะดวกสบายของระบบปฏิบัติการสมัยใหม่ จะได้ไม่ต้องมาพูดเชิงดูแคลนนักพัฒนาโอเพนซอร์สที่พยายามทำของฟรีให้ยืดยาวแบบนี้
    • ในวิธีวิทยาของบทความเรื่อง keyboard latency ที่ลิงก์ไว้ ผมขัดใจอยู่เสมอที่มันรวม เวลาที่ปุ่มเคลื่อนที่ทางกายภาพ เข้าไปด้วย
    • การจัดการ Unicode ไม่ใช่ปัญหาที่ยากอย่างที่คนชอบคิด มีเคสขอบ ๆ ที่ทำให้เพี้ยนอยู่บ้าง แต่ก็มีไม่มากและแก้ไม่ยาก
      สิ่งที่กวนใจจริง ๆ ในบทความนี้คือก่อน test build รุ่นล่าสุด Gnome มี อัตราการวาดใหม่ ถูกตรึงไว้ที่ 40Hz ใครเป็นคนตัดสินใจแบบนั้นกันแน่
    • ข้ออ้างเรื่อง 60ms ในบทความ keyboard latency น่าสงสัย ถ้า latency จากการกดปุ่มไปถึง USB ในคีย์บอร์ดมักอยู่ราว 60ms จริง เกมริธึม ก็คงเล่นไม่ได้เลยตามตัวอักษร แต่ผมไม่เคยเจอปัญหาแบบนั้นกับคีย์บอร์ดตัวไหนที่เคยใช้

  • ดีมาก ชอบที่นักพัฒนา VTE ให้ความสำคัญกับ ประสิทธิภาพ และกระบวนการวัดแบบอิงฮาร์ดแวร์ในบทความก็น่าประทับใจ
    วิธีใช้ photosensor วัด latency ทำให้นึกถึงผลิตภัณฑ์ชื่อโจ่งแจ้งของ Ben Heck อย่าง “Xbox One Controller Monitor” [1] ซึ่งอ่านสถานะปุ่มของเกมคอนโซลคอนโทรลเลอร์โดยตรง แล้วจับคู่กับ photosensor เพื่อช่วยให้นักพัฒนาเกมรักษา latency ให้ต่ำไว้ ผลิตภัณฑ์นี้ดูเท่มาก แต่ราคาตั้ง 900 ดอลลาร์
    [1]: https://www.benheck.com/xbox1monitor/

    • การเริ่มโฟกัสที่ประสิทธิภาพเพิ่งเป็นเรื่องไม่นานนี้เอง เดิมที VTE ค่อนข้างช้า
    • เกร็ดน่าสนใจ: ถ้าเปิด vertical sync อยู่ latency จะเปลี่ยนตามว่าคุณวางเซ็นเซอร์ไว้ตรงไหน

  • ทั้งบทความนี้และบทความที่ลิงก์ไว้ต่างก็วาง photosensor ไว้แถวกลางจอ ซึ่งไม่มีปัญหาสำหรับการเปรียบเทียบค่าที่วัดได้ แต่ในจอทั่วไปจำนวนมาก ที่ 60Hz ถ้าวางเซ็นเซอร์ไว้ด้านบนของจอจะวัดได้เร็วขึ้นราว 8ms และถ้าวางไว้ด้านล่างจะช้าลงราว 8ms เพราะพิกเซลหรือเส้นภาพถูกขับจากบนลงล่าง ซึ่งโดยพื้นฐานก็คล้าย CRT
    ดังนั้นถ้าจะลงรายละเอียด ก็ควรพูดถึงจุดนี้ด้วย เช่นเดียวกับการกำหนด threshold ว่าจะถือว่าพิกเซลติดสว่างแล้วที่ระดับไหนจากสัญญาณ photosensor ดูจากตัวเลขในบทความแล้ว 8ms ถือว่าแตกต่างมาก และในทำนองเดียวกัน การพูดว่า “จอ X ช้ากว่าจอ Y อยู่ 30ms” เฉย ๆ ก็อาจเกินจริง ควรมองว่าเป็นค่าที่วัดได้ในชุดอุปกรณ์และการตั้งค่า X, Y, Z ของผมมากกว่า ต้องตรวจด้วยว่าจอมีการใช้ฟีเจอร์ปรับปรุงแปลก ๆ ที่เพิ่ม latency แต่ไม่ได้ช่วยด้านการรับรู้หรือไม่ และเวลาเปลี่ยนจอ การ์ดจอหรือไดรเวอร์ได้แอบสลับไปใช้การชดเชย, scaling หรือโปรไฟล์เพิ่มคุณภาพแบบหวังดีเกินเหตุหรือเปล่า อุปกรณ์พวกนี้มักไม่เตือนอะไรเลย ซึ่งผมเคยเจอจริงหลายครั้ง

    • ถ้าภาพบนหน้าจอกำลังเลื่อนแบบเรียลไทม์ ผมมีแนวโน้มจะมอง ช่วงล่างหนึ่งในสามของจอ มากกว่ามาก

  • โลกเรานี่ตลกดี ทั้งที่เรามีโลกที่สามารถเรนเดอร์ ฉาก 3D เหนือจริง และเกมบนฮาร์ดแวร์ผู้บริโภคได้ แต่ในเวลาเดียวกันก็ยังต้องพยายามทำเรื่องการพิมพ์ข้อความลงเทอร์มินัลให้สมบูรณ์อยู่

    • ส่วนหนึ่งอาจเป็นเพราะเราไป optimize เพื่อกราฟิกมากขึ้น มี trade-off อยู่ระหว่างสองอย่างนี้ และยิ่งกราฟิกดีขึ้น ข้อความก็อาจแย่ลงตามไปด้วย แม้เทอร์มินัลจะใช้ GPU acceleration มาชดเชยได้บางส่วน แต่ก็ยังต้องจ่ายต้นทุนของ graphics pipeline อยู่ดี
    • อาจเป็นเพราะสมัยก่อนมันไม่ได้สำคัญนักด้วยหรือเปล่า แค่ “ใช้งานได้” ก็พอแล้ว และจนไม่นานมานี้ ในหลายกรณีการใช้งานเทอร์มินัล network latency คือปัญหาใหญ่ที่ต้องจัดการ

  • ไม่เกี่ยวกับเรื่องความเร็ว แต่สงสัยว่าบน Linux มีเทอร์มินัลแบบเดียวกับ Mac OSX Terminal ไหม ที่พอปิดแล้วเปิดใหม่จะกู้คืนทุกแท็บ ประวัติคำสั่งของแต่ละแท็บ และ scrollback ได้ทั้งหมด
    ฝั่ง Mac จัดการโดยตั้งค่าไฟล์ประวัติ bash คนละไฟล์สำหรับแต่ละแท็บประมาณนั้น
    สำหรับการใช้งานแบบนี้ ฉันชอบ GUI terminal มากกว่า

    • พูดถึงอีกเรื่องที่คล้ายกัน พึ่งรู้เมื่อ 1 ชั่วโมงก่อนว่า iterm2 บน Mac สามารถทำงานร่วมกับ tmux ได้ ถ้ารัน tmux ด้วยอาร์กิวเมนต์ -CC เซสชัน tmux จะถูกแมปกับหน้าต่างและแท็บ GUI ของ iterm2 และใช้กับ tmux บนเครื่องรีโมตผ่าน ssh ก็ได้ด้วย
      ฉันชอบลืมคีย์ลัดและคำสั่งควบคุมของ tmux อยู่เสมอ ฟีเจอร์นี้เลยน่าสนใจมาก
      [1] https://iterm2.com/documentation-tmux-integration.html
    • สงสัยว่าถ้าปิดทุกแท็บแล้วเปิดแท็บใหม่จะเกิดอะไรขึ้น ประวัติรายแท็บจะถูกรวมกลับเข้าไปใน ไฟล์ประวัติหลัก ตอนปิดหรือเปล่า เพื่อให้ยังใช้คำสั่งเหล่านั้นในแท็บใหม่ได้
    • ฉันใช้ Tmux มันเป็น multiplexer ที่ไม่ผูกกับตัวเทอร์มินัล ทำให้เรื่องความต่อเนื่องและการทำงานอัตโนมัติทรงพลังมาก
      https://github.com/tmux/tmux/wiki
    • ถ้าชอบ GUI terminal อาจจะไม่ถูกใจ แต่ก็น่าจะมีประโยชน์กับบางคน: https://github.com/tmux-plugins/tmux-resurrect
      แน่นอนว่า tmux ใช้งานร่วมกับ GUI terminal emulator ตัวไหนก็ได้ตามต้องการ
    • ฉันก็กำลังหาสิ่งนี้อยู่พอดี ตอนนี้ใช้ tmux กับ tmux-ressurect เพื่อเก็บสถานะข้ามการรีบูต ซึ่งก็พอใช้ได้ แต่เป็นแค่การแฮ็กที่ยังให้ความรู้สึกเหมือนแฮ็กอยู่ดี
      น่าเสียดายที่ถ้าไม่นับ warp ก็แทบไม่มีวิธีแก้ปัญหานี้แบบจริงจังเลย ความฝันด้าน UX เล็ก ๆ ของฉันคือให้ฟีเจอร์ บันทึก workspace แบบนี้ถูกรวมเข้ากับทั้งระบบปฏิบัติการและแอปข้างในทั้งหมด คงเจ๋งมาก

  • ใช้ Gnome มาหลายปีแล้ว แต่เมื่อ 2 ปีก่อนย้ายไปใช้ sway และ alacritty และพูดตามตรงคือไม่รู้สึกถึงความต่างเลย เหมือนหูและตาของฉันไม่ได้ถูกฝึกให้แยกความแตกต่างแบบอุปกรณ์เสียงระดับไฮเอนด์ได้

    • เคยลองกลับไปใช้ไหม บางทีเรามักจะรู้สึกได้ชัดกว่าเมื่ออาการหน่วง เพิ่มขึ้น มากกว่าตอนที่มันลดลง
    • ฉันใช้ Gnome มาหลายปีและตอนนี้ก็ Gnome 46 แต่เมื่อเทียบกับ Gnome 45 แล้วไม่รู้สึกถึงความต่างของอาการหน่วงในเทอร์มินัลเหมือนกัน ดูเหมือนฉันก็เป็นคนที่ไม่ค่อยรู้สึกกับเรื่องแบบนี้
    • อาจจะไม่ใช่การเปรียบเทียบที่ยุติธรรมนัก แต่เมื่อราว 20 ปีก่อน ระหว่างคอมไพล์เคอร์เนล gnome-terminal ใช้ CPU ไปครึ่งหนึ่ง หลังจากนั้นฉันก็เลิกใช้มัน Xterm ใช้ประมาณ 2%
    • สำหรับเรื่อง latency หรือ responsiveness สิ่งเดียวที่ฉันแคร์คือเวลา เลื่อนหน้าจอใน vim แล้วเทอร์มินัลทำให้ฉันแทบอาเจียนหรือเปล่า
    • หน้าจอหรือคีย์บอร์ดอาจเพิ่ม latency มากพออยู่แล้วจนไม่ว่าคุณจะใช้ซอฟต์แวร์อะไรผลลัพธ์ก็อาจไม่ดี ความต่างระหว่าง latency แย่กับแย่มากอาจไม่ได้ชัดเจนขนาดนั้น สงสัยว่าคุณเคยลองใช้ ฮาร์ดแวร์เกมมิง ไหม

  • ในที่สุดก็มี benchmark เทอร์มินัล ที่ไม่ได้มีแค่การ cat ไฟล์ใหญ่อย่างเดียวแล้ว อยากเห็นเทอร์มินัลที่หลากหลายกว่านี้ โดยเฉพาะ Linux console แบบพื้นฐาน มาทดสอบแบบเดียวกัน

  • นอกประเด็นหน่อย แต่สิ่งที่ฉันไม่ชอบที่สุดใน Gnome Terminal คือมันเปิดหน้าต่างเล็กเป็นค่าเริ่มต้น ขนาดประมาณ 1/4 ของหน้าจอ และถึงจะปรับขนาดแล้วก็ไม่จำหลังจากรีสตาร์ต สุดท้ายเลยต้องเข้าไปตั้งค่า จำนวนคอลัมน์และแถว เอง

    • พฤติกรรมแบบนั้นค่อนข้างพบได้บ่อยในหลายเทอร์มินัล เท่าที่นึกออกก็ทั้ง macOS Terminal แบบค่าเริ่มต้นและ Windows Terminal ก็ต้องไปเปลี่ยนขนาดเริ่มต้นใน settings เหมือนกัน
      ส่วนตัวฉันชอบเก็บขนาดเริ่มต้นไว้ แล้วค่อยปรับเฉพาะหน้าต่างที่ต้องการพื้นที่มากกว่า ถึงอย่างนั้นอย่างน้อยก็ควรมีตัวเลือกให้จำขนาดที่ปรับไว้
    • เปลี่ยนได้ใน settings
      เมนูแฮมเบอร์เกอร์ > Preferences > ชื่อโปรไฟล์ ได้เลย ของฉันชื่อแค่ “Unnamed” เปลี่ยน “initial terminal size” แล้วจะได้ตามต้องการ ฉันตั้งไว้ที่ 132x43
    • ฉันมักเปิดเทอร์มินัลหลายหน้าต่างที่ขนาดไม่เท่ากัน จึงไม่ชัดเจนว่าควรจำขนาดไหนถึงจะถูก
      เพราะงั้นฉันไม่อยากให้มันพยายามทำแบบนั้น ถ้าซอฟต์แวร์ฉลาดตอนที่มันมั่นใจได้ว่ารู้ว่าฉันต้องการอะไร ก็โอเคอยู่หรอก แต่ถ้าไม่ใช่ มันก็จะกลายเป็นอีกกรณีของ “ฉันจัดการทำพังให้อัตโนมัติแล้ว ขอบคุณนะ?”
    • Console ซึ่งเป็น gnome terminal รุ่นใหม่กว่าจะจำขนาดหน้าต่างได้
    • ถ้าจำไม่ผิด นี่เป็นฟีเจอร์ที่มาจาก CMD.EXE

  • ถ้าเปิดตัวเมื่อไร ก็น่าจะดีถ้าเอาเทอร์มินัล Ghostty ของ Mitchell Hashimoto มาใส่ใน benchmark ด้วย ตอนนี้ยังอยู่ในช่วงพัฒนาและเก็บรายละเอียด และยังเป็น private beta
    https://mitchellh.com/ghostty

  • ฉันใช้ xterm กับ i3wn บน debian และยังไม่เคยเจออะไรที่เร็วกว่านี้เลย ไม่เคยคิดด้วยซ้ำว่าจะต้องเอา GPU มาเปลืองกับเทอร์มินัล ดังนั้นส่วนตัวมองว่า alacritty เยอะเกินไป

    • ฉันก็รู้สึกคล้ายกัน ตอนใช้ xterm ฉันไม่เคยคิดเรื่อง latency เลย ทั้งที่ก็ใช้ฟีเจอร์หนัก ๆ อย่างการแปลหรือ sixel ทุกวันด้วยซ้ำ ดูเหมือนผู้คนจะมองข้ามมันเพราะหน้าตาแบบ Athena widget แต่จริง ๆ แล้วมันยอดเยี่ยมมาก