เวอร์ชัน Windows ของ Zed ซึ่งเป็นโปรแกรมแก้ไขโค้ดที่เน้นประสิทธิภาพที่ได้รับการรอคอยอย่างมาก ได้เผชิญกับความท้าทายทางเทคนิคที่สำคัญซึ่งเน้นย้ำถึงความซับซ้อนของการพัฒนาข้ามแพลตฟอร์ม แม้ว่าทีมจะมีความคืบหน้าอย่างมากด้วยวิศวกร 4 คนที่ทำงานเต็มเวลาในการพอร์ตเป็นเวลา 6 สัปดาห์ แต่การเดินทางนี้ได้เผยให้เห็นความแตกต่างพื้นฐานในการที่ Windows จัดการกราฟิก ระบบไฟล์ และการดำเนินการของระบบเมื่อเปรียบเทียบกับ macOS และ Linux
การปรับปรุงแบ็กเอนด์กราฟิกใหญ่จุดประกายการอภิปรายของนักพัฒนา
ความท้าทายที่สำคัญที่สุดมาจากการพึ่งพา Vulkan graphics API ในตอนแรกของ Zed ซึ่งทำให้เกิดปัญหาความเข้ากันได้บนเครื่อง Windows หลายเครื่อง ทีมค้นพบว่าการใช้ dynamic rendering extension ของ Vulkan 1.3 นั้นมีความทะเยอทะยานเกินไปสำหรับความเข้ากันได้อย่างกว้างขวาง สิ่งนี้บังคับให้พวกเขาสร้างแบ็กเอนด์การเรนเดอร์ DirectX 11 ใหม่ทั้งหมด พร้อมกับการใช้งาน HLSL shader เพื่อเสริม MSL ( macOS ) และ WGSL ( Vulkan ) เวอร์ชันที่มีอยู่
การปรับปรุงกราฟิกขยายไปเกินกว่าแค่การเปลี่ยน API ทีมต้องละทิ้ง Direct2D สำหรับการเรนเดอร์ข้อความเพราะมันขัดแย้งกับ RenderDoc ซึ่งเป็นเครื่องมือดีบักที่สำคัญสำหรับการพัฒนากราฟิกบน Windows พวกเขาเปลี่ยนไปใช้ DirectWrite สำหรับ glyph rasterization ซึ่งจริงๆ แล้วช่วยแก้ไขบั๊กที่มีอยู่เกี่ยวกับขอบเขตตัวอักษรและปัญหา clipping
หมายเหตุ: Vulkan เป็น graphics API สมัยใหม่ที่ให้การเข้าถึงระดับต่ำไปยังฮาร์ดแวร์ GPU ในขณะที่ DirectX 11 เป็น graphics API ที่จัดตั้งขึ้นของ Microsoft ที่รับประกันว่าจะทำงานบน Windows 7 และเวอร์ชันที่ใหม่กว่า
ความท้าทายทางเทคนิคที่พบ:
- Graphics API: เปลี่ยนจาก Vulkan 1.3 ไปใช้ DirectX 11 เพื่อความเข้ากันได้ที่กว้างขึ้น
- Shader Languages: ขณะนี้ดูแลรักษาการใช้งานสามแบบ (MSL, WGSL, HLSL)
- Text Rendering: เปลี่ยนจาก Direct2D ไปใช้ DirectWrite เพื่อความเข้ากันได้ในการดีบัก
- Memory Usage: แก้ไขปัญหาการใช้งาน VRAM ที่ไม่มีประสิทธิภาพในการเรนเดอร์เส้นทางด้วยการปรับปรุง MSAA
- Auto-Updates: สร้างไบนารีช่วยเหลือเฉพาะสำหรับข้อจำกัดของระบบไฟล์ Windows
- Crash Reporting: ใช้งาน server-side symbolication โดยใช้ไฟล์ minidump
 |
