เรนเดอเรอร์ใหม่สำหรับ GTK

 (blog.gtk.org)
1 คะแนน โดย GN⁺ 2024-01-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงสร้างพื้นฐานการเรนเดอร์ของ GTK ถูกจัดใหม่เป็น ngl สำหรับ GL และ vulkan สำหรับ Vulkan โดยเรนเดอเรอร์ทั้งสองใช้โครงสร้างแบบรวมศูนย์ที่บิลด์จากซอร์สเดียวกัน
  • อิมพลีเมนเทชันส่วนกลางอิงตามลำดับการทำงานของ Vulkan API และทำ abstraction ความแตกต่างระหว่าง GL 3.3+ กับ GLES 3.0+ เพื่อใช้ โครงสร้างพื้นฐานการเรนเดอร์ ร่วมกัน เช่น การท่อง scene graph และแคช
  • เรนเดอเรอร์ใหม่นี้ให้ความสำคัญกับ ความถูกต้อง และการบำรุงรักษามากกว่าความเร็วในทันที พร้อมปรับปรุง anti-aliasing, fractional scaling, จุดหยุดสีของไล่ระดับแบบไม่จำกัด และการรองรับ dmabuf
  • นักพัฒนาแอปควรตรวจสอบว่า ไม่รองรับโหนด glshader, มีการเปลี่ยนแปลงในการจัดการตำแหน่งแบบเศษส่วน และอาจเจอปัญหาไดรเวอร์ โดยแม้จะดูเหมือนเป็นปัญหาฝั่งไดรเวอร์ก็ควรรายงานไปที่ GTK
  • ในสแนปช็อต GTK 4.13.6 ตอนนี้ ngl เป็นค่าเริ่มต้นใหม่แล้ว แต่ยังอยู่ในช่วงทดลองใช้งาน และหากพบปัญหาใหญ่ก็อาจย้อนกลับไปใช้เรนเดอเรอร์ gl เดิมใน GTK 4.14 ได้

เรนเดอเรอร์แบบรวมสำหรับ GL และ Vulkan

  • GTK เพิ่มเรนเดอเรอร์ใหม่ ngl สำหรับ GL และ vulkan สำหรับ Vulkan
  • เรนเดอเรอร์ทั้งสองถูกบิลด์จากซอร์สเดียวกัน จึงถูกเรียกว่า เรนเดอเรอร์แบบรวม
  • โมเดลการอิมพลีเมนต์ยึดตาม Vulkan API และมี abstraction สำหรับจัดการความแตกต่างของ GL 3.3+ และ GLES 3.0+
  • โครงสร้างนี้ช่วยให้สามารถแชร์งานพื้นฐานที่เดิมต้องดูแลแยกตามเรนเดอเรอร์ได้
    • การท่อง scene graph
    • การจัดการทรานส์ฟอร์มและสถานะอื่น ๆ
    • แคช texture และ glyph
    • งานดูแลให้เรนเดอเรอร์ทั้งสองทันสมัยและสอดคล้องกัน

เงื่อนไขเมื่อต้องการขยายไปยัง Metal และ DirectX

  • มีความเป็นไปได้ที่จะขยายแนวทางเดียวกันนี้ไปยังเรนเดอเรอร์บน macOS ที่ใช้ Metal หรือบน Windows ที่ใช้ DirectX
  • Vulkan และ GL ได้เปรียบเพราะโดยพื้นฐานแล้วใช้ภาษา shader เดียวกันคือ GLSL
  • แต่เงื่อนไขแบบเดียวกันนี้ใช้ไม่ได้กับ Metal หรือ DirectX จึงอาจต้องเขียน shader ซ้ำ หรือใช้เครื่องมือแปลงอย่าง SPIRV-Cross
  • ผู้มีส่วนร่วมที่สนใจงานด้านนี้ยินดีต้อนรับ

วิธีอิมพลีเมนต์และ ubershader

  • เรนเดอเรอร์ GL เดิมใช้ shader แบบเรียบง่ายแยกตามแต่ละประเภทของ rendernode และมักพึ่งพา offscreen rendering เมื่อเนื้อหาซับซ้อน
  • เรนเดอเรอร์แบบรวมก็มี shader แยกตามโหนด ที่ทรงพลังขึ้นเช่นกัน แต่ยังใช้ shader ที่ซับซ้อนเพื่อแปลข้อมูลในบัฟเฟอร์แทนการทำ offscreen ด้วย
  • ในวงการเขียนโปรแกรมเกม แนวทางนี้เรียกว่า ubershader
  • อิมพลีเมนเทชันใหม่ยังปรับแต่งไม่มากเท่าเรนเดอเรอร์ GL เดิม แต่ให้ความสำคัญกับ ความถูกต้อง และการบำรุงรักษา จึงสามารถจัดการต้นไม้ rendernode ที่หลากหลายได้อย่างถูกต้องมากขึ้น

