Louvre
vre v2.13.0-1
Louvre เป็นไลบรารี C++ ประสิทธิภาพสูงที่ออกแบบมาเพื่อสร้างตัวแต่งเพลงของ Wayland โดยเน้นที่ความง่ายในการพัฒนา
การสร้างนักแต่งเพลงของ Wayland อาจเป็นงานที่น่ากังวล ซึ่งมักใช้เวลาหลายเดือนหรือหลายปีในการอุทิศตน งานที่ท้าทายนี้เกี่ยวข้องกับการเรียนรู้อินพุต Linux และ API กราฟิก การจัดการบัฟเฟอร์กราฟิก และการนำโปรโตคอล Wayland จำนวนมากและอินเทอร์เฟซที่เกี่ยวข้องไปใช้อย่างพิถีพิถัน
โชคดีที่พิพิธภัณฑ์ลูฟร์ทำให้กระบวนการที่ซับซ้อนนี้ง่ายขึ้นโดยจัดการงานระดับต่ำที่ซับซ้อนทั้งหมดในนามของคุณ มันยังให้วิธีเริ่มต้นในการจัดการโปรโตคอล ช่วยให้คุณสามารถมีตัวสร้างพื้นฐานแต่ใช้งานได้ตั้งแต่วันแรก และสำรวจและปรับแต่งฟังก์ชันการทำงานของมันอย่างต่อเนื่องเพื่อให้ตรงกับความต้องการของคุณอย่างแม่นยำ
ภายใน Louvre คุณมีความยืดหยุ่นในการใช้เชเดอร์/โปรแกรม OpenGL ES 2.0 ของคุณเอง ใช้คลาส LPainter สำหรับการเรนเดอร์ 2D พื้นฐาน หรือใช้ประโยชน์จากระบบ LScene และ LView ซึ่งจัดการความเสียหายของบัฟเฟอร์และยังสามารถจัดการเหตุการณ์อินพุตให้กับคุณได้ นอกจากนี้ คุณยังสามารถรวมแนวทางทั้งสามนี้เข้าด้วยกันได้ตามต้องการ
พิพิธภัณฑ์ลูฟร์มีการแสดงที่ยอดเยี่ยม เกณฑ์มาตรฐานที่ประกอบด้วยการเรนเดอร์ wl_subsurfaces ที่เคลื่อนไหวจำนวนมาก (ทึบแสงและโปร่งแสง) ซึ่งมีการทดสอบตัวประกอบตัวอย่างลูฟร์-เวสตัน-โคลน แสดงให้เห็นว่าลูฟร์สามารถรักษาอัตรา FPS สูงได้แม้ในสถานการณ์ที่ซับซ้อน นอกจากนี้ยังใช้ทรัพยากร CPU และ GPU น้อยกว่าโปรแกรมแต่งเพลงยอดนิยมอย่าง Weston และ Sway
| เครื่องจักร | MacBook Pro A1398 (Retina 15 นิ้ว กลางปี 2015) |
| ซีพียู | Intel Core i7-4770HQ @ 2.20GHz (สูงสุด 3.4GHz) พร้อมแคช L3 ที่ใช้ร่วมกัน 6MB |
| หน่วยความจำ | DDR3L ความเร็ว 1600MHz ขนาด 16GB |
| จีพียู | กราฟิก Intel Iris Pro - i915 (กราฟิก Intel) เวอร์ชัน 1.6.0 (20201103) |
| แสดง | จอแสดงผล Retina ขนาด 15 นิ้วพร้อมโหมดเดี่ยว 2880x1800@60Hz |
| ระบบปฏิบัติการ | Linux Mint 21 - Linux 5.15.0-86-ทั่วไป |
หากคุณสนใจในรายละเอียดเกี่ยวกับวิธีการทำงานของเกณฑ์มาตรฐานและต้องการลองด้วยตนเอง โปรดดูที่ลิงก์นี้
นี่คือกราฟที่แสดงผลการวัดประสิทธิภาพ โดยจะแสดง FPS เฉลี่ยของตัวประกอบแต่ละตัวที่เรนเดอร์พื้นผิวที่เคลื่อนไหว 1 ถึง 50 พื้นผิวโดยใช้การบัฟเฟอร์สองเท่าบนจอแสดงผล HiDPI
ผลลัพธ์การวัดประสิทธิภาพไม่ได้รับการอัปเดตตั้งแต่ปี 2023 และอาจไม่สะท้อนถึงประสิทธิภาพในปัจจุบันของผู้ประกอบที่ทดสอบอย่างแม่นยำ
ผู้แต่งเพลงของ Wayland ส่วนใหญ่ใช้เธรดเดียว ซึ่งจะทำให้ประสิทธิภาพการทำงานช้าลงอย่างมากเมื่อเรนเดอร์สถานการณ์ที่ซับซ้อน สาเหตุนี้เกิดจาก การซิงค์แนวตั้ง โดยที่ผู้แต่งต้องรอสองสามมิลลิวินาทีก่อนจึงจะสามารถสลับเฟรมบัฟเฟอร์ที่เพิ่งแสดงผลกับอันที่แสดงบนหน้าจอได้ ซึ่งทำเพื่อซิงโครไนซ์การสลับกับอัตรารีเฟรชของจอแสดงผล ( vblank ) และหลีกเลี่ยง เอฟเฟกต์การฉีกขาด เมื่อทำงานกับเธรดเดียว ผู้แต่งจะมี "เวลาตาย" ซึ่งทำให้ไม่สามารถประมวลผลและเรนเดอร์เนื้อหาได้ทันเวลาสำหรับเฟรมถัดไป นั่นเป็นเหตุผลว่าทำไมพวกเขาถึงข้าม vblank ทำให้อัตราการรีเฟรชลดลงครึ่งหนึ่ง (หรือมากกว่านั้น) เพื่อหลีกเลี่ยงปัญหานี้ พิพิธภัณฑ์ลูฟร์จึงทำงานร่วมกับหลายเธรด แต่ละเอาต์พุต (จอแสดงผล) เรนเดอร์เนื้อหาบนเธรดของตัวเอง ช่วยให้ผู้แต่งสามารถประมวลผลคำขอต่อไปและเรนเดอร์ไปยังเอาต์พุตอื่นในขณะที่เอาต์พุตหนึ่งกำลังรอ vblank วิธีนี้จะป้องกันไม่ให้ผู้แต่ง Louvre มี "เวลาตาย" และช่วยให้สามารถรักษาอัตราการรีเฟรชที่สูงได้
กราฟทางด้านซ้ายแสดงผลการใช้ CPU ดิบ ซึ่งอาจบ่งบอกว่าพิพิธภัณฑ์ลูฟร์ใช้ทรัพยากร CPU มากกว่า อย่างไรก็ตาม การเปรียบเทียบนี้ไม่ยุติธรรมเลย เนื่องจากอัตราการรีเฟรชของ Louvre เกือบสองเท่าของอัตราอื่นๆ (60 FPS เทียบกับ 30 FPS เฉลี่ย) เมื่อเราแบ่งการใช้ CPU ด้วยเฟรมต่อวินาที (FPS) ดังที่แสดงในกราฟทางด้านขวา จะเห็นได้ชัดว่าที่จริงแล้ว Louvre ใช้ทรัพยากร CPU น้อยกว่าเมื่อเทียบกับ FPS เมื่อเปรียบเทียบกับตัวประกอบอื่นๆ
เช่นเดียวกับการใช้ CPU เราจะสังเกตได้ว่า Louvre ใช้ทรัพยากร GPU น้อยกว่าเมื่อเทียบกับ FPS มากกว่าตัวประกอบอื่นๆ
