非同期テキストレンダリング

Description説明

The candera engineエンジンは非同期テキスト provides asynchronous text rendering to improve the handling of time-consuming text processings. The focus is not to improve performance but to improve resource handling.レンダリングを提供し、時間のかかるテキスト処理の処理を改善します。焦点は、パフォーマンスの向上ではなく、リソース処理の向上です。

Asynchronous非同期テキスト textレンダリングには、テキスト rendering requires knowledge of how text nodes work.ノードの動作に関する知識が必要です。

General information of how to use Candera::TextNode2D can be found in the following section:の使用方法に関する一般的な情報は、次のセクションにあります。

Asynchronous非同期テキスト text rendering requires further knowledge of which steps are necessary to display a text. Please refer to the following section:レンダリングには、テキストを表示するためにどの手順が必要かについての詳細な知識が必要です。次のセクションを参照してください。

Based on the knowledge about the TextNode2D andと CanvasText,CanvasText theに関する知識に基づいて、次の章では非同期テキスト followingレンダリングのしくみについて説明します。さらに、これらの章では、非同期テキスト chapters describe how asynchronous text rendering works. Further, these chapters explain how to customize the asynchronous text rendering and which restrictions should be considered when using this feature. The documentation focuses mainly on レンダリングをカスタマイズする方法と、この機能を使用する際に考慮すべき制限について説明します。ドキュメントは主にCandera::TextNode2D. The concepts described inside these chapters are applicable to に焦点を当てています。これらの章で説明されている概念は、Candera::CanvasText, too.にも適用できます。

Chapters章

Text renderingテキストレンダリング - Useful knowledge 役に立つ知識 

TextNode2D – textテキスト renderレンダリング processプロセス

Aテキストは、そのレンダリング textプロセスで uses3 three steps in its render process:つのステップを使用します。

All of these steps have to be fulfilled to come to a visible result. Using a 目に見える結果を得るには、これらすべての手順を実行する必要があります。TextNode2D hasの使用には、そのテキストを更新する three3 differentつの異なる方法があるため、最終結果にアプローチする ways3 toつの異なる方法があります。主な違いは、情報の提供と update3 itsつのプロセス text and therefore three different ways to approach the final result. The main difference lies in providing information and handling the three process steps:ステップの処理にあります。

First最初のケース: case: No layout usageレイアウトの使用なし

Candera::TextNode2D には has no real layout information. There is also no layout in which the 実際のレイアウト情報はありません。Candera::TextNode2Dが統合されたレイアウトもありません。したがって、テキスト isレンダリング integrated.プロセスのレンダリング Therefore,プロセスをトリガーするだけで十分です。テキストは領域にバインドされておらず、シーン trigger the render process for text render process is enough. The text is not bound to an area and has no relationship other than the visible layer to any other node in the scene graph.グラフ内の他のノードに対する可視レイヤー以外の関係はありません。

Pro:プロ：

Contra:反対:

Back to the sub menuサブメニューに戻る

Second2 case:番目のケース: Layoutレイアウト process but no プロセスはあるが、TextNode2D layouterレイアウターがない

Candera::TextNode2D には has no real layout information. However, it is arranged within a layout実際のレイアウト情報はありません。ただし、レイアウト (e.g.GridLayout GridLayout).など) This implies that 内に配置されます。これは、Candera::TextNode2D が実際のレイアウト結果を提供して、レイアウト領域内にテキストを配置する必要があることを意味します。したがって、レイアウト hasプロセスは、事前にテキスト toレンダリング provideプロセスを開始する必要があります。テキスト actualレンダリング layoutプロセスは、レイアウト resultsプロセスがテキストのバウンディング to arrange the text within the layout area. Therefore, the layout process has to start the text render process beforehand. The text render process has to complete the first stepボックスを評価するときに、最初のステップ (measurement測定と配置) andを完了する必要があります。レイアウト placement) when the layout process evaluates the bounding box of the text. The layout process has no influence on the size of the bounding box. It only receives the information of the bounding box and can place all the other nodes around the text. The actual handling of this information is defined by the used layouter.プロセスは、境界ボックスのサイズには影響しません。境界ボックスの情報のみを受け取り、テキストの周りに他のすべてのノードを配置できます。この情報の実際の処理は、使用するレイアウタによって定義されます。

Pro:プロ：

Contra:反対:

Back to the sub menuサブメニューに戻る

Thirdケース case: Layout process with3: TextNode2D layouterレイアウターを使用したレイアウト処理

