Xamarinはwpfレンダラーを形成し、ButtonRendererなどの一部のAndroidレンダラーは高速であり、ここで「高速」とはどういう意味かを知っています。
これらのレンダラーは高速ですか？
前もって感謝します。

@ysmoradiうん！ これらの新しいレンダラーは、高速レンダラーパターンに従います（つまり、メインビューの周りにラッパービューはありません）。 これは、AndroidとWPFだけでなく、すべてのプラットフォームで実行する予定です。

いかなる場合でも、下位互換性を維持しようとしないでください。 これは何か新しいことです。 XFと互換性がある必要はありません。 あなたは何かをより良くすることができます。

Skiaグラフィックライブラリでレンダリングされるc＃で完全に記述されたマッピングや動作ロジックを一切使用せずに、独自のコントロールセットを使用してUIフレームワークを作成してみませんか？ 人々は強力にカスタマイズされた設計を使用するため、プラットフォームの設計ガイドラインに一致させる必要はありません。 唯一の必要性は、柔軟なカスタマイズの可能性です。 何かが足りない場合は訂正してください。ただし、レンダラーアーキテクチャよりもメリットがある理由がわかりません。

このアプローチでは、プラットフォーム固有のレンダラーの代わりにクロスプラットフォームのレンダラーを作成することは可能ですか？ ボタンコントロールとskia-sharpコントロールのマッピングのように。

プラットフォームレンダラーは悪い設計です。 ご覧のとおり、プラットフォームの制限のためにUWPをサポートしていないxamarinコントロールライブラリがたくさんあります。
例として、UWPの影を取り上げます。 コーナーボタンからコーナーシャドウを取得することはできません（もちろん、ボタンテンプレートを変更してこれを行うことはできますが、それは別のことです）。

クロスプラットフォームのレンダリングを作成するのは非常に難しいことを私は知っています。 しかし、フラッターはこれが実行可能であると私たちに言いました。 長期的には、クロスプラットフォームのレンダラーが最適なソリューションです。

カスタム2Dキャンバスとしてアプリ全体をレンダリングすると、モバイルアプリでシームレスに機能する可能性があると思います。

ただし、ドラッグアンドドロップ、テキストの選択、テキストを操作するためのキーボードショートカットなど、再実装する必要のあるユーザーアクションが非常に多いため、デスクトップアプリや複雑なアプリでは機能しない可能性があります。

Skiaグラフィックライブラリでレンダリングされるc＃で完全に記述されたマッピングや動作ロジックを一切使用せずに、独自のコントロールセットを使用してUIフレームワークを作成してみませんか？ 人々は強力にカスタマイズされた設計を使用するため、プラットフォームの設計ガイドラインに一致させる必要はありません。 唯一の必要性は、柔軟なカスタマイズの可能性です。 何かが足りない場合は訂正してください。ただし、レンダラーアーキテクチャよりもメリットがある理由がわかりません。

カスタム2Dキャンバスとしてアプリ全体をレンダリングすると、モバイルアプリでシームレスに機能する可能性があると思います。

ただし、ドラッグアンドドロップ、テキストの選択、テキストを操作するためのキーボードショートカットなど、再実装する必要のあるユーザーアクションが非常に多いため、デスクトップアプリや複雑なアプリでは機能しない可能性があります。

Skiaグラフィックライブラリでレンダリングされるc＃で完全に記述されたマッピングや動作ロジックを一切使用せずに、独自のコントロールセットを使用してUIフレームワークを作成してみませんか？ 人々は強力にカスタマイズされた設計を使用するため、プラットフォームの設計ガイドラインに一致させる必要はありません。 唯一の必要性は、柔軟なカスタマイズの可能性です。 何かが足りない場合は訂正してください。ただし、レンダラーアーキテクチャよりもメリットがある理由がわかりません。

あなたはこれらすべてについて絶対に正しいですが、チームは唯一のアプローチを選択することを強制されていません。 これはすべて時間の不足だと思います。 つまり、彼らは.net 6と一緒に「真新しい」完全にクロスプラットフォームのUIフレームワークを1年以内にリリースする必要があるということです。そして、古き良き実績のあるフレームワークを基礎として採用することははるかにリスクが少ないです。 それは大丈夫です、そしてそうあるべきです。 しかし、長期的には、カスタム2Dキャンバスレンダリングにははるかに多くの利点があり、「クロスプラットフォーム」と呼ばれるに値すると思います。 Xamarinフォームは本当に良いものであり、今日では大きな進歩を遂げています。 しかし、次に進む時が来ました。 Microsoftとxamarinのチームには非常に賢いエンジニアがいて、おそらくそのようなアプローチを検討しているか、切り札としてhttp://avaloniaui.net/と何らかの関係があるかもしれません。

