สถาปัตยกรรม RenderingNG

Chris Harrelson

ในส่วนนี้ คุณจะเห็นวิธีตั้งค่าคอมโพเนนต์ของ RenderingNG และวิธีที่ไปป์ไลน์การแสดงผลทำงาน

เริ่มที่ระดับสูงสุด งานในการแสดงภาพมีดังนี้

1. แสดงเนื้อหาเป็นพิกเซลบนหน้าจอ
2. ทำให้เอฟเฟกต์ภาพเคลื่อนไหวในเนื้อหาจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง
3. เลื่อนตามการป้อนข้อมูล
4. ป้อนเส้นทางไปยังตำแหน่งที่เหมาะสมอย่างมีประสิทธิภาพเพื่อให้สคริปต์ของนักพัฒนาซอฟต์แวร์และระบบย่อยอื่นๆ ตอบสนองได้

เนื้อหาที่จะแสดงผลคือลําดับชั้นของเฟรมสําหรับแท็บเบราว์เซอร์แต่ละแท็บ รวมถึงอินเทอร์เฟซของเบราว์เซอร์ และกระแสเหตุการณ์อินพุตดิบจากหน้าจอสัมผัส เมาส์ แป้นพิมพ์ และอุปกรณ์ฮาร์ดแวร์อื่นๆ

แต่ละเฟรมประกอบด้วย

• สถานะ DOM
• CSS
• แคนวาส
• แหล่งข้อมูลภายนอก เช่น รูปภาพ วิดีโอ แบบอักษร และ SVG

เฟรมคือเอกสาร HTML พร้อม URL ของเฟรม หน้าเว็บที่โหลดในแท็บเบราว์เซอร์จะมีเฟรมระดับบนสุด เฟรมย่อยสำหรับ iframe แต่ละรายการรวมอยู่ในเอกสารระดับบนสุด และองค์ประกอบสืบทอด iframe ที่เกิดซ้ำ

เอฟเฟกต์ภาพคือการดําเนินการแบบกราฟิกที่ใช้กับบิตแมป เช่น เลื่อน การเปลี่ยนรูปแบบ คลิป ฟิลเตอร์ ความทึบแสง หรือการรวม

คอมโพเนนต์ของสถาปัตยกรรม

ใน RenderingNG งานเหล่านี้จะแยกออกเป็นหลายระยะและคอมโพเนนต์โค้ดอย่างเป็นเหตุเป็นผล คอมโพเนนต์จะปรากฏในกระบวนการต่างๆ ของ CPU, เทรด และคอมโพเนนต์ย่อยภายในเทรดเหล่านั้น แต่ละรายการมีบทบาทสำคัญในการบรรลุความน่าเชื่อถือ ประสิทธิภาพที่ปรับขนาดได้ และความสามารถในการขยายสำหรับเนื้อหาเว็บทั้งหมด

โครงสร้างไปป์ไลน์การแสดงผล

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

ระยะต่างๆ มีดังนี้