Candera::TextNode2D はレイアウト情報を提供します。さらに、一般的なレイアウト providesプロセスは、テキストの表示方法にも影響を与える可能性があります。レイアウト layoutプロセスでは、テキストが収まる必要がある最大領域を提案できます。これは配置に直接影響します。テキスト自体は、レイアウト information.プロセスで実際に使用されたバウンディング Additionally, the general layout process can influence the way text is displayed, too. The layout process can propose a maximum area in which the text has to fit. This has a direct impact on the placement. The text itself provides the layout process a bounding box which were actually used by it.ボックスを提供します。

Pro:プロ：

Contra:反対:

CanvasText – textテキスト renderレンダリング processプロセス

Candera::CanvasText は uses the third approach of Candera::TextNode2D:の 3 番目のアプローチを使用します。

All other approaches have been removed from 処理の複雑さを軽減するために、他のすべてのアプローチはCandera::CanvasText to reduce the complexity of processing. Another difference to から削除されました。Candera::TextNode2Dとのもう is1 the actualつの違いは、実際の Render() part. Whilst the 部分です。Candera::TextNode2D は calls the各ノードで Render() onを呼び出しますが、 each node, Candera::CanvasTextは同じレンダリング設定でテキストを収集し、それらを renders1 it in a batched form by collecting texts with equal render settings and drawing them with a single draw call. 回の描画呼び出しで描画することにより、バッチ形式でレンダリングします。Candera::CanvasText はGlyphAtlas uses GlyphAtlas.を使用しています。

Please note also the following restriction when using asynchronous text processing:非同期テキスト処理を使用する場合は、次の制限にも注意してください。

Back to the sub menuサブメニューに戻る

Back to the menuメニューに戻る

Asynchronous非同期テキスト text rendering レンダリング 

Asynchronous非同期テキスト textレンダリングは、テキスト renderingレンダリング isステップを独自のスレッドまたはレンダリング aスロットに移動するために導入された機能です。正確には、3 featureつのレンダリング introduced to move text render steps to an own thread or render slot. To be precise only the first of the three render steps can be handled asynchronously. All the other steps are possibly bound toステップのうち最初のステップのみを非同期で処理できます。他のすべてのステップは、おそらく GPU orにバインドされているか、フレームワークとユーザー has to extend the complexity of how to receive the desired output for both framework and user application.アプリケーションの両方で目的の出力を受け取る方法の複雑さを拡張する必要があります。

Asynchronous非同期テキスト text renderingレンダリング – Workerワーカー threadスレッド

The非同期テキスト defaultレンダリングのデフォルトの方法は、ワーカー wayスレッドの使用です。レンダリング ofループは、最初のステップである測定と配置をワーカー asynchronousスレッドに委任します。すべてのデリゲートはキューに入れられ、処理の準備が整います。ワーカー textスレッドを使用する主な利点は、レンダー renderingループをブロックしないことです。テキストの測定と配置が完了するまで、レンダリング isループ自体はブロックされません。このアプローチの欠点は、実行の瞬間と結果の到着時間を制御できないことです。これは、単一のレンダリング the usage of a worker thread. The render loop delegates the first step, Measurement and Placement, to a worker thread. Every delegate is placed in a queue and ready for processing. Using a worker thread has its main advantage in not blocking the render loop. The render loop itself will not block until the text has been measured and placed. The disadvantage of this approach is that there is no control over the execution moment and result arrival time. It can happen after a single render cycle but also after an undefined amount of cycles.サイクルの後に発生する可能性がありますが、未定義のサイクル数の後に発生することもあります。

The次の図は、非同期テキスト next figure shows in a draft how the measure and placement process has been replaced when asynchronous text rendering is used. For simplicity only the way without a layouter is used. All other ways do replace the measurement and placement process with the same approach in their flow chart.レンダリングを使用する場合に、測定と配置のプロセスがどのように置き換えられるかを下書きで示しています。簡単にするために、レイアウターを使用しない方法のみを使用します。他のすべての方法は、測定と配置のプロセスをフローチャートの同じアプローチに置き換えます。

The非同期プロセスを実際にトリガーする関数は、2 function回トリガーする必要があります。1 which回はプロセスをキューに入れ、2 actually回目は結果を取得します。このフローチャートのサンプルでは、​​Render triggersメソッドを the2 asynchronous回呼び出す必要があります。2 process has to be triggered twice. One time to queue the process and a second time to retrieve the result. In this flow chart sample the Render-method has to be called twice. The second call has to be done when the asynchronous process has actually finished.番目の呼び出しは、非同期プロセスが実際に終了したときに実行する必要があります。

Asynchronous非同期テキスト text renderingレンダリング - Singleシングル threadedスレッド

