ตัวเลขโดยละเอียดในการอภิปรายเรื่องความหน่วงอินพุตของ Wayland เทียบกับ X11

 (mort.coffee)
2 คะแนน โดย GN⁺ 2025-01-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เปรียบเทียบ Wayland กับ X11 โดยถ่าย ความหน่วงอินพุตของเคอร์เซอร์ ในสภาพแวดล้อม Fedora Workstation 41·GNOME 47 ด้วยสโลว์โมชัน 240 FPS
  • บันทึก ความหน่วงเป็นจำนวนเฟรม ของ Wayland 16 ครั้งและ X11 16 ครั้ง โดยนับตั้งแต่เฟรมที่เมาส์เริ่มขยับจนถึงเฟรมที่เห็นเคอร์เซอร์อยู่ในตำแหน่งใหม่
  • GNOME X11 วัดได้เฉลี่ย 4 เฟรม·16.7ms·2.4 รอบรีเฟรชหน้าจอ ส่วน GNOME Wayland วัดได้เฉลี่ย 5.5625 เฟรม·23.2ms·3.3 รอบรีเฟรชหน้าจอ
  • ในระบบดังกล่าว Wayland มี ความหน่วงของเคอร์เซอร์สูงกว่า X11 โดยเฉลี่ยประมาณ 6.5ms และส่วนต่างเกือบเท่ากับการรีเฟรชหน้าจอ 1 ครั้ง
  • ผลลัพธ์แสดงเฉพาะ ความแตกต่างของความหน่วงเคอร์เซอร์ ในชุด GNOME/AMD เท่านั้น ไม่ใช่หลักฐานว่า Wayland มีความหน่วงอินพุตสูงกว่าในเกมหรือแอปกราฟิกทั่วไป

ทำไมจึงวัด

  • ผู้ใช้ Linux รายหนึ่งทำการทดลองเพื่อหาค่า ตัวเลขที่เป็นรูปธรรม แทนความรู้สึกส่วนตัว หลังจากมีบทความ Wayland Cursor Lag: Just give me a break already... ที่พูดถึงข้อร้องเรียนเรื่องความหน่วงอินพุตของ Wayland
  • จุดเริ่มต้นของการทดลองคือ แม้โดยรวมจะพอใจกับการใช้งาน Wayland แต่รู้สึกว่าอาจมี ความหน่วงของเคอร์เซอร์ มากกว่า X11
  • เห็นว่ากล้องมือถือ 90 FPS ในบทความเดิมยังไม่เพียงพอสำหรับตัดสินความแตกต่างระดับหนึ่งรอบรีเฟรชหน้าจอ จึงใช้โหมดถ่าย 240 FPS

วิธีการวัด

  • ใช้กล้องมือถือถ่ายหน้าจอ โต๊ะ เคอร์เซอร์เมาส์ เมาส์ และมือพร้อมกัน ขณะใช้นิ้วดีดเมาส์ซ้ำ ๆ
  • ถ่ายในเซสชัน GNOME Wayland 16 ครั้ง จากนั้นล็อกอินเข้าเซสชัน GNOME X11 แล้วถ่ายอีก 16 ครั้งด้วยวิธีเดียวกัน
  • แปลงวิดีโอที่ถ่ายเป็น เฟรม JPEG ด้วยคำสั่ง ffmpeg -i <input file> %04d.jpg
  • นับความหน่วงเป็นเฟรมตามเกณฑ์ต่อไปนี้
    • เริ่มนับจากเฟรมแรกที่เห็นว่าเมาส์ขยับ
    • นับจนถึงเฟรมแรกที่เห็นชัดว่าเคอร์เซอร์ขยับไปตำแหน่งใหม่
    • นับรวมทั้งเฟรมเริ่มต้นและเฟรมสิ้นสุด
    • ตัวอย่างเช่น หากเมาส์ขยับที่เฟรม 1045 และเคอร์เซอร์ขยับที่เฟรม 1047 จะบันทึกเป็นความหน่วง 3 เฟรม

สภาพแวดล้อมทดสอบ

  • ฮาร์ดแวร์และซอฟต์แวร์ที่ใช้ทดลองมีดังนี้
    • ดิสทริบิวชัน: Fedora Workstation 41
    • เวอร์ชัน GNOME: 47
    • CPU: AMD Ryzen 9 5950X
    • GPU: AMD Radeon RX 7900XT
    • จอภาพ: Gigabyte M32U, 4K IPS, 144.99Hz, ไม่มี DPI scaling
    • เมาส์: Logitech G502 Lightspeed
    • กล้อง: iPhone 15 Pro, สโลว์โมชัน 240 FPS

