เตรียมพร้อมสำหรับเนื้อหาเว็บรุ่นใหม่
ผมชื่อ Chris Harrelson เป็นหัวหน้าฝ่ายวิศวกรรม ด้านการแสดงภาพ (เปลี่ยน HTML และ CSS เป็นพิกเซล) ใน Blink ฉันทุ่มเทให้กับประสิทธิภาพการแสดงผลบนเว็บมานานกว่า 8 ปีแล้ว โดยมีเป้าหมายส่วนตัวที่จะทำทุกวิถีทางเพื่อให้การแสดง UX ที่ยอดเยี่ยมบนเว็บเร็วขึ้น ง่าย และน่าเชื่อถือยิ่งขึ้น เรายินดีอย่างยิ่งที่จะแจ้งให้คุณทราบถึงสิ่งที่เราได้ทำไปในช่วงนั้นในการสร้างสถาปัตยกรรมเครื่องมือแสดงผล Chromium แบบใหม่ที่ล้ำสมัย เพื่อให้บรรลุเป้าหมายนี้ผ่านความรักอันยิ่งใหญ่ และหวังว่าคุณจะสนุกกับการได้ฟังเกี่ยวกับเรื่องนี้
ในปี 2021 เราจะผ่านขั้นตอนส่วนใหญ่ในการออกแบบ สร้าง และจัดส่งสถาปัตยกรรมนี้ เราจะเรียกว่า RenderingNG เนื่องจากเป็นสถาปัตยกรรมการแสดงผลรุ่นใหม่ที่มีประสิทธิภาพสูงกว่าที่เคยมีมาอย่างมาก RenderingNG ดำเนินการมาอย่างน้อย 8 ปีแล้ว และแสดงถึงการทำงานร่วมกันของนักพัฒนาซอฟต์แวร์ Chromium จำนวนมาก ฟีเจอร์นี้ช่วยปลดล็อกศักยภาพจำนวนมากสำหรับเนื้อหาเว็บรุ่นใหม่ที่รวดเร็ว ลื่นไหล เชื่อถือได้ ปรับเปลี่ยนตามพื้นที่โฆษณา และโต้ตอบได้ และยังเป็นเกณฑ์พื้นฐานที่เราเชื่อว่าเป็นการกำหนดมาตรฐานขั้นต่ำใหม่สำหรับเครื่องมือแสดงผลเว็บทั้งหมดที่นักพัฒนาซอฟต์แวร์พึ่งพาได้
บล็อกโพสต์นี้เป็นข้อมูลแรกในชุด ซึ่งจะอธิบาย สิ่งที่เราสร้าง เหตุผลที่เราสร้าง และวิธีการทำงาน ในโพสต์แรกนี้ เราจะเริ่มต้นด้วย:
- เป้าหมายดาวเหนือของเรา
- พีระมิดแห่งความสำเร็จ: หลักการที่เป็นแนวทางในการทำงานของเรา และตัวอย่างของหลักการเหล่านั้นในทางปฏิบัติ
- ฟีเจอร์และความสามารถของ RenderingNG ทำให้เป็นจริงได้
- ภาพรวมระดับสูงเกี่ยวกับองค์ประกอบหลักของโปรเจ็กต์ RenderingNG
ดาวเหนือ
เป้าหมายของดาวเหนือที่สร้างแรงจูงใจ RenderingNG คือการใช้งานเครื่องมือเบราว์เซอร์ และความหลากหลายของ API การแสดงผล ไม่ควรเป็นปัจจัยจำกัดของ UX บนเว็บ
คุณไม่จำเป็นต้องกังวลเกี่ยวกับข้อบกพร่องของเบราว์เซอร์ที่ทำให้ฟีเจอร์ไม่น่าเชื่อถือ หรือทำให้การแสดงผลของเว็บไซต์เสียหาย
ไม่ควรมีหน้าผาการแสดงลึกลับ และคุณจะไม่ต้องแก้ปัญหาด้วยการพลาดฟีเจอร์ในตัว
แค่นี้ก็ใช้งานได้แล้ว
ผมเชื่อว่า RenderingNG เป็นก้าวสำคัญสู่เป้าหมายดาวเหนือนี้ ก่อนที่จะใช้ RenderingNG เราสามารถเพิ่มฟีเจอร์การแสดงผลและปรับปรุงประสิทธิภาพได้ แต่ก็พบปัญหาในการทำให้ฟีเจอร์เหล่านั้นน่าเชื่อถือสำหรับนักพัฒนาซอฟต์แวร์ และก็มีอุปสรรคหลายอย่างด้านประสิทธิภาพ ตอนนี้เรามีสถาปัตยกรรมที่ขจัดปัญหาเหล่านั้นอย่างเป็นระบบ และยังเลิกบล็อกฟีเจอร์ขั้นสูงที่ไม่เคยคิดว่าเป็นไปได้มาก่อนด้วย ดังนี้
- มีฟีเจอร์หลักที่แข็งแกร่งทั้งในแพลตฟอร์ม อุปกรณ์ และระบบปฏิบัติการต่างๆ
- มีประสิทธิภาพที่คาดการณ์ได้และเชื่อถือได้
- เพิ่มการใช้งานความสามารถของฮาร์ดแวร์ให้ได้มากที่สุด (แกน, GPU, ความละเอียดหน้าจอ, อัตราการรีเฟรช, Raster API ระดับต่ำ)
- ทำงานเฉพาะที่จำเป็นต่อการแสดงเนื้อหาที่มองเห็นได้
- มีการสนับสนุนในตัวสำหรับการออกแบบภาพ ภาพเคลื่อนไหว และการออกแบบการโต้ตอบทั่วไป
- มี API สำหรับนักพัฒนาแอปเพื่อให้จัดการค่าใช้จ่ายในการแสดงผลได้อย่างง่ายดาย
- ระบุจุดขยายไปป์ไลน์สำหรับการแสดงผลสำหรับส่วนเสริมของนักพัฒนาซอฟต์แวร์
- เพิ่มประสิทธิภาพเนื้อหาทั้งหมด ได้แก่ HTML, CSS, 2D Canvas, 3D Canvas, รูปภาพ, วิดีโอ และแบบอักษร
การเปรียบเทียบกับเครื่องมือแสดงผลเบราว์เซอร์อื่นๆ
Gecko และ Webkit ยังใช้ฟีเจอร์ทางสถาปัตยกรรมส่วนใหญ่แบบเดียวกับที่อธิบายไว้ในบล็อกโพสต์เหล่านี้ และในบางกรณียังเพิ่มฟีเจอร์ดังกล่าวก่อน Chromium ด้วย ซึ่งดีมากๆ เลย แม้ว่าเบราว์เซอร์ตัวใดตัวหนึ่งที่เร็วและเสถียรขึ้นก็เป็นปัจจัยสำคัญที่ควรเฉลิมฉลองและส่งผลอย่างแท้จริง แต่เป้าหมายสูงสุดคือการพัฒนาพื้นฐานสำหรับเบราว์เซอร์ทุกชนิด เพื่อให้นักพัฒนาซอฟต์แวร์สามารถใช้เบราว์เซอร์พื้นฐานได้
พีระมิดแห่งความสำเร็จ
ปรัชญาของผมคือ ความสำเร็จเริ่มจากการมีความน่าเชื่อถือก่อน แล้วค่อยขยายประสิทธิภาพที่รองรับการปรับขนาด และสุดท้ายคือการขยายการใช้งานได้
เช่นเดียวกับพีระมิดในชีวิตจริง แต่ละระดับมีรากฐานที่มั่นคงสำหรับระดับที่เหนือกว่า
ความน่าเชื่อถือ
หากประสบการณ์ของผู้ใช้ที่สมบูรณ์และซับซ้อนนั้นเป็นไปได้ได้ สิ่งแรกที่เราต้องการคือแพลตฟอร์มที่แข็งแกร่ง ฟีเจอร์หลักและรากฐานต้องทำงานอย่างถูกต้อง และต้องทำงานอย่างต่อเนื่อง สิ่งที่สำคัญก็คือฟีเจอร์เหล่านั้นสามารถเขียนออกมาได้ดีและไม่มีการทำงานที่แปลกใหม่หรือมีข้อบกพร่องใดๆ
ด้วยเหตุนี้ ความเสถียรจึงเป็นส่วนสำคัญที่สุดอย่างหนึ่งของ RenderingNG ความเสถียรคือผลลัพธ์ของการทดสอบที่ดี ลูปความคิดเห็นที่มีคุณภาพ เมตริก และรูปแบบการออกแบบซอฟต์แวร์
เพื่อให้ผมคิดว่าความเสถียรสำคัญแค่ไหน เราใช้เวลาส่วนใหญ่ในช่วง 8 ปีที่ผ่านมาเพื่อพูดถึงส่วนนี้เท่านั้น อันดับแรก เราได้สร้างความรู้เกี่ยวกับระบบอย่างลึกซึ้ง การเรียนรู้จากรายงานข้อบกพร่องที่มีจุดอ่อนและจุดที่ต้องแก้ไข จัดการกับการทดสอบที่ครอบคลุม และเข้าใจความต้องการด้านประสิทธิภาพของเว็บไซต์และข้อจำกัดด้านประสิทธิภาพของ Chromium จากนั้น เราค่อยๆ ออกแบบและเปิดตัวรูปแบบการออกแบบและโครงสร้างข้อมูลที่สำคัญ เราพร้อมที่จะเพิ่มรูปแบบพื้นฐานรุ่นถัดไปอย่างแท้จริงสำหรับการออกแบบที่ตอบสนองตามอุปกรณ์ ความสามารถในการปรับขนาด และการปรับแต่งการแสดงผล
แต่ไม่ได้หมายความว่าเรายังไม่มีการปรับปรุงอะไรเลยใน Chromium แต่จริงๆ แล้วตรงกันข้ามเลย ในช่วงหลายปีที่ผ่านมา ความน่าเชื่อถือและประสิทธิภาพเพิ่มขึ้นอย่างต่อเนื่องและยั่งยืน เมื่อเราปรับเปลี่ยนโครงสร้างและเปิดตัวการปรับปรุงทีละรายการไปทีละขั้น
การทดสอบและเมตริก
ในช่วง 8 ปีที่ผ่านมา เราได้เพิ่มการทดสอบหน่วย ประสิทธิภาพ และการผสานรวมหลายหมื่นเครื่อง นอกจากนี้ เราได้พัฒนาเมตริกที่ครอบคลุมสำหรับวัดพฤติกรรมการแสดงผลของ Chromium ในการทดสอบในท้องถิ่น ในการเปรียบเทียบประสิทธิภาพ และข้อมูลจริงในเว็บไซต์จริงกับผู้ใช้และอุปกรณ์จริง
อย่างไรก็ตาม ไม่ว่า RenderingNG (หรือเครื่องมือแสดงผลของเบราว์เซอร์อื่นในกรณีนั้น) จะดีเยี่ยมเพียงใด การพัฒนาเว็บจะยังคงไม่ง่ายนักหากยังมีข้อบกพร่องหรือลักษณะการทำงานที่แตกต่างกันในแต่ละเบราว์เซอร์ จึงได้นำการทดสอบแพลตฟอร์มเว็บมาใช้ให้เกิดประโยชน์สูงสุดเพื่อแก้ไขปัญหานี้ การทดสอบแต่ละครั้งนี้จะยืนยันรูปแบบการใช้งานแพลตฟอร์มเว็บที่เบราว์เซอร์ทั้งหมดควรมุ่งหวังให้ผ่าน นอกจากนี้ เรายังติดตามเมตริกอย่างใกล้ชิดเพื่อผ่านการทดสอบเพิ่มเติมเมื่อเวลาผ่านไปและการเพิ่มความเข้ากันได้หลัก
การทดสอบแพลตฟอร์มเว็บเป็นความพยายามในการทำงานร่วมกัน ตัวอย่างเช่น วิศวกร Chromium ได้เพิ่มการทดสอบ WPT ทั้งหมดราว 10% สำหรับฟีเจอร์ของ CSS ส่วนผู้ให้บริการเบราว์เซอร์อื่นๆ, ผู้ร่วมให้ข้อมูลอิสระ และผู้เขียนข้อกำหนดจะเป็นผู้สนับสนุนส่วนที่เหลือ การพัฒนาให้การทำงานร่วมกันระหว่างเว็บเป็นเรื่องที่ต้องอาศัยความร่วมมือ
รูปแบบการออกแบบซอฟต์แวร์ที่ดี
ในทางกลับกัน การมอบซอฟต์แวร์ที่มีคุณภาพที่เชื่อถือได้ จะง่ายขึ้นมากหากโค้ดเข้าใจได้ง่าย และออกแบบมาในลักษณะที่ลดโอกาสในการเกิดข้อบกพร่องให้เหลือน้อยที่สุด เราจะบอกอะไรได้มากมายเกี่ยวกับการออกแบบซอฟต์แวร์ของ RenderingNG ในบล็อกโพสต์ต่อๆ ไป
ประสิทธิภาพที่รองรับการปรับขนาด
การบรรลุเป้าหมายด้านประสิทธิภาพที่ดีเยี่ยมในทุกมิติของความเร็ว หน่วยความจำ และการใช้พลังงานนั้นคือแง่มุมที่สำคัญที่สุดของ RenderingNG เราต้องการให้การโต้ตอบกับทุกเว็บไซต์เป็นไปอย่างราบรื่นและตอบสนองดี แต่ก็อย่าลดความเสถียรของอุปกรณ์ไป
แต่เราไม่เพียงต้องการประสิทธิภาพเท่านั้น เราต้องการประสิทธิภาพที่รองรับการปรับขนาด ซึ่งเป็นสถาปัตยกรรมที่ทำงานได้ดีและเชื่อถือได้ในอุปกรณ์ระดับล่างและระดับไฮเอนด์ และข้ามแพลตฟอร์มระบบปฏิบัติการ ผมเรียกสิ่งนี้ว่าการขยายใหญ่ การใช้ประโยชน์จากทุกสิ่งที่อุปกรณ์ฮาร์ดแวร์สามารถทำได้ และลดขนาดลง เพื่อเพิ่มประสิทธิภาพสูงสุดและลดความต้องการในระบบเมื่อจำเป็น
ในการไปถึงจุดนั้น เราต้องใช้ประโยชน์จากการแคช การแยกประสิทธิภาพ และการเร่งฮาร์ดแวร์ GPU ให้ได้มากที่สุด ลองพิจารณาแต่ละอย่างไป และเพื่อให้เกิดเป็นรูปธรรม เรามาลองพิจารณากันว่าการโต้ตอบแต่ละรายการมีส่วนต่อประสิทธิภาพของการโต้ตอบที่สำคัญมากๆ เพียงครั้งเดียวในหน้าเว็บ ซึ่งก็คือการเลื่อนหน้าเว็บ
การแคช
ในแพลตฟอร์ม UI เชิงโต้ตอบแบบไดนามิก เช่น เว็บ การแคชเป็นวิธีเดียวที่สำคัญที่สุดในการปรับปรุงประสิทธิภาพได้อย่างมาก การแคชประเภทที่เป็นที่รู้จักมากที่สุดในเบราว์เซอร์คือแคช HTTP แต่การแสดงผลก็มีแคชจำนวนมากเช่นกัน แคชที่สำคัญที่สุดสำหรับการเลื่อนคือพื้นผิว GPU และรายการการแสดงผลที่แคชไว้ ซึ่งช่วยให้การเลื่อนเป็นไปอย่างรวดเร็วมากขณะที่ลดการใช้พลังงานแบตเตอรี่และทำงานได้ดีในอุปกรณ์หลากหลายประเภท
การแคชช่วยให้แบตเตอรี่ใช้งานได้ยาวนานขึ้นและอัตราเฟรมของภาพเคลื่อนไหวสำหรับการเลื่อน แต่สิ่งที่สำคัญยิ่งกว่าคือการเลิกบล็อกการแยกประสิทธิภาพออกจากเทรดหลัก
การแยกประสิทธิภาพ
สำหรับคอมพิวเตอร์เดสก์ท็อปสมัยใหม่ คุณไม่จำเป็นต้องกังวลว่าแอปพลิเคชันพื้นหลังจะทำให้แอปพลิเคชันที่คุณกำลังทำงานทำงานช้าลง นั่นเป็นเพราะการทำงานหลายอย่างพร้อมกันแบบเชิงรุก ซึ่งถือเป็นรูปแบบหนึ่งของการแยกประสิทธิภาพ โดยการทำให้แน่ใจว่างานที่แยกจากกันจะไม่ทำให้กันและกันทำงานช้าลง
ตัวอย่างที่ดีที่สุดของการแยกประสิทธิภาพในเว็บคือการเลื่อน แม้แต่ในเว็บไซต์ที่มี JavaScript ช้าจำนวนมาก การเลื่อนก็ทำได้อย่างราบรื่นมาก เพราะเป็นการดำเนินการในเทรดอื่นที่ไม่จำเป็นต้องใช้ JavaScript และเทรดเลย์เอาต์ เราทุ่มเทอย่างหนักใน RenderingNG เพื่อให้มั่นใจว่าการเลื่อนที่เป็นไปได้ทั้งหมดเป็นแบบชุดข้อความ ผ่านการแคชที่มีประสิทธิภาพมากกว่าแค่รายการการแสดงผลในสถานการณ์ที่ซับซ้อนมากขึ้น ตัวอย่างเช่น โค้ดสำหรับแสดงถึงองค์ประกอบที่มีตำแหน่งคงที่และมีตำแหน่งคงที่ Listener เหตุการณ์แบบแพสซีฟ และการแสดงผลข้อความคุณภาพสูง
การเร่ง GPU
GPU ช่วยให้การสร้างพิกเซลและการวาดไปยังหน้าจอเร็วขึ้นมาก ในหลายๆ กรณี คุณสามารถวาดทุกพิกเซลควบคู่ไปกับพิกเซลอื่นๆ ได้ ส่งผลให้มีความเร็วเพิ่มขึ้นอย่างมาก องค์ประกอบสำคัญของ RenderingNG คือแรสเตอร์ GPU และวาดได้ทุกที่ ซึ่งจะใช้ GPU ในทุกแพลตฟอร์มและอุปกรณ์ทั้งหมดเพื่อเร่งการแสดงผลและการเคลื่อนไหวของเนื้อหาเว็บให้เร็วขึ้น ซึ่งสำคัญมากโดยเฉพาะในอุปกรณ์ระดับล่างหรืออุปกรณ์ระดับไฮเอนด์มาก ซึ่งมักจะมี GPU ความสามารถมากกว่าส่วนอื่นๆ ของอุปกรณ์มาก
ความสามารถในการขยายตัว: เครื่องมือที่เหมาะสมสำหรับงาน
เมื่อเรามีความน่าเชื่อถือและรองรับการปรับขนาด ตอนนี้เราก็พร้อมแล้วที่จะพัฒนาเครื่องมือจำนวนมากที่จะช่วยให้นักพัฒนาซอฟต์แวร์ขยายส่วนต่างๆ ในตัวของ HTML, CSS และ Canvas ในรูปแบบที่ไม่ลดทอนประสิทธิภาพและความเชื่อถือได้ที่ได้มาอย่างสิ้นเชิง
ซึ่งรวมถึง API ในตัวและ API ที่เปิด JavaScript สำหรับ Use Case ขั้นสูงของการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ การแสดงผลแบบโปรเกรสซีฟ ความราบรื่นและการตอบสนองอย่างรวดเร็ว และการแสดงผลแบบชุดข้อความ
API เว็บแบบเปิดต่อไปนี้ซึ่งได้รับการสนับสนุนจาก Chromium สร้างขึ้นจาก RenderingNG และก่อนหน้านี้มองว่าเป็นไปไม่ได้
ทั้งหมดนี้พัฒนาขึ้นด้วยข้อกำหนดที่เปิดกว้างและร่วมมือกับพาร์ทเนอร์เว็บแบบเปิด ซึ่งเป็นวิศวกรในเบราว์เซอร์ ผู้เชี่ยวชาญ และนักพัฒนาเว็บอื่นๆ ในบล็อกโพสต์ต่อๆ ไป เราจะเจาะลึกรายละเอียดของบทความเหล่านี้และอธิบายว่า RenderingNG ทำงานได้อย่างไร
- การมองเห็นเนื้อหา: ช่วยให้เว็บไซต์หลีกเลี่ยงการแสดงผลเนื้อหานอกจอภาพได้โดยง่าย และแคชการแสดงผลสำหรับมุมมองแอปพลิเคชันหน้าเว็บเดียวที่ไม่ได้แสดงในปัจจุบัน
- OffscreenCanvas: รองรับการแสดงผล Canvas (ทั้ง 2D Canvas API และ WebGL) ในเทรดของตัวเองเพื่อประสิทธิภาพที่ยอดเยี่ยมและเชื่อถือได้ โปรเจ็กต์นี้ยังเป็นเป้าหมายสำคัญของเว็บอีก 1 รายการ เพราะเป็น API ของเว็บแรกที่ช่วยให้ JavaScript (หรือ WebAssembly!) แสดงผลเอกสารหน้าเว็บเดียวจากชุดข้อความหลายรายการได้
- คำค้นหาคอนเทนเนอร์: ช่วยให้คอมโพเนนต์เดียวสามารถจัดองค์ประกอบเองตามขนาดหน้าจอ ซึ่งช่วยเลิกบล็อกทั้งจักรวาลของคอมโพเนนต์ที่นำไปใช้งานได้ทันที (ปัจจุบันเป็นการใช้งานที่อยู่ระหว่างการทดสอบ)
- การแยกต้นทาง: อนุญาตให้เว็บไซต์เลือกใช้การแยกประสิทธิภาพระหว่าง iframe ได้มากขึ้น
- เวิร์กเลตสีนอกเทรด: ช่วยให้นักพัฒนาซอฟต์แวร์ขยายวิธีทาสีองค์ประกอบด้วยโค้ดที่ทำงานบนเทรดคอมโพสิเตอร์
นอกจาก API เว็บอย่างชัดแจ้งแล้ว RenderingNG ช่วยให้เราจัดส่ง "ฟีเจอร์อัตโนมัติ" ที่สำคัญหลายอย่าง ซึ่งเป็นประโยชน์ต่อทุกเว็บไซต์ ดังนี้
- การแยกเว็บไซต์: ใส่ iframe แบบข้ามต้นทางในกระบวนการของ CPU ต่างๆ เพื่อให้แยกประสิทธิภาพและความปลอดภัยที่ดียิ่งขึ้น
- Vulkan, D3D12 และ Metal: ใช้ประโยชน์จาก API ระดับล่างที่ใช้ GPU มีประสิทธิภาพมากกว่า OpenGL
- ภาพเคลื่อนไหวแบบผสมเพิ่มเติม: SVG, สีพื้นหลัง
ฟีเจอร์ที่กำลังจะเปิดตัวในเร็วๆ นี้ซึ่งเราจะเลิกบล็อกโดย RenderingNG มีดังนี้
- ภาพเคลื่อนไหวที่ลิงก์การเลื่อน
- DOM ที่ซ่อน แต่ค้นหาและเข้าถึงได้
- การเปลี่ยนองค์ประกอบที่แชร์
- เลย์เอาต์ที่กำหนดเอง
- การประกอบคอมโพเนนต์นอกเธรดหลัก การแยกสาย Thread และการประกอบภาพ
โปรเจ็กต์สำคัญที่ประกอบกันเป็น RenderingNG
ด้านล่างนี้เป็นรายการโปรเจ็กต์หลักภายใน RenderingNG บล็อกโพสต์ที่ตามมาจะเจาะลึกเกี่ยวกับแต่ละรายการ
CompositeAfterPaint
ความแตกต่างที่ประกอบขึ้นจากรูปแบบ เลย์เอาต์ และสี ช่วยให้มีความเสถียรและประสิทธิภาพที่คาดการณ์ได้มากขึ้น เพิ่มอัตราการส่งข้อมูล และใช้หน่วยความจำน้อยลงโดยที่ไม่กระทบต่อประสิทธิภาพ ซึ่งเริ่มต้นในปี 2014 และจะเสร็จสิ้นในปีนี้
ปี | ความคืบหน้า |
---|---|
2015 | จัดส่งรายการที่แสดง |
2017 | การจัดส่งใหม่ที่ไม่ถูกต้อง |
2018 | ต้นไม้ใหญ่ในเรือ ส่วนที่ 1 |
2019 | ต้นไม้ใหญ่ในเรือ ตอนที่ 2 |
2021 | จัดส่งโครงการเสร็จสมบูรณ์แล้ว |
LayoutNG
การเขียนใหม่ตั้งแต่ต้นสำหรับอัลกอริทึมเลย์เอาต์ทั้งหมด เพื่อปรับปรุงความน่าเชื่อถือและประสิทธิภาพที่คาดการณ์ได้มากขึ้น ซึ่งเริ่มต้นในปี 2016 และวางแผนไว้ว่าจะเสร็จสิ้นในปีนี้
ปี | ความคืบหน้า |
---|---|
2019 | ขั้นตอนบล็อกเรือ |
2020 | ท่าเบ่งกล้าม การแก้ไข |
2021 | จัดส่งสินค้าอื่นๆ ทั้งหมด |
BlinkNG
การทำความสะอาดและการเปลี่ยนโครงสร้างภายในเครื่องมือแสดงผล Blink อย่างเป็นระบบโดยแยกออกเป็นช่วงต่างๆ ในไปป์ไลน์แบบแยกกันอย่างชัดเจน วิธีนี้จะช่วยให้การแคชดีขึ้น มีความน่าเชื่อถือสูงขึ้น และมีผู้เข้าร่วมอีกครั้งหรือแสดงผลล่าช้า เช่น การแสดงเนื้อหาและคำค้นหาของคอนเทนเนอร์ ซึ่งเริ่มต้นขึ้นในปี 2014 และได้รับการพัฒนาเพิ่มขึ้นอย่างต่อเนื่องนับตั้งแต่นั้นมา ซึ่งจะเสร็จสมบูรณ์ในปี 2021
การเร่งความเร็วของ GPU ในทุกที่
ความพยายามระยะยาวในการปล่อยแรสเตอร์ GPU, การวาด และภาพเคลื่อนไหวบนทุกแพลตฟอร์มตลอดเวลา การเร่งความเร็ว GPU ช่วยให้เนื้อหาส่วนใหญ่เร็วขึ้นอย่างมาก เพราะทุกๆ พิกเซลสามารถประมวลผลพร้อมกันได้ และยังเป็นวิธีที่มีประสิทธิภาพในการปรับปรุงประสิทธิภาพในอุปกรณ์ระดับล่าง ซึ่งมีแนวโน้มที่จะยังมี GPU อยู่ ซึ่งเริ่มต้นในปี 2014 และสร้างเสร็จในปี 2020
ปี | ความคืบหน้า |
---|---|
2014 | การรองรับ Canvas จัดส่งเนื้อหาแบบเลือกรับใน Android แล้ว |
2016 | จัดส่งใน Mac |
2017 | มีการใช้ GPU กับการดูหน้าเว็บ Android มากกว่า 60% |
2018 | จัดส่งบน Windows, ChromeOS และ Android Go |
2019 | การแรสเตอร์ GPU แบบเทรด |
2020 | ส่งเนื้อหา Android ที่เหลือ |
การเลื่อนชุดข้อความ ภาพเคลื่อนไหว และการถอดรหัส
ความพยายามระยะยาวในการย้ายภาพเคลื่อนไหวแบบเลื่อนทั้งหมด แบบไม่สร้างเลย์เอาต์ และการถอดรหัสรูปภาพออกจากเทรดหลัก ซึ่งเริ่มต้นในปี 2011 และยังคงดำเนินไปอย่างต่อเนื่อง
ปี | ความคืบหน้า |
---|---|
2011 | การรองรับการเลื่อนแบบชุดข้อความและภาพเคลื่อนไหวเบื้องต้น |
2015 | การบีบเลเยอร์ |
2016 | การเลื่อนรายการเพิ่มเติมสากล |
2017 | การถอดรหัสรูปภาพในเธรดคอมโพสิเตอร์ |
2018 | ภาพเคลื่อนไหวบนชุดข้อความของตัวจัดวางองค์ประกอบ |
2020 | ผสมตำแหน่งคงที่เสมอ |
2021 | ภาพเคลื่อนไหวการเปลี่ยนรูปแบบเปอร์เซ็นต์, ภาพเคลื่อนไหว SVG |
วิซ
กระบวนการแรสเตอร์และการวาดแบบรวมศูนย์สำหรับ Chromium ที่เพิ่มอัตราการส่งข้อมูล เพิ่มประสิทธิภาพหน่วยความจำ และเปิดโอกาสให้ใช้ความสามารถของฮาร์ดแวร์ให้เกิดประโยชน์สูงสุด นอกจากนี้ ยังมีประโยชน์อื่นๆ ที่นักพัฒนาเว็บจะมองไม่เห็น แต่ผู้ใช้จะมองเห็นได้อย่างมาก เช่น การเลิกบล็อกการแยกเว็บไซต์และการแยกไปป์ไลน์การแสดงผลออกจากการแสดงผล UI ของเบราว์เซอร์ ซึ่งเริ่มต้นในปี 2016 และจะแล้วเสร็จในปี 2021
ปี | ความคืบหน้า |
---|---|
2018 | OOP-R จัดส่งใน Android, Mac และ Windows |
2019 | จัดส่ง OOP-D แล้ว OOP-R จัดส่งได้ทุกที่ (ยกเว้น Canvas) SkiaRenderer จัดส่งใน Linux |
2020 | SkiaRenderer จัดส่งบน Windows และ Android Vulkan จัดส่งบน Android |
2021 | SkiaRenderer จะจัดส่งบน Mac (และ ChromeOS เร็วๆ นี้) |
คําจํากัดความของคําในแผนภูมิด้านบน
- OOP-D
- ตัวจัดวางองค์ประกอบ Display นอกกระบวนการ การรวมการแสดงผลเป็นกิจกรรมประเภทเดียวกับคอมโพเนนต์ของระบบปฏิบัติการ การไม่ประมวลผลหมายถึงการดำเนินการในกระบวนการ Viz แทนกระบวนการแสดงผลของหน้าเว็บหรือกระบวนการ UI ของเบราว์เซอร์
- OOP-R
- แรสเตอร์นอกกระบวนการ แรสเตอร์จะแปลงรายการที่แสดงเป็นพิกเซล หากอยู่นอกกระบวนการ หมายถึงการดำเนินการในกระบวนการ Viz แทนที่จะเป็นกระบวนการแสดงผลของหน้าเว็บ
- SkiaRenderer
- การใช้งานเครื่องมือจัดวางองค์ประกอบ Display ใหม่ที่รองรับการดำเนินการบน GPU API ต่างๆ ที่มีอยู่ เช่น Vulkan, D3D12 หรือ Metal
การแสดงผล Canvas แบบชุดข้อความและแบบเร่ง
เพราะเป็นโปรเจ็กต์ที่ใส่ชิ้นส่วนสถาปัตยกรรมที่ทำให้ OffscreenCanvas เป็นไปได้ ซึ่งเริ่มต้นในปี 2015 และจะเสร็จสิ้นในปี 2021
ปี | ความคืบหน้า |
---|---|
2018 | Ship OffscreenCanvas |
2019 | Ship ImageBitmapRenderingContext |
2021 | จัดส่ง OOP-R |
VideoNG
คือความพยายามระยะยาวในการเล่นวิดีโอบนเว็บที่มีประสิทธิภาพ เชื่อถือได้ และมีคุณภาพสูง
ปี | ความคืบหน้า |
---|---|
2014 | เปิดตัวเฟรมเวิร์กการแสดงผลที่อิงตาม Mojo |
2015 | จัดส่ง Project Butter และการวางซ้อนวิดีโอเพื่อให้แสดงผลวิดีโอราบรื่นยิ่งขึ้น |
2016 | จัดส่งไปป์ไลน์การถอดรหัสและการแสดงผลแบบรวมของ Android และเดสก์ท็อปแล้ว |
2017 | การแสดงภาพ HDR และวิดีโอที่มีการแก้สีแล้ว |
2018 | ไปป์ไลน์การถอดรหัสวิดีโอของ Mojo ที่จัดส่งแล้ว |
2019 | ไปป์ไลน์การแสดงภาพวิดีโอที่ใช้พื้นผิวที่จัดส่งแล้ว |
2021 | จัดส่งการรองรับการแสดงผลเนื้อหาที่มีการป้องกันแบบ 4K ใน ChromeOS แล้ว |
คําจํากัดความของคําในแผนภูมิด้านบน
- โมโจ
- ระบบย่อย IPC รุ่นใหม่สำหรับ Chromium
- แพลตฟอร์ม
- แนวคิดที่เป็นส่วนหนึ่งของการออกแบบโปรเจ็กต์ Viz
บทสรุป
เราตื่นเต้นมากกับอัตราการปรับปรุงการแสดงผลในเว็บและ Chromium และคาดว่าอัตราความเร็วจะยังเติบโตขึ้นเรื่อยๆ ในปีต่อๆ ไป เนื่องจากเราสามารถต่อยอดจาก RenderingNG ที่มั่นคง
โปรดรอติดตามโพสต์อื่นๆ ในอนาคตที่จะให้รายละเอียดเพิ่มเติมเกี่ยวกับสถาปัตยกรรมใหม่ วิธีการทำงาน และวิธีการทำงาน
รูปภาพอุปกรณ์โดย Eirik Solheim ใน Unsplash
ภาพโดย Una Kravets