Asynchronous非同期とは、作業負荷を別のスレッドで処理する必要があるという意味ではありません。また、別の時点で同じスレッドによって実行されることもあります。シングル doesスレッド notバージョンの主な欠点は、レンダリング meanループ theスレッドがまだテキストを処理していることです。ただし、今回は、1 work回のレンダリング load has to be done by another thread. It can also be done by the same thread at another point in time. The main disadvantage of the single threaded version is that the render loop thread is still handling the text. However, this time it does not have to handle every text in a single render cycle. The amount of texts which will be rendered in a cycle can be determined.サイクルですべてのテキストを処理する必要はありません。サイクルでレンダリングされるテキストの量を決定できます。

Thisこれは、テキスト/サイクルと処理するテキストの implies2 that two factors are given: Text/cycle and text to handle. Based on this information the amount of cycles needed to calculate all texts can be estimated. The duration of each cycle cannot be determined, though.つの要素が与えられていることを意味します。この情報に基づいて、すべてのテキストを計算するために必要なサイクル数を見積もることができます。ただし、各サイクルの期間を決定することはできません。

Synchronization methods同期方法  

Text-Synchronizationテキスト同期

With非同期テキスト theレンダリングの導入により、すべてのテキスト introductionノードを同期する方法を提供する必要があります。基本的な考え方は、すべての非同期テキストを同じレンダリング ofサイクルで視覚的に更新することです。テキストがランダムにポップアップするのを防ぐ必要があります。もう1つの側面は、レイアウトプロセスを減らすことです。レイアウターがCandera::TextNode2Dにアタッチされている場合、レイアウト asynchronous text rendering a way to synchronize all text nodes have to be provided. The basic idea is to visually update all asynchronous texts at the same render cycle. It should prevent text popping up randomly. Another aspect is to decrease layout processes. When a layouter is attached to a プロセスはCandera::TextNode2D,のサイズを評価します。これは、レイアウト theプロセスが必要に応じて非同期テキスト layoutレンダリングを開始することも意味します。レイアウト process will evaluate the size of a Candera::TextNode2D. This also means the layout process starts the asynchronous text rendering if necessary. When the layout process starts the process, it should not wait for the result as this results in the same blocking issue as before.プロセスがプロセスを開始するとき、結果を待つべきではありません。これは、以前と同じブロッキングの問題が発生するためです。

Theレイアウタは、非同期テキスト layouterレンダリングがまだ行われていない限り有効な古い情報とテキストを使用します。レイアウト uses the old information and text which is still valid as long as the asynchronous text rendering is not done yet. Rerunning the layout process will check whether the new text is valid yet or not. If not, it will continue using the old information. If the new text is valid now, it will update the text. The same procedure happens without a layouter attached. However, the part of starting and collecting the results is done by the プロセスを再実行すると、新しいテキストがまだ有効かどうかがチェックされます。そうでない場合は、古い情報を引き続き使用します。新しいテキストが現在有効な場合、テキストが更新されます。同じ手順は、レイアウターがアタッチされていなくても発生します。ただし、結果の開始と収集の部分は、render call呼び出し自体によって行われます。つまり、非同期テキスト itself.レンダリングを開始し、最低 In2 short回の呼び出しで結果を受け取る必要があります。呼び出し元が実際に誰であるかは、レイアウト an asynchronous text rendering has to be started and the result has to be received in a minimum of two calls. It depends on the usage of layout procedures who the caller really is.プロシージャの使用法に依存します。

This section describes the possibilities of synchronization:このセクションでは、同期の可能性について説明します。

Text-Synchronizationテキスト同期 – Default synchronizationデフォルトの同期

The default synchronization is kept as simple as possible. This section describes the lifecycle of the validation and how does the synchronization works including its flaws.デフォルトの同期は、可能な限りシンプルに保たれています。このセクションでは、検証のライフサイクルと、その欠陥を含めて同期がどのように機能するかについて説明します。

Lifecycleライフサイクル

Every object which has to be synchronized implements the interface 同期する必要があるすべてのオブジェクトは、インターフェイスCandera::TextRendering::ITextValidationUser,を実装します(例: e.g. TextNode2D. In the next step this object has to be attached to a TextNode2D)。次のステップで、このオブジェクトをCandera::TextRendering::TextValidationGroup.にアタッチする必要があります。デフォルト Theグループはシングルトン defaultインスタンスです。Candera group is a singleton instance. The Candera:::TextRendering::TextValidationGroup は creates a specific validator and attaches it to the object. Detaching the validator is comparable to this process.特定のバリデータを作成し、それをオブジェクトに添付します。バリデーターの切り離しは、このプロセスに匹敵します。

Synchronization同期 - flowフロー

