Phiên bản Windows được mong đợi của Zed, một trình soạn thảo mã tập trung vào hiệu suất, đã gặp phải những thách thức kỹ thuật đáng kể làm nổi bật sự phức tạp của việc phát triển đa nền tảng. Trong khi nhóm đã đạt được tiến bộ đáng kể với bốn kỹ sư làm việc toàn thời gian trên phiên bản chuyển đổi trong sáu tuần, hành trình này đã tiết lộ những khác biệt cơ bản trong cách Windows xử lý đồ họa, hệ thống tệp và các hoạt động hệ thống so với macOS và Linux.
Đại tu backend đồ họa gây ra cuộc thảo luận của nhà phát triển
Thách thức lớn nhất đến từ việc Zed ban đầu dựa vào API đồ họa Vulkan, điều này gây ra các vấn đề tương thích trên nhiều máy Windows. Nhóm phát hiện rằng việc sử dụng tiện ích mở rộng dynamic rendering của Vulkan 1.3 quá tham vọng để có tính tương thích rộng rãi. Điều này buộc họ phải tạo ra một backend rendering DirectX 11 hoàn toàn mới, hoàn chỉnh với các triển khai shader HLSL để bổ sung cho các phiên bản MSL (macOS) và WGSL (Vulkan) hiện có.
Việc đại tu đồ họa mở rộng ra ngoài việc chỉ thay đổi API. Nhóm phải từ bỏ Direct2D cho việc render văn bản vì nó xung đột với RenderDoc, một công cụ debug quan trọng cho việc phát triển đồ họa Windows. Họ chuyển sang DirectWrite để rasterization glyph, điều này thực sự giúp sửa các lỗi hiện có với ranh giới ký tự và các vấn đề clipping.
Lưu ý: Vulkan là một API đồ họa hiện đại cung cấp quyền truy cập cấp thấp vào phần cứng GPU, trong khi DirectX 11 là API đồ họa đã được thiết lập của Microsoft được đảm bảo hoạt động trên Windows 7 và các phiên bản mới hơn.
Các thách thức kỹ thuật gặp phải:
- Graphics API: Chuyển từ Vulkan 1.3 sang DirectX 11 để có khả năng tương thích rộng rãi hơn
- Shader Languages: Hiện đang duy trì ba phiên bản triển khai ( MSL , WGSL , HLSL )
- Text Rendering: Chuyển từ Direct2D sang DirectWrite để tương thích với việc gỡ lỗi
- Memory Usage: Khắc phục các vấn đề không hiệu quả của VRAM trong việc render đường dẫn với tối ưu hóa MSAA
- Auto-Updates: Tạo ra tệp nhị phân hỗ trợ chuyên dụng cho các hạn chế hệ thống tệp Windows
- Crash Reporting: Triển khai symbolication phía máy chủ sử dụng các tệp minidump
 |
