@jassmith 、

これは、XAML標準化の観点からは非常に優れたアイデアであり、強力な機能を提供します。ただし、この道を進む際には注意が必要です。 これは、Xamarin.FormsをXAML標準（https://github.com/Microsoft/xaml-standard）に移行するという全体的な目標に確実に貢献します。 しかし、VisualStatesとともに、これが実際にどれほど役立つかについては大きな疑問符があります。

これらの種類の領域でのグラフィカルな加速を考慮に入れる必要があります。 グラフィックアクセラレーションの欠如は、アニメーションなどのシステムの一部ですでに問題になっています。 私の推測では、Xamarin.Formsがベクターイメージングのレンダリングを担当する場合、その後、基盤となるプラットフォームから削除され、GPU処理からCPU処理に移行されます。 これは、場合によってはパフォーマンスに大きな打撃を与えるでしょう。 やるべきではないということではありませんが、CPUに移すのではなく、GPUレベルで処理を任せることができるかどうかを考えるべきです。 XFライブラリの利用者は、ネイティブプラットフォームで何が実行され、XFライブラリによって何がレンダリングされるかを知っておく必要があります。

ネイティブ描画とクロスプラットフォーム描画の違いのバランスの問題もあります。 テキストは重要なポイントです。 テキストはすべてのプラットフォームで同じようにレンダリングする必要がありますか？ つまり、すべてのプラットフォームで均一性を実現するために、フォントレンダリングをXFに渡す必要がありますか？ 多分。 しかし、それがXFの全体的なプロジェクトになるべきだとは思いません。 人々は無意識のうちに小さな視覚的な詳細を検出します。 詳細はアニメーションなどにあるかもしれません。 特定のプラットフォームの標準から少し外れただけでも、ユーザーは不快に感じる可能性があります。 したがって、すべての描画を均一にすることは必ずしも良い考えではありません。 Avaloniaは確かにその道を進んでいますが、それは完全に別のケースであり、それがAvaloniaとXamarinFormsの違いのポイントです。

また、もう1つのコメントは、プリミティブ型の名前が同じであり、XAML標準と一致するようにUWPやWPFなどの他のプラットフォームにできるだけ近い位置に配置されるように注意する必要があるということです。

@davidortinau 、これについて考えはありますか？

マテリアルデザインの優れた機能の1つは、リップルです。 これをサポートする予定ですか？
全体的に、これは素晴らしいと思います！

私はこの方向が本当に好きです。 iOSの場合、ネイティブ要素（i、>オプション）を使用してネイティブビューセルを使用していましたが、カスタムテーマを適用すればするほど、ネイティブセルを少し模倣し、流暢で見栄えの良い/機能するテーマをさらに追求するようになります。アプリでは一貫性がありますが、詳細を除けばそれ自体はネイティブではありません。 適切な基礎となるレンダリングライブラリを使用すれば、GPUは問題にならないだろうと思います。Skiaを読んでください。 Flutterに電力を供給しているのと同じもの。

おそらくそれは別の問題ですが、同時にSVGをFormsの第一級市民にするのは素晴らしいことです。 たとえば、押したときに画像ボタンのアニメーションの色合いなどのすっきりとした効果を有効にします。

私の意見では、プラットフォームのネイティブな癖に対応するという奇妙な例外を除いて、最終的には、クロスプラットフォームで一貫した動作でプログラミングしやすい、強力でリッチなネイティブな外観の（それ自体はネイティブではありません！）コントロールが必要です。 たとえば、Androidの波及効果。

@ChaseFlorellは、実際のところ私が行っています。 テンプレート内の物にx：Nameを付けてから、FindByNameを使用してそれらを掘り下げることができるという考えです。 ネイティブ要素を取得したら、他の要素と同じようにアニメーションを適用できますが、アニメーションコールバックを取得する特別な方法がある可能性があります。 私はまだそれらの正確な詳細を検討しています。 Skiaを使用すると、Androidで60FPSを簡単にヒットでき、Skiaがなくても、他のプラットフォームで60FPSをヒットできます。