The object can be invalidated at any time by calling the invalidation method of the Candera::TextRendering::TextValidator. Every time an invalidated object changes it state to validate, the の無効化メソッドを呼び出すことで、いつでもオブジェクトを無効化できます。無効化されたオブジェクトがその状態を検証に変更するたびに、Candera::TextRendering::TextValidator は notifies the group of its validation change. If all objects of the group are valid now, all update methods of these objects will be called.検証の変更をグループに通知します。グループのすべてのオブジェクトが現在有効である場合、これらのオブジェクトのすべての更新メソッドが呼び出されます。

In case of the Candera::TextNode2Dにレイアウターがアタッチされている場合、 with an attached layouter, the layout of the scene in which the Candera::TextNode2D が存在するシーンのレイアウトは無効になります。レイアウト lies will be invalidated. If there is layout process used at allプロセスがまったく使用されている場合 (disabledカンデラ candera layout functionality) nothing will be done in the update method. However, the レイアウト機能が無効になっている場合)、更新メソッドでは何も実行されません。ただし、render methodメソッド自体は、新しく呼び出されたときにこのケースを処理できます。ここでの問題は、誰がレンダリングをトリガーするかが明示的に指定されていないことです。のレンダリング itselfメカニズムとレイアウト can handle this case when it is newly called. The issue here is that it is not explicitly specified who will trigger the render. Both render and layout mechanisms of will check whether the whole group is valid or not. Only in case that the whole group is valid, the text will be updated. If the layout is triggered by another object despite the fact that the group is not valid, the text will not be updated.メカニズムの両方が、グループ全体が有効かどうかをチェックします。グループ全体が有効な場合にのみ、テキストが更新されます。グループが無効であるにもかかわらず、別のオブジェクトによってレイアウトがトリガーされた場合、テキストは更新されません。

Synchronization同期 - Restrictions制限事項

The default synchronization is as lightweight as possible and still provides the feature that all texts in the group have to be valid until the text can be visibly updated. Due to the variety of combinations a text can be used, it is not a universal solution for synchronization. Therefore in some cases it is not as practical as it should be.デフォルトの同期は可能な限り軽量であり、テキストが視覚的に更新されるまでグループ内のすべてのテキストが有効でなければならないという機能を提供します。テキストはさまざまな組み合わせで使用できるため、同期のための普遍的なソリューションではありません。したがって、場合によっては、本来あるべきほど実用的ではありません。

ACandera ::TextNode2D は、同期または非同期にすることも、実行時に両方のケースを切り替えることもできます。したがって、デフォルトでは、非同期フラグが変更されたときに TextNode2D をグループにアタッチ/デタッチすることはお勧めできません。保留中のリクエストは、ここでの主要な問題の 1 つです。

同期Candera::TextNode2D は同期でなければなりません。これは、テキストが変更された場合、その後の最初のレンダリング can be synchronous or asynchronous or switch between both cases at runtime. Therefore it is not advisable per default to attach/detach the TextNode2D to the group when the asynchronous flag changes. Pending requests are one of the major issues here.サイクルでテキストを表示する必要があることを意味します。そのため、テキストが実際に表示されることが確定的になります。これらのノードで同期グループを使用すると、この決定論に反します。ノードはグループに接続されていますが、常に有効な状態です。デフォルトの同期では、ノードは完全に無視されます。

Aもう synchronous1 Candera::TextNode2Dつの重要な制限は、テキストの更新率です。これは、同期がなくても発生する問題ですが、同期によって激化します。つまり、テキストが変更されるたびに、グループが無効になります。無効化率が、グループ全体のテキスト hasレンダリング toプロセス全体がレンダリングする必要があるよりも高い場合、表示されるはずのテキストが表示されなくなります。2 beつのテキストがより高い割合でそれ自体を無効にしている場合、グループ全体が常に無効な状態になる可能性もあります。グループ自体には、既に終了したテキストをカウントするメカニズムがあるため、グループが有効であるか、まだ表示されていない保留中の有効なテキストがあるという事実に基づいて、テキストを更新できます。この情報に基づいて、新しいテキストを設定したためにテキストの synchronous.1 This implies when the text has been changed the text has to be visible in the first render cycle afterwards. So it becomes deterministic that the text is truly displayed. Using the synchronization groups on these nodes is opposing this determinism. The node is attached to the group but it is always in the valid state. The node will be ignored completely by the default synchronization.つが無効に戻った場合でも、有効なグループを認識することができます。