คุณภาพการเรนเดอร์และฟีเจอร์ใหม่

  • Anti-aliasing

    • เรนเดอเรอร์ GL เดิมอาจทำให้รายละเอียดเล็กมากที่พอดีอยู่ระหว่างขอบเขตหนึ่งพิกเซลหายไป
    • ปัญหานี้อาจกระทบแม้แต่เส้นใต้แบบ mnemonic
    • เรนเดอเรอร์แบบรวมเก็บรายละเอียดเล็ก ๆ ได้ดีกว่า และลดอาการขอบหยักของเส้นรอบ primitive ได้ด้วย

  • Fractional scaling

    • Anti-aliasing เป็นพื้นฐานสำคัญสำหรับการจัดการ สเกลแบบเศษส่วน อย่างถูกต้อง
    • เมื่อสเกลหน้าต่างขนาด 1200×800 ที่ 125% เรนเดอเรอร์แบบรวมจะใช้ framebuffer ขนาด 1500×1000
    • วิธีนี้ใช้พิกเซลน้อยกว่ามากและให้ภาพคมชัดกว่าการปล่อยให้ compositor ย่อภาพ 2400×1600 ลงมา

  • ไล่ระดับแบบอิสระ

    • เรนเดอเรอร์ GL เดิมรองรับจุดหยุดสีได้สูงสุด 6 จุดสำหรับไล่ระดับเชิงเส้น, แบบรัศมี และแบบกรวย
    • เรนเดอเรอร์แบบรวมอนุญาตให้มีจุดหยุดสีได้ ไม่จำกัด
    • ยังใช้ anti-aliasing กับไล่ระดับด้วย เพื่อสร้างเส้นที่นุ่มนวลบนขอบที่คม

  • dmabuf

    • GTK ได้เพิ่มการรองรับ dmabuf และงานด้าน graphics offloading ตั้งแต่ช่วงฤดูใบไม้ร่วงที่ผ่านมา
    • เรนเดอเรอร์ใหม่รองรับสิ่งนี้ และขยาย API render_texture เพื่อให้สร้าง dmabuf ได้เมื่อมีการขอสร้าง texture
    • ตอนนี้ส่วนขยายนี้ใช้ได้เฉพาะกับเรนเดอเรอร์ Vulkan เท่านั้น

สิ่งที่นักพัฒนาแอปควรตรวจสอบ

  • ไม่รองรับโหนด glshader

    • โหนด glshader มีประโยชน์กับเดโมของ GTK 4.0 แต่ผูกติดกับเรนเดอเรอร์ GL เดิมอย่างมาก
    • โหนดดังกล่าวตั้งอยู่บนสมมติฐานของ GLSL API ที่เรนเดอเรอร์เดิมเปิดเผยไว้
    • เรนเดอเรอร์ใหม่ ไม่รองรับโหนด glshader
    • เอกสารของ GTK แนะนำให้ตรวจสอบก่อนพึ่งพา shader และหากล้มเหลวให้ใช้ shader ที่ง่ายกว่า หรือเส้นทางสำรองที่ไม่ใช้ shader
    • หลัง GTK 4.0 มีการเพิ่มฟีเจอร์อย่างโหนด mask และการรองรับ texture แบบ straight-alpha ทำให้หลายกรณีใช้งานของโหนด glshader ไม่จำเป็นอีกต่อไป

  • ตำแหน่งแบบเศษส่วน

    • เรนเดอเรอร์ GL เดิมปัดค่าตำแหน่ง จึงอาจไม่เห็นปัญหาแม้ส่งตำแหน่งแบบเศษส่วนเข้าไป
    • เรนเดอเรอร์ใหม่จะวางตามตำแหน่งที่ระบุไว้ตรง ๆ
    • ความต่างนี้อาจทำให้เกิดผลลัพธ์ที่ไม่ได้ตั้งใจ จึงควรตรวจสอบว่าตำแหน่งเป็นค่าที่ต้องการจริงหรือไม่
    • ควรระวังเป็นพิเศษกับการวาดแบบสไตล์ cairo ที่วางเส้นไว้ที่ตำแหน่งครึ่งพิกเซลเพื่อให้เติมหนึ่งแถวพิกเซลได้พอดี

  • ปัญหาไดรเวอร์

    • เรนเดอเรอร์ใหม่ใช้งานไดรเวอร์กราฟิกในรูปแบบใหม่และต่างจากเดิม จึงมีโอกาสกระตุ้นให้เกิดปัญหาฝั่งไดรเวอร์
    • แม้ปัญหาจะดูเหมือนเป็น issue ของไดรเวอร์ ก็ควรรายงานไปที่ GTK
    • สิ่งนี้ช่วยให้ประเมินได้ว่าโค้ดใหม่ทำงานได้ดีแค่ไหนบนไดรเวอร์และฮาร์ดแวร์ที่หลากหลาย