Skiaグラフィックライブラリでレンダリングされるc＃で完全に記述されたマッピングや動作ロジックを一切使用せずに、独自のコントロールセットを使用してUIフレームワークを作成してみませんか？ 人々は強力にカスタマイズされた設計を使用するため、プラットフォームの設計ガイドラインに一致させる必要はありません。 唯一の必要性は、柔軟なカスタマイズの可能性です。 何かが足りない場合は訂正してください。ただし、レンダラーアーキテクチャよりもメリットがある理由がわかりません。

Skia開発者向けに4番目のレンダリングのデフォルトのグレーを100％変更して、リッチなデザインを確実に提供するのはクールかもしれません。
バックコーマビリティについては、これら3つをそのままにしますが、「自分で描画する」_skia_renderを追加し、開発者の90％の責任を負います。

レンダラーの概念を維持する必要がある場合、 INotifyPropertyChangedとイベントハンドラーを介して共有UIコードとレンダラーの間のブリッジを排除することを考えることができますか？ NS

• 共有コントロールに_property_を設定し、 PropertyChangedイベントを伝播する代わりに、プロパティをプラットフォームレンダラーに直接マッピングして設定できますか？
• 共有コントロールで_method_を呼び出し、レンダラーによって発生および処理されるイベントを呼び出す代わりに、メソッドをプラットフォームレンダラーに直接マッピングして関与させることはできますか？

INotifyPropertyChangedは、MVVMデザインと緩く結合されたビューモデルに最適ですが、共有UIコードとプラットフォームレンダラーの間のブリッジメカニズムとして常に不格好に感じられてきました。 これにより、パフォーマンスが向上し、共有UIとレンダラーレイヤー間の「おしゃべり」が減り、開発者のエクスペリエンスが向上します。

これは長いですが、マウイ島の「インサイドベースボール」に注目する価値があります。
https://www.youtube.com/watch?v=_MGh3xipWm4

マウイのアーキテクチャは、プラットフォームでレンダリングされたコントロールとキャンバスで描画されたコントロールの両方をサポートするようです。さらに、高貴な@Clanceyは、MVUフレーバーだけでなく機能するマウイのスキアベースのレンダリングセットで作業を続けます。マウイ島だけでなく、MVVMパターンにも使用できます。

一見、マウイはフォームのブランド変更のように見えましたが、よく見ると、フォームアーキテクチャを再構築して、レイヤーをより緩く結合し、このスレッドで求めている多くのことをサポートしています。 これからの楽しい時間。

これは少し話題から外れていますが、この正確なこととの関連性のために私が聞きたかったことです。

メモリはSKCanvasView （または一般的にSkia）でどのように機能しますか？ それぞれが常にそのサイズに比例してメモリを消費しますか？ 他の人と重なる場合、これは変わりますか？

たとえば、グラデーションコントロール（Skiaで記述されたレンダラー）があり、その上に半透明のボタン（Skiaで記述されたレンダラー）がある場合、2倍のメモリを消費しますか、それともグラフィックスコンテキストが何らかの形で共有されますか？ SkiaコントロールがSkia以外のコントロールとオーバーラップした場合はどうですか？

以前、Skiaを使用してFormsにいくつかの凝ったグラフィックスコントロールを実装することを検討しましたが、メモリがどのように機能するかを理解していないと、常に十分な懸念が生じ、私はそうしませんでした。

@GalaxiaGuy wpfコントロールでホストされているwinformコントロールのように、skiaコントロールを非skiaコントロールでオーバーラップさせて使用すると思います。 あなたはこれを行うことができますが、最善ではありません。
SKCanvasViewによってレンダリングされた2つのコントロールがある場合、グラフィックスコンテキストは共有されません。 最良の方法は、レンダリングされた2つを合成し、それを1つのキャンバスに描画することです。
私のテストでは、静的なことを行うだけで、 SkiaSharpパフォーマンスはそれほど悪くありません。 そして、私はいくつかのアニメーションを試してみましたが、私のラップトップではCPU使用率が少し高くなっています。

なぜそんなに多くの人がSkiaに夢中になっているのですか？ 優れたレンダリング仕様は、低レベルで使用されるレンダリングエンジンに依存しません。 特定のプラットフォームレンダラーがSkia（またはDirect2DやOpenGLなど）を使用したい場合、それはアプリケーション層が心配しなければならないことではありません。

何年も前のWPFでのXAMLの最大の約束は、委ねられているルックレスコントロールのアイデアでした。 Xamarin Formsはこの機能なしでXAMLを使用しましたが、これが最も弱い点でしたが、わずか数年後に図面仕様によって部分的に修正されました。
さまざまなOSやフレームワークの既存のコンポーネントに対して、さらに別のインターフェイスと抽象化のセットが必要だとは思いませんが、プラットフォームに依存しないビジュアルプリミティブとプラットフォーム固有のグラフィックレンダリングバックエンドでテンプレート化された、XAMLベースの真に見栄えのしないコントロールが

何年も前のWPFでのXAMLの最大の約束は、コントロールの実際のグラフィックスがテンプレートに委ねられているルックレスコントロールのアイデアでした。 Xamarin Formsはこの機能なしでXAMLを使用しましたが、これが最も弱い点でしたが、わずか数年後に図面仕様によって部分的に修正されました。

