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

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

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

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

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

แต่ละเฟรมประกอบด้วยข้อมูลต่อไปนี้

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

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

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

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

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

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

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

ขั้นตอนต่างๆ มีดังนี้

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

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

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

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

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

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

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

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

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

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

Chromium ทั้งหมดจะมีกระบวนการของ Viz เพียง 1 รายการเท่านั้น เนื่องจากมักจะมี GPU และหน้าจอเพียง 1 รายการให้วาด

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

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

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

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

ชุดข้อความ

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

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

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

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

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

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

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

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

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

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

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

กระบวนการแสดงผล

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

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

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

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

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

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

ในโปรแกรมแสดงภาพกะพริบ

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

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

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

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

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

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

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

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

สถาปัตยกรรมตัวอย่างในสถานการณ์จริง

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

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

1. ลำดับของเหตุการณ์ input (เมาส์ การสัมผัส หรือแป้นพิมพ์) มาที่กระบวนการของเบราว์เซอร์
2. แต่ละเหตุการณ์จะถูกกำหนดเส้นทางไปยังเธรดประมวลผลการแสดงผลสำหรับกระบวนการแสดงผลของ baz.com
3. ตัวประกอบจะกำหนดว่าเทรดหลักจำเป็นต้องทราบเกี่ยวกับเหตุการณ์หรือไม่
4. ส่งเหตุการณ์ไปยังเทรดหลัก หากจำเป็น
5. เทรดหลักจะเริ่มการทำงานของ Listener เหตุการณ์ input (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 #two ในแท็บที่ 1

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

สั่งกลับบ้าน

จึงอาจต้องใช้เวลานานในการจดจำและเข้าใจวิธีการทำงานของการแสดงภาพ

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

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

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

---

ภาพโดย Una Kravets