1. ภาพเคลื่อนไหว: เปลี่ยนสไตล์ที่คำนวณแล้วและเปลี่ยนแปลงต้นไม้พร็อพเพอร์ตี้เมื่อเวลาผ่านไปตามไทม์ไลน์แบบประกาศ
2. สไตล์: ใช้ CSS กับ DOM และสร้างสไตล์ที่คอมไพล์แล้ว
3. เลย์เอาต์: กำหนดขนาดและตำแหน่งขององค์ประกอบ DOM บนหน้าจอ และสร้างแผนผังส่วนย่อยที่เปลี่ยนแปลงไม่ได้
4. การลงสีล่วงหน้า: คำนวณโครงสร้างพร็อพเพอร์ตี้และinvalidateรายการที่แสดงและชิ้นส่วนพื้นผิว GPU ที่มีอยู่ตามความเหมาะสม
5. เลื่อน: อัปเดตออฟเซตการเลื่อนของเอกสารและองค์ประกอบ DOM ที่เลื่อนได้โดยการทำให้ต้นไม้พร็อพเพอร์ตี้เปลี่ยนแปลง
6. สี: คำนวณรายการแสดงผลที่อธิบายวิธีแรสเตอร์ชิ้นส่วนพื้นผิว GPU จาก DOM
7. คอมมิต: คัดลอกแผนผังคุณสมบัติและรายการที่แสดงผลไปยังชุดข้อความของคอมโพสิเตอร์
8. กำหนดเลเยอร์: แบ่งรายการที่แสดงเป็นรายการเลเยอร์แบบผสมสำหรับการแรสเตอร์และภาพเคลื่อนไหวอิสระ
9. เวิร์กเลตแรสเตอร์ ถอดรหัส และเพนต์: เปลี่ยนรายการที่แสดง รูปภาพที่เข้ารหัส และโค้ดเวิร์กเลตเพนต์เป็นไทล์พื้นผิว GPU ตามลำดับ
10. เปิดใช้งาน: สร้างเฟรมคอมโพสิตที่แสดงวิธีวาดและจัดตำแหน่งชิ้นส่วน GPU ไปยังหน้าจอ พร้อมกับเอฟเฟกต์ภาพต่างๆ
11. รวม: รวมเฟรมคอมโพสิตจากเฟรมคอมโพสิตที่มองเห็นได้ทั้งหมดเข้าเป็นเฟรมคอมโพสิตส่วนกลางเฟรมเดียว
12. วาด: เรียกใช้เฟรมคอมโพสิเตอร์แบบรวมบน GPU เพื่อสร้างพิกเซลบนหน้าจอ

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

การแสดงภาพ UI ของเบราว์เซอร์ไม่ได้แสดงที่นี่โดยตรง แต่ก็นึกถึงเวอร์ชันที่เรียบง่ายของไปป์ไลน์เดียวกันนี้ (และอันที่จริงการติดตั้งใช้งานก็ใช้โค้ดส่วนมากเหมือนกัน) วิดีโอ (ไม่ได้แสดงโดยตรงเช่นกัน) โดยทั่วไปจะแสดงผลด้วยโค้ดอิสระที่ถอดรหัสเฟรมเป็นไทล์พื้นผิว GPU ซึ่งจะเสียบเข้ากับเฟรมคอมโพสิตและขั้นตอนวาด

กระบวนการและโครงสร้างชุดข้อความ

กระบวนการของ CPU

การใช้กระบวนการ CPU หลายรายการจะแยกประสิทธิภาพและความปลอดภัยระหว่างเว็บไซต์และสถานะเบราว์เซอร์ รวมถึงแยกความเสถียรและความปลอดภัยจากฮาร์ดแวร์ GPU

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

เว็บไซต์ต่างๆ มักจะใช้กระบวนการแสดงผลที่แตกต่างกัน

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

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

Chromium ทั้งหมดมีกระบวนการแสดงผลภาพเพียง 1 รายการเท่านั้น เนื่องจากปกติแล้วจะมี GPU และหน้าจอสำหรับวาดภาพเพียงรายการเดียว

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

เนื่องจากเบราว์เซอร์มีแท็บและหน้าต่างได้หลายรายการ และทุกรายการมีพิกเซล UI ของเบราว์เซอร์ที่ต้องวาด คุณอาจสงสัยว่าทำไมจึงมีกระบวนการของเบราว์เซอร์เพียง 1 รายการ เหตุผลก็คือมีกลุ่มแท็บที่โฟกัสอยู่ครั้งละ 1 แท็บเท่านั้น ที่จริงแล้วแท็บเบราว์เซอร์ที่มองไม่เห็นมักปิดใช้งานและลดหน่วยความจำ GPU ทั้งหมด อย่างไรก็ตาม มีการนําฟีเจอร์การแสดงผล UI ที่ซับซ้อนของเบราว์เซอร์มาใช้ในกระบวนการแสดงผลมากขึ้นด้วย (เรียกว่า WebUI) การดำเนินการนี้ไม่ได้เป็นไปเพื่อแยกประสิทธิภาพ แต่เพื่อใช้ประโยชน์จากความสะดวกในการใช้งานเครื่องมือแสดงผลเว็บของ Chromium