同意しました！ そして、アプリが必要とするすべてのおそらく99％を達成するには、非常に少数のレンダリングプリミティブが本当に必要です。

• 境界線（ドロップシャドウと丸みを帯びたエッジのオプションを含む）
• 線/楕円/長方形
• プレーンテキストレンダリング
• プレーンテキスト入力
• リッチテキストレンダリング
• リッチテキスト入力
• HTMLレンダリング
• 画像プレゼンター
• オーディオ/ビデオプレゼンター
• ソリッドおよびリニア/ラジアルグラデーションブラシ

XFレンダリングプラットフォームは、新しいタイプのコントロールがフレームワークに追加されるたびに、フレームワーク内の既存のプリミティブの上に構築するのではなく、新しいレンダラーで実行されるため、非常に肥大化しています。

はい、より多くのロジックをフレームワークレイヤーに移動する必要があります。最も難しいのは、アイテムコントロールに関してです（ VirtualizingStackPanelは、スケーラブルなアイテムビューアーを持つために重要ですが、私の知る限り、外部に効果的に移植されることはありません。非常に複雑なため、WPFの）。 しかし、WPFがオープンソースであるため、その多くは現在MAUIに移植でき、ついにそれが起こり始める時期だと思います。

アプリが必要とするすべての99％を達成するには、非常に少数のレンダリングプリミティブが本当に必要です。

Unoプラットフォームはこのアプローチを使用しています。

@velocitysystems

共有コントロールにプロパティを設定し、PropertyChangedイベントを伝播する代わりに、プロパティをプラットフォームレンダラーに直接マッピングして設定できますか？

これもこの変更の大きな目標です。 これらの変更の反対側にいると、レンダラーはBindableObjectまたはINPCが何を意味するのかわかりません。

これもこの変更の大きな目標です。 これらの変更の反対側にいると、レンダラーはBindableObjectまたはINPCが何を意味するのかわかりません。

したがって、レンダラーがPropertyChangedにサブスクライブする代わりに、 BindableProperty値が変更されるたびに、レンダラーのメソッドがフレームワークによって呼び出されますか？

@legistek右

これは基本的に依存関係を反転させます

したがって、レンダラーはIButtonに対してのみ機能します。

そして、System.Mauiは、レンダラーがXamarin.Forms.Coreへの参照を持っている方法とは対照的に、レンダラープロジェクトへの参照を追加します。

ここにあるスパイクをチェックインしました
https://github.com/dotnet/maui/pull/66

だからあなたはこれがどのように見えるかを見ることができます

今日は太平洋夏時間の3:30に

https://www.twitch.tv/microsoftdeveloper

参加しませんか！ 見てみな！ そして質問をしてください！

@PureWeen残念ながら私はそれを逃しました。 YouTubeで利用できる録音はありますか？

これもこの変更の大きな目標です。 これらの変更の反対側にいると、レンダラーはBindableObjectまたはINPCが何を意味するのかわかりません。

それは巨大で、本当に実質的な改善です。 マウイへの移行に伴い、多くのレンダラーで使用されている複雑な継承モデルが削除され、より構成的なアプローチが採用されることは間違いありませんか？

今日は＃66をレビューします。

＃66を見ると、スリムレンダラーがリフレクションを使用するのではなく、「おとり商法」で構築および呼び出されているのがわかります。 ほんの少しの考え：

• SlimレンダラーはGCの問題に対処しますか？特に、マネージドコントロールとネイティブコントロールのライフサイクルの間に不一致があるAndroidではそうですか？ これは、恐ろしいObjectDisposedExceptionつながる仮想化レイアウトの子ビューで特に顕著です。
• SlimレンダラーはEffectの廃止につながりますか？ 効果は役立つ場合がありますが、最終的には複雑さを増し、レイアウトのライフサイクルに待ち時間が発生する可能性があります。
• 「双方向」プロパティは、新しいレンダラーデザインでどのように機能しますか？ たとえば、Position（ TimeSpan ）プロパティを持つMediaElementとします。 セッターは現在の位置を更新し、ゲッターはネイティブメディアプレーヤー、つまりAVPlayer 、 MediaPlayerから現在の位置を取得します。 スリムレンダラーで_getter_をマッピングするためのデザインはありますか？

SlimレンダラーはGCの問題に対処しますか？特に、マネージドコントロールとネイティブコントロールのライフサイクルの間に不一致があるAndroidではそうですか？ これは、恐ろしいObjectDisposedExceptionにつながる仮想化レイアウトの子ビューで特に顕著です。

ここにいくつかのアイデアがあります!! すべてではないにしてもほとんどのODE例外を解決できるように、廃棄戦略を少し作り直したいと思います。 現在、Android / iOSですべてを非常に積極的に処理していますが、GCが行うことをGCに任せることができると確信しています。 すべてを逆参照し、GCにこれらの多くの場合に役立つはずの作業を行わせるようにすれば