@rogihee SVGは実際には出荷形式ではありません申し訳ありません：/ SVGを一貫してクロスプラットフォームにレンダリングしようとする責任を負いたくありません。 とにかく彼らはいつSVGにヒントを追加するつもりですか...

@jassmith 、これはハードウェアグラフィックアクセラレーションですか？

QtのQMLから来て、これを見たいです。 いくつかの明らかな組み込みコントロールと組み合わせると、多くのことを理解できます。

少し時期尚早であるか、別の問題に値するかもしれませんが、これに基づいて構築されたコントロールのアクセシビリティ/テスト容易性のストーリープランは何ですか？

@ RichiCoder1 a11yは確かに、適切に解決する必要があるものです。 理想的には、Text要素は、単純なコントロールに必要なプロパティのほとんどを自動的に設定します。

これはxf4.0の機能ですか？

3.0シリーズ

@jassmithロードマップには描画とシェルについては何もありません

AFAIKの公開ロードマップには、完全にスケジュールされていないものは含まれていません

これらすべてのプレビューは2018年に行われますか？@jassmith

@juepiezhongren私たちはこれらの提案をすることを約束していません。 それらは、それらの長所、短所などについてのオープンな議論のためにここに提示されます。

私はあなたの興味から、これらのスペックがあなたにとって興味深いものだと思います。 Xamarin.Formsを使用してアプリを構築するときに、それらが役立つと思われる具体的な例をいくつか教えてください。 これでどのような問題が解決すると思いますか？ 彼らがあなたのためにどのような機会を開いていると思いますか？

共有できる実際の例やストーリーは、これが真の価値を提供している可能性があることを検証するのに非常に役立ちます。

いつものように、必要に応じて誰でも私に電子メールを送ってください。 デビッド。 [email protected]

私にとって最大の問題は、潜在的な顧客とUX / UIに提供しなければならない「Formsフレームワークではそれができない」という回答です。 それはフレームワークを信用しません、そして私は顧客と非常に多くのチャンスを得るだけです。

フォームには、私たちが広報する構成パラダイムが欠けています。 プロジェクトは、UIプリミティブを使用してUIを構築できます。 これは、ナビゲーション、アニメーション（ヒーローアニメーションなど）、UI要素、ジェスチャーに適用されます。

この提案は、そのようなプラットフォームに中立な構成UIプリミティブを提供しますか？

@timahrentlovこれらの制限が何であるか、およびそれらの制限の理由について話し合い、正確に確認する必要があります。 しかし、正直なところ、私はあえてそこまで考えたり見たりすることさえしません。 Xamarin Formsで私が目にする問題は、はるかに単純な観点からのものです。それでも、開発リソースが非常に限られたプロジェクトのままです。 実際に十分な電力と燃料がないのに、それが何ができるかを議論することは非現実的または役に立たない。 要点がわかりません。 Xamarinは、OSSコミュニティの一部の個人が作業を開始し、問題を修正し始めることを密かに望んでいるのでしょうか。 誤解しないでください。XamarinがXamarinフォームに費やした時間と労力を尊重します。

@davidortinau
クロスプラットフォームは、特徴的なビジュアルデザイン、ユニークなボタンの外観、ユニークなプレースホルダーの消失効果などを理解するのが難しいです。r私たちのアプリが同一であることを本当に避けます。 たとえば、わずかな爆発を伴うmacの通知のフェードは、顧客を感動させるのは非常に簡単です。 その日にwpfが大好きな理由のひとつは、コントロールテンプレートです。ここでは、角のある六角形のボタンのように、独自性のためにパスを非常に楽しんでいます。 xfがこれらをクロスプラットフォームのクライアント開発者に提供することを望んでいます。

@juepiezhongrenそのようなUIのカスタマイズを探しているなら、それを実行できるクロスプラットフォームフレームワークはないと思います。 また、WPFについて：WPFとモバイルを混在させることはお勧めできません。