ในอุปกรณ์ Android รุ่นเก่า ระบบจะแชร์กระบวนการแสดงผลและเบราว์เซอร์เมื่อใช้ใน WebView (โดยทั่วไปจะไม่ใช้กับ Chromium ใน Android แต่จะใช้ได้กับ WebView เท่านั้น) ใน WebView จะมีการแชร์กระบวนการของเบราว์เซอร์กับแอปที่ฝังอยู่ด้วย และ WebView มีกระบวนการแสดงผลเพียงขั้นตอนเดียว

ในบางครั้งอาจมีกระบวนการที่เป็นประโยชน์ในการถอดรหัสเนื้อหาวิดีโอที่ได้รับการคุ้มครอง กระบวนการนี้ไม่ได้แสดงอยู่ในแผนภาพก่อนหน้า

ชุดข้อความ

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

• ชุดข้อความหลักจะเรียกใช้สคริปต์ ลูปเหตุการณ์การแสดงผล วงจรชีวิตของเอกสาร การทดสอบ Hit การกระจายเหตุการณ์สคริปต์ และการแยกวิเคราะห์ HTML, CSS และรูปแบบข้อมูลอื่นๆ
  • ตัวช่วยชุดข้อความหลักจะทํางานต่างๆ เช่น สร้างบิตแมปรูปภาพและ Blob ที่ต้องเข้ารหัสหรือถอดรหัส
  • เวิร์กเกอร์เว็บ เรียกใช้สคริปต์ และลูปเหตุการณ์การแสดงผลสําหรับ OffscreenCanvas
• ชุดข้อความแบบผสมจะประมวลผลเหตุการณ์อินพุต เลื่อนดูและภาพเคลื่อนไหวของเนื้อหาเว็บ คำนวณการกำหนดเลเยอร์ของเนื้อหาเว็บอย่างเหมาะสมที่สุด และประสานงานการถอดรหัสรูปภาพ เวิร์กเล็ตการระบายสี และงานแรสเตอร์
  • ตัวช่วยเธรดคอมโพสิตจะประสานงานงานแรสเตอร์ของ Viz และดำเนินการถอดรหัสรูปภาพ วาดเวิร์กเลต และแรสเตอร์สำรอง
• เทรดสื่อ demuxer หรือเอาต์พุตเสียงจะถอดรหัส ประมวลผลและซิงค์ข้อมูลสตรีมวิดีโอและเสียง (โปรดทราบว่าวิดีโอจะทำงานควบคู่ไปกับไปป์ไลน์การแสดงผลหลัก)

การแยกเทรดหลักและเทรดคอมโพสิตมีความสําคัญอย่างยิ่งสําหรับการแยกประสิทธิภาพของภาพเคลื่อนไหวและการเลื่อนออกจากการทำงานของเทรดหลัก

แต่ละกระบวนการแสดงผลจะมีเธรดหลักเพียงเธรดเดียว แม้ว่าแท็บหรือเฟรมหลายรายการจากเว็บไซต์เดียวกันอาจอยู่ในกระบวนการเดียวกันก็ตาม อย่างไรก็ตาม มีการแยกประสิทธิภาพออกจากงานที่ดำเนินการใน API ของเบราว์เซอร์ต่างๆ เช่น การสร้างบิตแมปรูปภาพและ Blob ใน Canvas API จะทํางานในเธรดตัวช่วยของเธรดหลัก

ในทำนองเดียวกัน เทรดคอมโพสิตจะมีเพียง 1 เทรดต่อกระบวนการแสดงผล โดยทั่วไปแล้ว การมีเพียง 1 รายการนั้นไม่ใช่ปัญหา เนื่องจากระบบจะมอบหมายการดำเนินการทั้งหมดที่มีค่าใช้จ่ายสูงในเธรดคอมโพสิตให้กับเธรดผู้ปฏิบัติงานคอมโพสิตหรือกระบวนการ Viz และงานนี้จะทําควบคู่ไปกับการกำหนดเส้นทางอินพุต การเลื่อน หรือภาพเคลื่อนไหวได้ เทรดเวิร์กคอมโพสิตอร์จะประสานงานงานต่างๆ ที่ทำงานในกระบวนการ Viz แต่การเร่งด้วย GPU ทุกที่อาจไม่ทำงานด้วยเหตุผลที่อยู่นอกเหนือการควบคุมของ Chromium เช่น ข้อบกพร่องของไดรเวอร์ ในกรณีเหล่านี้ เทรดเวิร์กจะทํางานในโหมดสํารองใน CPU