ข้อจำกัดในการวัด

  • แม้ 240 FPS ก็ยังมีเฟรมกล้องน้อยกว่า 2 เฟรมต่อการรีเฟรชหน้าจอหนึ่งครั้งบนหน้าจอ 144Hz จึงเกิด ความแปรผันแบบสุ่ม ได้
  • เนื่องจากพิกเซลไม่ได้เปลี่ยนสถานะทันที จึงมี เฟรมที่กำกวม ซึ่งเคอร์เซอร์เริ่มปรากฏจาง ๆ ในตำแหน่งใหม่
  • แม้เคอร์เซอร์ยังไม่สว่างเต็มที่ แต่หากเห็นชัดในตำแหน่งใหม่ ก็ถือว่าเคอร์เซอร์ขยับแล้ว
  • วิดีโอจาก iPhone มี เฟรมซ้ำ บางส่วน โดยไม่ทราบสาเหตุ
    • เฟรมซ้ำถูกนับเหมือนเฟรมปกติ โดยถือว่าเวลาผ่านไปหนึ่งเฟรม
  • ปัจจัยเหล่านี้ทำให้ผลลัพธ์มีความไม่แน่นอน แต่คาดว่าจะส่งผลต่อ Wayland และ X11 เหมือนกัน และจะถูกเฉลี่ยออกหากมีข้อมูลเพียงพอ
  • ไม่ได้ทดสอบ Wayland compositor อื่นนอกเหนือจาก GNOME หรือไดรเวอร์ GPU อื่นนอกเหนือจาก AMD ดังนั้นผลลัพธ์อาจต่างออกไปในชุดอื่น

ผลการวัด

  • ค่าที่วัดได้ 16 ครั้งของ GNOME X11 คือ 5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4 เฟรม
    • ค่าเฉลี่ย: 4 เฟรม
    • เวลาหน่วง: 16.7ms
    • การรีเฟรชหน้าจอ: 2.4 ครั้ง
  • ค่าที่วัดได้ 16 ครั้งของ GNOME Wayland คือ 6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6 เฟรม
    • ค่าเฉลี่ย: 5.5625 เฟรม
    • เวลาหน่วง: 23.2ms
    • การรีเฟรชหน้าจอ: 3.3 ครั้ง
  • ในระบบนี้ Wayland มีความหน่วงของเคอร์เซอร์สูงกว่า X11 โดยเฉลี่ยประมาณ 6.5ms
  • แม้ไม่มีความเชี่ยวชาญพอจะวิเคราะห์อย่างถูกต้องว่ามีนัยสำคัญทางสถิติหรือไม่ แต่จากค่าที่วัดได้ ดูเหมือนมีความแตกต่างที่ชัดเจนและสม่ำเสมอ
  • ส่วนต่างเกือบเท่ากับ การรีเฟรชหน้าจอ 1 ครั้ง และไม่ทราบว่าเป็นเรื่องบังเอิญหรือไม่

