Breeze: Tại sao nó không có mặc định trong KDE 5?

Như chúng ta đã biết, KDE Next (hoặc KDE 5 tùy thích) đã được phát hành ổn định cách đây vài ngày và trong số các tính năng mới mà nó mang lại, một trong những tính năng được nhắc đến nhiều nhất là Artwork mới có tên Breeze.

Những ai đã dùng thử phiên bản mới này hoặc đã xem video, có thể nhận thấy rằng trong trường hợp của trình trang trí cửa sổ, cái mặc định là Oxygen chứ không phải Breeze. Cũng Martin Gräßlin giải thích cho chúng tôi trên blog của anh ấy lý do cho quyết định này là gì.

Vì bài viết bằng tiếng Anh, tôi sẽ cố gắng cung cấp cho bạn ý tưởng cơ bản về điều này.

Tại sao Breeze không đến theo mặc định?

Tôi bắt đầu với phần giải thích về cách trang trí cửa sổ hoạt động trong KWin 4. KWin là cái gọi là cách nuôi dạy con cái của những người quản lý cửa sổ. Điều này có nghĩa là cửa sổ do X11 quản lý được đưa vào một cửa sổ X11 khác cung cấp khung cửa sổ. Tại KWin, chúng tôi sử dụng QWidget cho khung cửa sổ. Do đó, chúng tôi cũng bị hạn chế đối với những gì QWidget cung cấp cho chúng tôi ... Giải pháp của chúng tôi là chặn tất cả các sự kiện vẽ tranh trang trí trong QWidget và ngăn chặn nó, kích hoạt bản vẽ lại của nhà soạn nhạc và trong bước kết xuất đảm bảo trang trí của một hình ảnh tạm thời sau đó được sao chép thành một kết cấu.

Trang trí cửa sổ chủ đề Breeze dựa trên công cụ chủ đề Aurorae. Vì tôi là tác giả chính của Aurorae, tôi có thể viết nó trên bài đăng blog này mà không cảm thấy tồi tệ về nó 🙂 Aurorae được thiết kế để rất dễ tạo trang trí và sử dụng các tính năng trong mờ mới. Là một giải pháp có thể được sử dụng như một vật trang trí mặc định, nhưng nó chưa bao giờ là mục tiêu của họ. Ý tưởng là cho phép những người dùng muốn tùy chỉnh tính năng này, trong khi hầu hết người dùng có thể sử dụng các chủ đề gốc nhanh hơn. Aurorae không bao giờ nhanh và cô ấy sẽ không nhanh.

Bây giờ trong KWin 5, việc sử dụng QML là vấn đề chính khiến Aurorae khó sử dụng. QtQuick sử dụng Scenegraph và sử dụng QWindows thay vì QWidget. Đó là một điều đáng tiếc cho API dựa trên QWidget của chúng tôi. Chúng tôi đã điều chỉnh cách sử dụng bên trong để hỗ trợ trang trí dựa trên QWindows, nhưng đó là một chặng đường khá khó khăn vì có sự khác biệt trong hành vi cửa sổ. Vì nó không còn dựa trên QWidget, bẫy sự kiện sơn của chúng tôi đã bị hỏng và chúng tôi cần một giải pháp mới cho nó. Và giải pháp này thậm chí còn xấu hơn giải pháp trước vì QtQuick hiện đang làm việc thông qua OpenGL. Do những hạn chế trong ứng dụng OpenGL Qt (có thể được giải quyết trong Qt 5.4) mà chúng tôi không thể chia sẻ với ngữ cảnh OpenGL được QtQuick sử dụng ... Đây không chỉ là một chi phí lớn khi sao chép nội dung từ GPU sang RAM và quay lại GPU, bạn cũng đang mất rất nhiều bộ nhớ. Trong trường hợp cửa sổ được phóng to, nó không chỉ là thanh tiêu đề mà là toàn bộ cửa sổ. Và có đó là chi phí cho mỗi cửa sổ.

Chỉ điều đó thôi cũng có thể khiến Aurorae hoàn toàn không thể sử dụng được. Tôi hiện đang sử dụng chủ đề Breeze và KWin cần hơn 200MB RAM - không thực sự chấp nhận được. Nhưng tình hình còn tồi tệ hơn. Với QWindows, chúng tôi không thể biết khu vực nào đã được cập nhật. Vì vậy, ví dụ, khi một nút được cập nhật, chúng tôi phải sơn lại toàn bộ cửa sổ, bao gồm cả bản sao hoàn chỉnh của nội dung trang trí. Điều đó đặc biệt là trong các tình huống hoạt hình là một vấn đề lớn.

Vậy con đường phía trước là gì? Tôi bắt đầu triển khai trang trí mới cho API bằng cách loại bỏ hạn chế của trang trí dựa trên sức khỏe khỏi QWidget và đồng thời tôi bắt đầu triển khai trang trí Breeze với API mới này. Hy vọng chúng tôi có thể giới thiệu điều này trong KWin 5.1.

Và đó là cách mọi thứ diễn ra, các quý ông. Tôi hy vọng bạn hiểu được ít nhiều vấn đề là gì. Tôi sẽ hỏi Martin rằng liệu việc tạo chủ đề Breeze bản địa như Oxygen có thực tế và nhanh hơn không, mặc dù hiện tại tôi không lo lắng, Oxygen mặc dù nó không phải là thứ dễ thương nhất trên thế giới nhưng nó có rất nhiều lựa chọn ..