จำนวนเทรดของผู้ปฏิบัติงานคอมโพสิตขึ้นอยู่กับความสามารถของอุปกรณ์ เช่น โดยทั่วไปแล้วเดสก์ท็อปจะใช้เทรดมากกว่าเนื่องจากมีแกนของ CPU มากกว่าและจำกัดแบตเตอรี่น้อยกว่าอุปกรณ์เคลื่อนที่ นี่คือตัวอย่างของการเพิ่มและปรับขนาด

สถาปัตยกรรมการแยกชุดเธรดของกระบวนการแสดงผลคือการใช้รูปแบบการเพิ่มประสิทธิภาพ 3 รูปแบบ ได้แก่

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

กระบวนการของเบราว์เซอร์

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

เทรดการเรนเดอร์และคอมโพสิตของกระบวนการของเบราว์เซอร์จะคล้ายกับโค้ดและฟังก์ชันการทํางานของกระบวนการเรนเดอร์ ยกเว้นว่าเทรดหลักและเทรดคอมโพสิตจะรวมกันเป็นเทรดเดียว ในกรณีนี้ต้องใช้เทรดเพียง 1 รายการเท่านั้น เนื่องจากไม่จำเป็นต้องแยกประสิทธิภาพจากงานเทรดหลักที่ใช้เวลานาน เนื่องจากไม่มีการออกแบบ

กระบวนการแสดงภาพ

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

โดยปกติแล้ว แรสเตอร์และการวาดภาพจะเกิดขึ้นในเธรดเดียวกันเนื่องจากทั้ง 2 กระบวนการใช้ทรัพยากร GPU และการใช้ GPU แบบหลายเธรดอย่างน่าเชื่อถือนั้นทำได้ยาก (การเข้าถึง GPU แบบหลายเธรดที่ง่ายขึ้นเป็นหนึ่งในแรงจูงใจในการพัฒนามาตรฐาน Vulkan ใหม่) ใน WebView ของ Android จะมีเธรดแสดงผลระดับระบบปฏิบัติการแยกต่างหากสำหรับการวาดภาพเนื่องจากวิธีที่ฝัง WebView ลงในแอปเนทีฟ แพลตฟอร์มอื่นๆ มีแนวโน้มที่จะมีเธรดดังกล่าวในอนาคต

คอมโพสิตการแสดงผลอยู่ในเธรดอื่นเนื่องจากต้องตอบสนองได้ตลอดเวลา และจะไม่บล็อกแหล่งที่มาที่อาจทำให้เธรดหลักของ GPU ทำงานช้าลง สาเหตุหนึ่งที่ทำให้การประมวลผลในเธรดหลักของ GPU ช้าลงคือการเรียกใช้โค้ดที่ไม่ใช่ Chromium เช่น ไดรเวอร์ GPU เฉพาะของผู้ให้บริการ ซึ่งอาจทำงานช้าในลักษณะที่คาดเดาได้ยาก

โครงสร้างคอมโพเนนต์

ในเธรดหลักหรือเธรดคอมโพสิตของกระบวนการเรนเดอร์แต่ละรายการ จะมีคอมโพเนนต์ซอฟต์แวร์เชิงตรรกะที่โต้ตอบกันในรูปแบบที่มีโครงสร้าง

แสดงผลคอมโพเนนต์ของเทรดหลัก

ในโปรแกรมแสดงผล Blink ให้ทำดังนี้