ข้อสรุปและขอบเขตการตีความ

  • การทดลองนี้แสดงให้เห็นว่า บนฮาร์ดแวร์เฉพาะชุดหนึ่ง มี ความแตกต่างของความหน่วงอินพุต ระหว่าง X11 และ Wayland และอาจมากพอที่ผู้ใช้บางคนจะสังเกตได้
  • หากต้องการทำความเข้าใจขอบเขตและขนาดของปัญหาให้ชัดเจน จำเป็นต้องทดสอบเพิ่มเติมกับฮาร์ดแวร์และอัตรารีเฟรชหน้าจอที่หลากหลายกว่าเดิม
  • ขนาดของความแตกต่างอาจเปลี่ยนไปตามปัจจัยอย่าง compositor ที่ใช้และอัตรารีเฟรชหน้าจอ
  • การทดลองเพิ่มเติมใช้เวลามาก จึงมีความเป็นไปได้สูงว่าจะไม่ได้ทำเอง
  • การทดสอบนี้ไม่ได้แสดงว่า Wayland มีความหน่วงอินพุตโดยรวมสูงกว่า X11
    • โดยเฉพาะอย่างยิ่ง ไม่ใช่หลักฐานว่า Wayland มีความหน่วงอินพุตสูงกว่าในเกม
    • เป็นไปได้ว่าความหน่วงที่เพิ่มขึ้นเป็น เฉพาะเคอร์เซอร์
    • เข้าใจว่าเคอร์เซอร์ถูกจัดการแตกต่างจากแอปกราฟิกทั่วไปมาก
    • การที่ Wayland มีความหน่วงอินพุตสูงกว่า X11 ในเกมหรือไม่ จำเป็นต้องทดสอบแยกต่างหาก

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

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

 
GN⁺ 2025-01-27
ความคิดเห็นจาก Hacker News

  • เป็นแนวทางที่ยอดเยี่ยม ดูเหมือนผู้คนมักจะเดาเรื่องที่สามารถ ตรวจสอบเชิงทดลอง ได้บ่อยเกินไป หลังจากเรียนรู้วิธีการทางวิทยาศาสตร์แล้ว ผมมักถูกดึงไปทาง “ลองออกแบบการทดลองกันเถอะ” เสมอ
    ไม่รู้ว่าทำไม Wayland ถึงมี latency เพิ่มขึ้น แต่ในฐานะคนที่อยู่ในคอมมูนิตี้คอมพิวเตอร์ตั้งแต่ยุคที่ X11 เพิ่งออกมา ผมบอกได้ว่าตั้งแต่ช่วงแรก ๆ ก็มีเสียงบ่นเรื่องความหน่วงของหน้าจอไม่ขาดสายแล้ว ไม่ว่าจะเป็นการตอบสนองของเคอร์เซอร์หรือการเลื่อนใน xterm ก็เหมือนกัน
    ตอนที่ “เวิร์กสเตชัน” ปรากฏขึ้น บางเครื่องมีฮาร์ดแวร์แสดงผลแยกต่างหากสำหรับเมาส์โดยเฉพาะ เป็นอุปกรณ์เพื่อลดความหน่วงในการเรนเดอร์เมาส์ลงในเฟรม และยังมีสิทธิบัตร XOR อันเลื่องชื่อด้วย: https://patents.google.com/patent/US4197590
    เพราะเสียงบ่นเหล่านี้ เส้นทางโค้ดตั้งแต่อินพุตคีย์บอร์ด/เมาส์ไปจนถึงการสะท้อนผลบนหน้าจอจึงถูกทบทวนอยู่เสมอว่าจะทำให้ “เร็วขึ้น หน่วงน้อยลง” ได้อย่างไร Wayland ค่อนข้าง “ใหม่” เมื่อเทียบกับ X11 จึงยังไม่ได้ถูกพิสูจน์มายาวนานเท่า แต่ก็หวังว่าผู้คนจะช่วยกันแก้ไขต่อไป

    • อุปกรณ์แสดงผล ซึ่งโดยมากเป็นส่วนหนึ่งของ GPU ยังคงมีฮาร์ดแวร์แสดงผลที่ระบุชัดสำหรับเมาส์โดยเฉพาะ และตอนนี้อยู่ในรูปของ cursor plane ต่อมาก็มี overlay plane ที่ทำให้แนวคิดนี้ทั่วไปขึ้นด้วย
      plane สามารถอัปเดตหรือเปลี่ยนตำแหน่งได้โดยไม่ต้องวาดหน้าจอส่วนที่เหลือใหม่ ภาพหน้าจอทั่วไปอยู่บน primary plane ส่วนการเลื่อนเคอร์เซอร์ก็ใกล้เคียงกับการ commit ตำแหน่ง plane ใหม่
      latency อินพุตที่ GNOME Mutter ซึ่งเป็นเซิร์ฟเวอร์ Wayland ที่ใช้ในที่นี้เพิ่มเข้ามา น่าจะเป็นปัญหาเรื่องกลยุทธ์ timing ของการ sampling อินพุตและการ commit เป็นหลัก แต่ละเซิร์ฟเวอร์มีกลยุทธ์และลำดับความสำคัญต่างกัน จึงมีข้อดีข้อเสียต่างกัน
      Wayland เป็นโปรโตคอล จึงไม่ได้เข้าไปเกี่ยวข้องกับกระบวนการกำหนดตำแหน่งเคอร์เซอร์โดยทั่วไป ดังนั้นปัญหานี้จึงเป็นเรื่องภายใน implementation และการ optimize ของ display server ทั้งหมด ในระดับโปรโตคอล สิ่งที่เกิดขึ้นก็แค่ให้ client ตั้งค่าภาพเคอร์เซอร์ และแจ้งตำแหน่งเคอร์เซอร์ให้ client ทราบเท่านั้น
    • สมัยก่อน XFree86 และ Xorg อัปเดต pointer โดยตรงภายใน SIGIO handler แต่ตอนนี้เป็นเรื่องเก่ามากแล้ว และในยุคนี้ก็ไม่ได้คาดว่า Wayland กับ Xorg จะต่างกันมากในส่วนนี้
      เท่าที่จำได้ สถานการณ์เริ่มแย่ลงเมื่อ glamour ปรากฏใน Xorg เมื่อเส้นทางการเรนเดอร์เคอร์เซอร์ไม่ปลอดภัยที่จะรันใน signal handler อีกต่อไป ซึ่งถ้าใช้ OpenGL เป็นฐานก็ย่อมเป็นแบบนั้นอยู่แล้ว latency จึงแย่ลงไปอีก
      สมัยก่อนแม้เครื่อง Linux จะกำลัง thrashing อยู่ pointer ของเมาส์ก็ยังตอบสนองต่อไป และเป็นตัวบ่งชี้ที่เชื่อถือได้ว่าคอร์เนลค้างหรือไม่ ถ้า pointer ไม่ตอบสนองเร็วพอ มักเป็นกรณีที่ต้องเปิด unmask irq ด้วย hdparm บนโฮสต์ IDE/PATA pointer ที่ไม่ตอบสนองใน XFree86 เป็นสัญญาณที่มีประโยชน์มากว่ามีอะไรผิดปกติหรือการตั้งค่าผิดพลาด คิดถึงวันเหล่านั้นจริง ๆ
    • Wayland อายุเท่าไรแล้ว? ด้วยความเร็วแบบนี้คงได้นั่งอ่าน “ความฝันในฤดูใบไม้ผลิ” อยู่ในหลุมศพแล้ว
      ผมเข้าใจว่าการบ่นซอฟต์แวร์ฟรีเป็นอย่างไร แต่สิ่งนี้ถูก บังคับให้ย้าย ไปสู่สิ่งที่แย่กว่ามานานเกินไปแล้ว การนำ Wayland มาใช้ควรตั้งอยู่บนสมมติฐานว่ามันเหนือกว่าแทบจะครอบคลุมทั้งหมดในทุกความต้องการด้านอินพุตและการแสดงผล
      ผู้ผลิต Intel, AMD, Nvidia, Arm ควรรวมพลังกันผ่านคอนซอร์เทียมเพื่อผลักดันเดสก์ท็อป Linux ที่ใช้งานได้จริงอย่างเต็มที่ รัฐบาลก็ควรทำเช่นเดียวกัน เพราะเดสก์ท็อป Linux ที่ปลอดภัยนั้นเป็นไปได้จริง และเป็นเส้นทางที่เร็วที่สุดในการแสดงศักยภาพของ CPU, ฟังก์ชัน 3D และฮาร์ดแวร์เวกเตอร์/คอมพิวต์ขั้นสูง
      Wayland ปรากฏขึ้นในช่วงที่ Windows กำลังพยายามทำลายตัวเองด้วย UI แบบ tile ที่ย่ำแย่ และช่วงที่ Apple ดื้อดึงปฏิเสธมูลค่าตลาดเพิ่มเติมที่อาจได้หากปล่อย macOS สำหรับ x86 ทั่วไป จึงกลายเป็นการเพิ่มความล่าช้าให้เดสก์ท็อป Linux เข้าไปอีก
    • เรื่องที่ว่า “มีฮาร์ดแวร์แสดงผลเฉพาะสำหรับเมาส์เพื่อลด latency” ทุกวันนี้ก็ยังเหมือนเดิม เคอร์เซอร์เมาส์ถูกเรนเดอร์เป็น sprite/overlay ที่แยกจาก swapchain ของ compositor ไม่เช่นนั้นโดยเฉพาะที่ 60Hz latency จะเห็นได้ชัดมาก
      ส่วนที่ต้องใช้เทคนิคคือเวลาลากหน้าต่างหรือไอคอน ตอนนั้น latency ของ swapchain จะเริ่มปรากฏให้เห็น compositor บางตัวเห็นว่าอัตรารีเฟรชสูงช่วยให้ latency ดูน้อยลงแล้วจึงไม่ใส่ใจอีกต่อไป เช่น macOS ส่วน Windows ดูเหมือนจะสลับไปใช้เคอร์เซอร์เมาส์แบบซอฟต์แวร์ระหว่างการลาก
    • GNOME รองรับ unredirection อยู่ ดังนั้นจึงยากจะบอกว่าการทดสอบนี้ใช้กับประสิทธิภาพเกมจริงได้
      แอปเต็มหน้าจอควรใช้ fast path ที่ผ่าน compositor หรือข้าม compositor ไปเลย

  • ถ้าใครใช้ ffmpeg สำหรับการวิเคราะห์เป็นรายเฟรมแบบนี้ สามารถใช้ ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png เพื่อดู เวลาที่แสดงผล ของแต่ละเฟรมในวิดีโอได้ วิธีนี้แม่นยำกว่าการ dump เฟรมแล้วคำนวณ timestamp เอง
    ในเว็บเบราว์เซอร์ก็ทำคล้ายกันได้โดยใช้ requestVideoFrameCallback() ระหว่างเล่นวิดีโอ แต่ถ้าคอมพิวเตอร์ถอดรหัสทุกเฟรมได้ไม่เร็วพอ อาจต้องลด .playbackRate ลง
    การที่ Wayland บนหน้าจอ 144Hz ช้ากว่า X11 โดยเฉลี่ยประมาณ 6.5ms และความต่างนั้นเกือบเท่ากับการรีเฟรชหน้าจอหนึ่งครั้ง อาจไม่ใช่เรื่องบังเอิญ ถ้า latency เกือบเท่ากับ 1/144 วินาที บนจอ 60Hz ทั่วไปก็อาจกลายเป็น 1/60 วินาทีได้ แม้จะยากที่จะรับรู้แบบมีสติโดยไม่มีการฝึก แต่คนส่วนใหญ่อาจ “รู้สึก” ได้แม้อธิบายไม่ออก

    • เดาว่าตัวเลข “จริง” น่าจะใกล้ 2.5 เฟรมและ 3.5 เฟรม เพราะ phase แบบสุ่มระหว่างจังหวะที่ขยับเมาส์กับการรีเฟรชหน้าจอทำให้เฉลี่ยครึ่งเฟรม จากนั้นมีอีก 2 เฟรมหรือ 3 เฟรมสำหรับการย้ายเคอร์เซอร์ ถ้าตัด outlier ต่ำ ๆ ในแต่ละกลุ่มออก ก็จะค่อนข้างใกล้ค่านั้น
      แน่นอนว่าสำหรับผู้ใช้จำนวนมาก อัตรา polling ของเมาส์ 125Hz ก็เป็นปัจจัยรบกวนด้วย แต่ในกรณีนี้ใช้เมาส์ 1KHz
      ความต่าง 7ms ไม่แย่ แต่ความต่าง 16.6ms เริ่มถือว่าค่อนข้างมาก โดยส่วนตัวคิดว่าคอมพิวเตอร์ควรพยายามตั้งเป้า latency 1.6 เฟรม ซึ่งประกอบด้วย phase แบบสุ่มครึ่งเฟรม หนึ่งเฟรม และเวลา processing อีกเล็กน้อย
    • เทอร์มินัล latency ต่ำ ให้ความรู้สึกดีขึ้นมากแม้ในงานง่าย ๆ อย่างการพิมพ์
    • ดูค่อนข้างแน่ชัดว่ามี การ buffering เพิ่มอีกหนึ่งเฟรม ระหว่างการขยับเมาส์กับหน้าจอ V-sync อาจทำให้เกิดสิ่งนี้ได้ แต่แค่ double buffering ก็ควรทำ V-sync ได้แล้ว

  • ผลลัพธ์น่าจะต่างกันไปตามคอมโพสิตเตอร์, GPU และการตั้งค่า ใน X11 นั้นการติดตั้งใช้งาน X server ที่ระบบเดสก์ท็อป Linux ใช้มีอยู่แทบจะตัวเดียว จึงมีความต่างแบบนี้น้อยกว่า
    ทุกวันนี้ยังอาจมีปัญหาที่คอมโพสิตเตอร์/GPU หลายชุดยังไม่ได้ hardware cursor plane และถ้าเป็นเช่นนั้น ความต่างของดีเลย์แบบนี้ก็เกิดขึ้นได้มากพอสมควร

  • วันนี้เพิ่งรู้ว่า Wayland มีอายุถึง 16 ปี แล้ว อีกไม่กี่ปี Wayland ก็จะอายุเท่ากับ X ตอนที่ Wayland ออกมา แต่ดูเหมือนว่ายังถูกมองว่าแค่ธรรมดา หรือแย่กว่า X อยู่

    • X ออกรุ่นแรกในเดือนมิถุนายน 1984 ส่วน Wayland ออกมาครั้งแรกในปี 2008 ดังนั้น Wayland จะมีอายุเท่ากันก็ต้องเป็นปี 2032 เวลาคนบ่นว่า Wayland ธรรมดา หรือ “ไม่ดีเท่า X” ส่วนใหญ่มักหมายถึง “Wayland ไม่รองรับ $very_specific_feature” หรือ “เศร้าเพราะไดรเวอร์ proprietary ของผู้ผลิตการ์ดจอของฉันยังไม่ได้ทดสอบกับ Wayland มากพอ”
      ข้อบ่นแบบนั้นราว 99.999% มาจากคนที่ 1) ไม่ได้ลงมือทำเอง 2) ไม่มีความสนใจหรือความสามารถจะทำ และ 3) ไม่เข้าใจหรือไม่ยอมรับว่านักพัฒนา Wayland กับ X ส่วนใหญ่เป็นคนกลุ่มเดียวกัน และพวกเขาไม่อยากทำงานกับ X11 อีกแล้ว
      ผมไม่ได้มีส่วนได้เสียเป็นพิเศษในเรื่องถกเถียงนี้ แต่เบื่อที่เห็นคนใช้ซอฟต์แวร์ที่คนอื่นให้ใช้ฟรีแล้วก็บ่นเรื่อง Wayland ถ้าคำบ่นเรื่อง Wayland มีมากขนาดนั้น ป่านนี้ก็น่าจะรวมตัวกันมาดูแลและปรับปรุง X แล้ว และถ้าคำบ่นกับทฤษฎีเหล่านั้นถูกต้อง ก็อาจทิ้ง Wayland ไว้ข้างหลังได้แล้ว
      น่าแปลกที่ X เป็นโอเพนซอร์สและ fork ได้เต็มที่ แถมยังเคยมีกรณี X.org เกิดจาก XFree86 แต่ผู้สนับสนุนกลับปล่อยให้ฝุ่นจับและไม่ทำอะไรเพื่อดูแลรักษาเลย
      ถ้ามีผลงานออกมาว่า “Wayland ไม่ดีเท่า X เราจึงทำ fork ของ X ที่ทันสมัยขึ้นและทุกคนใช้ได้” ก็คงน่าสนใจไม่น้อย
    • ไม่ใช่ ไม่ใช่อย่างนั้น X เป็นของปี 1984: https://www.talisman.org/x-debut.shtml
      กล่าวคือ Wayland มีอายุแค่ประมาณ 66% ของอายุ X ในตอนที่ Wayland ออกมา และถ้าจะให้มีอายุเท่ากัน ต้องเพิ่มจากอายุของ Wayland ตอนนี้ไปอีก 50%
    • ถ้า X อายุ 40 ปี และ Wayland อายุ 16 ปี ส่วนต่างคือ 24 ปี ดังนั้นคอมโพสิตเตอร์ของ Wayland ยังมีเวลาอีก 8 ปี ในการขัดเกลาปัญหา
      ตอนนี้ผมใช้ Wayland บน Plasma 6 และมันทำงานได้ดีพอ แต่ผมไม่มีความต้องการพิเศษ เลยไม่รู้ว่าตัวอ่านหน้าจอทำงานได้ดีแค่ไหน เป็นต้น
    • ถ้ามองตัวเลขนี้อีกแบบ อีกไม่กี่ปีก็อาจถึงเวลาที่ผู้สืบทอดของ Wayland จะออกมาแล้วก็ได้ ด้วยแรงจูงใจเดียวกับ Wayland คือมีคนไม่พอที่จะดูแล ซอฟต์แวร์เลกาซี
      ถึงตอนนั้นผมคาดว่า frontend stack ของเบราว์เซอร์คงกลืนเดสก์ท็อปไปหมดแล้ว ยังไงเสียก็ไม่ได้มีแอปเดสก์ท็อปใหม่ ๆ บน Linux ออกมามากมายอยู่แล้ว
    • Wayland ออกมาในช่วงเวลาเดียวกับคอมโพสิตเตอร์ของ Windows Vista ถ้าจะมองแบบใจกว้างว่าคอมโพสิตเตอร์ที่ “ดีและเสถียร” มีใน Windows 7 ซึ่งเป็นรุ่นถัดไป ก็เท่ากับว่า Wayland ตามหลัง Windows อยู่ 13 ปี

  • ความพยายามเขียนสิ่งที่ใช้งานได้อยู่แล้วใหม่ด้วยเหตุผลว่า “ทันสมัยกว่า ดูแลง่ายกว่า และรองรับอนาคตได้ดีกว่า” ส่วนใหญ่ไม่ได้ออกมาเป็นแบบนั้น จึงไม่น่าแปลกใจ โดยมากมันช้าลง ดีเลย์มากขึ้น และเป็นแค่ฮาร์ดแวร์ที่เร็วขึ้นมาช่วยพยุงไว้ ไม่ใช่ซอฟต์แวร์ที่เร็วขึ้น
    รู้สึกเหมือนทุก ๆ 20 ปี คนรุ่นใหม่จะอ่อนแอลง เพราะเอาแต่พึ่งพา abstraction ที่คนรุ่นก่อนทำงานหนักสร้างไว้ หลังจากนักพัฒนาซอฟต์แวร์ผ่านมาสัก 3 รุ่น สิ่งที่เหลืออยู่ก็มีแต่คนเรียกใช้ไลบรารี/เฟรมเวิร์ก และแทบไม่มีใครเข้าใจเรื่องประสิทธิภาพกับการปรับแต่งให้เหมาะสมอย่างแท้จริง

    • ประสบการณ์ของผมต่างออกไป ผมอัปเกรดคอมพิวเตอร์หลายเครื่องเป็น KDE 6 แล้วเปลี่ยนมาใช้ Wayland พบว่า ความตอบสนอง และความลื่นไหลโดยรวมของระบบดีขึ้นอย่างเห็นได้ชัด
      Wayland ยังมีฟีเจอร์ที่ขาดเมื่อเทียบกับ X11 แต่ด้วยข้อดีด้านอื่น ๆ ผมยอมประนีประนอมกับเรื่องนั้นได้
    • คอมพิวเตอร์สมัยก่อนมีดีเลย์ต่ำกว่า แต่ในทางกลับกัน บนระบบปฏิบัติการหลายตัว ถ้าแอปหนึ่งล่ม OS ทั้งระบบก็ไม่ตอบสนองจนต้องรีบูตทั้งระบบ

  • คอมโพสิตเตอร์ Wayland หลายตัวมีปัญหาใหญ่กับคีย์บอร์ด เมาส์ และอุปกรณ์อินพุตอื่น ๆ เพราะสเปก Wayland และ implementation อ้างอิงเลือกที่จะไม่รองรับสิ่งเหล่านั้น ดังนั้นคอมโพสิตเตอร์ Wayland แต่ละตัวจึงเลือกวิธีแก้ต่างกันไป
    ตัวเลือกที่พบได้บ่อยคือ libei และ libinput แต่หลายกรณีก็ไม่รองรับอินพุตเมาส์/คีย์บอร์ด “ขั้นสูง” เลย weston เป็นตัวอย่างหนึ่ง เราไม่มีทางรู้เลยว่าซอฟต์แวร์ Linux ตัวหนึ่งจะทำงานในสภาพแวดล้อม Wayland แบบใดแบบหนึ่งได้หรือไม่ และ การแตกเป็นเสี่ยง ๆ นั้นรุนแรงมาก
    ใน X มี reference ของ X11 ที่แข็งแรงซึ่ง implement แทบทุกอย่างจริง ๆ ดังนั้นถ้ามันทำงานที่หนึ่ง ก็มั่นใจได้ว่าจะทำงานที่อื่นด้วย
    แม้จะผ่านมา 12 ปีแล้ว ก็ยังไม่มีคอมโพสิตเตอร์ Wayland ตัวไหนรองรับตัวอ่านหน้าจอสำหรับผู้พิการทางสายตาเลย ระดับเหมือนของเล่น

    • ได้ยินมาว่าการรองรับการปรับเทียบสีก็หายไปด้วย พออ่านดูแล้วเหมือนจะไม่มีแม้แต่วิธีควบคุมหรือรู้ว่ามีการปรับเทียบอะไรถูกใช้ระหว่างที่แอปปรับเทียบกำลังวัดอยู่ นอกจากนี้ client-side window decoration ก็ยังคงอยู่ ทำให้พลาดโอกาสแก้ ช่องโหว่ด้านความปลอดภัย เก่า ๆ
      ดังนั้นจึงไม่ดีสำหรับเกม ไม่ดีสำหรับงานกราฟิกระดับมืออาชีพ และไม่ดีสำหรับคนที่สายตาไม่ดี สรุปคือโดยทั่วไปไม่ดีสำหรับผู้ใช้ที่ต่างจากคนสร้างมันแม้แต่นิดเดียว
      แต่ถ้าโชคดี มันอาจลดอาการภาพฉีกที่ผมไม่เคยรู้สึกได้เลยก็ได้
    • หลังจากย้ายจาก macOS ไป Windows สุดท้ายก็ปักหลักที่ Windows และใช้เวลาพัฒนาในยามว่างไปกับการปรับปรุงประสบการณ์ของ power user/นักพัฒนาในระบบนิเวศ tiling window manager บน Windows: https://github.com/LGUG2Z/awesome-komorebi
      หนึ่งในผลลัพธ์เจ๋ง ๆ ที่เกิดขึ้นคือการเห็นผู้คนเพิ่มเวิร์กโฟลว์ด้าน accessibility บนระบบนิเวศนี้ บางคนควบคุมเดสก์ท็อปทั้งระบบผ่าน tiling window manager ด้วยการสั่งงานด้วยเสียง: https://youtu.be/fiPJLmhnnXM
    • ที่ว่า “ไม่รองรับอินพุตเมาส์/คีย์บอร์ดขั้นสูงเลย” น่าจะโทษผิดฝ่าย ควรไปดูบริษัทที่ทำอุปกรณ์ต่อพ่วงเหล่านั้นแต่ไม่ยอม提供 ไดรเวอร์ Linux มากกว่า
    • เวลาใช้ Orca บน Wayland ของ GNOME มีอะไรที่ยังขาดอยู่บ้าง?

  • เมื่อ GPU รับโหลดหนัก เช่น งานอนุมาน Stable Diffusion จะเกิดสไปก์ดีเลย์ขนาดใหญ่ แม้ไม่ได้ทำ A/B test กับ X11 แต่เมื่อก่อนจำได้ว่าไม่เคยเจอแบบนี้
    การมีดีเลย์เพิ่มขึ้นอีกหนึ่งเฟรมก็ไม่ดีอยู่แล้ว แต่ สไปก์ดีเลย์ ที่โผล่มาเป็นครั้งคราวนี่น่ารำคาญจริง ๆ

    • โดยเฉพาะถ้าเป็นสถานการณ์ที่เกิด thrashing ระหว่าง VRAM กับหน่วยความจำระบบ ก็ยังอาจเกิดขึ้นได้อยู่ดี แต่ก็สงสัยว่าได้ลองลด priority ของโปรเซส Stable Diffusion แล้วหรือยัง

  • ดีเลย์ของอินพุตเคอร์เซอร์เป็นสิ่งรบกวนที่คอยบั่นทอนความพึงพอใจต่อแอปพลิเคชันหรือระบบปฏิบัติการอยู่ตลอด
    ดีเลย์ของเคอร์เซอร์ข้อความใน IDE? รับไม่ได้
    ดีเลย์ของเคอร์เซอร์ข้อความใน shell? รับไม่ได้
    ดีเลย์ของเคอร์เซอร์เมาส์ใน GUI? รับไม่ได้
    ทั้งหมดเป็นเงื่อนไขตกรอบทันที

    • นี่เป็นหนึ่งในด้านที่ macOS ทำได้ยอดเยี่ยมมาโดยตลอด ย้อนไปได้ถึงยุค Mac OS คลาสสิก
      แม้แต่ System 1 ที่รันบนฮาร์ดแวร์อ่อนแอแทบจะสุด ๆ เมื่อกว่า 40 ปีก่อน ก็ยังให้ความสำคัญสูงสุดกับ การตอบสนองของเคอร์เซอร์ จนเหนือกว่าคู่แข่งทั้งหมด แม้รากฐานของ OS และ UI ในปัจจุบันจะแตกต่างไป 100% แล้ว แต่ลำดับความสำคัญนั้นยังคงอยู่
    • น่าตกใจที่เรื่องนี้แย่ได้ขนาดนี้ โดยเฉพาะถ้าเป็น Linux ยิ่งแล้วใหญ่ การเคลื่อนเมาส์ก็ควรถูกให้ความสำคัญเหนือทุกอย่างไม่ใช่หรือ? แม้แต่การไฮไลต์สิ่งที่เมาส์ชี้อยู่ ก็ไม่ควรทำให้ตัวเคอร์เซอร์เมาส์เองช้าลง
      ช่วงหลังเจออาการเมาส์หน่วงอย่างหนักกับ KDE/Plasma 6 บน X11 ร่วมกับ NVidia โดยสังเกตได้ว่าหน่วงหนักเป็นพิเศษเวลาอยู่เหนือแท็บของเบราว์เซอร์
      ขอจดไว้สำหรับคนที่เจอปัญหาเดียวกัน วิธีแก้คือปิด OpenGL flipping ไม่รู้เลยว่า OpenGL flipping ทำอะไร แต่พอปิดใน nvidia-settings และ /etc/X11/xorg.conf แล้วปัญหาก็หายไป
      ถ้ามีใครอธิบายได้ว่าทำไมเป็นแบบนั้น หรือทำไมค่านี้ถึงไม่ใช่ค่าเริ่มต้น ก็คงดี

  • เป็นงานที่ยอดเยี่ยม น่าจะคุ้มที่จะลองตั้งจอไว้ที่อัตรารีเฟรชต่ำมาก ๆ เช่น 30Hz แล้วทำการทดลองซ้ำ
    ถ้า Wayland ช้ากว่า X11 หนึ่งเฟรมเสมอ ก็น่าจะสังเกตได้ง่ายกว่ามาก

  • มีข้อบ่นส่วนตัวที่ต่างออกไปเล็กน้อย ตอนเริ่มใช้ Linux ใหม่ ๆ เดสก์ท็อปยังเป็นการ composite ด้วยซอฟต์แวร์ น่าจะเป็นลักษณะที่ CPU วาด UI ลงใน RAM แล้ว blit ไปยัง framebuffer ของ GPU และคิดว่าเป็นวิธีที่ใช้กันมานานแล้ว
    เมื่อ compositor รวมถึง X11 composite และ GPU renderer เริ่มเป็นที่นิยม ดีเลย์ก็แย่มากจนอยู่ในระดับหลายร้อย ms จริง ๆ แปลกดี เพราะตอนโตมากับเกม DOS ไม่เคยมีปัญหาแบบนี้
    แม้เวลาผ่านไปจะดีขึ้น แต่ก็ไม่แน่ใจว่าเราได้กลับไปสู่ ยุคทองของการเรนเดอร์ด้วย CPU แล้วหรือยัง