เรนเดอร์ข้อความให้คมชัดบน GPU

 (osor.io)
1 คะแนน โดย GN⁺ 2025-06-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเสนอเทคนิคการเรนเดอร์เวกเตอร์แบบเรียลไทม์รูปแบบใหม่เพื่อแก้ปัญหาคุณภาพของ การเรนเดอร์ข้อความ โดยเฉพาะข้อจำกัดของวิธีแบบ SDF (distance field)
  • ส่งข้อมูล glyph (อักขระ) ในรูปเส้นโค้งเวกเตอร์ไปยัง GPU โดยตรงเพื่อทำ การแรสเตอร์ไรซ์แบบเรียลไทม์ จึงได้ทั้งความละเอียดไม่จำกัดและการใช้หน่วยความจำต่ำ
  • ใช้เทคนิค texture atlas และ temporal accumulation เพื่อให้ได้ คุณภาพ anti-aliasing สูง และการแคชที่มีประสิทธิภาพ
  • สามารถปรับใช้ให้เหมาะกับ โครงสร้าง subpixel ได้หลากหลายแบบ (เช่น OLED, LCD เป็นต้น) จึงให้ผลลัพธ์ที่นุ่มนวลและคมชัดโดยไม่มีปัญหา fringing (สีฟุ้ง)
  • นำเสนอแนวทางที่เรียบง่ายแต่ขยายต่อได้ดีสำหรับ การเรนเดอร์ฟอนต์คุณภาพสูง ในงานอย่างข้อความแบบเรียลไทม์, UI, เกม เป็นต้น

บทนำ: โจทย์ของการเรนเดอร์ข้อความ

  • ในการเรนเดอร์ข้อความแบบเรียลไทม์มีปัญหาหลากหลาย เช่น aliasing (รอยหยัก), texture ขนาดใหญ่, เวลา build, การซูมเข้าออก, การเคลื่อนที่ที่ลื่นไหล
  • วิธี Multi-Channel Signed Distance Fields (SDFs) ที่นิยมใช้กันก่อนหน้านี้มีข้อจำกัดทั้งด้านคุณภาพและความยืดหยุ่น
  • จากปัญหา โครงสร้าง subpixel ที่ไม่เป็นมาตรฐาน ของจอ OLED รุ่นใหม่และปัญหา fringing จึงพัฒนาแนวทางใหม่ที่คำนึงถึง subpixel anti-aliasing ด้วย

ข้อจำกัดของวิธี SDF แบบเดิม

คุณภาพ

  • ในวิธี SDF หากเป็นฟอนต์ที่มี รายละเอียดเล็กมาก หรือมี เส้นบาง จำนวนมาก จะเกิดปัญหาคุณภาพลดลงและข้อมูลสูญหาย
  • หากไม่เพิ่มความละเอียด ก็จะยังมี artifact หลงเหลือใน glyph บางตัว

ขนาด atlas

  • SDF ต้องสร้างแบบออฟไลน์ก่อนแล้วเก็บลง atlas ซึ่งในกรณีที่มี glyph จำนวนมากหรือฟอนต์ CJK (จีน ญี่ปุ่น เกาหลี) ขนาดจะใหญ่จนแทบใช้งานจริงไม่ได้
  • หากใช้หลายฟอนต์พร้อมกัน ภาระด้านหน่วยความจำและแบนด์วิดท์สำหรับการสตรีมจะสูงมาก

ความยืดหยุ่นและความเรียบง่าย

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

แนวทางใหม่: แรสเตอร์ไรซ์เส้นโค้งเวกเตอร์แบบเรียลไทม์

  • แทนที่จะสร้าง texture ไว้ล่วงหน้า จะส่ง ข้อมูลเส้นโค้งเวกเตอร์ของ glyph ที่มองเห็นอยู่จริงบนหน้าจอ (เช่น เส้นโค้งเบซิเยร์) ไปยัง GPU โดยตรง แล้วแรสเตอร์ไรซ์ ณ จุดนั้น
  • ใส่ glyph ลงใน atlas texture เท่าที่จำเป็น และคงไว้หรือปล่อยออกตามความถี่ในการใช้งาน
  • ตราบใดที่ glyph ยังอยู่บนหน้าจอ จะใช้ การสะสมตัวอย่าง (temporal accumulation) เพื่อให้ได้ ผลลัพธ์แบบ anti-aliased ที่ลื่นและมีคุณภาพสูงมาก
  • เนื่องจากประมวลผลแบบ เวกเตอร์ ตลอดเวลา จึงให้ผลลัพธ์ที่คมชัดโดยไม่มีข้อจำกัดด้านความละเอียด