私のチームもreactnativeを使用しています。ここでは、非常に多くのjserが多大な貢献をしており、3か月後にはまったく生産的ではないと結論付けました。 xfの場合、欠点とバグがありますが、基本的には固溶体であり、epsx.nativeはすべてのネイティブAPIを有効にします。 欠けているのは、ユビの外観だけで、フラッターの最近のマフネスを考慮しています。 その上、シェルを使用すると、フラッターは役に立たなくなり、flutter.iosのようなものがなければ、フラッターはネイティブAPIの無限の苦しみを伴うrnのようになります。

@opcodewriter
私たちはskiasharpをかなり頻繁に使用し、特別な制御を行い、そのパフォーマンスは満足のいくものです

@jassmithは、webglを使用してmaterialShellをwasmに移植することを検討しました。skiaの場合、ダウンロードするには大きすぎる可能性があります

正解です。デフォルトの描画APIについて、サードパーティのライブラリを徹底的に調べたくありません。 \それを行うことができます

xamarin.monoとshellin wasmを使用すると、アルファ製品があれば、ドットネットに対する憎悪が蔓延している中国でドットネットのルネッサンスが発生します。

@jassmithこの問題について何か良いニュースはありますか？

@juepiezhongrenでどんなニュースを探していますか？ この時点で、ディスカッションを呼び出すために投稿された仕様です。

ドローとシェルがいつroadmap @ ChaseFlorellに含まれるかを確認したい
ユニバーサルレンダリングは、アバロニアとフラッターに対して非常に有効です

これに関するタイムラインは、私の個人的な開発速度に依存します。 ここでの目標は、チーム全体をこれらの取り組みに集中させることではなく、私をその努力に惜しまないことです。 シェルブランチが一緒になるのを見たい場合は、シェルブランチを追跡できます。 シェルが描画した後。

注として、私は非常に迅速に描画の垂直スライスを立ち上げてから、コミュニティがそれをより速く完了したい場合は助けを求めるつもりです。

これはすべて非常に優れていますが、グラフィックアクセラレーションを使用しますか？

@jassmith on ios、system.drawを使用します。 アンドロイドでは、skiasharpを使用する|| すべてのもののためのskiasharp？

@juepiezhongrenは複数のバックエンドをサポートするため、Skiaを使用する場合は、Skiaを使用します。ネイティブの描画APIを使用する場合は、代わりにそれを使用します。 デフォルトでは、ネイティブバックエンドを使用し、Skiaがオプトインされるため、依存関係が強制されることはありません。

@jassmith system.drawはiOSで利用できますが、Androidでは利用できません。

@juepiezhongrenがSystem.Drawingのサポートを追加することは、ここでの私の範囲内のものではありません。 ただし、この仕様ではSystem.Drawingを使用するものはありません。

基本的に、描画によってレンダリングがはるかに少なくなります

実際には、図面はそれらをレンダリングする何かによって裏付けられている必要があります。 カスタムレンダラーの必要性が少ないという意味でない限り、その場合はそうです。

私は「wpf / uwpにできるだけ近づける」キャンプにいます。これは、このあたりで常に最も人気のある位置であるとは限らないことを私は知っています。

しかし、これは、すべてのレンダリングを実行するフレームワークで完全に見栄えが悪いことと、現在のXFパラダイムとの間の大きな妥協点のようです。

プリミティブには各プラットフォームに対応するものがあると思います。したがって、ハードウェアアクセラレーションは問題になりません。 Windows / iOS / Android / etcはまだ長方形、円、グラデーションなどをレンダリングしており、ハードウェアアクセラレーションをすでに使用しているのと同じ程度に使用します。 これにより、コントロールデザイナーは、AppleのボタンとMicrosoftのアイデアに固執するのではなく、プリミティブを使用してコントロールをデザインできるようになります。

私はそれを正しく要約しますか？

@pmoorelegistekそれは基本的にそうです。 そして、私たちは最初にマテリアルに取り組んでいます。これは主に、主要なデザイン要素としてブラーが背後にないためです。 これは、実際にどこでも機能させることができることを意味します（Androidを見てください）。

Shell v1を終了すると、すぐにこれに移行します