|---|
| Hình ảnh này làm nổi bật những thách thức mà đội ngũ phát triển Zed phải đối mặt do các vấn đề tương thích đồ họa trong quá trình chuyển đổi sang Windows |
Các vấn đề quản lý bộ nhớ phơi bày sự khác biệt nền tảng
Một vấn đề quan trọng xuất hiện khi các thành viên nhóm bắt đầu sử dụng Zed như trình điều khiển hàng ngày của họ trên Windows - các lỗi crash thường xuyên do lỗi phân bổ bộ nhớ GPU. Vấn đề này không thể thấy được trên macOS vì các máy Mac gần đây sử dụng kiến trúc bộ nhớ thống nhất, nơi RAM hệ thống và bộ nhớ đồ họa được chia sẻ. Các hệ thống Windows và Linux thường có bộ nhớ đồ họa riêng biệt, hạn chế hơn.
Giải pháp đến từ một nguồn bất ngờ: nhóm Longbridge, những người sử dụng framework UI của Zed cho các ứng dụng của riêng họ. Họ xác định sự không hiệu quả trong cách Zed render các đường dẫn (các đường và đường cong được sử dụng cho selections và highlights). Cách tiếp cận ban đầu tạo ra nhiều texture lớn cho anti-aliasing, tiêu thụ quá nhiều bộ nhớ video. Bản sửa lỗi liên quan đến việc vẽ tất cả các đường dẫn vào một texture duy nhất, giảm việc sử dụng bộ nhớ trong khi thực sự cải thiện hiệu suất trên tất cả các nền tảng.
Cộng đồng chia rẽ về cách tiếp cận phát triển đa nền tảng
Các thách thức kỹ thuật đã khơi lại các cuộc tranh luận trong cộng đồng nhà phát triển về các chiến lược phát triển đa nền tảng. Một số lập luận rằng việc xây dựng các toolkit tùy chỉnh dẫn đến chính xác những loại vấn đề này, gợi ý rằng các framework đã được thiết lập sẽ tránh được hoàn toàn các vấn đề tương thích đồ họa.
Tuy nhiên, những người ủng hộ phản bác rằng cách tiếp cận này cho phép Zed cảm thấy thực sự native trên mỗi nền tảng thay vì cung cấp một trình soạn thảo chậm khác đóng gói toàn bộ trình duyệt. Lợi ích hiệu suất của cách tiếp cận tùy chỉnh của họ rõ ràng trong việc sử dụng hàng ngày, ngay cả khi quá trình phát triển phức tạp hơn.
Đây là lý do tại sao bạn không tự tạo toolkit đa nền tảng của riêng mình.
Cuộc thảo luận phản ánh những căng thẳng rộng lớn hơn trong phát triển phần mềm giữa việc sử dụng các phím tắt với các framework hiện có so với việc xây dựng các giải pháp được tối ưu hóa, cụ thể cho từng nền tảng.
Các mục công việc còn lại:
- Điều chỉnh phím tắt theo quy ước của Windows
- Kết nối SSH từ xa với khả năng tương thích đường dẫn Windows/Linux
- Hỗ trợ toàn diện cho WSL ( Windows Subsystem for Linux )
- Sửa lỗi quy ước đường dẫn extension
- Tối ưu hóa hiệu suất cho backend DirectX 11 mới
Các thách thức cụ thể của Windows ngoài đồ họa
Phiên bản chuyển đổi Windows tiết lộ nhiều trở ngại cụ thể của nền tảng ngoài việc render đồ họa. Auto-updater yêu cầu thiết kế lại hoàn toàn vì Windows ngăn chặn việc ghi đè các tệp thực thi trong khi chúng đang chạy. Nhóm đã tạo ra một trình trợ giúp auto update riêng biệt xử lý các hoạt động tệp khi Zed không hoạt động.
Ngay cả việc báo cáo crash cũng cần được làm lại. Phân tích crash Windows yêu cầu các tệp PDB quá lớn để ship với trình cài đặt, vì vậy nhóm đã triển khai symbolication phía máy chủ của các tệp minidump cho những người dùng chọn tham gia.
Nhìn về phía trước, nhóm vẫn đối mặt với các thách thức về key bindings (người dùng Windows mong đợi các phím tắt khác nhau), SSH remoting (quy ước đường dẫn tệp khác nhau), tích hợp WSL, tương thích extension và tối ưu hóa hiệu suất cho backend đồ họa mới.
Phiên bản chuyển đổi Zed Windows minh họa cách các khác biệt nền tảng chạy sâu hơn nhiều so với các yếu tố UI cấp bề mặt. Trong khi cam kết của nhóm đối với hiệu suất native đáng ngưỡng mộ, nợ kỹ thuật từ cách tiếp cận tùy chỉnh của họ tiếp tục tích lũy khi họ mở rộng sang các nền tảng mới.
Tham khảo: Zed for Windows: What's Taking So Long?!