SlimレンダラーはEffectの非推奨につながりますか？ 効果は役立つ場合がありますが、最終的には複雑さを増し、レイアウトのライフサイクルに待ち時間が発生する可能性があります。

これは、私たちがこのアイデアを発展させるときに調べるのに間違いなく良いことです。 これらすべての最終設計に到達したら、効果を確認します。 しかし、はい、完全なレンダラーを使用せずにネイティブ要素を利用する方法として意図されているため、エフェクトが廃止されているのを見ることができました。 マッパーは基本的に廃止された効果

「双方向」プロパティは、新しいレンダラーデザインでどのように機能しますか？ たとえば、Position（TimeSpan）プロパティを持つMediaElementがあるとします。 セッターは現在の位置を更新し、ゲッターはネイティブメディアプレーヤー（AVPlayer、MediaPlayer）から現在の位置を取得します。 ゲッターをスリムレンダラーでマッピングするためのデザインはありますか？

これはまだ少し作業中です。 @Clanceyが間違っている場合は訂正してください。ただし、ActionMapperが現在のアプローチでした。 https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

「双方向」プロパティは、新しいレンダラーデザインでどのように機能しますか？ たとえば、Position（TimeSpan）プロパティを持つMediaElementがあるとします。 セッターは現在の位置を更新し、ゲッターはネイティブメディアプレーヤー（AVPlayer、MediaPlayer）から現在の位置を取得します。 ゲッターをスリムレンダラーでマッピングするためのデザインはありますか？

これはまだ少し作業中です。 @Clanceyが間違っている場合は訂正してください。ただし、ActionMapperが現在のアプローチでした。 https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

ではない正確に。 したがって、ActionMapperはPropertyMapperと同じですが、SetElementフェーズでは呼び出されません。 したがって、WebView、GoBackなどの場合。 初期化中にそれを呼び出したくはありませんが、それでもレンダラーと通信する必要があります。

すでに双方向マッピングをサポートしています。 すなわちエントリー。 テキスト値がエントリにチャンスがあるとき。 IEntryにはstring Text {get;set;}あり、値を設定するだけです。 したがって、メディア要素には2つのオプションがあります。 1つは、変更されたときの位置/時間を単純に戻すことです。 何かにしたい場合は、代わりにクエリを実行します。 出来るよ。 xplatビューはレンダラーにアクセスできます。 view.Renderer.NativeView as NativeMediaViewこれで、必要なプロパティをすべて取得できます。

ビルド中のストリームからのいくつかのビデオがあります

@Clanceyのここはもっと深くなります
https://www.youtube.com/watch?v=_MGh3xipWm4

ここでDavidと少し触れます
https://www.youtube.com/watch?v=lAmwjfZY1IM

「双方向」プロパティは、新しいレンダラーデザインでどのように機能しますか？ たとえば、Position（TimeSpan）プロパティを持つMediaElementがあるとします。 セッターは現在の位置を更新し、ゲッターはネイティブメディアプレーヤー（AVPlayer、MediaPlayer）から現在の位置を取得します。 ゲッターをスリムレンダラーでマッピングするためのデザインはありますか？

これはまだ少し作業中です。 @Clanceyが間違っている場合は訂正してください。ただし、ActionMapperが現在のアプローチでした。 https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

ではない正確に。 したがって、ActionMapperはPropertyMapperと同じですが、SetElementフェーズでは呼び出されません。 したがって、WebView、GoBackなどの場合。 初期化中にそれを呼び出したくはありませんが、それでもレンダラーと通信する必要があります。

すでに双方向マッピングをサポートしています。 すなわちエントリー。 テキスト値がエントリにチャンスがあるとき。 IEntryにはstring Text {get;set;}あり、値を設定するだけです。 したがって、メディア要素には2つのオプションがあります。 1つは、変更されたときの位置/時間を単純に戻すことです。 何かにしたい場合は、代わりにクエリを実行します。 出来るよ。 xplatビューはレンダラーにアクセスできます。 view.Renderer.NativeView as NativeMediaViewこれで、必要なプロパティをすべて取得できます。

ここで考慮すべきもう1つのことは、C＃9で提供されるレコードです。 専門は、それらが不変であり、 initプロパティアクセサーを持っていることです。 したがって、双方向バインディングでそれらを使用できるようにするには、マッパーがwith演算子を使用して新しいインスタンスを返すことができる必要があります。

ビューがレコードにバインド可能であることを本当に望んでいます。これにより、純粋なMVVMまたは純粋なMVUに関しても非常に簡単になるからです。

質問：投稿した図では、WindowsコントロールがWindows.UI.*でレンダリングされていますが、私が理解しているように、これは現在非推奨になっている途中であり、更新は表示されません。流暢なデザインのレンダリングに対するすべての改善は次のとおりです。 WinUIプロジェクトの一部としてMicrosoft.UI.*れます。 これについてコメントしていただけますか？