• ส่วนย่อยของแผนผังเฟรมในเครื่องแสดงโครงสร้างของเฟรมในเครื่องและ DOM ภายในเฟรม
• คอมโพเนนต์ DOM และ Canvas API มีการใช้งาน API ทั้งหมดเหล่านี้
• เครื่องมือเรียกใช้วงจรชีวิตของเอกสารจะดำเนินการตามขั้นตอนในไปป์ไลน์การแสดงผลจนถึงขั้นตอนคอมมิต
• คอมโพเนนต์การทดสอบ Hit และการจัดทําคําสั่งของเหตุการณ์ป้อนข้อมูลจะดําเนินการทดสอบ Hit เพื่อค้นหาองค์ประกอบ DOM ที่เหตุการณ์กําหนดเป้าหมาย และเรียกใช้อัลกอริทึมการจัดทําคําสั่งของเหตุการณ์ป้อนข้อมูลและลักษณะการทํางานเริ่มต้น

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

เศษส่วนของต้นไม้เฟรมในพื้นที่มีความซับซ้อนเล็กน้อย ให้ระลึกว่าแผนผังเฟรมคือหน้าหลักและ iframe ย่อยของเฟรมนี้ซ้ำๆ เฟรมจะอยู่ในเครื่องของกระบวนการแสดงผลหากแสดงผลในกระบวนการนั้น และจะเป็นเฟรมระยะไกลหากไม่ได้แสดงผลในกระบวนการนั้น

คุณจินตนาการได้ว่าการระบายสีเฟรมจะเป็นไปตามกระบวนการแสดงผล ในรูปภาพก่อนหน้า วงกลมสีเขียวคือเฟรมทั้งหมดในกระบวนการแสดงผล 1 รายการ วงกลมสีส้มคือเฟรมในกระบวนการที่ 2 และวงกลมสีน้ำเงินคือเฟรมในกระบวนการที่ 3

เศษเฟรมต้นไม้ในเครื่องคือคอมโพเนนต์ที่เชื่อมต่อกันซึ่งมีสีเดียวกันในเฟรมต้นไม้ รูปภาพมีต้นไม้เฟรมในร้าน 4 ต้น ได้แก่ 2 ต้นสําหรับเว็บไซต์ ก. 1 ต้นสําหรับเว็บไซต์ ข. และ 1 ต้นสําหรับเว็บไซต์ ค. ต้นไม้เฟรมในเครื่องแต่ละต้นจะมีคอมโพเนนต์โปรแกรมแสดงผล Blink ของตัวเอง ตัวแสดงผล Blink ของแผนผังเฟรมในเครื่องอาจอยู่ในกระบวนการแสดงผลเดียวกันกับแผนผังเฟรมในเครื่องอื่นๆ ซึ่งจะกำหนดโดยวิธีเลือกกระบวนการแสดงผลตามที่อธิบายไว้ก่อนหน้านี้

โครงสร้างชุดข้อความคอมโพสเซอร์ของกระบวนการแสดงผล

องค์ประกอบคอมโพสิตของกระบวนการแสดงผลมีดังนี้

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

ตัวอย่างสถาปัตยกรรมที่ใช้จริง

ในตัวอย่างนี้ มี 3 แท็บ ดังนี้

แท็บ 1: foo.com

<html>
  <iframe id=one src="foo.com/other-url"></iframe>
  <iframe  id=two src="bar.com"></iframe>
</html>

แท็บ 2: bar.com

<html>
 …
</html>

แท็บ 3: baz.com html <html> … </html>

โครงสร้างกระบวนการ ด้าย และคอมโพเนนต์สำหรับแท็บเหล่านี้มีลักษณะดังนี้

มาดูตัวอย่างงานหลัก 4 อย่างของการเรนเดอร์กัน ขอย้ำอีกครั้งว่า

1. แสดงผลเนื้อหาเป็นพิกเซลบนหน้าจอ
2. Animateเอฟเฟกต์ภาพในเนื้อหาจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง
3. เลื่อนตามการป้อนข้อมูล
4. กำหนดเส้นทางอินพุตไปยังตำแหน่งที่เหมาะสมอย่างมีประสิทธิภาพเพื่อให้สคริปต์ของนักพัฒนาซอฟต์แวร์และระบบย่อยอื่นๆ ตอบสนองได้

วิธีแสดงผล DOM ที่เปลี่ยนแปลงแล้วสําหรับแท็บที่ 1