Another同期は単純であるため、テキスト更新を相互にリンクすることはできません。たとえば、すべてのテキストを一度に別の言語に変更することは機能しています。保留中のテキストの変更に関する問題は critical1 restriction is the update rate of a text. This is an issue that happens even without a synchronization but will be intensified by it. In short, every time a text changes, it invalidates the group. When the invalidation rate is higher than the overall text render process of the whole group needs to render, text which should have been shown will never occur. If two texts are invalidating itself in a higher rate, it can also happen that whole group is always in an invalid state. The group itself has a mechanism to count already finished texts and is therefore able to update the text based on the fact that the group is valid or has pending valid texts which are not displayed yet. Based on this information it can recognize a valid group even if one of the texts already changed back to invalid due to setting a new text. However this is not a guarantee that the texts will be updated correctly.つだけです。通常、どのテキスト変更が相互に関連しており、同時に変更する必要があるかを特定することはできません。

Because of the simplicity of the synchronization it cannot link text updates to each other. For example changing all texts at once to another language is working. There is only one issue with already pending text changes. It is not possible to generally specify which text changes are related to each other and have to be changed at the same time.顧客のすべてのユースケースが、単一の同期方法で満たされるわけではありません。ある方法では、別の方法とは異なる副作用が生じます。

Not every use case of a customer can be satisfied by a single way of synchronization. One way produce other side effects than another.

Therefore, own synchronizations can be implemented or used.したがって、独自の同期を実装または使用できます。

Text-Synchronizationテキスト同期 – Custom implementationカスタム実装

The customization of the synchronization has several levels of complexity and several different goals.同期のカスタマイズには、いくつかのレベルの複雑さといくつかの異なる目標があります。

A new synchronization group新しい同期グループ

The最も単純なカスタマイズは、追加の同期グループです。デフォルトでは、すべての simplestTextNode2D customization is an additional synchronization group. As default, all TextNode2Ds are attached to the singleton instance of the .のシングルトン Itインスタンスにアタッチされています。カスタム is possible to create an additional instance of this class in custom code. Now two steps have to be done to correctly bind a コードでこのクラスの追加インスタンスを作成することができます。Candera::TextNode2D を新しいグループに正しくバインドするには、2 toつの手順を実行する必要があります。
最初に、古い theCandera new group.
First, detach the Candera::TextNode2D:TextRendering::TextValidationGroup from its old group by using theの Detach-method ofを使用して、古いグループからCandera::TextNode2Dを切り離します。次に、新しい theCandera old Candera:::TextRendering::TextValidationGroup.
Second, attach the Candera::TextNode2D to the new group by using theTextValidationGroupの Attach-method ofを使用して、 the new Candera::TextRendering::TextValidationGroupTextNode2D.を新しいグループに接続します。

Additional追加のトリガー trigger objectsオブジェクト

A一般的な問題は、 common issue is that setting the underlying scene layout of a の基礎となるシーン toレイアウトを無効に設定するだけでは、実際のレンダリング invalidサイクルをトリガーするのに十分ではないということです。たとえば、レンダリング isウェイクアップ notメカニズムには、ウェイクアップしてレンダリング enough to trigger the actual render cycle. For example a render wakeup mechanism needs a trigger to wake up and start the render cycle, too.サイクルを開始するためのトリガーも必要です。

TheCandera Candera:::TextNode2D itself does not know which additional trigger are needed because this depends on the given application.自体は、特定のアプリケーションに依存するため、どの追加のトリガーが必要かを知りません。

Anこれを拡張すると、グループが有効になるとすぐにシーン extension of this would be to update nodes within the scene graph as soon as the group is valid. A simple use case is to set a new scene visible only when all texts in the new scene are valid or a control pops up only when its text in it is valid.グラフ内のノードを更新できます。簡単な使用例は、新しいシーン内のすべてのテキストが有効な場合にのみ新しいシーンを表示するように設定するか、そのテキストが有効な場合にのみコントロールがポップアップするように設定することです。

To accomplish this the specified object which is responsible for these calls has to implement the interface これを達成するために、これらの呼び出しを担当する特定のオブジェクトは、インターフェイスCandera::TextRendering::ITextValidationUser.を実装する必要があります。オブジェクトは、既定の同期の記述されたライフ The object can be attached to the サイクルに等しいCandera::TextRendering::TextValidationGroupTextValidationGroupにアタッチできます。その中の equalCandera to::TextRendering::ITextValidationUser::TriggerValidUpdate()メソッドは、グループ全体が有効になり、カスタム the described life cycle of the default synchronization. The コードを実行できるようになるとすぐに呼び出されます。さらに、オブジェクトは独自のCandera::TextRendering::TextValidatorを受け取ります。これは、グループが有効な時間またはCandera::TextRendering::ITextValidationUser::TriggerValidUpdate()の時間に影響を与える可能性があります。-method in it will be called as soon as the whole group is valid and the custom code can be executed. Additionally, the object receives an own Candera::TextRendering::TextValidator which can influence the time when a group is valid or when the Candera::TextRendering::ITextValidationUser::TriggerValidUpdate() on all objects in the whole group has to be additionally called.グループ全体のすべてのオブジェクトに対して、追加で呼び出す必要があります。