ネイティブコントロールへのマッピングは大きな間違いだと思います。これはXamarin.Formsのひどい部分です。ユニークで美しいレイアウトを簡単に作成することはできません。レンダリングを使用して、外観のないWPFおよびFlutterコントロールの概念とアプローチに従う必要がありました。 OpenGL / DirectX / Metalを使用してC ++で記述されたエンジン。これにより、絶えず変化するプラットフォーム構造に依存しないことに加えて、移植性、パフォーマンス、柔軟性が向上します。

問題は、新しいアーキテクチャ/プロパティマッパーについて話すことです。 彼らがマッピングするものではありません。 繰り返しますが。 ネイティブ向けのスリムレンダリングアーキテクチャは、私たちが決して描画された制御アプローチを実行できないことを意味するものではありません。 しかし、これにより、ネイティブコントロールと非ネイティブコントロールを組み合わせて組み合わせることができます。純粋に描画された場合、それはより困難になります。 描画レイヤーを含め、同じスリムレンダラーアーキテクチャに従うSkiaベースのコントロールの作業を継続する予定です。 https://github.com/Clancey/Comet/tree/dev/src/Comet.Skia/Handlers。

このレンダラーに関する私の2¢（私は完全には理解していないことを認めます、TBH）：

同じコントロールクラスを使用して、プラットフォームでレンダリングされたコントロール（UIButtonのラップなど）とルックレスコントロール（WPF）の両方を実装する方法について考えました。 正直なところ、これは非常に単純です。MauiButtonクラスにコントロールテンプレートを使用させ、プラットフォーム固有のレンダラーコードをすべて削除します。 次に、ButtonRendererを含むButtonのインボックステンプレートを提供します。 ButtonRendererは、Cocoa / UIKit / UWP / etcと通信し、各UIツールキットのプラットフォーム固有のコードを使用します。アプリ開発者が使用するButtonクラスは、そのプロパティを単純に転送します。 ユーザーがカスタム描画ボタンを使用したい場合は、WPFの場合と同様に、テンプレートをオーバーライドして、ButtonRendererの代わりに描画クラス（最終的にはどのようなものでも）を使用できます。 Xamarin.FormsをWPFを理解するほど深く理解するのに時間をかけたことはなかったので、今日のマウイでこれがすでに可能であるか（またはすでに使用されているか）は正直にわかりません。

あなたの考えを教えてください！

Slimレンダラーがさまざまなアプリモデル（MVVM、MVUなど）で何を意味するのかを理解しようとしています。

最初の図は、異なるアプリモデルごとに独自のレンダラーのセットがあることを示しているようです。
しかし、私の意見では、レンダリングのタイプごとに1セットのレンダラーを用意する方がよいでしょう（たとえば、XFなどのネイティブコントロールへのレンダリング、キャンバスへのレンダリングなど）。
レンダラーはアプリモデルを認識する必要はありません。基になるコントロールに正しい更新を適用できるように、どの値がどのプロパティにマップされているかを知る必要があるだけです。
IButtonのみがアプリモデルごとに異なる方法で実装され、レンダラーのマップされた関数を呼び出す責任があります。

Fabulousのようなサードパーティライブラリには、各プラットフォームの各コントロールに適切なレンダラーをすべて実装する（すべてのバグが伴う）Microsoftのマンパワーがないため、これは重要です。

もう1つのポイントは、コントロールインターフェイス（ IButton ）は、レンダラーによってのみ使用されるゲッターである必要があります。
レンダラーは値を設定せず、アプリモデルごとにコントロールの形状が異なります（BindableProperty、BindingObjectなど）。
たとえば、Fabulousには不変のビューがあります。 内部的にのみ、ミューテーションをIButtonインスタンスに設定することが許可されます。

そうすれば、FabulousはIButtonインターフェースを内部辞書のリーダービューとして直接使用できるため、レンダラーが機能します。

// This is the type used by our users, sort of a Builder that return a new instance each time
// and append the set value to an internal list 
public struct Button
{
     public Button Text(string value) => (...);

     internal ReadOnlyDictionary<string, obj> Build() { ... }
}

// This will be an implementation of IButton, hidden from our users
internal class FabulousButton : IButton
{
    private ReadOnlyDictionary<string, obj> _properties;
    FabulousButton(ReadOnlyDictionary<string, obj> properties)
    {
        _properties = properties;
    }

    void Update(ReadOnlyDictionary<string, obj> properties)
    {
        var previousProperties = _properties;
        _properties = properties;

        // Diffing of the 2 dictionaries to determine what changed
        // and which mapped functions inside the renderer should be called
        (...)
    }

    public string Text => _properties["Text"];
}

@TimLariviereあなたが言ったことはすべてそれがどのように機能するかです:-)

そこの描画は、レンダラーに関しては混乱を招きます。

あなたが心配する必要があるこれの唯一の部分は素晴らしいボタンですそしてそれから私達が世話をする他のすべて

ほとんどの場合、インターフェースは読み取り専用です

これはボタンが使用するインターフェースです
https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Views/IText.cs