1. สคริปต์ของนักพัฒนาซอฟต์แวร์จะเปลี่ยน DOM ในกระบวนการแสดงผลสําหรับ foo.com
2. ตัวแสดงผลการกะพริบจะบอกคอมโพสเซอร์ว่าจำเป็นต้องมีการแสดงภาพ
3. คอมโพสิตเตอร์บอก Viz ว่าต้องมีการเรนเดอร์
4. Viz จะส่งสัญญาณการเริ่มต้นแสดงผลกลับไปให้โปรแกรมคอมโพสิท
5. คอมโพสิตจะส่งต่อสัญญาณเริ่มต้นไปยังโปรแกรมแสดงผล Blink
6. โปรแกรมรันไทม์ลูปเหตุการณ์ของเธรดหลักจะเรียกใช้วงจรของเอกสาร
7. และเธรดหลักจะส่งผลลัพธ์ไปยังเธรดคอมโพสิต
8. ตัวเรียกใช้ลูปเหตุการณ์ของคอมโพสิเตอร์จะเรียกใช้วงจรการคอมโพสิต
9. ระบบจะส่งงานแรสเตอร์ไปยัง Viz สำหรับแรสเตอร์ (โดยปกติแล้วจะมีงานเหล่านี้มากกว่า 1 งาน)
10. Viz จะแรสเตอร์เนื้อหาใน GPU
11. Viz รับทราบว่างานแรสเตอร์เสร็จสมบูรณ์แล้ว หมายเหตุ: บ่อยครั้งที่ Chromium จะไม่รอให้แรสเตอร์เสร็จสมบูรณ์ แต่จะใช้สิ่งที่เรียกว่าโทเค็นการซิงค์แทน ซึ่งต้องได้รับการแก้ไขโดยงานแรสเตอร์ก่อนดำเนินการขั้นตอนที่ 15
12. ระบบจะส่งเฟรมคอมโพสิตไปยัง Viz
13. Viz จะรวบรวมเฟรมคอมโพสิตสําหรับกระบวนการแสดงผลของ foo.com, กระบวนการแสดงผล iframe ของ bar.com และ UI ของเบราว์เซอร์
14. Viz กำหนดเวลาเสมอ
15. Viz จะวาดเฟรมคอมโพสิตที่รวบรวมไว้บนหน้าจอ

วิธีทำให้การเปลี่ยนเป็นการเปลี่ยนรูปแบบ CSS เคลื่อนไหวในแท็บที่ 2

1. เทรดคอมโพสิตสําหรับกระบวนการแสดงผลของ bar.com จะทําเครื่องหมายภาพเคลื่อนไหวในลูปเหตุการณ์คอมโพสิตโดยการเปลี่ยนต้นไม้พร็อพเพอร์ตี้ที่มีอยู่ จากนั้นระบบจะเรียกใช้วงจรชีวิตของคอมโพสิตอีกครั้ง (งานแรสเตอร์และการถอดรหัสอาจเกิดขึ้น แต่ไม่ได้แสดงที่นี่)
2. ระบบจะส่งเฟรมคอมโพสิตไปยัง Viz
3. Viz จะรวบรวมเฟรมคอมโพสิตสําหรับกระบวนการแสดงผลของ foo.com, กระบวนการแสดงผลของ bar.com และ UI ของเบราว์เซอร์
4. Viz กําหนดเวลาการจับสลาก
5. Viz จะวาดเฟรมคอมโพสิตที่รวบรวมไว้บนหน้าจอ

วิธีเลื่อนหน้าเว็บในแท็บที่ 3