การจัดการข้อมูลเส้นโค้งของฟอนต์

  • ใช้ไลบรารีโอเพนซอร์สอย่าง FreeType เพื่ออ่านฟอร์แมตฟอนต์หลากหลายแบบและดึงข้อมูลเส้นโค้งของ glyph ออกมา
  • แยกวิเคราะห์ glyph เป็น เส้นตรง, เส้นโค้งเบซิเยร์กำลังสอง/กำลังสาม แล้วแปลงเส้นโค้งทั้งหมดให้เป็นเส้นโค้งเบซิเยร์กำลังสองเพื่อให้ GPU shader ประมวลผลง่ายขึ้น
    • เส้นตรงจะถูกแปลงเป็นเส้นโค้งกำลังสองโดยเพิ่มจุดควบคุมตรงกลาง
    • เส้นโค้งกำลังสามจะแบ่งเป็นเส้นโค้งกำลังสอง 2 ช่วง

การคำนวณ coverage (การเติมพื้นที่ภายในพิกเซล)

  • ในแต่ละพิกเซลจะคำนวณ จุดตัดระหว่างเส้นโค้งกับรังสีในแนวนอน แล้วใช้ winding number (จำนวนจุดตัดสะสม) เพื่อตัดสินว่าอยู่ด้านในหรือด้านนอก
  • มีการรวม ตัวอย่างจำนวนมาก (สะสมตัวอย่าง n ครั้ง) โดยความคลาดเคลื่อนเล็กน้อยบางส่วนแทบไม่ส่งผลต่อผลลัพธ์สุดท้าย
  • ใช้เทคนิค การจัดวางจุดตัวอย่าง (quasirandom sequence) เพื่อสะสมผลลัพธ์จากตำแหน่งที่หลากหลายในแต่ละเฟรม

การปรับให้การเข้าถึงเส้นโค้งมีประสิทธิภาพ

  • แบ่ง glyph ออกเป็น band แนวนอน แล้วทดสอบเฉพาะเส้นโค้งที่เกี่ยวข้องในแต่ละ band เพื่อลดปริมาณการคำนวณ
  • ใช้ การจัดวาง thread และการวนซ้ำระดับ band เพื่อเพิ่มประสิทธิภาพของการประมวลผลแบบ bulk บน GPU ให้สูงสุด

การแพ็กและจัดการ atlas

  • จัดสรรและบริหารภาพ glyph แต่ละตัวภายใน atlas (texture ร่วม)
    • glyph ที่ยังไม่มีจะจัดสรรพื้นที่ใหม่แล้วแรสเตอร์ไรซ์ ส่วน glyph ที่มีอยู่แล้วจะนำกลับมาใช้ซ้ำ
    • ทั้งนี้ แม้จะเป็น glyph เดียวกันก็อาจต้องมีหลายเวอร์ชันตาม ตำแหน่ง subpixel และขนาด
  • ใช้ Z-Order Packing (เช่น Morton code) เพื่อทำการแพ็กระหว่างบิตเซตแบบหนึ่งมิติกับพื้นที่ 2D อย่างมีประสิทธิภาพ
    • สามารถประยุกต์อย่างยืดหยุ่นตามโครงสร้างของภาษา เช่น กลุ่มอักษรละตินเน้นแนวตั้ง กลุ่มอักษรอาหรับเน้นแนวนอน เป็นต้น
  • เมื่อ glyph ไม่จำเป็นต้องใช้อีก ก็สามารถจัดสรรพื้นที่ใน atlas นั้นใหม่ได้

การสะสมตามเวลา (Temporal Accumulation)

  • ผ่านวิธีแคช glyph และการสะสมตัวอย่าง หลังแสดงผลทันทีจะเก็บตัวอย่างคุณภาพสูงได้อย่างรวดเร็ว และค่อยปรับละเอียดขึ้นในเฟรมถัดไป
    • เฟรมแรกใช้ 8 samples/pixel จากนั้นค่อย ๆ ลดจำนวนตัวอย่างลง โดยสะสมได้สูงสุด 512 ครั้ง
  • ทำให้ได้ทั้ง การแสดง glyph ที่ลื่นไหล และการใช้ทรัพยากรอย่างเหมาะสม

