Kanzi 3.9.6 マイグレーションガイド¶

このマイグレーションガイドを使用して、Kanzi アプリケーションを Kanzi 3.9.5 から Kanzi 3.9.6 に更新してください。

kanzi::variantの変更¶

kanzi::variant の C++ typedef を boost::variant から boost::variant2 に変更しました。

boost::variant2 はC++17の std::variant と同じAPIを使用していますが、これは以前使用されていた boost::variant のAPIとは異なります。

たとえば、Kanzi アプリケーションを移行するには：

v.which() を v.index() に置き換えます。
v.type() == typeid(T) を holds_alternative<T>(v) に置き換えます。
すべてのビジタークラスから boost::static_visitor の派生を削除します。
v.apply_visitor(visitor) と apply_visitor(visitor, v) を visit(visitor, v) に置き換えます。

ヘッダーファイルの変更¶

Kanzi Engine は、より多くの前方宣言を使用し、domain.hpp および metaclass.hpp のヘッダーファイルに不要なインクルードを含まなくなりました。Kanzi アプリケーションを移行するには、欠落しているヘッダーをインクルードしてください。

例えば、以前は kanzi::TaskDispatcher と kanzi::ResourceDictionary を使用することが可能でした。

#include <kanzi/core.ui/domain/domain.hpp>

ですが、今後は以下を使用する必要があります

#include <kanzi/core.ui/domain/domain.hpp>
#include <kanzi/core.ui/task_dispatcher/task_dispatcher.hpp>
#include <kanzi/core.ui/resource/resource_dictionary.hpp>

CMake構成ファイルの変更¶

Cotire CMakeモジュールは、Kanzi ワークスペースで利用できなくなりました。このモジュールを引き続き使用したい場合は、https://github.com/sakra/cotire または以前の Kanzi リリースから入手できます。しかし、CMakeバージョン3.16から利用可能なCMakeの組み込み機能 target_precompile_headers を使用するようにCMake構成ファイルを移行することをお勧めします。

Kanzi Java API カスタムリソースマネージャープロトコルの変更点¶

Kanzi Java API カスタムリソースマネージャープロトコルを使用する場合、リソースは非所有の Resource 参照を使用する代わりに、ObjectRef インスタンスの背後に配置されます。これにより、リソースがまだロードされている間に作成されたオブジェクトのライフタイムがJVMのガベージコレクタによって回収されないことが保証されます。

同期ロードを実装する際、ResourceManager.ProtocolHandler.Result コンストラクタは単純な Resource の代わりに ObjectRef<? extends Resource> を受け取るように変更されました。このコンストラクタを使用するコードを変更して、所有する ObjectRef インスタンスを提供してください。

Kanzi 3.9.5	Kanzi 3.9.6
`public Result(Resource resource)`	`public <TResultType extends Resource> Result(ObjectRef<TResultType>`

非同期ロードを実装する際、ResourceManager.LoadTask.getResult() メソッドは、単純な Resource の代わりに ObjectRef<? extendes Resource> を返すようになりました。通常、LoadTask インスタンスはリソースを作成する際に ObjectRef へのアクセス権を既に持っています。推奨される方法は、clone() メソッドを使用して、その内部 ObjectRef インスタンスのクローンを返すことです。

Kanzi 3.9.5	Kanzi 3.9.6
`abstract public Resource getResult();`	`abstract public ObjectRef<? extends Resource> getResult();`

拡張クラスでオーバーライドできる ResourceManager.LoadTask.close() メソッドを追加しました。必要に応じて、内部の LoadTask リソースの明示的なメモリクリーンアップを可能にします。

Kanzi application framework (appfw) に関連する入力値の変更¶

Kanzi application framework (appfw) で KanziView を拡張する際、いくつかの入力関連の値名がネイティブの対応する用語と同期されました。

Kanzi 3.9.5	Kanzi 3.9.6
`TOUCH_STATE_CONTINUE`	`TOUCH_STATE_UPDATE`
`CURSOR_STATE_DOWN`	`TOUCH_POINT_STATE_PRESSED`
`CURSOR_STATE_STATIONARY`	`TOUCH_POINT_STATE_STATIONARY`
`CURSOR_STATE_MOVE`	`TOUCH_POINT_STATE_MOVED`
`CURSOR_STATE_UP`	`TOUCH_POINT_STATE_RELEASED`
`KEY_STATE_DOWN`	`KEY_STATE_PRESSED`
`KEY_STATE_UP`	`KEY_STATE_RELEASED`

ブラシレンダリングの変更¶

タイルベースのレンダリングを使用するGPUでのパフォーマンスを向上させるために、Kanzi は2Dレンダリング中にフレームバッファをクリアしないようにすることを試みなくなりました。

