Qt 6 の技術的なビジョン
The Qt Blog に Technical vision for Qt 6 という記事が投稿されました。
この記事の内容を元に、来年リリースされる予定の Qt 6 がどうなるのかを紹介したいと思います。
Qt 5 の振り返り
2011年5月に、Thoughts about Qt 5 (日本語訳:Qt 5 に関する構想)という記事で、今回と同じように Qt 5 のビジョンが示されました。
Qt 4 から Qt 5 への移行時には、以下のようなことがメインのトピックでした
- Qt Quick を高速に描画したい
- 当時の GPU の標準 API である OpenGL を最大限活用したい
- シェーダーによるカスタマイズを可能にしたい
- WebKit に同梱されていた JavaScript エンジンは遅かったので V8 に移行したい
- (現在は、V8 もやめ、Qt 独自の JavaScript エンジンで動いています)
- 様々なプラットフォームに対応するための描画系の抽象化レイヤーの導入
- QPA、実際にはフライング気味に Qt 4.8 に入りました
- Qt の開発効率の向上やメンテナンスのコストの削減
- Qt 4 の単一のリポジトリを、モジュールごとに分割
- 各モジュールの段階や状態に応じて柔軟に開発サイクルを回せるように
- QtWidgets を別モジュールに切り離し、オプションに
この記事を踏まえ、Qt 5 の開発が加速し、2012年に Qt 5.0 がリリースされましたが、それ以降も世の中の技術はどんどん進歩しています。Qt がこの先も素晴らしい技術であり続けるために、メジャーアップデートを行うタイミングがまた近づいてきました。
改めて Qt のいいところをまとめてみよう
Qt は本当に様々なところで様々な使われ方をしています。ユーザー目線で Qt のいいところをまとめると以下のようになるでしょう。
- ネイティブのクロスプラットフォーム対応フレームワーク
- パソコンからスマホ、組み込み機器の UI まで、共通のソースコードで対応可能です
- C++ や OpenGL を活用し、高速に動作します
- ローエンドからハイエンドまで対応可能なスケーラビリティ
- 単純なデバイスから、高機能なデバイス、パソコン用の複雑なアプリケーションまで対応可能です
- 最高級の API と、ツールとドキュメント
- コーディングを効率的に行うことができます
- メンテナンス、安定性、互換性
- 巨大なプロジェクトでも効率よくメンテナンスが行えます
- 100万人以上のユーザーによる開発者のエコシステム
- インターネット上には様々な情報がありますし
- わからないことがあれば質問に快く答えてくれるユーザーもたくさん存在します
Qt が活用されているエリアもまとめてみましょう。
- パソコン用のアプリケーション
- もともと Qt はここからはじまりました
- 現在でも重要かつ Qt が強い分野です
- 組み込み機器、コネクテッド端末
- Qt 的に近年大幅に成長した分野です
- 比較的安価なハードウェアで、最先端の UI を滑らかに動かすために利用されています
- AR や VR のように、2D と 3D を組み合わせた高機能で複雑なデバイスの開発も拡大しています
Qt 6 は、これらの利点をさらに強化し、2020年以降の将来を見据えたメジャーアップデートになります。
Qt 6 の主なトピック
QML の大幅な改良
Qt 4.7 で導入され、Qt 5 を通して大幅な改善が行われてきた QML ですが、独特の癖があったり細かい制限が気になるようになってきて、思い切った改善が必要になってきました。
強い型付けの導入
弱い型付けの弊害として大規模なリファクタリングが困難だという問題があります。強い型付けによる単純なパフォーマンスの向上以外にも、エディタなどのツールの利便性の向上やパフォーマンスの改善が期待できます。
JavaScript をオプションに
これまでは QML と JavaScript は一心同体のようなものでしたが、マイコンなどに JavaScript のエンジンを載せるのは比較的重いため、これを外せるようにする予定です。
QML モジュールのバージョン番号を廃止
これにより、対応する API の捜索ロジックを単純化、高速化することが可能になる予定です。バージョンを気にせずに済むことは、ユーザーにとっても大きなメリットでしょう。
QObject と QML のデータ構造の重複を改善
メタオブジェクト系のコードの重複を排除することで、大幅なパフォーマンスの改善とメンテナンスコストの削減が期待できます。
実行時のデータ構造の作成の抑制
上記のトピックとも関係がありますが、なるべくコンパイル時側に処理を持っていくことで、実行時のパフォーマンスを改善できる予定です。
QML を C++ へコンパイル
前述の、強い型付け対応とバージョン番号の廃止により、ネイティブコードへの変換が可能になる予定で、これによりパフォーマンスの改善が期待できます。
コンポーネントのデータや関数の秘匿が可能に
Private な関数やプロパティは長年の課題でしたが、Qt 6 で解決する予定です。
ツールの改善
既存の Qt Creator の QML 用のシンタックスハイライトや補完機能、エラー検知などはしばしば問題を引き起こします。上述の改善により、Qt 6 ではこれらの問題は大幅に改善されると共に、より高度なリファクタリングの機能なども提供できるようになるでしょう。
グラフィックスタックの刷新
Qt 5 の構想時には 3D グラフィックスの API として OpenGL を採用しましたが、それ以降、Vulkan や Metal, Direct3D などが登場し、Qt もそれらによりよく対応していきたいと思っています。
Rendering Hardware Interface(RHI) の導入
QPA でウィンドウ周りの抽象化を行ったように、RHI という描画用のハードウェアの抽象化レイヤーを導入することにしました。Qt の既存の描画パス(QPainter と Qt Quick の Scenegraph と 3D の描画)をこの RHI 上に移行する予定です。
RHI は Qt 5 をベースにすでに開発が進んでいて、Qt 5.14 で初期導入が行われる予定です。
詳しくは、コードレビュー や、gitlab 上で行われた実際のコード、github 上に置かれた一時的なドキュメントをご覧ください。
シェーダー用のツール
OpenGL 以外の 3D API をサポートするにあたり、シェーダー言語の対応が多様化します。
Qt では、それを解決するためのツールを提供する予定です。
一時的なドキュメントが github 上で公開されています。興味のある方はこちらも見てみてはいかがでしょうか。
Qt Quick 用のレンダラーの 3D 対応
Qt 5 では、2D 用の SceneGraph 上に、別途描画した3Dのシーンを2Dで貼り付ける形で 2D と 3D の描画を行っていましたが、より高度に精密にパフォーマンス良く描画ができるよう、Qt Quick のレンダラーを改善し、2D のコンテンツも 3D のコンテンツも描画できるようにする予定です。
この機能は Qt 5.14 に含める予定で、別途ブログ記事が公開されるようなので、楽しみに待ちましょう。
アセット管理の改善
コンパイル時に、PNG 画像を圧縮テクスチャに変換したり、テクスチャアトラスを生成したり、シェーダーやメッシュをバイナリ形式に変換したりということが可能になる予定です。
新しいテーマ・スタイルエンジンの導入
Qt Widgets と Qt Quick で共通で使えるスタイルエンジンを導入する予定です。
個人的に、これは Qt 5 で後悔してた事の1つなので、Qt 6 でこの対応が行われることはとても嬉しいです。
ツールの統合
デザイナー向けのツールの統合
個人的に、これはどうでもいい事の1つですが、Qt Design Studio や Qt 3D Studio (や Qt Creator)を統合して1つのツールで、2D のデザインも 3D のデザインもできるようにする予定です。
プログラマー向けのツールの統合
C++, QML, Python のより良い開発環境を目指します。デザイナー側のツールから来たものをシームレスに使えるようにもするようです。
Qt *自身の* ビルドツールを変更
Qt 6 では、cmake を Qt をビルドするための標準のサードパーティーのビルドシステムとする予定です。qmake は今後も継続する予定ですが、「Qt 自身のビルドのための開発」は行わない予定です。
うーん。イマイチですね。
C++ の API の強化
Qt 5 は C++98 がベースでしたが、Qt 6 は C++17 をベースにする予定で、Qt 5 時代にはできなかったことがたくさんできるようになります。
新しいプロパティシステムとバインディングの仕組み
QObject のプロパティシステムを刷新し、C++ でもバインディングが使えるようにする予定です。
これにより、パフォーマンスの大幅な改善と省メモリ化が実現できる予定です。
言語の対応
Qt 5.12 では Python を新たにサポートし、その後 WebAssembly にも対応しました。
Qt 6 でも状況に応じて別の言語の対応が柔軟に行えるといいなと思っています。
Qt 5 との互換性について
基本的に可能な限り互換性を維持する予定ではありますが、メジャーアップデートは互換性を破れる稀有な機会でもあるため、互換性を破る十分な理由がある場合には行います。
Qt のユーザーが既存のコードをなるべくすくないコストで Qt 6 に移行できるように、以下のようなことを考えています。
- 互換性がないものについては、なるべくコンパイル時にエラーを出すようにする
- それが難しい場合にも、実行時にはエラーを出すようにする
- 機能を廃止する場合には、可能な限り代替の手法を提供する
- 基本的にソースレベルでは互換性を維持する、バイナリは互換を維持しない
- メンテのコストの維持等の理由で Qt 5 で廃止したかったものは Qt 6 では削除する予定
- Qt 5.14, Qt 5.15 LTS, Qt 6 の流れでなるべくシームレスに移行ができるようにする
マーケットプレイスの提供
Qt のコンポーネントを公開する場所を提供する予定
まとめ
Qt Quick のさらなる改善と、グラフィックススタックの刷新という、Qt 4 から 5 の移行の際と同じような理由で Qt 6 へ移行するということがわかりますね。
Qt 6 に関する議論は Qt の開発者用のメーリングリストですでに行われていますが、今後さらに活発になることが期待されます。
皆さんも良いアイディアやフィードバックがあれば、ぜひ議論や実装に参加してはいかがでしょう?