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

Chris Harrelson

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

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

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

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

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

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

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

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

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

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

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

วันที่

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

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

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

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

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

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

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

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

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

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

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

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

มีกระบวนการ Viz เพียงกระบวนการเดียวสำหรับ Chromium ทั้งหมด เนื่องจากมักจะมีเฉพาะ GPU และหน้าจอ 1 รายการที่จะดึงไป

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

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

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

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

ชุดข้อความ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ส่วนย่อยของแผนผังเฟรมในเครื่องเป็นคอมโพเนนต์ที่เชื่อมโยงกันซึ่งมีสีเดียวกันในแผนผังเฟรม รูปภาพมีแผนผังเฟรมเฉพาะที่ 4 แบบ แบ่งเป็น 2 แบบสำหรับเว็บไซต์ ก. ส่วน 1 ส่วนของเว็บไซต์ ข. และอีก 1 ต้นไม้สำหรับเว็บไซต์ ค. แผนผังเฟรมในเครื่องแต่ละเฟรมจะมีคอมโพเนนต์ตัวแสดงผล 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