Breeze：KDE 5にデフォルトで付属しないのはなぜですか？

すでに知っているように、KDE ​​Next（またはお好みでKDE 5）は数日前に安定してリリースされ、それがもたらす新機能の中で最も話題になっているのはBreezeと呼ばれる新しいアートワークです。

この新しいバージョンをすでに試したことがあるか、ビデオを見たことがある人は、ウィンドウデコレータの場合、デフォルトで付属しているのはBreezeではなくOxygenであることに気付いたかもしれません。 同様に マーティン・グラーリン 私たちを説明します 彼のブログで この決定の理由は何ですか。

記事は英語なので、これの基本的な考え方をお伝えしようと思います。

Breezeがデフォルトで付属しないのはなぜですか？

まず、KWin 4でウィンドウ装飾がどのように機能するかについて説明します。KWinは、いわゆるウィンドウマネージャーの子育てです。 これは、X11によって管理されているウィンドウが、ウィンドウフレームを提供する別のX11ウィンドウに配置されることを意味します。 KWinでは、ウィンドウフレームにQWidgetを使用しています。 したがって、QWidgetが提供するものにも制限されます...私たちの解決策は、QWidgetのすべての装飾ペイントイベントをインターセプトして抑制し、コンポーザーの再ペイントをトリガーし、レンダリングステップで一時的な画像の装飾を保証してからコピーすることですテクスチャに。

Breezeテーマウィンドウの装飾は、Auroraeテーマエンジンに基づいています。 私はAuroraeの筆頭著者なので、このブログ投稿で気にせずにそれを見つけることができます🙂Auroraeは、装飾を簡単に作成し、新しい半透明の機能を利用できるように設計されています。 デフォルトの装飾として使用できるソリューションであることは、彼らの目標ではありませんでした。 この機能をカスタマイズしたいユーザーが、より高速なネイティブテーマを使用できるようにするというアイデアでした。 オーロラは決して速くはなく、彼女は速くはありません。

現在、KWin 5では、QMLの使用がAuroraeの使用を困難にする主な問題です。 QtQuickはシーングラフを使用し、QWidgetの代わりにQWindowsを使用します。 これは、QWidgetベースのAPIにとっては残念なことです。 QWindowsベースの装飾をサポートするために内部使用法を微調整しましたが、ウィンドウの動作に違いがあるため、これは非常に困難な道でした。 QWidgetに基づいていないため、ペイントイベントのトラップが壊れており、新しいソリューションが必要でした。 また、QtQuickは現在OpenGLを介して動作しているため、このソリューションは以前のソリューションよりもさらに醜いです。 QtQuickで使用されるOpenGLコンテキストと共有できないOpenGLQtアプリケーション（Qt 5.4で対処可能）の制限により...これは、コンテンツをGPUからRAMにコピーし、再びにコピーする場合の大きなオーバーヘッドだけではありません。 GPU、あなたはまた多くのメモリを失っています。 最大化されたウィンドウの場合、それはタイトルバーだけでなく、ウィンドウ全体です。 そして、すべてのウィンドウにそのオーバーヘッドがあります。

それだけで、Auroraeは完全に使用できなくなります。 私は現在Breezeテーマを使用していますが、KWinには200MBを超えるRAMが必要です。これは実際には受け入れられません。 しかし、状況はさらに悪化しています。 QWindowsでは、どの領域が更新されたかを知ることができません。 したがって、たとえばボタンが更新された場合、装飾コンテンツの完全なコピーを含むウィンドウ全体を再描画する必要があります。 特にアニメーションの状況では、それは大きな問題です。

では、今後の道は何ですか？ QWidgetからウェルビーイングベースの装飾の制限を削除することでAPIの新しい装飾の実装を開始し、同時にこの新しいAPIでBreeze装飾の実装を開始しました。 これをKWin5.1で紹介できることを願っています。

そして、それは物事がそうである方法です、紳士。 問題が何であるかを多かれ少なかれ理解していただければ幸いです。 マーティンに、酸素のようなネイティブのBreezeテーマを作成する方が実用的で高速ではないかどうかを尋ねます。現時点では心配していませんが、酸素は世界で最もかわいいものではありませんが、多くのオプションがあります。 ..