（レンダラーに関して）本当にあなたにあるのは、IButtonを再消費する必要があることをレンダラーに通知することだけです。

たとえば、これらすべてのBindableObjectバージョンでは、ここではレンダラーのupdatepropertyメソッドを呼び出しています。

https://github.com/dotnet/maui/blob/slim-renderer-samples/System.Maui.Core/VisualElement.cs#L1132

ある時点で（すぐに？） @ Clanceyには、Cometの公開バージョンがあり、彼がどのようにそれを行っているかを確認できます。

私はチェックアウトします
https://github.com/dotnet/maui/blob/slim-renderer-samples

おそらく、独自のFabulous.Coreヘッドをそれに追加してから、インターフェースへの実装の追加を開始できます。

@PureWeenかっこいい。 おかげで、私はそれがどうなるかを見るためにあなたがリンクしたサンプルで遊んでみます。

@PureWeen @Clanceyマウイチームがこれですべてになると確信していますが、新しいスリムレンダラーが継承よりもコンポジションを優先できるようにしてください。 継承は便利ですが、残念ながらXFでは、レンダラー階層の一部が非常に複雑になり、保守が困難になっています。

@PureWeen
このURL
https://github.com/dotnet/maui/blob/slim-renderer-samples

404を与えます、それはプライベートですか？

@ Rand-ランダム

https://github.com/dotnet/maui/tree/slim-renderer-samples

@velocitysystems

マウイチームがこれですべてになると確信していますが、新しいスリムレンダラーは継承よりもコンポジションを優先できますか？ 継承は便利ですが、残念ながらXFでは、レンダラー階層の一部が非常に複雑になり、保守が困難になっています。

それが彼らが構築される方法です。 古き良きSystem.Objectから直接継承する非常に薄い基本クラスがあります

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.Android.cs

そして、ネイティブの関係はありません。

そこからすべてが基本的に辞書であるものを通して定義されます

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.cs#L31

これは基本的にデコレータのように動作します。

追加のマッパーでマッパーを装飾したり、独自の関数などを挿入したりできます。

独自のFuncをマッパーに追加するか、ネイティブ要素に直接アクセスするだけで、ユーザーシナリオの95％がカバーされることを目指しています。これは、すべてマルチターゲットになるためです。

@PureWeenサンプルでこれらのスリムレンダラーの実装について話し合うのに最も適切なチャネルは何ですか？

私は次のようないくつかの質問があります：

• デフォルト値は一元化された場所で定義されますか？ XFでは、これらは現在BindablePropertyフィールドの作成時に定義されていますが、アプリモデルによっては存在しません。
• Applicationクラスも（部分的に）インターフェイスになりますか？ これは多くのUI動作（リソース、メニュー、メインページ）を定義し、異なる方法で実装するのに最適です。
• Measure / Arrange / etcはコントロールインターフェースから抽出されますか？ アプリモデルがそれらを異なる方法で実装することは実際には意味がないと思います。

デフォルト値は一元化された場所で定義されますか？ XFでは、これらは現在BindablePropertyフィールドの作成時に定義されていますが、アプリモデルによっては存在しません。

これは良い質問です。 @Clancey ？ これをまだ定義したかどうかはわかりません。 すべてのマッパーがプロパティの現在の値（デフォルト値）で呼び出される初期セットアップフェーズがありますが、デフォルト値の計画があるかどうか、およびそれらがどのように一般化されるかはわかりません

Applicationクラスも（部分的に）インターフェイスになりますか？ これは多くのUI動作（リソース、メニュー、メインページ）を定義し、異なる方法で実装するのに最適です。

はい！ すべてのアプリケーションクラス（ネイティブおよびxplat）を1つのアプリケーションクラスにまとめたいと考えています。 なぜあなたはこれについて尋ねているのですか？ ここであなたのユースケースに興味がありますので、確実に対処することができます

Measure / Arrange / etcはコントロールインターフェースから抽出されますか？ アプリモデルがそれらを異なる方法で実装することは実際には意味がないと思います。

この時点でそれが計画です。 アイデアは、BindableObject / Propertyに依存しないように、すべてのレイアウトコードを抽出することです。このようにして、Blazor / Comet / otherはStackLayoutを使用するだけで、結果は同じになります。

なぜあなたはこれについて尋ねているのですか？ ここであなたのユースケースに興味がありますので、確実に対処することができます

まだ何が欲しいのか完全にはわかりません。 しかし、Fabulousでは、現在、グローバルスタイルとメインメニュー（macOSのように）を定義するための良い話がありません。 ユーザーが自分でApplicationクラスをサブクラス化できるようにするため、基本的には、従来のXamarin.Formsの場合と同じようにリソース/メニューを定義するようにユーザーに指示します。

したがって、理想的には、アプリケーションのUI関連のすべてのプロパティもビューの一部になり、ビュー差分ロジックをビューに適用できるようになります。

そんな感じ

