ต่อไปนี้คุณจะเห็นวิธีตั้งค่าคอมโพเนนต์คอมโพเนนต์ RenderingNG และวิธีที่ไปป์ไลน์การแสดงผลไหลผ่านองค์ประกอบเหล่านั้น
เริ่มที่ระดับสูงสุด งานในการแสดงภาพมีดังนี้
- แสดงเนื้อหาเป็นพิกเซลบนหน้าจอ
- ทำให้เอฟเฟกต์ภาพเคลื่อนไหวในเนื้อหาจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง
- เลื่อนเพื่อตอบสนองต่ออินพุต
- ป้อนเส้นทางไปยังตำแหน่งที่เหมาะสมอย่างมีประสิทธิภาพเพื่อให้สคริปต์ของนักพัฒนาซอฟต์แวร์และระบบย่อยอื่นๆ ตอบสนองได้
เนื้อหาที่จะแสดงคือโครงสร้างของเฟรมสำหรับแต่ละแท็บของเบราว์เซอร์ และอินเทอร์เฟซของเบราว์เซอร์ รวมถึงสตรีมเหตุการณ์การป้อนข้อมูลดิบจากหน้าจอสัมผัส เมาส์ แป้นพิมพ์ และอุปกรณ์ฮาร์ดแวร์อื่นๆ
แต่ละเฟรมประกอบด้วยข้อมูลต่อไปนี้
- สถานะ DOM
- CSS
- แคนวาส
- ทรัพยากรภายนอก เช่น รูปภาพ วิดีโอ แบบอักษร และ SVG
Frame คือเอกสาร HTML พร้อมด้วย URL ของเอกสาร หน้าเว็บที่โหลดในแท็บเบราว์เซอร์จะมีเฟรมระดับบนสุด เฟรมย่อยสำหรับ iframe แต่ละรายการรวมอยู่ในเอกสารระดับบนสุด และองค์ประกอบสืบทอด iframe ที่เกิดซ้ำ
เอฟเฟกต์ภาพคือการดําเนินการแบบกราฟิกที่ใช้กับบิตแมป เช่น เลื่อน การเปลี่ยนรูปแบบ คลิป ฟิลเตอร์ ความทึบแสง หรือการรวม
คอมโพเนนต์ของสถาปัตยกรรม
ใน RenderingNG งานเหล่านี้จะแบ่งออกเป็นขั้นตอนและคอมโพเนนต์โค้ดอย่างสมเหตุสมผล คอมโพเนนต์จะลงเอยด้วยกระบวนการของ CPU, เทรด และคอมโพเนนต์ย่อยต่างๆ ภายในเทรดเหล่านั้น แต่ละองค์ประกอบมีบทบาทสำคัญในการสร้างความน่าเชื่อถือ ประสิทธิภาพที่ปรับขนาดได้ และความสามารถในการขยายการใช้งานสำหรับเนื้อหาเว็บทั้งหมด
กำลังแสดงผลโครงสร้างไปป์ไลน์
การแสดงผลจะดำเนินการไปในไปป์ไลน์ โดยมีขั้นตอนและอาร์ติแฟกต์จำนวนมากสร้างขึ้นระหว่างทาง แต่ละขั้นจะแสดงโค้ดที่ทำงานที่กำหนดไว้อย่างดี 1 งานภายในการแสดงผล อาร์ติแฟกต์คือโครงสร้างข้อมูล ที่เป็นอินพุตหรือเอาต์พุตของขั้นตอน
ขั้นตอนต่างๆ มีดังนี้
- เคลื่อนไหว: เปลี่ยนรูปแบบที่คำนวณและกลายพันธุ์ต้นไม้พร็อพเพอร์ตี้เมื่อเวลาผ่านไปโดยอิงตามไทม์ไลน์การประกาศ
- รูปแบบ: ใช้ CSS กับ DOM และสร้างรูปแบบที่คำนวณ
- เลย์เอาต์: กำหนดขนาดและตำแหน่งขององค์ประกอบ DOM บนหน้าจอ และสร้างแผนผังส่วนย่อยที่เปลี่ยนแปลงไม่ได้
- การลงสีล่วงหน้า: คำนวณโครงสร้างพร็อพเพอร์ตี้และทำให้ไม่ถูกต้องรายการที่แสดงและชิ้นส่วนพื้นผิว GPU ที่มีอยู่ตามความเหมาะสม
- เลื่อน: อัปเดตออฟเซ็ตการเลื่อนของเอกสารและองค์ประกอบ DOM ที่เลื่อนได้ โดยการเปลี่ยนแปลงแผนผังคุณสมบัติ
- สี: คำนวณรายการแสดงผลที่อธิบายวิธีแรสเตอร์ชิ้นส่วนพื้นผิว GPU จาก DOM
- คอมมิต: คัดลอกแผนผังคุณสมบัติและรายการที่แสดงผลไปยังชุดข้อความของคอมโพสิเตอร์
- กำหนดเลเยอร์: แบ่งรายการที่แสดงเป็นรายการเลเยอร์แบบผสมสำหรับการแรสเตอร์และภาพเคลื่อนไหวอิสระ
- เวิร์กเล็ตแรสเตอร์ ถอดรหัส และระบายสี: เปลี่ยนรายการ Display, รูปภาพที่เข้ารหัส และโค้ดเวิร์กเล็ตการวาดภาพเป็นชิ้นส่วนพื้นผิว GPU ตามลำดับ
- เปิดใช้งาน: สร้างเฟรมคอมโพสิตที่แสดงวิธีวาดและจัดตำแหน่งชิ้นส่วน GPU ไปยังหน้าจอ พร้อมกับเอฟเฟกต์ภาพต่างๆ
- รวม: รวมเฟรมคอมโพสิเตอร์จากเฟรมคอมโพสิเตอร์ที่มองเห็นได้ทั้งหมดไว้ในเฟรมสำหรับคอมโพสิเตอร์ส่วนกลางเดียว
- วาด: เรียกใช้เฟรมคอมโพสิเตอร์แบบรวมบน 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 ข้อเกี่ยวกับการแสดงภาพ ขอย้ำอีกครั้งว่า
- แสดงผลเนื้อหาเป็นพิกเซลบนหน้าจอ
- เอฟเฟกต์ภาพเคลื่อนไหวในเนื้อหาจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง
- เลื่อนเพื่อตอบสนองต่ออินพุต
- กำหนดเส้นทางอินพุตไปยังตำแหน่งที่ถูกต้องอย่างมีประสิทธิภาพเพื่อให้สคริปต์ของนักพัฒนาซอฟต์แวร์และระบบย่อยอื่นๆ ตอบสนองได้
วิธีแสดงผล DOM ที่เปลี่ยนแปลงสำหรับแท็บ 1
- สคริปต์นักพัฒนาซอฟต์แวร์เปลี่ยน DOM ในกระบวนการแสดงผลสำหรับ foo.com
- ตัวแสดงผลการกะพริบจะบอกคอมโพสเซอร์ว่าจำเป็นต้องมีการแสดงภาพ
- เครื่องมือประกอบจะบอก Viz ว่าจำเป็นต้องแสดงผล
- Viz ส่งสัญญาณเมื่อเริ่มการแสดงภาพกลับไปยังเครื่องมือประมวลผลภาพ
- เครื่องมือประกอบจะส่งต่อสัญญาณเริ่มต้นไปยังโหมดแสดงภาพ Blink
- ตัวเรียกใช้ลูปเหตุการณ์ของเทรดหลักจะเรียกใช้วงจรการใช้งานเอกสาร
- โดยเทรดหลักจะส่งผลลัพธ์ไปยังเทรดคอมโพสิต
- ตัวเรียกใช้ลูปเหตุการณ์ของคอมโพสิเตอร์จะเรียกใช้วงจรการคอมโพสิต
- ระบบจะส่งงานแรสเตอร์ไปยัง Viz สำหรับแรสเตอร์ (มักจะมีงานเหล่านี้มากกว่า 1 งาน)
- เนื้อหา Viz แรสเตอร์บน GPU
- Viz รับทราบว่างานแรสเตอร์เสร็จสมบูรณ์แล้ว หมายเหตุ: Chromium มักไม่รอให้แรสเตอร์ทำงานเสร็จ และใช้สิ่งที่เรียกว่า โทเค็นการซิงค์ ที่ต้องได้รับการแก้ไขโดยงานแรสเตอร์ก่อนขั้นตอนที่ 15 จะทำงาน
- ระบบส่งเฟรมคอมโพสิเตอร์ไปยัง Viz
- Viz รวมเฟรมคอมโพสิเตอร์สำหรับกระบวนการแสดงผล foo.com, กระบวนการแสดงผล iframe bar.com และ UI ของเบราว์เซอร์
- Viz กำหนดเวลาเสมอ
- Viz วาดเฟรมคอมโพสิเตอร์แบบรวมไปยังหน้าจอ
วิธีทำให้การเปลี่ยนผ่านการเปลี่ยนรูปแบบ CSS เคลื่อนไหวในแท็บที่ 2
- เธรดคอมโพสิเตอร์สำหรับกระบวนการแสดงผล bar.com จะทำเครื่องหมายภาพเคลื่อนไหวในลูปเหตุการณ์ของ compositor โดยการกลายพันธุ์ต้นไม้พร็อพเพอร์ตี้ที่มีอยู่ จากนั้นจะเรียกใช้วงจรการทำงานของคอมโพสิตอีกครั้ง (อาจมีงานแรสเตอร์และการถอดรหัส แต่ไม่ได้แสดงไว้ในที่นี้)
- ระบบส่งเฟรมคอมโพสิเตอร์ไปยัง Viz
- Viz รวมเฟรมคอมโพสิเตอร์สำหรับกระบวนการแสดงผลของ foo.com, กระบวนการแสดงผล bar.com และ UI ของเบราว์เซอร์
- Viz กำหนดเวลาเสมอ
- Viz วาดเฟรมคอมโพสิเตอร์แบบรวมไปยังหน้าจอ
วิธีเลื่อนหน้าเว็บในแท็บที่ 3
- ลำดับของเหตุการณ์
input
(เมาส์ การสัมผัส หรือแป้นพิมพ์) มาที่กระบวนการของเบราว์เซอร์ - แต่ละเหตุการณ์จะถูกกำหนดเส้นทางไปยังเธรดประมวลผลการแสดงผลสำหรับกระบวนการแสดงผลของ baz.com
- ตัวประกอบจะกำหนดว่าเทรดหลักจำเป็นต้องทราบเกี่ยวกับเหตุการณ์หรือไม่
- ส่งเหตุการณ์ไปยังเทรดหลัก หากจำเป็น
- เทรดหลักจะเริ่มการทำงานของ Listener เหตุการณ์
input
(pointerdown
,touchstar
,pointermove
,touchmove
หรือwheel
) เพื่อดูว่า Listener จะเรียกใช้preventDefault
ในเหตุการณ์หรือไม่ - เทรดหลักจะแสดงว่ามีการเรียก
preventDefault
ไปยังเครื่องมือประมวลผลหรือไม่ - หากไม่เป็นเช่นนั้น ระบบจะส่งเหตุการณ์อินพุตกลับไปยังกระบวนการของเบราว์เซอร์
- กระบวนการของเบราว์เซอร์จะแปลงเป็นท่าทางสัมผัสการเลื่อนโดยรวมขั้นตอนดังกล่าวกับเหตุการณ์ล่าสุดอื่นๆ
- ระบบจะส่งท่าทางสัมผัสการเลื่อนไปยังเธรดประมวลผลการแสดงผลการประมวลผลของ baz.com อีกครั้ง
- ระบบจะใช้การเลื่อนในหน้านั้น และเธรดของตัวประกอบสำหรับกระบวนการแสดงผล bar.com จะทำเครื่องหมายภาพเคลื่อนไหวในลูปเหตุการณ์ของคอมโพสิเตอร์
จากนั้นจะกลายพันธุ์การเลื่อนออฟเซ็ตในแผนผังคุณสมบัติ และเรียกใช้วงจรของคอมโพสิตอีกครั้ง
นอกจากนี้ยังบอกให้ชุดข้อความหลักเริ่มเหตุการณ์
scroll
ด้วย (ไม่ได้แสดงที่นี่) - ระบบส่งเฟรมคอมโพสิเตอร์ไปยัง Viz
- Viz รวมเฟรมคอมโพสิเตอร์สำหรับกระบวนการแสดงผลของ foo.com, กระบวนการแสดงผล bar.com และ UI ของเบราว์เซอร์
- Viz กำหนดเวลาเสมอ
- Viz วาดเฟรมคอมโพสิเตอร์แบบรวมไปยังหน้าจอ
วิธีกำหนดเส้นทางเหตุการณ์ click
บนไฮเปอร์ลิงก์ใน iframe #two ในแท็บที่ 1
- เหตุการณ์
input
(เมาส์ การแตะ หรือแป้นพิมพ์) มาที่กระบวนการของเบราว์เซอร์ โดยจะทำการทดสอบ Hit โดยประมาณเพื่อระบุว่ากระบวนการแสดงผล iframe ของ bar.com ควรจะได้รับคลิก แล้วส่งไปที่นั่น - เทรดคอมโพสิเตอร์สำหรับ bar.com จะกำหนดเส้นทางเหตุการณ์
click
ไปยังเทรดหลักสำหรับ bar.com และกำหนดเวลาให้งานวนซ้ำเหตุการณ์การแสดงผลเพื่อประมวลผล - ตัวประมวลผลเหตุการณ์อินพุตสำหรับการทดสอบ Thread Hit หลักของ bar.com เพื่อดูว่าองค์ประกอบ DOM ใดใน iframe ถูกคลิก และทำให้เหตุการณ์
click
เริ่มทำงานเพื่อให้สคริปต์สังเกตการณ์ ไม่ได้ยินเสียงpreventDefault
ระบบจึงนำทางไปยังไฮเปอร์ลิงก์ - เมื่อโหลดหน้าปลายทางของไฮเปอร์ลิงก์ขึ้น สถานะใหม่จะแสดงผลโดยมีขั้นตอนคล้ายกับตัวอย่างก่อนหน้านี้ของ "การแสดงผล DOM ที่เปลี่ยนแปลง" (การเปลี่ยนแปลงที่เกิดขึ้นภายหลังไม่ปรากฏในที่นี้)
สั่งกลับบ้าน
จึงอาจต้องใช้เวลานานในการจดจำและเข้าใจวิธีการทำงานของการแสดงภาพ
สิ่งที่สำคัญที่สุดคือไปป์ไลน์การแสดงผลผ่านการแยกชิ้นส่วนอย่างละเอียดรอบคอบและความใส่ใจในรายละเอียดได้แยกออกเป็นคอมโพเนนต์ต่างๆ แบบเดี่ยวๆ จากนั้นระบบจะแยกคอมโพเนนต์เหล่านี้ตามกระบวนการและเทรดแบบโหลดพร้อมกันเพื่อเพิ่มประสิทธิภาพที่ปรับขนาดได้และโอกาสในการขยายการใช้งานให้ได้สูงสุด
คอมโพเนนต์แต่ละอย่างมีบทบาทสำคัญในการเพิ่มประสิทธิภาพและฟีเจอร์ของเว็บแอปสมัยใหม่
อ่านต่อไปเกี่ยวกับโครงสร้างข้อมูลสำคัญ ซึ่งมีความสำคัญพอๆ กับ RenderingNG ในองค์ประกอบโค้ด
ภาพโดย Una Kravets