|---|
| ภาพนี้เน้นย้ำถึงความท้าทายที่ทีมพัฒนา Zed เผชิญเนื่องจากปัญหาความเข้ากันได้ของกราฟิกส์ในระหว่างการพอร์ตไปยัง Windows |
ปัญหาการจัดการหน่วยความจำเผยให้เห็นความแตกต่างของแพลตฟอร์ม
ปัญหาสำคัญเกิดขึ้นเมื่อสมาชิกในทีมเริ่มใช้ Zed เป็นโปรแกรมหลักในชีวิตประจำวันบน Windows - การแครชบ่อยครั้งเนื่องจากความล้มเหลวในการจัดสรรหน่วยความจำ GPU ปัญหานี้มองไม่เห็นบน macOS เพราะ Mac รุ่นล่าสุดใช้สถาปัตยกรรมหน่วยความจำแบบรวม ซึ่ง RAM ของระบบและหน่วยความจำกราฟิกใช้ร่วมกัน ระบบ Windows และ Linux มักจะมีหน่วยความจำกราฟิกแยกต่างหากที่มีข้อจำกัดมากกว่า
วิธีแก้ไขมาจากแหล่งที่ไม่คาดคิด: ทีม Longbridge ที่ใช้ UI framework ของ Zed สำหรับแอปพลิเคชันของตนเอง พวกเขาระบุความไม่มีประสิทธิภาพในวิธีที่ Zed เรนเดอร์เส้นทาง (เส้นและเส้นโค้งที่ใช้สำหรับการเลือกและการไฮไลต์) แนวทางเดิมสร้างเทกซ์เจอร์ขนาดใหญ่หลายอันสำหรับ anti-aliasing ซึ่งใช้หน่วยความจำวิดีโอมากเกินไป การแก้ไขเกี่ยวข้องกับการวาดเส้นทางทั้งหมดไปยังเทกซ์เจอร์เดียว ลดการใช้หน่วยความจำในขณะที่ปรับปรุงประสิทธิภาพในทุกแพลตฟอร์ม
ชุมชนแบ่งออกเกี่ยวกับแนวทางการพัฒนาข้ามแพลตฟอร์ม
ความท้าทายทางเทคนิคได้จุดประกายการถกเถียงใหม่ภายในชุมชนนักพัฒนาเกี่ยวกับกลยุทธ์การพัฒนาข้ามแพลตฟอร์ม บางคนโต้แย้งว่าการสร้างชุดเครื่องมือที่กำหนดเองนำไปสู่ปัญหาประเภทนี้พอดี โดยแนะนำว่าเฟรมเวิร์กที่จัดตั้งขึ้นแล้วจะหลีกเลี่ยงปัญหาความเข้ากันได้ของกราฟิกได้ทั้งหมด
อย่างไรก็ตาม ผู้สนับสนุนโต้แย้งว่าแนวทางนี้ทำให้ Zed รู้สึกเป็นเนทีฟอย่างแท้จริงในแต่ละแพลตฟอร์มแทนที่จะส่งมอบโปรแกรมแก้ไขที่ช้าอีกตัวที่บรรจุเบราว์เซอร์ทั้งหมด ประโยชน์ด้านประสิทธิภาพของแนวทางที่กำหนดเองของพวกเขาเห็นได้ชัดในการใช้งานประจำวัน แม้ว่ากระบวนการพัฒนาจะซับซ้อนกว่า
นี่คือเหตุผลที่คุณไม่ควรสร้างชุดเครื่องมือข้ามแพลตฟอร์มของคุณเอง
การอภิปรายสะท้อนถึงความตึงเครียดที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ระหว่างการใช้ทางลัดกับเฟรมเวิร์กที่มีอยู่เทียบกับการสร้างโซลูชันที่ปรับให้เหมาะสมและเฉพาะแพลตฟอร์ม
งานที่เหลืออยู่:
- การปรับแต่งการกำหนดปุ่มลัดให้เข้ากับมาตรฐานของ Windows
- การเชื่อมต่อ SSH ที่รองรับความเข้ากันได้ของเส้นทางไฟล์ระหว่าง Windows/Linux
- การรองรับ WSL ( Windows Subsystem for Linux ) แบบเต็มรูปแบบ
- การแก้ไขมาตรฐานเส้นทางของ Extension
- การปรับปรุงประสิทธิภาพสำหรับ DirectX 11 backend ใหม่
ความท้าทายเฉพาะ Windows นอกเหนือจากกราฟิก
การพอร์ต Windows เผยให้เห็นอุปสรรคเฉพาะแพลตฟอร์มมากมายนอกเหนือจากการเรนเดอร์กราฟิก ตัวอัปเดตอัตโนมัติต้องการการออกแบบใหม่ทั้งหมดเพราะ Windows ป้องกันการเขียนทับไฟล์ปฏิบัติการขณะที่กำลังทำงาน ทีมสร้างตัวช่วยอัปเดตอัตโนมัติแยกต่างหากที่จัดการการดำเนินการไฟล์เมื่อ Zed ไม่ทำงาน
แม้แต่การรายงานแครชก็ต้องการการปรับปรุง การวิเคราะห์แครชของ Windows ต้องการไฟล์ PDB ที่มีขนาดใหญ่เกินไปที่จะส่งมาพร้อมกับตัวติดตั้ง ดังนั้นทีมจึงใช้งาน symbolication ฝั่งเซิร์ฟเวอร์ของไฟล์ minidump สำหรับผู้ใช้ที่เลือกเข้าร่วม
มองไปข้างหน้า ทีมยังคงเผชิญความท้าทายกับการผูกคีย์ (ผู้ใช้ Windows คาดหวังทางลัดแป้นพิมพ์ที่แตกต่างกัน) การรีโมท SSH (ข้อตกลงเส้นทางไฟล์ที่แตกต่างกัน) การรวม WSL ความเข้ากันได้ของส่วนขยาย และการปรับปรุงประสิทธิภาพสำหรับแบ็กเอนด์กราฟิกใหม่
การพอร์ต Zed Windows แสดงให้เห็นว่าความแตกต่างของแพลตฟอร์มลึกกว่าองค์ประกอบ UI ระดับผิวเผินมาก แม้ว่าความมุ่งมั่นของทีมต่อประสิทธิภาพเนทีฟจะน่าชื่นชม แต่หนี้ทางเทคนิคจากแนวทางที่กำหนดเองของพวกเขายังคงสะสมขึ้นเมื่อพวกเขาขยายไปยังแพลตฟอร์มใหม่