Implementation of an own synchronization独自の同期の実装

The most customized solution is to write an own synchronization mechanism.最もカスタマイズされたソリューションは、独自の同期メカニズムを作成することです。

There独自の実装には are2 two important interfaces for an own implementation:つの重要なインターフェイスがあります。

Candera::TextRendering::ITextValidationUser は、 is the interface which provides the Candera::TextNode2Dに任意の検証メソッドを提供するインターフェースです。このような検証メソッドを正しくアタッチおよびデタッチします。Candera with any validation method. It correctly attaches and detaches such a validation method. And Candera:::TextRendering::ITextValidationUser::TriggerValidUpdate() は、 invalidates the scene layout of the Candera::TextNode2D.のシーン The interface レイアウトを無効にします。インターフェイスFeatStd::ValidationHelperBase は、オブジェクトを検証および無効化する機能を提供します。それがどのように機能するかはカスタム実装です。ここでの制限は provides1 functionalityつだけです。同期的に使用される toTextNode2D は、カスタム実装の有効な状態を常に無視します。ただし、validate andメソッドと invalidate theメソッドは呼び出されます。Candera object. It is a custom implementation how it will work. There is only one restriction here. A synchronously used TextNode2D will always ignore the valid state of the custom implementation. It will call the validate and invalidate methods, though. A Candera:::TextNode2D calls the functions as following:次のように関数を呼び出します。

Back to the menuメニューに戻る

Configuration possibilities 構成の可能性 

General setup and configuration possibilities一般的なセットアップと構成の可能性

Thisこのセクションでは、非同期テキスト section describes how to configure the asynchronous text rendering.レンダリングを構成する方法について説明します。

Asynchronous非同期 TextNode2D andおよび CanvasText

Enabling非同期テキスト the asynchronous text rendering is something that has to be done on each  or またはCandera::CanvasText.で行う必要があります。これは、SceneComposer This can be done within the SceneComposer:内で実行できます。

Or in code itself:またはコード自体で：

void SetAsyncPreRenderEnabled(bool enabled);
bool IsAsyncPreRenderEnabled() const;

Example usage:使用例:

TextNode2D node; 
node.SetAsyncPreRenderEnabled(true);   //Enables async rendering 
node.IsAsyncPreRenderEnabled();        //returns true
node.SetAsyncPreRenderEnabled(false);  //Disables async rendering 
node.IsAsyncPreRenderEnabled();        //returns false

The flag in SceneComposer and code can be equally configured in とコードのフラグは、Candera::CanvasText.で同様に構成できます。

Asynchronous dispatching methods非同期ディスパッチ方法

CMake providesには、ワーカー aスレッド flagソリューションとシングル toスレッド chooseバージョンのどちらかを選択するためのフラグが用意されています。フラグを有効にすると、ワーカー betweenスレッドが使用されます。このフラグはデフォルトで有効になっています。スレッドが利用できない場合、またはスレッド theセーフが無効になっている場合、コードはこのフラグを無視してシングル workerスレッド threadバージョンにフォールバックします。フラグはシステム全体です。これは、すべての非同期 solutionTextNode2D andでカウントされます。これはプログラムで定義することもできますが、スレッド theセーフ single threaded version. When the flag is enabled a worker thread is used. The flag is enabled by default. If threading is not available or thread safety is disabled, the code will fall back to the single threaded version ignoring this flag. The flag is system wide. It counts for all asynchronous TextNode2D. This can also be defined programmatically, whereas there are no thread safety checks.チェックはありません。

Dispatcher settingsディスパッチャー設定

The TextRenderDispatcher contains a settings object which can be retrieved by calling:には、以下を呼び出して取得できる設定オブジェクトが含まれています。

class Candera::TextRendering::TextRenderDispatcher::TextRenderSettings{…};

Candera::TextRendering:: TextRenderDispatcher::GetTextRenderSettings();

To programmatically change the asynchronous dispatching method use the function of settings:非同期ディスパッチ方法をプログラムで変更するには、設定の関数を使用します。

#include <Candera/TextEngine/Async/ AsyncTextRenderDispatcher.h>
#include <Candera/TextEngine/Async/ ThreadingTextRenderDispatcher.h>

void SetDefaultTextRenderer(Candera::TextRendering::TextRenderer * val);