สถานะประสิทธิภาพในปัจจุบัน

  • เรนเดอเรอร์ใหม่ยังไม่ได้เร็วกว่าของเดิม
  • เรนเดอเรอร์ GL เดิมถูกปรับแต่งมาอย่างหนักเพื่อความเร็ว ใช้ shader ที่เรียบง่ายกว่า และไม่ต้องคำนวณสิ่งที่จำเป็นต่อฟีเจอร์อย่าง anti-aliasing
  • เป้าหมายคือทำให้เรนเดอเรอร์ใหม่เร็วกว่าในท้ายที่สุด แต่ตอนนี้ ฟีเจอร์ใหม่และความถูกต้อง คือจุดปรับปรุงที่สำคัญกว่า
  • เรนเดอเรอร์แบบใช้ GPU ทั้งหมดในปัจจุบันเร็วพอสำหรับการเรนเดอร์แอป GTK ที่ 60fps หรือ 144fps
  • จากเบนช์มาร์กแบบไม่เป็นทางการ เรนเดอเรอร์ Vulkan อยู่ในระดับใกล้เคียงกับเรนเดอเรอร์ GL เดิม หรือบางกรณีก็ดีกว่า
  • สาเหตุที่เรนเดอเรอร์ GL ใหม่ช้ากว่ายังไม่ได้รับการติดตามอย่างชัดเจน

การเปลี่ยนค่าเริ่มต้นและข้อยกเว้น

  • ใน สแนปช็อต GTK 4.13.6 ที่เพิ่งออกมา เรนเดอเรอร์ ngl กลายเป็นค่าเริ่มต้นใหม่
  • การเปลี่ยนแปลงนี้ยังเป็นการทดลองใช้ และต้องผ่านการทดสอบกับแอปจำนวนมากขึ้นเพื่อยืนยันความพร้อมสำหรับการใช้งานจริง
  • หากพบปัญหาใหญ่ อาจย้อนกลับไปใช้เรนเดอเรอร์ gl เดิมใน GTK 4.14 ได้
  • เรนเดอเรอร์ Vulkan ยังไม่ใช่ค่าเริ่มต้น
    • พอร์ต WebKit GTK4 ทำงานได้บน GL แต่ยังไม่ทำงานบน Vulkan
    • ตอนนี้ GtkGLArea และ GtkMediaStream สร้าง GL texture และเรนเดอเรอร์ Vulkan ยังนำเข้าโดยตรงไม่ได้
    • หากปัญหาเหล่านี้ได้รับการแก้ไขในอนาคตอันใกล้ ก็จะทบทวนการตัดสินใจเรื่องเรนเดอเรอร์เริ่มต้นอีกครั้ง
  • หากใช้งาน GTK บนฮาร์ดแวร์ที่เก่ามาก เรนเดอเรอร์ GL เดิมอาจเหมาะกว่า
    • เรนเดอเรอร์ GL เดิมต้องการความสามารถจาก GPU น้อยกว่า
    • สามารถ override การเลือกเรนเดอเรอร์ได้ด้วยตัวแปรแวดล้อม GSK_RENDERER
    • ตัวอย่าง: GSK_RENDERER=gl