public interface IAppRoot
{
    IEnumerable<object> Resources { get; }
    IMenu MainMenu { get; }
    IPage MainPage { get; }
}

public class Application
{
    /// Bootstrapping and other logic of MAUI

   public IAppRoot Root { get; set; } // Replaces MainPage, which is typed for pages only
}

@PureWeen別の質問： TextChanged 、 Toggledなどのイベントのトリガーは誰が担当しますか？ コントロールまたはレンダラー？

他のアプリモデルの実装を大幅に簡素化すると思うことの1つは、変更がプログラムによる場合に状態変更イベントをトリガーしない可能性です。

たとえば、今日、エントリのTextChangedは、ユーザーが何かを書き込んだとき、またはMyEntry.Text = "New value";を実行したときにトリガーされます。
プログラムによる変更に対応することは実際には役に立たず、暗黙的であり、コードについて推論するのに悪いと思います。

また、これによりAndroidで無限ループが発生します。これは、プラットフォームがわずかな遅延でイベントをトリガーし、Fabulousが同期を解除して、元に戻る可能性がないためです。
私たちが見つけた唯一の回避策は、値を設定する前に最初にイベントのサブスクライブを解除してから、再サブスクライブすることでした...

奇妙な質問。 MAUIがアーキテクチャに依存しない場合、コントロールにアーキテクチャ名で名前が付けられるのはなぜですか？ たとえば、上の図にはマウイ島があります。 Mvvm .ButtonRenderer.Android？ @PureWeen @Clancey

XFには圧縮レイアウトと呼ばれるものがあります（これはバグがあります）
MAUIに（確かにバグなしで！）そのようなものはありますか？

このスレッドで、Flutter / Skiaアプローチを使用してUIをレンダリングすることについて、人々がどのように反応するかがわかります。私はほとんど同意します。
MAUIがカスタム/ネイティブではないコントロールとレンダリングをサポートする可能性があることを本当にうれしく思います。
ただし、ネイティブUIを操作する機能は、物事の政治的側面のフレームワークを保護すると言わざるを得ません。
そして、はい、私はアップルについて指摘しています。 最新のニュースにより、ある時点で何らかの理由でFlutterの使用が「文書化されていない/制限された機能の悪用」または「AppleUIガイドラインに従わない」などと見なされても驚かないでしょう。

このスレッドで、Flutter / Skiaアプローチを使用してUIをレンダリングすることについて、人々がどのように反応するかがわかります。私はほとんど同意します。
MAUIで、カスタム/ネイティブではないコントロールとレンダリングがサポートされる可能性があることを本当にうれしく思います。
ただし、ネイティブUIを操作する機能は、物事の政治的側面のフレームワークを保護すると言わざるを得ません。
そして、はい、私はアップルについて指摘しています。 最新のニュースにより、ある時点で何らかの理由でFlutterの使用が「文書化されていない/制限された機能の悪用」または「AppleUIガイドラインに従わない」などと見なされても驚かないでしょう。

MAUIがWeb（Flitterなど）をサポートしている場合は、いつでもWebViewにレンダリングできます。
一部の大企業はWebViewを介してのみAppStoreに表示されるため、AppleがWebViewベースのアプリケーションをあえてブロックする可能性はほとんどありません。

このスレッドで、Flutter / Skiaアプローチを使用してUIをレンダリングすることについて、人々がどのように反応するかがわかります。私はほとんど同意します。
MAUIで、カスタム/ネイティブではないコントロールとレンダリングがサポートされる可能性があることを本当にうれしく思います。
ただし、ネイティブUIを操作する機能は、物事の政治的側面のフレームワークを保護すると言わざるを得ません。
そして、はい、私はアップルについて指摘しています。 最新のニュースにより、ある時点で何らかの理由でFlutterの使用が「文書化されていない/制限された機能の悪用」または「AppleUIガイドラインに従わない」などと見なされても驚かないでしょう。

MAUIがWeb（Flitterなど）をサポートしている場合は、いつでもWebViewにレンダリングできます。
一部の大企業はWebViewを介してのみAppStoreに表示されるため、AppleがWebViewベースのアプリケーションをあえてブロックする可能性はほとんどありません。

それはすでにそこのガイドラインに反しています-https ： //developer.apple.com/app-store/review/guidelines/#minimum-functionality

MAUIのこのまったく新しい世界がどのように見えるかを少し前後に読んだ後、SKIAや他のマルチプラットフォームレンダリングエンジンのようなどこでも使用して、カスタムを実装する必要がある、聖なるものすべてを愛してください。 Xamarin Formsのような各プラットフォームのUIは古く感じられ、地獄の7番目のサークルで作成されたソリューションのようです。

下位互換性が「ただ」必要な場合は、新しい最新のレンダリングサポートで古いコンポーネントをレンダリングする方法をサポートします。他のプラットフォームにもこれに対する適切なソリューションがあることがわかりました。最近使用したのは、ユニティのUIエンジンです。新しい最新のUXMLにはIMGUIレンダリングがあります。

@ jackie0100
私は完全に同意します