@jassmithこれは金色です。 UXデザインに適合するネイティブコントロールを使用し、それを必要とする（できれば少数の）デザイン要素に対してのみ、skiaのような描画コントロールを簡単に追加します。

「XamarinFormsではそれができない」というデザイナーや顧客との話し合いはもうありません。 これにより、（フラッターとは異なり）真のネイティブ感を維持しながら、デザインの制限がなくなります。

マテリアルシェルの前にこれを見てみたいです。 これにより、XFの実際の制限が解決されます。
シェルは、簡単/迅速に開始するためのn番目の機能です。 _started_を取得することはあまりにも長い間焦点でしたが、_further_を取得するためのこのような機能はXF開発者をオンボードに_維持します_。

Material Shellはこれに依存しているため、これはMaterialShellの前に発生する必要があります。 シェルの前にこれを見たいと言うつもりだったと思いますか？

シェルは、より速く/より簡単に始めることに焦点を合わせていません。 これは、ページを独自のコントロールとして使用できない方法でページを最新化することを目的としています。 基本的には完全に置き換えることを目的としており、移植を検討することをお勧めします。 Shellは、エンドユーザーにはるかにスムーズでリッチなエクスペリエンスを提供することに重点を置いており、アニメーションをカスタマイズできます。アニメーションの前後に遅延/遅延読み込みを行うことができるため、問題が発生することはありません。 これは、Androidで0 GPUのオーバードローコンテンツ領域を提供します。これを、オーバードローがチャートの「red gofuckyourself」の部分にある現在のページと比較してください。

Shellは、人々をより早く始めることではなく、アプリをより速くすることです。 Shellを使用すると、たとえば、ページ/タブ/グループを「頻繁」としてマークすることができ、ユーザーが常にアクセスすることを前提として、システムによって保持されます。 これは、あなたが離れて戻ってきたときに彼らがリロードしないことを意味します。 シェルがページの階層全体を所有しているため、これを行うことができます。

シェルでの描画パフォーマンスを最適化する方法についてもいくつかの考えがあります。シェルに描画を制限することは決してありませんが、すべての描画を同じパスで実行できる可能性があるため、シェルでの描画がはるかに効率的になる可能性があります。 このスパイクはまだ行われていないため、ここで必要な塩の粒ですが、紙の上ではまともなように見えます。

@weitzhandler今後4〜6週間でこれに移行したいと思っています。 これにより、そのシェルを動作させるのがはるかに速くなります。 それらの時代のどれも石に設定されていません。

+1

@jassmith https://github.com/nventive/Uno
それは素晴らしい。
ユニレンダリングは素晴らしいです

フォームは急進的な探検家になり、ウノは保守的な探検家になります
私たちは両方が大好きです

+1優れた機能それは私たちができるだけ早く見たい多くのカスタムUIの問題を解決します

@jassmithは3.3.0で抽選が行われるようです。

これに関する更新はありますか？

私たちにとって、これはXamarinに実装してもらいたい最も魅力的な機能です。

私たちは主にLoBアプリを開発しており、最優先事項の1つは開発速度です。
きちんとした仕事をし、うまくレンダリングし、開発時間もかからない魅力的なUIがある限り、ネイティブのルックアンドフィールはあまり気にしません。

各プラットフォームで各フォームとページを個別にテストして調整する必要があることは、リアルタイムのキラーであり、UIの小さな変更は、すべてのプラットフォームで3回チェックする必要があります。

Shell＆Material Shellは祝福であり、素晴らしいニュースです。これを推進してください。 これは、ユーザーを他の場所（Uno、Flutterなど）に移動させ続ける唯一のものです。

3.3ではドローが表示されない悲しいニュース

+ 1、uwpのバックグラウンドから来て、私は本当にXFを使用したいのですが、欠点があります。現在、フラッターを試していますが、これができるだけ早く実装されれば、確実にXFに到達します。

これはすばらしい機能であり、実装する必要があることに同意します。たとえば、実線、点線などの線のスタイルも含めます。

連絡あった？ 予定？ ロードマップ？