Ifシングル theスレッド single threaded version is used, the amount of processed text per バージョンを使用する場合、DispatchNext can be set:ごとに処理されるテキストの量を設定できます。

void SetAsyncLoopCount(UInt8 const val);

Back to the menuメニューに戻る

Restrictions 制限 

This section describes issues which should be kept in mind when using the asynchronous feature.このセクションでは、非同期機能を使用する際に留意すべき問題について説明します。

Performance improvementsパフォーマンスの向上

The非同期テキスト mainレンダリングの主な目的は、テキスト ideaレンダリングのパフォーマンスを向上させることではなく、レンダリング behindループ自体のパフォーマンスを向上させることです。結果を表示するためにレンダリング asynchronousループの text2 rendering回目のサイクルが必要な場合でも。最初のサイクルはテキスト isレンダリング呼び出しをキューに追加するだけなので、2 not to improve the performance of text rendering but to improve the performance of the render loop itself. Even if a second cycle through the render loop is necessary to display the results. The second cycle is mandatory as the first cycle only adds the text render call into a queue. The first cycle uses the old result to handle the text.番目のサイクルは必須です。最初のサイクルでは、古い結果を使用してテキストを処理します。

Usingワーカー aスレッドは worker2 thread番目のコアで処理できるため、実際のパフォーマンスを向上させるには、ワーカー andスレッドを使用し、最小限のデュアル havingコア a minimum of dual core processor is mandatory to gain an actual performance improvement as the worker thread can be handled by the second core.プロセッサを使用することが必須です。

High frequency changes高周波変化

The最も必須の制限は、非同期テキストの更新間隔です。テキストエンジンが処理できるよりも速くテキストを変更すると、システムの決定論が確実に破られます。高速更新テキストを処理するための most3 mandatoryつの異なるアプローチを概説できます。最初のアプローチは、すべてのテキストの変更を視覚的に示すことです。すべてのテキストを表示することは決定論的です。それらが単一のフレームでしか表示されず、テキストが表示されるときに決定論的ではない場合でも. restriction2 is番目のアプローチは、キューに入れられた古いテキストを新しいテキストで上書きすることです。すべてのテキストを見るという決定論は失われました。ただし、レンダリング theプロセスが開始される前に既に古いテキストをレンダリングすると、パフォーマンスが低下しますが、発生することはありません。3 update interval of an asynchronous text. Changing the text faster than the text engine can handle will definitely break the determinism of a system. Three different approaches can be outlined for handling fast updated texts. The first approach is to visibly show every text change. It is deterministic to see every text. Even if they are only visible for a single frame and it is not deterministic when the text is shown. The second approach is overriding the old queued text with the new one. The determinism of seeing every text has been lost. However, rendering a text which is already outdated before the render process started is a performance drop which will not occur. The third solution is to render these texts synchronously.番目の解決策は、これらのテキストを同期的にレンダリングすることです。

Currently現在利用できるのは、2 available番目と are3 the second and the third approach. This decision is based on the possible use cases.番目のアプローチです。この決定は、考えられるユースケースに基づいています。

The最初のユース firstケースは、フレーム useレート、クロック caseタイムなどの代替テキストです。基本的に、このようなテキスト isタイプには an3 alternatingつの共通点があります。まず、指定された時間間隔でコンテンツを常に変更します。テキストの背後にあるロジックは、最初は text,1 e.g.フレーム後、2 frame回目は rate,6 clockフレーム後に更新が表示された時点で既に壊れています。第二に、テキストは通常​​短いテキストです。長いテキストの頻繁な変更は、おそらくユーザビリティの問題です。第 time.3 Basicallyに、頻度がそれ自体を追い越すほど高く、テキストが常に交互に表示される場合、キューは無期限に積み重なっていきます。新しいテキストが到着するまで、キューに入れられたすべてのテキストを表示する時間はありません。視覚的なテキスト自体はますます時代遅れになっています。テキストの長さは、キューイング such a text type has three things in common. First, it changes its content all the time in a specified time interval. The logic behind the text is already broken when the update is visible the first time after a single frame and the second time after six frames. Second, the texts are usually short texts. A high frequency alternation of a long text is most probably an issue in the usability. Third, if the frequency is high enough to outrun itself and the text is alternating all the time, the queue will stack up indefinitely. There is no time to show all queued text until new texts arrive. The visual text itself becomes more and more outdated. The length of the text would increase the change of queuing text even more.テキストの変化をさらに大きくします。

Therefore,そのため、周期的な交替でそれらを同期的にレンダリングすることをお勧めします。短いテキストは、レンダリング it is recommended for cyclic alternation to render them synchronously. Short texts will not affect the render loop itself that much. And long texts should be reconsidered and checked against its reasonableness.ループ自体にはそれほど影響しません。また、長いテキストは再検討し、その合理性をチェックする必要があります。