Xamarin Formsのように各プラットフォームにカスタムUIを実装する必要があるのは古く、地獄の7番目のサークルで作成されたソリューションのようです。

レンダラの実装については、IViewのの考え方についてどのようなことはネイティブビュー（代わりにたIViewのネイティブのビューを持っている）です。 つまり、構成の代わりに継承？ これにより、「フォームのオーバーヘッド」がまったくない、最速で最もスリムなアーキテクチャになります。 基本的に、純粋なネイティブビューと、単なる共通のインターフェイスを使用しています。

次に、iOSランドで、ビューをUIViewにキャストし、IViewがUIViewであるため、ネイティブの子を（任意のタイプで）追加するなどのことができます。 同様に、「ネイティブ埋め込み」を実行する場合、IViewはUIViewであるため簡単です。同じものであるため、IViewの1つをネイティブビューに追加するだけで済みます。 これにより、ネイティブの<-> mauiの相互運用性が大幅に向上し、最高レベルのパフォーマンスと最低のメモリ消費量が実現します。

自分でプロトタイピングしたい気がします。 おそらく週末/夜のプロジェクト...

MAUIがWeb（Flitterなど）をサポートしている場合は、いつでもWebViewにレンダリングできます。

iOSの上のWebViewを必要としないでくださいに直接レンダリングすることができますOpenGLのかメタル。

または、OpenGLまたはMetalを下に置いてSkiaを使用します。

ネイティブUIを操作する機能は、物事の政治的側面のフレームワークを保護します。 [アップル]

ある時点で、Appleは書面によるポリシーからネイティブUIウィジェットを使用する要件を削除しました。 彼らが政策を制限に戻す実際的な方法は見当たらない。

とにかく、ネイティブコントロールを操作できるようにすることは良いオプションです。

@legistek

なぜそんなに多くの人がSkiaに夢中になっているのですか？ 優れたレンダリング仕様は、レンダリングエンジンに依存しません...

「不可知論者」であることについては完全に同意しますが、OpenGL / Metal / Vulkan /その他の低レベルのレンダリングエンジンに直接アクセスする場合は、インタラクティブなUIをレンダリングするために実装する必要のある詳細がたくさんあります。 Skiaは、アプリのUIの問題と実際のレンダリングエンジンの間の効果的な「中間層」であるため、人々は夢中になっています。Skiaは、ベアメタルだけの場合、設計および実装する必要のあるものの多くを処理します。 この作品を再発明する理由はありません。 _only_ターゲットであってはなりませんが、非常に価値があり成熟したターゲットであるため、OpenGLからVulkanへの移行がはるかに簡単になります。

また、Skiaをターゲットにすることは、クロスプラットフォームウィジェットとネイティブウィジェットの2つの並列ウィジェット階層のXamarinFormsメンテナンスよりもはるかに面倒ではないのではないかと思います。

Skiaは、.NetMauiがブラウザで高いパフォーマンスを発揮する日を早めるかもしれません。 繰り返しになりますが、低レベルから構築するのではなく、レンダリングの適切な中間レベルの抽象化から始めているためです。 それは大きな勝利になるでしょう。

みなさん、こんにちは。忘れないでください。
https://github.com/dotnet/maui/discussions/103

最近のマウイのビデオを見たことがありますが、私が誤解しない限り、プラットフォームに依存しない側で行われる描画でネイティブコントロールがオーバーレイされる、よりスタイルの高いコントロールを持つ傾向があったようです。 そのスキアであろうと、ネイティブキャンバス描画へのある種のバッチ相互運用であろうと、このアプローチが追求されることを願っています！ XFプラットフォームレンダラーモデルは、常に皮肉なことにMicrosoft UIプラットフォームに最も大きな打撃を与え、最も使用されていません。

また、コントロールがネイティブコンポーネントを明示的に持たないようにする機能を開いたままにし、レイアウトコンポジターがこれを検出すると、作成されるネイティブビューを自動的に削減できる可能性があります（つまり、コンテナー内のすべてのコントロールがで描画されたmauiラベルである場合）スキア、それはコンテナをSkViewにし、ラベルの子コントロールで描画操作を呼び出すことができます）、Androidでは、たとえば、多くの画像とテキストコントロールを持つリスト要素などの速度が向上します。

I don't understand what a renderer is.
If the program for absorbing the visual differences of the target is called a renderer, it should be absorbed by Xamarin and MAUI altogether. If not, I think it's an unfinished Xamarin and MAUI. And it will never be completed.
I think application programming should be more independent of the differences in the target environment.

レンダラーというものが理解できません。
ターゲットのビジュアルに関する差異を吸収するためのプログラムをレンダラーというのであれば、それはXamarinやMAUIが全て吸収すべきです。そうではないのだとすると、それはXamarinもMAUIも未完成なのだと思います。そしてそれは、永遠に完成することはないでしょう。
アプリケーションプログラミングは、もっとターゲットの環境の差異から独立できるようにすべきだと考えます。