สิ่งที่อาจทำได้ต่อจากนี้

  • เรนเดอเรอร์ใหม่เป็นรากฐานสำหรับการพัฒนาฟีเจอร์ที่ต้องการมานาน
  • งานที่เป็นไปได้ในอนาคตมีดังนี้
    • การจัดการสี ที่ถูกต้อง รวมถึง HDR
    • path rendering บน GPU
    • ความเป็นไปได้ในการเรนเดอร์ glyph
    • การเรนเดอร์นอก main thread
    • การปรับปรุงประสิทธิภาพบนอุปกรณ์ที่เก่าและมีสมรรถนะต่ำกว่า
  • บางรายการจะเป็นจุดโฟกัสของงานระยะสั้นและระยะกลาง
  • ยังมีฟีเจอร์เพิ่มเติมที่วางแผนไว้สำหรับเรนเดอเรอร์ใหม่ และผู้ใช้สามารถลองใช้งานเองแล้วแจ้งผลการทำงานได้

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

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

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

  • นานมาแล้ว น่าจะราวปี 2010 เห็นจะได้ เหมือนเคยมี HTML renderer แบบทดลองที่ให้รัน แอป GTK ภายในเบราว์เซอร์ และประกอบ UI ด้วย HTML+CSS ทั่วไป
    ตอนนั้นรู้สึกช็อกมาก และน่าจะยังเป็นช่วงก่อน Atom, VS Code, Electron หรืออาจจะกระทั่ง NodeJS จะออกมาด้วยซ้ำ
    ไม่แน่ใจว่า renderer ตัวนั้นยังอยู่หรือเปล่า

    • หมายถึง Broadway หรือเปล่า?
      https://docs.gtk.org/gtk4/broadway.html
      https://www.phoronix.com/news/GTK4-Broadway-Being-Used
      ไม่คิดว่ามันเป็นแบ็กเอนด์หลัก/ทางการ แต่ก็ยังอยู่และถูกพอร์ตมาที่ Gtk4 แล้ว
    • มันใช้ HTML และ CSS มากกว่าสิ่งที่คล้ายกันอยู่บ้าง แต่ผมว่าเรียกว่า HTML+CSS ทั่วไป คงไม่ได้
      เพราะลักษณะการทำงานมันใกล้กับแนวทาง pure canvas ที่ทิ้งแทบทุกอย่างที่เบราว์เซอร์มีให้ แล้วสร้างใหม่ทั้งหมดตั้งแต่ต้น
      เกณฑ์ในการดูว่ามันทำงานได้ถูกต้องหรือไม่โดยทั่วไปคือ (a) ใช้การเลื่อนของเบราว์เซอร์ (b) ใช้การเรนเดอร์ข้อความของเบราว์เซอร์ (c) จัดการลิงก์เป็นองค์ประกอบจริง ซึ่ง Broadway ไม่ผ่านทั้งสามข้อ
      มันเขียนระบบเลื่อนเอง, เรนเดอร์ข้อความที่ฝั่งเซิร์ฟเวอร์แล้วส่งมาเป็นภาพ, และพอพยายามคลิกลิงก์ก็ดูเหมือนจะค้างจริง ๆ
      นอกจากนี้การป้อนข้อความก็น่าจะใช้แค่อีเวนต์คีย์ ทำให้ IME composition พังหมด และการนำทางด้วยคีย์บอร์ดก็น่าจะเป็นฝั่ง GTK แทนที่จะเป็น native
      มันยังไม่สามารถให้ accessibility tree ได้อย่างมีความหมายด้วย
      สำหรับ tech demo หรือการใช้งานส่วนตัวที่ยอมรับข้อจำกัดได้ก็โอเค แต่ไม่เหมาะกับการแจกจ่ายสู่สาธารณะ และจริง ๆ แล้วใกล้เคียงกับ พวก RDP/VNC ที่ผสมการใช้ DOM นิดหน่อยมากกว่า
      และต้องจำไว้ด้วยว่าโค้ดทั้งหมดรันอยู่ที่ฝั่งเซิร์ฟเวอร์
    • ถ้าอิงจาก GTK3 จะเรียกมันว่า HTML renderer ก็ดูเกินไปหน่อย
      โดยพื้นฐานแล้วมันคือการสตรีมข้อมูลพิกเซลไปยังองค์ประกอบ canvas จึงแทบไม่ต่างจาก VNC ที่มี web viewer ติดมาด้วย
      https://imgur.com/a/2EDZ2Ti
    • ชื่อมันคือ Broadway: https://docs.gtk.org/gtk4/broadway.html
    • เมื่อก่อนเคยทำ proof of concept เล็ก ๆ ที่รันใน Docker ด้วย broadway และมันทำงานได้ดีพอสมควร
      https://github.com/moondev/gtk3-docker
      use case ของผมคือรันเบราว์เซอร์ภายในเบราว์เซอร์ เพื่อให้โต้ตอบกับบริการ Kubernetes clusterip ได้ง่ายโดยไม่ต้องทำ port forwarding หรือ proxy
      อีกตัวอย่างเจ๋ง ๆ คือเปิด virt-manager แล้วรัน VM ด้วย gtk virt-viewer จากนั้นควบคุมผ่านเบราว์เซอร์
      https://github.com/m-bers/docker-virt-manager

  • หวังว่า GTK จะไม่เดินตามกระแสการใส่ วิดเจ็ตในแถบชื่อหน้าต่าง
    บางอย่างลากได้ บางอย่างลากไม่ได้ และยังทำให้พื้นที่สำหรับแสดงชื่อแอปกับชื่อไฟล์ลดลงด้วย
    ไม่ใช่ว่านี่เป็นข้อบ่นที่มีต่อ GTK อย่างเดียว

    • กระแสนั้น gtk/gnome เป็นคนเริ่มไม่ใช่เหรอ?
    • แค่มีเรื่องแบบนี้เกิดขึ้นใน GNOME ก็แย่พออยู่แล้ว หวังว่าจะไม่มี ความพลาด แบบอื่นจาก GTK เพิ่มอีก

  • การปรับสเกลแบบเศษส่วน ที่แม่นยำระดับพิกเซล เยี่ยมเลย วู้!

    • นานกว่าสิบปีแล้วที่ GTK ยืนกรานว่าการปรับสเกลแบบเศษส่วน “เป็นไปไม่ได้” และนักพัฒนา GTK ก็ขัดขวาง fractional scaling ในโปรโตคอล Wayland มาโดยตลอด ตอนนี้ในที่สุดก็ตาม Qt ทันในด้านฟีเจอร์นี้แล้ว
      ถ้าต่อไปมีการรองรับบน Wayland อย่างเหมาะสม ก็ดูเหมือนว่า การรองรับ HiDPI จะเป็นไปได้บนเดสก์ท็อป Linux หลักทุกตัว
    • คำอธิบายในบล็อกโพสต์ค่อนข้างชวนสับสน
      มันบอกว่าถ้าปรับสเกลหน้าต่าง 1200×800 เป็น 125% ตัว unified renderer จะใช้ framebuffer ขนาด 1500×1000 แทนที่จะปล่อยให้ compositor ย่อภาพ 2400×1600
      เท่าที่ผมเข้าใจคือ หน้าต่างที่เพราะสเกล 125% จึงควรถูกวาดบนหน้าจอเป็น 1500×1000 พิกเซลนั้น ในแง่ application pixel ยังถือเป็น 1200×800 อยู่
      OpenGL และ Vulkan เรนเดอร์ด้วย floating point อยู่แล้ว ก็น่าจะหมายถึงว่าสามารถวาดลงบัฟเฟอร์ที่เรนเดอร์แบบ 1:1 กับหน้าจอได้โดยตรงผ่านการแปลงพิกัด
      ถ้าเข้าใจถูก แบบนี้ก็ดูเป็น วิธีที่สมเหตุสมผล เสียที

  • มีใครเข้าใจจริง ๆ ไหมว่า เดสก์ท็อปเอนไวรอนเมนต์ บน Linux ทำงานกันอย่างไร? ผมไม่เข้าใจเลย
    มันให้ความรู้สึกว่าซับซ้อนขึ้นเรื่อย ๆ และเหมือนแค่มีของถูกพอกเพิ่มเข้าไป

    • X Window System เป็นการตัดสินใจตั้งต้นที่ผิดพลาดโดยพื้นฐานเกี่ยวกับทิศทางที่ GUI และฮาร์ดแวร์คอมพิวเตอร์จะพัฒนาไป
      โครงสร้างแบบไคลเอนต์/เซิร์ฟเวอร์ในท้ายที่สุดกลับตรงข้ามกับโมเดลการประมวลผลกราฟิกแบบบูรณาการสูงที่เรามาถึงทุกวันนี้
      แทนที่จะยอมเลิก X11 ตั้งแต่เนิ่น ๆ เพื่อลดความเสียหาย ทั้งฝั่งผู้ขาย Unix และโอเพนซอร์สกลับพยายามทำน้ำมะนาวจากมะนาวเสียทั้งรถบรรทุกอยู่นานเกินไป
      นั่นจึงเป็นเหตุผลว่าทำไม GUI บน Linux ถึงล้าหลังแบบนี้
      Apple ไม่ได้ถูกผูกติดกับ X11 และยอมรับโมเดลแบบบูรณาการ จึงพัฒนา GUI บน Unix ได้อย่างรวดเร็ว และตอนนี้ยังออกแบบ GPU ของตัวเองอีกด้วย ซึ่งยิ่งเห็นได้ชัด
    • ทางนั้น GNOME ดูจะใกล้เคียงกับการเป็นผู้นำมากที่สุด
      ผมสงสัยว่าสถาปัตยกรรม Wayland จะส่งผลมากแค่ไหน และจะมี แอปเฉพาะสำหรับ GNOME เกิดขึ้นจริงหรือไม่

  • น่าจะดีถ้ามีตัวเรนเดอร์ข้อความแบบ ansi
    จะได้รันโปรแกรม GTK ภายใน xterm ของฉันได้ และถ้าเลือกได้ก็อยากแถม sixel มานิดหน่อยด้วย

    • ทุกวันนี้แอป GTK ส่วนใหญ่หน้าตาคล้าย ๆ กันมาก
      มีแถบด้านข้าง, พฤติกรรมบางอย่างในแถบชื่อเรื่อง, และโครงสร้างแบบมุมมองรายละเอียด
      แอปบน Mac, แอป Windows แบบ “Modern”, และแอปมือถือก็คล้ายกัน
      เลยสงสัยว่าชุดเครื่องมือ UX จะเป็นแบบประกาศเชิงสมบูรณ์และเชิงความหมายทั้งหมดได้ไหม
      ในระดับสูงประมาณว่า “มุมมองมาสเตอร์/รายละเอียด, มุมมองรายการที่มีฟิลด์พวกนี้, และต้องมีการกระทำบางอย่าง” โดยไม่ระบุตำแหน่งหรือสไตล์ แล้วให้ระบบเลือกวิดเจ็ตที่เหมาะสมให้อัตโนมัติ
      แล้วค่อยมีทางหนีทีไล่ด้วย CSS เล็กน้อยหรือเจาะลงไปใช้วิดเจ็ตเนทีฟได้
      ดูเหมือนว่าแทบทุกแอปที่ไม่ใช่เบราว์เซอร์, โปรแกรมแก้ไข WYSIWYG, หรือโปรแกรมดูสื่อ จะเข้ากับกรอบนี้ได้ และประเด็นสำคัญคือสามารถสร้าง TUI จากคำอธิบายแบบนี้ได้ง่าย
    • ถ้าเอา broadway จากคอมเมนต์อื่นมารวมกับ carbonyl ก็จะได้อะไรที่คล้ายกันพอสมควร
      https://github.com/fathyb/carbonyl
      https://i.imgur.com/pIQ4K7Q.png

  • ถ้าใช้ https://wgpu.rs/ ก็คงได้ DirectX และ Metal ฟรีเลย :)

  • งานนี้ดูสนุกมากจริง ๆ
    ตอนอ่านส่วนของการทำ anti-aliasing ก็คิดว่า signed distance field แบบที่ใช้ในเกมเอนจิน น่าจะใช้กับการเรนเดอร์ฟอนต์ที่สเกลได้ตามใจเหมือนกันหรือเปล่า
    Valve เคยออกบทความวิชาการดี ๆ เรื่องนี้ไว้
    ในโค้ด UI ของตัวเรนเดอร์เกมหรือฝั่งการเรนเดอร์เดคาล มีเทคนิคเจ๋ง ๆ เยอะมากที่น่าจะเป็นประโยชน์กับโค้ด GUI ด้วย

  • ไม่เข้าใจว่าทำไม ประสิทธิภาพที่ลดลง ถึงยอมรับกันได้
    ฉันยังทำงานส่วนใหญ่บนฮาร์ดแวร์เก่า ถ้าฟีเจอร์พวกนี้ปิดได้ฉันก็อยากปิด และบน GPU ของฉันมันอาจไม่รองรับด้วยซ้ำ

    • ในประโยค “ไม่ครับ ตัวเรนเดอร์ใหม่ยังไม่เร็วกว่า” คำสำคัญคือ ยัง
      ถ้ามีอาการช้าจนสังเกตได้ก็ใช้ GSK_RENDERER=gl ได้
      ถ้าเป็น Microsoft, Apple หรือ Google ก็คงไม่เปิดให้ถกเรื่องพวกนี้เลยด้วยซ้ำ
      Microsoft คงจะประมาณว่า “ลืม API เดิมไปซะ นี่คือ API ใหม่”, Apple คงเป็น “บังคับใช้ตั้งแต่ ${WEIRD_NAME}”, ส่วน Google คงเป็น “อัปเดตนั้นคุณไม่ได้”
    • บน GL ถ้าพลาด fast path ไปโดยบังเอิญก็อาจช้าลงอย่างน่าตกใจ และในทางกลับกันถ้าเข้าทางนั้นได้ก็อาจเร็วอย่างน่าตกใจเช่นกัน
      แต่สิ่งที่น่าผิดหวังคือ ตัวเรนเดอร์ Vulkan กลับไปได้แค่ประสิทธิภาพใกล้เคียงกับตัวเรนเดอร์ GL เดิม
      นี่ดูเหมือนเป็นสัญญาณว่าปัญหาอยู่ฝั่งผู้เรียกใช้มากกว่าตัว 3D API เอง
      น่าจะต้องติดตามประสิทธิภาพและปรับปรุงซ้ำตลอดทั้งการพัฒนา มากกว่าจะหวังพึ่ง “ความบริสุทธิ์ทางสถาปัตยกรรม” ซึ่งคงไม่ใช่ความคิดที่ดีนัก
    • กรณีเดียวที่ฉันยอมรับ performance regression ได้ คือเมื่อของเดิมมีปัญหาจริง ๆ ไม่ใช่แค่เก่าแล้วหรืออยากเขียนใหม่ด้วยเฟรมเวิร์ก/เทคโนโลยีที่กำลังนิยม
    • ตัวเรนเดอร์พวกนี้ไม่ใช่ค่าเริ่มต้น และก็คงจะไม่กลายเป็นค่าเริ่มต้นในอนาคตด้วย
      ฉันไม่เคยเห็นกรณีที่เอา immediate mode rendering API ไปแปลงเป็น retained mode แล้วจะเร็วขึ้น
      มันอาจเป็นไปได้ไม่ทางใดก็ทางหนึ่ง แต่ต้องใช้แรงมหาศาล และถ้าจะซ่อมเคสประหลาด ๆ ก็ต้องแก้ฝั่งไคลเอนต์ของ API ด้วย
    • ทีมพัฒนา GNOME และในวงกว้างคือฝั่ง GTK ดูเหมือนจะไม่ได้ใส่ใจเรื่องนี้มากนัก
      เท่าที่จำได้ ส่วนใหญ่ใช้ MacBook ราคาแพง เลยมีปัญหาหลายอย่างที่ถูกปัดไปด้วยคำว่า “บนเครื่องฉันใช้ได้”
      ตัวอย่างเช่น มีปัญหาเรื่อง การเรนเดอร์ฟอนต์ หลายอย่างที่ไม่กระทบจอ Retina

  • ไม่ได้อยากให้ฟังดูขมขื่น แต่โดยมากแล้วนักพัฒนาเอนจินกราฟิกที่เก่ง ๆ ได้สร้างเรนเดอเรอร์ที่ล้ำหน้ากว่าเรนเดอเรอร์ของ GUI toolkit แบบโอเพนซอร์สไปแล้วหลายยุค
    ในหมู่พวกเรามีหลายคนที่สามารถนำการเรนเดอร์ยุคถัดไปของจริงมาสู่เดสก์ท็อปโอเพนซอร์สได้ แต่กำลังทำงานอยู่ที่บริษัทพัฒนาเกมและนั่นคือสิ่งที่เลี้ยงชีพ
    จึงไม่มีเวลาไปมีส่วนร่วมกับสแตกโอเพนซอร์ส
    ถ้าชุมชนสามารถจัดงบเพื่อจ่ายค่าตอบแทนให้กับนักพัฒนาเหล่านี้อย่างสม่ำเสมอได้ การอัปเดตเรนเดอเรอร์และ toolkit ก็คงจะแตกต่างไปมาก
    แอปโอเพนซอร์สอื่น ๆ ก็เช่นกัน

    • ผมเคยทำ GUI renderer สำหรับ GPU มาแล้วหลายครั้ง ตัวอย่างเช่นอันนี้: https://github.com/Const-me/Vrmac?tab=readme-ov-file#vector-graphics-engine https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA.md
      กราฟิก 2D มีจุดร่วมกับเกมเอนจินน้อยมาก
      ในงาน 2D อินพุตมักเป็น Bézier และ spline อื่น ๆ มี overdraw เยอะ และการจัดการหน่วยความจำ VRAM ก็ซับซ้อนขึ้นเพราะมี texture ที่ผู้ใช้จัดให้
      ในทางกลับกัน เกมเอนจินกำลังแก้ปัญหายาก ๆ ที่ไม่เกี่ยวกับเรนเดอเรอร์ 2D เช่น แสงแบบไดนามิก เอฟเฟกต์เชิงปริมาตร และสภาพแวดล้อมแบบไดนามิก
    • ผมค่อนข้างสงสัยกับข้ออ้างนี้
      รู้สึกว่า game UI toolkit กับ desktop GUI framework เป็นคนละโลกที่มีความคาดหวังต่างกัน
      จากประสบการณ์ที่เคยใช้ทั้งสองอย่างในสายงานของผม GTK/Qt มักจัดการเรื่องการผสานเข้ากับระบบปฏิบัติการ ฟีเจอร์การช่วยการเข้าถึง การนำทางด้วยคีย์บอร์ด และฟังก์ชันอย่างคัดลอก/วาง ได้ดีหรือดีมาก
      game UI toolkit มักไม่ต้องการสิ่งเหล่านี้ จึงยอมทิ้งไปทั้งหมด และไปโฟกัสที่ประสิทธิภาพ ธีม และการผสานเข้ากับเกมเอนจินแทน
      ในทางทฤษฎีอาจบอกได้ว่าเรนเดอเรอร์เป็นอิสระจากเรื่องเหล่านี้ แต่ในทางปฏิบัติไม่ได้เป็นแบบนั้นทั้งหมด
      เมื่อมีงบประมาณจำกัด เวลาที่จะใช้กับฟีเจอร์ไหนก็แตกต่างกันด้วย
      เรนเดอเรอร์ที่เร็วและแม่นยำมากไม่ได้สำคัญกับ desktop GUI framework เท่ากับที่สำคัญกับ game UI toolkit
    • ในบรรดาเกมเอนจินเหล่านั้น มีกี่ตัวที่มีระดับนามธรรมสูงพอจะสลับไปใช้ PDF หรือ SVG backend ได้?
      มีกี่ตัวที่รองรับ CMYK และหน่วยสำหรับงานพิมพ์?
      นี่ยังแค่แตะผิวของสิ่งที่ GUI renderer ต้องมี แต่เกมเอนจินไม่จำเป็นต้องมี
      ผมสงสัยมากว่ากลุ่มนักพัฒนาเกมจะสามารถประกอบอะไรสักอย่างที่เร็วกว่ามากเมื่อเทียบกับ Skia โดยไม่ต้องเสียฟีเจอร์ไปมากมายได้จริง
    • ชุมชนที่พูดถึงตรงนี้ สุดท้ายแล้วก็คือคนอย่างพวกคุณนั่นเอง
      คนที่ต้องหาเลี้ยงชีพ แต่ก็มีส่วนร่วมเท่าที่ทำได้ด้วยการใช้ซอฟต์แวร์และบางครั้งก็ช่วยเขียนโค้ด
      แน่นอนว่าถ้าชุมชนระดมทุนได้ก็คงยอดเยี่ยม แต่แม้แต่งานประสานงานนั้นเองก็เป็นงานที่สำหรับใครบางคนแล้วไม่ได้ช่วยเลี้ยงชีพ
      ผมชอบโอเพนซอร์ส/ซอฟต์แวร์เสรี รู้สึกขอบคุณที่มันมีอยู่ และก็ช่วยเท่าที่ทำได้เมื่อมีโอกาส แต่ผมคิดมานานแล้วว่านี่คือ ความมุ่งหมายของคนที่มีอภิสิทธิ์
      คุณต้องมีเวลาว่าง และต้องสามารถใช้เวลาว่างนั้นกับงานที่ไม่ได้ช่วยยกระดับคุณภาพชีวิตได้ อีกทั้งยังต้องทำแบบนั้นได้อย่างต่อเนื่อง
    • ผมค่อนข้างสงสัยกับคำนั้น
      ผมทำงานอยู่ในอุตสาหกรรมเกม และถึงแม้เรนเดอเรอร์ 3D จะดีมาก แต่ผมยังไม่เคยเห็น 2D UI renderer ที่ให้ความรู้สึกว่าแข่งขันได้จริง
      คุณใช้ตัวอะไรสำหรับการเรนเดอร์ path และ pattern?