The2 second番目の使用例は、テキストをすばやく切り替える場合です。たとえば、テキストが表示されますが、ユーザー入力によって次のテキスト更新が既にトリガーされています。この場合、テキストの長さは任意です。主な違いは、テキストの更新が無期限にキューに入れられるわけではなく、おそらく厳しい時間間隔の期限がないことです。この場合、非同期テキスト useレンダリングを使用できますが、両方のテキストをレンダリングすると、ユーザー case is to have occasionally a fast switch between texts, e.g. a text will be shown, but a user input already triggered the next text update. In this case the text can have any length. The main difference is that the text update does not queue indefinitely and there is most probably not a hard time interval deadline. In this case asynchronous text rendering can be used but rendering both texts can also impact the user experience. In most cases these will be noticeable in long texts. So there will be a visible delay until the outdated text is displayed and another visible delay until the new text is displayed.エクスペリエンスに影響を与える可能性もあります。ほとんどの場合、これらは長いテキストで顕著になります。したがって、古いテキストが表示されるまで目に見える遅延があり、新しいテキストが表示されるまで別の目に見える遅延があります。

Therefore,したがって、非同期アプローチでは、古いテキストが新しいテキストでできるだけ早くオーバーライドされます。古いテキストが既にレンダリングされている場合は、古いテキストが表示されます。古いテキストのレンダリングが開始されていない場合、古いテキストは置き換えられます。古いテキストと新しいテキストの両方が既にレンダリングされていて、レンダリング theループが古いテキストを表示する時間がない場合は、新しいテキストが表示されます。この場合、古いテキストの可視時間は asynchronous1 approach overrides the old text with the new one as soon as possible. If the old text is already rendering, the old text will be displayed. If the old text have not even started rendering, the old text will be replaced. If the old text and the new text both are already rendered and the render loop had no time to show the old text, the new text will be shown. In this case it would be most likely that the old text has only a visibility time of a single frame.フレームだけである可能性が最も高くなります。

DestructionTextNode2D of a TextNode2Dの破棄

Destroying a添付テキストのレンダリング中に TextNode2D while the attached text is being rendered can lead to undefined behavior.を破棄すると、未定義の動作が発生する可能性があります。

Layoutレイアウト process callsプロセスの呼び出し

Using an asynchronous approach means that there a functionality which starts the asynchronous process and another one which handles the result of the process. Based on the synchronization the check for a valid result can be solved by polling until a result is available.非同期アプローチを使用するということは、非同期プロセスを開始する機能と、プロセスの結果を処理する別の機能があることを意味します。同期に基づいて、有効な結果のチェックは、結果が利用可能になるまでポーリングすることで解決できます。

If the synchronization is done properly for a given use case, no polling will be needed.特定のユースケースで同期が適切に行われている場合、ポーリングは必要ありません。

However,ただし、非同期プロセスを開始するには、レイアウト情報が必要です。また、レイアウト theプロセスでは、テキスト asynchronousノードと依存ノードを配置するための結果が必要です。したがって、レイアウト processプロセスを requires2 layout回実行する必要があります。最低要件は information2 to回の呼び出しです。2 start. And the layout process requires the result to place the text node and depending nodes. Therefore, it is required to run the layout process twice now. Two calls are the minimum requirement. If the text has not been finished until the second call, more calls are necessary as this is equal to polling for results.回目の呼び出しまでテキストが完成していない場合は、結果のポーリングと同じであるため、さらに呼び出しが必要です。

Cacheキャッシュ type restrictionsタイプの制限

Some一部のキャッシュ cache types are タイプは、GPU contextコンテキストにバインドされています。したがって、ラスタライズされたグリフのアップロードは、正しいコンテキストで行う必要があります。ワーカー bound.スレッドを使用しても、アップロードが正しい場所にあるとは限りません。これには、追加のラスタライズとレンダリング Therefore,スレッド内のグリフごとのアップロードが必要になる場合があります。これらの問題が発生すると予想されるキャッシュ the upload of rasterized glyphs has to happen in the correct context. Using a worker thread cannot guarantee the upload at the correct location. This might require an additional rasterization and upload per glyph within the render thread. Expected cache types to have these issues are タイプは、SurfaceCache andと GlyphAtlas.GlyphAtlas です。Candera::CanvasText は主に usesGlyphAtlas primarily GlyphAtlas. A shared context and the non-threading method is preferred in this case.を使用します。この場合、共有コンテキストと非スレッド方式が推奨されます。

Back to the menuメニューに戻る