1. ลำดับของเหตุการณ์ input (เมาส์ การสัมผัส หรือแป้นพิมพ์) มาที่กระบวนการของเบราว์เซอร์
2. ระบบจะส่งแต่ละเหตุการณ์ไปยังเธรดคอมโพสิตกระบวนการแสดงผลของ baz.com
3. คอมโพสิตเตอร์จะเป็นผู้กำหนดว่าเธรดหลักจำเป็นต้องทราบเกี่ยวกับเหตุการณ์หรือไม่
4. ส่งเหตุการณ์ไปยังเทรดหลัก หากจำเป็น
5. เทรดหลักจะเรียก input event listener (pointerdown, touchstar, pointermove, touchmove หรือ wheel) เพื่อดูว่า Listener จะเรียก preventDefault ในเหตุการณ์หรือไม่
6. เทรดหลักจะแสดงผลว่ามีการเรียก preventDefault ไปยังคอมโพสิเตอร์หรือไม่
7. หากไม่ ระบบจะส่งเหตุการณ์อินพุตกลับไปยังกระบวนการเบราว์เซอร์
8. กระบวนการของเบราว์เซอร์จะแปลงเป็นท่าทางสัมผัสการเลื่อนโดยรวมเข้ากับเหตุการณ์ล่าสุดอื่นๆ
9. ระบบจะส่งท่าทางสัมผัสการเลื่อนไปยังเธรดคอมโพสิตกระบวนการแสดงผลของ baz.com อีกครั้ง
10. ระบบจะใช้การเลื่อนในนั้น และชุดข้อความคอมโพสิตสำหรับกระบวนการแสดงผลของ bar.com จะสร้างภาพเคลื่อนไหวในลูปเหตุการณ์คอมโพสิต จากนั้นจะเปลี่ยนรูปแบบการเลื่อนในต้นไม้พร็อพเพอร์ตี้และเรียกใช้วงจรคอมโพสิตอีกครั้ง และยังบอกให้เธรดหลักเรียกเหตุการณ์ scroll (ไม่ได้แสดงที่นี่) ด้วย
11. ระบบจะส่งเฟรมคอมโพสิเตอร์ไปยัง Viz
12. Viz จะรวบรวมเฟรมคอมโพสิตสําหรับกระบวนการแสดงผลของ foo.com, กระบวนการแสดงผลของ bar.com และ UI ของเบราว์เซอร์
13. Viz กําหนดเวลาการจับสลาก
14. Viz จะวาดเฟรมคอมโพสิตที่รวบรวมไว้บนหน้าจอ

วิธีกําหนดเส้นทางเหตุการณ์ click ในไฮเปอร์ลิงก์ใน iframe #2 ในแท็บที่ 1

1. เหตุการณ์ input (เมาส์ การสัมผัส หรือแป้นพิมพ์) มาถึงกระบวนการเบราว์เซอร์ โดยจะทำการทดสอบการทํางานโดยประมาณเพื่อระบุว่ากระบวนการแสดงผล iframe ของ bar.com ควรได้รับการคลิก และส่งการคลิกนั้นไป
2. เทรดคอมโพสิเตอร์สําหรับ bar.com จะกําหนดเส้นทางเหตุการณ์ click ไปยังเทรดหลักสําหรับ bar.com และกำหนดเวลางานลูปเหตุการณ์การแสดงผลเพื่อประมวลผล
3. ตัวประมวลผลเหตุการณ์อินพุตสําหรับการทดสอบ Hit ของเธรดหลักของ bar.com เพื่อระบุว่ามีการคลิกองค์ประกอบ DOM ใดใน iframe และเรียกเหตุการณ์ click ให้สคริปต์สังเกต ไม่ได้ยินเสียง preventDefault ระบบจึงนำทางไปยังไฮเปอร์ลิงก์
4. เมื่อโหลดหน้าปลายทางของไฮเปอร์ลิงก์ ระบบจะแสดงผลสถานะใหม่ โดยมีขั้นตอนคล้ายกับตัวอย่าง "แสดงผล DOM ที่เปลี่ยนแปลง" ก่อนหน้า (การเปลี่ยนแปลงที่ตามมาเหล่านี้ไม่ได้แสดงที่นี่)

สรุป

การจดจำและซึมซับวิธีการทำงานของการแสดงผลอาจใช้เวลานาน

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

คอมโพเนนต์แต่ละรายการมีบทบาทสําคัญในการเพิ่มประสิทธิภาพและฟีเจอร์ของเว็บแอปสมัยใหม่

อ่านต่อไปเกี่ยวกับโครงสร้างข้อมูลสำคัญ ซึ่งมีความสำคัญพอๆ กับ RenderingNG ในองค์ประกอบโค้ด

ภาพโดย Una Kravets