おかしなことに、昨夜、カスタムレンダラーを試してみたところ、独自のプリミティブをカスタムビューとして定義し、それらを基に構築するだけで、これをすべて実行できるとほぼ結論付けました。 Border、Ellipse、Line以上のものは必要ありません。
これが正式にサポートされるのを楽しみにしていますが、私は待っていません。 :)

@jassmith
たとえば、 LineとRectangleは、実際のビューになりますか？ （この例では、子ビューとしてEllipse Gridがあることがわかります）。 意思
TapGestureRecognizerをRectangleに追加して、タップイベントを処理することはできますか？
これらは実際のビューであるため、プリミティブを描画するための実際のビューがレンダリング速度に悪影響を与えることはありませんか？

@andreinitescu Xamarinフォーム側の実際のビューであることが意図されていると思いますが、ネイティブのビューとして実現されることは決してありません。

_描画プリミティブは、レンダラーを持たない単なるビューです_

したがって、チェーンのさらに上流のレンダラー（ Drawing ？ DrawingTemplate ？）は、描画可能な子孫を反復処理して描画する責任があります。

これは、 CompressedLayout.IsHeadlessが設定されたレイアウトに適用されるのと同じ種類の制限が適用されることを意味すると思います（ジェスチャ認識機能、効果、変換などはありません）。

@GalaxiaGuy私は同じ方針で考えていますが、グリッドのような実際のビューと混ざっているため、少し混乱します。 本当に必要ですか？ ビューから派生する代わりに、これらを抽象描画要素として使用しないのはなぜですか（共通のプロパティを持つDrawingElementと呼ばれる基本抽象クラスがあるのではないでしょうか？）

ニースジョブちょうど正しいサンプル

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button.Template> --> correct this line
</Button>

多分それは4.0になりますか？

Drawingは、ターゲットプラットフォームに依存しないグラフィックスプリミティブを使用してコントロールを実装するという点で優れています。 以前はNControlがありましたが、これには問題があり（netstandard2.0より前、SkiaSharpより前の日から）、更新されていません。

仕様1.SkiaSharpではるかに完全な形式ですでに実装されている機能を複製します。2。すでに保守不可能なXamarin.Formsリポジトリ内にあるXAML / Bindingを介して不要な複雑さのレイヤーを追加します。

より良いアプローチは、SkiaSharpに基づいて小さなコントロールライブラリを作成することです。 NControl ++

@jassmith @rogihee SVGは実際には出荷形式ではありません申し訳ありません：/ SVGを一貫してクロスプラットフォームにレンダリングしようとする責任を負いたくありません。

SkiaSharpはSVGをサポートしています。

これについて何かニュースはありますか？

これについて何かニュースはありますか？

また、これがまだ発生する可能性があるかどうか疑問に思います。 私は見た目のないクロスプラットフォームのUIフレームワークを望んでいますが、これがそれを実現するための最良の方法のようです。

@legistekSkiaSharpを使用して見栄えの悪いクロスプラットフォームの描画を行うことができます。 Xamarin.Forms固有のものの利点は何ですか？

UIフレームワークには、描画よりも少し多くのことがあります。

しかし、このスレッドでは、UIフレームワークではなく描画フレームワークについて説明しています...

_XamarinForms_の描画フレームワークについて話し合っていると思いました。

SkiaSharpは、Xamarinフォームの描画フレームワークです。 他の.NetUIプラットフォームでも機能するという事実は、確かに長所であり、短所ではありません。

OPで述べたように、SkiaSharpは個々のプラットフォームの基盤となる描画エンジンになる可能性がありますが、この提案のアイデアは、抽象化レイヤーを追加し、XAMLを介した描画をサポートし、そのすべての利点を備えています。最も注目すべきものはデータバインディングです。 あなたが不必要な複雑さと呼ぶものを私はエレガントと呼びます。

これはまだ生きていますか、および/またはMAUIにロールインされますか？

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-ロードマップには、Xamarin.Forms 4.7.0のロードマップと同様に、シェイプ、パス、およびブラシが一覧表示されます。

素晴らしいニュース！ ありがとう！