Subpixel anti-aliasing และการป้องกัน fringing

  • จัดสรรพื้นที่การเรนเดอร์ในระดับ subpixel (มององค์ประกอบอย่าง RGB แต่ละตัวเป็นหนึ่ง sample) เพื่อเพิ่มความละเอียดในแนวนอน
    • รองรับได้ทั้งโครงสร้างมาตรฐานของ LCD และการจัดเรียงแบบต่าง ๆ ของ OLED/WOLED
    • ให้เอฟเฟกต์ที่ลื่นไหลโดยไม่มี fringing (สีฟุ้ง)
  • เมื่อจัดเรียงให้ตัวอย่าง subpixel ซ้อนทับกัน (Overlapping) ก็สามารถสะท้อน ผลการผสมแสงของจอจริง ได้ด้วย
  • จึงให้ผลลัพธ์ที่เป็นธรรมชาติและคมชัดได้แม้ไม่มีขอบพิกเซลหรือ hinting

ความสำคัญของแนวทางตามโครงสร้าง subpixel ของแต่ละจอ

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

สรุปและแนวโน้มการใช้งาน

  • การเรนเดอร์ข้อความที่ดีส่งผลอย่างมากต่อการใช้งานโดยรวมและคุณภาพของบริการ
  • โดยเฉพาะใน UI/เกม การแสดงผลฟอนต์คุณภาพสูงสามารถสร้างความแตกต่างอย่างมากต่อประสบการณ์ของผลิตภัณฑ์
  • เป็นโครงสร้างการทำงานที่ทำให้หลักการ เรียบง่าย, ขยายต่อได้, คุณภาพสูง, ยืดหยุ่น เกิดขึ้นจริงได้
  • ทั้งการทำเป็นโอเพนซอร์สและการรองรับ subpixel ที่หลากหลาย ทำให้ เหมาะอย่างยิ่งต่อการใช้งานจริงในอุตสาหกรรม/โปรดักชัน

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

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

 
GN⁺ 2025-06-14
ความเห็นจาก Hacker News
  • ฉันเป็นผู้เขียนบทความเอง และไม่คิดเลยว่าบทความนี้จะกลายเป็นประเด็นได้มากขนาดนี้ ขอบคุณทุกคนที่มาร่วมวงสนทนาที่น่าสนใจ
  • มีคำถามว่าทำไมจุดของตัวเอียง "j" ถึงหายไปในวิดีโอแรก
  • มีความเห็นว่าการเรนเดอร์ฟอนต์แบบซับพิกเซลสำคัญมากต่อความสามารถในการอ่าน แต่ก็น่าเสียดายอย่างที่ผู้เขียนชี้ไว้ว่า มาตรฐานจอภาพปัจจุบันไม่เปิดให้ได้สเปกผังพิกเซลที่แม่นยำ
  • มองว่านี่จำเป็นเฉพาะกับจอความละเอียดมาตรฐานเท่านั้น จริง ๆ ไม่ถึงขั้นจำเป็น แค่มีไว้ก็ดี ตอนนี้จอระดับ Retina แพร่หลายแล้ว จึงกลายเป็นสภาพแวดล้อมที่ไม่จำเป็นต้องใช้การเรนเดอร์แบบซับพิกเซลอีกต่อไป มองว่าแท้จริงแล้วนี่เป็นนวัตกรรมชั่วคราวที่เกิดขึ้นในยุค LCD และตอนนี้เริ่มล้าสมัย อีกทั้งยังมีผลข้างเคียงไม่น้อย เช่น การพึ่งพาเลย์เอาต์ซับพิกเซลของภาพหน้าจอ และการขยายบิตแมปไม่ได้ คิดว่านี่จึงเป็นฉากหลังที่ทำให้ Apple เอาวิธีนี้ออกจาก macOS ไปเลย
  • มีการชี้ว่ามาตรฐานอย่าง DisplayID ถูกออกแบบมาให้ส่งข้อมูลเลย์เอาต์เหล่านี้ได้ เพียงแต่ผู้ผลิตมักไม่ค่อยทำให้ดีหรือไม่ได้เก็บลงฐานข้อมูล แต่ถ้าเป็นรุ่นจอที่นิยม ก็น่าจะบันทึกไว้ในฐานข้อมูลข้อมูลฮาร์ดแวร์และนำมาใช้ได้ ดูวิกิของ DisplayID
  • เสียดายที่เรารู้มาหลายสิบปีแล้วว่าโครงสร้างซับพิกเซลมีความหลากหลาย และชื่นชมที่บทความต้นฉบับสรุปไว้ได้ดี พร้อมแชร์หน้าตัวอย่างที่เรียกว่า ‘สวนสัตว์ซับพิกเซล’ subpixel zoo
  • คิดว่าการเรียกว่า ‘โศกนาฏกรรม’ นั้นเกินไปหน่อย มองว่าแค่แต่ละ OS ใส่ฟังก์ชันปรับจูนแยกตามจอภาพแบบที่ Windows รุ่นก่อนมี ClearType tuner ก็เพียงพอแล้ว และควรมีการจำค่าตั้งค่าของผู้ใช้ไว้เผื่อกรณีที่จอรายงานข้อมูลผิด
  • มองว่าการเรนเดอร์แบบซับพิกเซลไม่จำเป็นอย่างยิ่งสำหรับภาษาส่วนใหญ่ ใช้เพียงฟอนต์บิตแมปที่ไม่มี anti-aliasing หรือฟอนต์เวกเตอร์ที่มี hinting ก็อ่านง่ายอยู่แล้ว แต่สำหรับภาษาที่ใช้ตัวอักษรซับซ้อนอย่างอักษรจีนหรือญี่ปุ่น ความสำคัญจะมากกว่า
  • เนื้อหาว่าเบื้องหลังที่ GTK4 เปลี่ยนไปใช้การเรนเดอร์ที่เน้น GPU แล้วเลิกใช้การเรนเดอร์ RGB ซับพิกเซลนั้นเกี่ยวข้องกับเทคโนโลยี GPU แต่เมื่อบทความต้นฉบับแสดงให้เห็นแล้วว่าทำบน GPU ก็ได้ จึงมีการคาดเดาว่าอาจมีเหตุผลอื่น ข้อเสียอื่น หรือความยากในการรวมสแตกเข้าด้วยกัน
  • มีการพูดถึงความเป็นไปได้ที่ Cosmic Text (Cosmic DE) จะรองรับการเรนเดอร์แบบซับพิกเซลบน GPU ผ่าน Swash
  • ถ้าสนใจวิธีทำ SDF และ MSDF บน WebGL/WebGPU แนะนำให้ดูทิวทอเรียลที่ฉันเขียนเอง ลิงก์ทิวทอเรียล
  • มีการบอกว่าสนใจ WebGPU (WGPU) ที่พัฒนาด้วย Rust รู้สึกว่าทิวทอเรียลนี้ค่อนข้างระดับสูง และการลองแปลงตัวอย่าง JS เป็น Rust เพื่อเรียนรู้นั้นได้ผลดี
  • ชอบฟอร์แมตของเว็บไซต์มากจนอยากทำทิวทอเรียลเกี่ยวกับ GPU ของตัวเองในรูปแบบนี้บ้าง และสงสัยว่านี่เป็นเทมเพลตเฉพาะหรือเป็นส่วนหนึ่งของคอร์ส
  • มีการแชร์ข้อมูลว่าไลบรารี Slug เป็นมิดเดิลแวร์เชิงพาณิชย์ที่ทำ GPU glyph rasterizer Slug Library
  • คิดว่าน่าสนใจที่เว็บไซต์ของ Slug เปิดเผยอัลกอริทึมค่อนข้างละเอียด และสงสัยว่ามีสิทธิบัตรหรือไม่ มองว่าถ้าเอา cosmic-text มาใช้กับการพาร์ส/เลย์เอาต์ฟอนต์แล้วทำเวอร์ชัน wgpu แบบโอเพนซอร์สน่าจะสนุกดี แต่ก็กังวลว่าจะโดน Slug ฟ้องทีหลัง
  • สำหรับคนที่ไม่คุ้นกับสายนี้ มีการสรุปประวัติและสถานะปัจจุบันของการเรนเดอร์ข้อความแบบ SDF ว่า Valve เคยนำเสนอสถาปัตยกรรมที่อิง SDF ตั้งแต่ปี 2007 และต่อมาในปี 2012 Glyphy (โดย Behdad Esfahbod) ก็ออกการทำ SDF บน GPU ซึ่งทำให้เกิดความเปลี่ยนแปลง แต่ OS กระแสหลักและเว็บเบราว์เซอร์ยังคงอยู่กับแนวทาง Truetype แบบยุค 1990 วิธีนี้เล็กและเบา แต่ไม่รองรับการจัดแนวซับพิกเซล/เลย์เอาต์แบบ arbitrary และยังมีข้อจำกัดมากเมื่อขยายข้อความหรือแปลงแบบ 3D คิดว่าที่วิวัฒนาการของเทคโนโลยีนี้ช้า เพราะผลตอบแทนเมื่อเทียบกับความเสี่ยงไม่สูงมาก และเพราะการประสานงาน GPU/CPU นั้นยาก ไม่ใช่แค่เรื่องเรนเดอร์ แต่รวมถึงการจัดเลย์เอาต์ซับซ้อนอย่างการตัดบรรทัดด้วย
  • มีการชี้ว่าที่จริงงานจัดเลย์เอาต์ข้อความอย่างการตัดบรรทัดนั้นแทบจะแยกจากงานเรนเดอร์โดยสิ้นเชิง
  • มีการแนะนำ Pathfinder ของ Servo ว่าเป็นตัวอย่างที่ใช้ GPU compute shader เพื่อทำ GPU text rendering ที่ประสิทธิภาพดีกว่ามากได้แล้ว
  • มี ลิงก์บทความ เกี่ยวกับวิธีการเรนเดอร์ข้อความบน GPU ของ WebKit โดยชี้ว่าแม้ในปัจจุบันจะพอทำตั้งแต่สตริงไปจนถึงบิตแมปบน GPU ได้ระดับหนึ่งแล้ว แต่สิ่งที่หลายคนคาดหวังคือ ‘subpixel anti-aliasing’ กลับมักหายไปเวลาโปรโมต GPU
  • มีการกล่าวว่าจริง ๆ แล้วไม่ใช่แค่ Windows แต่ Chrome/Firefox ก็มีการเร่งความเร็วด้วย GPU ไปจนถึง subpixel anti-aliasing มาหลายปีแล้ว จึงย้ำว่าการมองว่าเทคโนโลยีสมัยใหม่ยังไม่ถูกใช้นั้นเป็นความเข้าใจผิด
  • มีคอมเมนต์ขอบคุณที่สรุปภาพรวมได้กระชับดี
  • มีข้อสังเกตว่าถ้าต้องการการเรนเดอร์แบบซับพิกเซล ก็ต้องรู้กริดซับพิกเซลของจออย่างแม่นยำ จึงมองว่าการให้ผู้ใช้ตั้งค่าแยกตามจอคือ UX ที่สมเหตุสมผลเพียงแบบเดียว และ OS ต้องรองรับไปถึงกรณีหมุนจอด้วย
  • เห็นด้วยกับผู้เขียนว่าทางที่ดีที่สุดคือให้จอภาพบอกโครงสร้างซับพิกเซลของตัวเองกับระบบโดยตรง
  • มีการประเมินว่าผลลัพธ์ยอดเยี่ยม และแม้ subpixel anti-aliasing จะมีข้อดีชัดเจนในยุค LCD ช่วงต้นทศวรรษ 2000 แต่ในยุคจอความละเอียดสูงแบบ Retina กลับแทบไม่มีความหมายแล้ว ข้อเสียที่ยกมาคือใช้ได้เฉพาะกับพื้นหลังทึบ, ใช้กับ post-processing ไม่ได้ (เช่น resize, mirror, blur) และภาพหน้าจอจะดูแปลกเมื่อไปเปิดบนอุปกรณ์อื่น
  • มีการยกข้อมูลว่าถึงจะเลิกใช้ subpixel AA แล้วจะทำให้ระบบง่ายขึ้น แต่ก็ยังมีผู้ใช้เดสก์ท็อปจำนวนมากที่ใช้จอความละเอียดต่ำ 96dpi, 1366x768 อยู่ โดยอ้างอิงข้อมูลจากแบบสำรวจฮาร์ดแวร์ของ Firefox ข้อมูล
  • ยังมีความเห็นเสริมว่าในฐานะผู้ใช้จอความละเอียดสูง การไม่คำนึงถึงผู้ใช้จอความละเอียดต่ำก็เป็นเรื่องไม่รับผิดชอบ
  • มีความกังวลว่าต่อให้มีโปรโตคอลสำหรับเลย์เอาต์ซับพิกเซล ผู้ผลิตบางรายก็อาจทำผิดพลาด จนทำให้เกิดปัญหาการเรนเดอร์ที่ผู้ใช้ทั่วไปเข้าใจได้ยาก
  • เมื่อเห็นฟอนต์ลายมือ (cursive) ความคิดแรกคือ “ใครกันที่คิดว่าฟอนต์ลายมือแบบนี้เป็นไอเดียที่ดี” ซึ่งเป็นความเห็นตรงไปตรงมา
  • มีคำอธิบายว่าคนที่ชอบการเขียนด้วยลายมือ โดยเฉพาะในยุคที่ใช้ปากกาคอแร้งหรือปากกาหมึกซึม น่าจะชอบมัน
  • มีคำอธิบายต่อว่าคนที่เขียนจดหมายบ่อยใช้ตัวเขียน และเมื่ออินเทอร์เน็ตกับการโทรทางไกลฟรีแพร่หลาย การใช้ตัวเขียนก็ลดลง
  • มีคำถามว่าหาลิงก์โค้ดไม่เจอ