この改善により、BrushRenderer インターフェースに以下の変更が導入されます。

Kanzi 3.9.5	Kanzi 3.9.6
`void updateRender(optional<int> blendMode, bool forceOpaque, bool translucencyHint)`	`void updateRender(optional<int> blendMode, bool translucencyHint)`
`virtual void updateRenderOverride(optional<int> blendMode, bool forceOpaque, bool translucencyHint) = 0;`	`virtual void updateRenderOverride(optional<int> blendMode, bool translucencyHint) = 0;`

変更は以下に影響します：

BrushRenderer から派生したカスタムクラス
ブラシを手動で使用してコンテンツをレンダリングするアプリケーションコード

シェーダー作成の変更¶

Kanzi 3.9.6. は、ジオメトリシェーダーとテッセレーションシェーダーのサポートを追加しました。この改善により、ShaderProgram::CreateInfo に以下の変更が導入されました。

頂点およびフラグメントシェーダー固有のフィールドを、より汎用的なバリアントに置き換えました。
バイナリデータ型を文字列からバイトベクターに変更しました。

便利クラス ShaderProgram::CreateInfoShaderSource と ShaderProgram::CreateInfoShaderBinary は同じままです。

Kanzi 3.9.5	Kanzi 3.9.6
`string vertexShaderSource` と `string fragmentShaderSource`	`void addSourceShader(ShaderType type, string_view source)` または `void addSourceShader(ShaderType type, const char* source)`
`string separateShaderBinaryVertexData` と `string separateShaderBinaryFragmentData`	`void addBinaryShader(ShaderType type, ConstByteSpan binary)`
`string programBinaryData`	`vector<byte> programBinaryData`
`string combinedShaderBinaryData`	`vector<byte> combinedShaderBinaryData`

フォーカスと入力管理の変更¶

Kanzi 3.9.6では、Node はそれがアタッチされている Screen ノードを認識し、その Screen から FocusManager および InputManager インスタンスを取得できます。

これらの関数を導入しました:

Node::getFocusManager() と Node::getInputManager() は、ノードが属する Screen ノードに関連付けられた FocusManager と InputManager インスタンスを取得します。
Node::getScreen() と Node::setScreen() は、ノードが属する Screen ノードを取得および設定します。
Screen::setFocusManager() と Screen::setInputManager() は、FocusManager と InputManager を Screen ノードに関連付けます。

これらの関数を削除しました:

Domain::getFocusManager()。代わりに Node::getFocusManager() を使用してください。
Domain::getInputManager()。代わりに Node::getInputManager() を使用してください。

Kanzi Android framework (droidfw) から Kanzi Java API へのアクセスの変更¶

If the root node of the prefab displayed in a Kanzi view is a Screen node, the getRoot() method now returns the child of that Screen node. In previous versions of Kanzi, the method returned the Screen node. See Kanzi Java および Kotlin API にアクセスする.

KzuEngineの変更点¶

kzuEngine 構造体は非推奨となり、その機能は Application、Node、ResourceManager、および Screen クラスに移行されました。

Kanzi 3.9.5	Kanzi 3.9.6
`kzuEngineLoadBinary()`	`Application::loadKzbFile()`
`kzuEngineGetScreen()`	`Application::getScreen()`
`kzuEngineSetScreen()`	`Application::setScreen()`
`kzuEngineGetRootCompositionTarget()`	`Application::getRootCompositionTarget()`
`kzuEngineSetRootCompositionTarget()`	`Application::setRootCompositionTarget()`
`kzuEngineGetRenderingAreaOffset()`	`Application::getRenderingAreaOffset()`
`kzuEngineSetRenderingAreaOffset()`	`Application::setRenderingAreaOffset()`
`kzuEngineMeasurePerformance()`	`Application::measurePerformance()`
`kzuEngineGetFramesPerSecond()`	`Application::getFramesPerSecond()`
`kzuEngineRestoreNodeResources()`	`Application::restoreNodeResources()`
`kzuEngineInvalidateScreenLayout()`	`Node::invalidateMeasure()`
`kzuEngineInvalidateGPUResources()`	`ResourceManager::invalidateAllGPUResources()`
`kzuEngineSetScreenOrientation()`	`Screen::setWindowOrientation()`

この変更により、kzuEngineCreate()、kzuEngineDelete()、および Application::getEngine() 関数は廃止されます。

その他の変更¶

GatherLightsRenderPass::checkLightsModified() 関数では、チェックする光の範囲を指定する lightRange パラメータが導入されました。この関数は、GatherLightsRenderPass を継承するカスタムレンダーパスで使用できます。
PropertyAccessRange では、adapt() 関数は、shared_ptr の代わりに範囲参照を入力として受け取るようになりました。