Xamarin membentuk perender wpf dan beberapa perender android seperti ButtonRenderer cepat, dan kita tahu apa yang dimaksud dengan "cepat" di sini.
Apakah penyaji ini akan cepat atau tidak?
Terima kasih sebelumnya.

@ysmoradi Ya! Penyaji baru ini akan mengikuti pola penyaji cepat (yaitu, tidak ada tampilan pembungkus di sekitar tampilan utama). Kami berencana melakukan ini untuk semua platform, bukan hanya Android dan WPF.

Tolong jangan mencoba untuk tetap kompatibel dengan cara apa pun. Ini adalah sesuatu yang baru. Itu tidak harus kompatibel dengan XF. Anda dapat membuat sesuatu yang lebih baik.

Mengapa tidak membuat kerangka UI dengan set kontrol sendiri tanpa pemetaan dan logika perilaku apa pun yang sepenuhnya ditulis pada c # yang akan dirender dengan pustaka grafis Skia? Karena orang menggunakan desain yang sangat disesuaikan, tidak perlu mencoba mencocokkan pedoman desain platform. Satu-satunya kebutuhan adalah kemungkinan penyesuaian yang fleksibel. Harap perbaiki saya jika saya melewatkan sesuatu, tetapi saya tidak mengerti mengapa manfaatnya melebihi arsitektur Renderer.

Dengan pendekatan ini, apakah mungkin untuk menulis perender lintas platform alih-alih perender khusus platform? Seperti memetakan Kontrol tombol dengan kontrol skia-tajam.

Renderer platform adalah desain yang buruk. Seperti yang Anda lihat, ada banyak lib kontrol xamarin yang tidak mendukung UWP karena batasan platform.
Ambil contoh, bayangan di UWP. Anda tidak bisa mendapatkan bayangan sudut dari tombol sudut (tentu saja, Anda dapat mengubah template tombol untuk melakukan ini, tapi itu hal lain).

Saya tahu sangat sulit untuk membangun render lintas platform. Tapi flutter memberi tahu kami bahwa ini layak. Dalam jangka panjang, penyaji lintas platform adalah solusi terbaik.

Saya pikir membuat seluruh aplikasi sebagai kanvas 2d khusus mungkin berfungsi dengan mulus untuk aplikasi seluler.

Tetapi mungkin tidak berfungsi untuk aplikasi desktop atau aplikasi kompleks karena ada begitu banyak tindakan pengguna yang perlu diimplementasikan kembali seperti drag-drop, pemilihan teks, pintasan keyboard untuk memanipulasi teks dan sebagainya.

Mengapa tidak membuat kerangka UI dengan set kontrol sendiri tanpa pemetaan dan logika perilaku apa pun yang sepenuhnya ditulis pada c # yang akan dirender dengan pustaka grafis Skia? Karena orang menggunakan desain yang sangat disesuaikan, tidak perlu mencoba mencocokkan pedoman desain platform. Satu-satunya kebutuhan adalah kemungkinan penyesuaian yang fleksibel. Harap perbaiki saya jika saya melewatkan sesuatu, tetapi saya tidak mengerti mengapa manfaatnya melebihi arsitektur Renderer.

Saya pikir membuat seluruh aplikasi sebagai kanvas 2d khusus mungkin berfungsi dengan mulus untuk aplikasi seluler.

Tetapi mungkin tidak berfungsi untuk aplikasi desktop atau aplikasi kompleks karena ada begitu banyak tindakan pengguna yang perlu diimplementasikan kembali seperti drag-drop, pemilihan teks, pintasan keyboard untuk memanipulasi teks dan sebagainya.

Mengapa tidak membuat kerangka UI dengan set kontrol sendiri tanpa pemetaan dan logika perilaku apa pun yang sepenuhnya ditulis pada c # yang akan dirender dengan pustaka grafis Skia? Karena orang menggunakan desain yang sangat disesuaikan, tidak perlu mencoba mencocokkan pedoman desain platform. Satu-satunya kebutuhan adalah kemungkinan penyesuaian yang fleksibel. Harap perbaiki saya jika saya melewatkan sesuatu, tetapi saya tidak mengerti mengapa manfaatnya melebihi arsitektur Renderer.

Anda benar tentang semua hal ini, tetapi tim tidak dipaksa untuk memilih satu-satunya pendekatan. Saya pikir ini semua tentang kurangnya waktu. Maksud saya, mereka hanya perlu merilis kerangka kerja ui lintas platform sepenuhnya "baru" dalam setahun bersama-sama dengan .net 6. Dan jauh lebih kecil risikonya untuk menggunakan kerangka kerja lama yang telah teruji waktu sebagai dasarnya. Tidak apa-apa dan seharusnya begitu. Tetapi saya percaya bahwa dalam jangka panjang, rendering kanvas 2d kustom memiliki lebih banyak manfaat dan benar-benar layak disebut "lintas platform". Bentuk Xamarin adalah hal yang sangat bagus dan memiliki kemajuan besar untuk hari ini. Tapi sudah waktunya untuk melanjutkan. Tim Microsoft dan xamarin memiliki insinyur yang sangat pintar dan mereka mungkin mempertimbangkan pendekatan seperti itu atau bahkan mungkin memiliki beberapa koneksi dengan http://avaloniaui.net/ sebagai kartu truf

Mengapa tidak membuat kerangka UI dengan set kontrol sendiri tanpa pemetaan dan logika perilaku apa pun yang sepenuhnya ditulis pada c # yang akan dirender dengan pustaka grafis Skia? Karena orang menggunakan desain yang sangat disesuaikan, tidak perlu mencoba mencocokkan pedoman desain platform. Satu-satunya kebutuhan adalah kemungkinan penyesuaian yang fleksibel. Harap perbaiki saya jika saya melewatkan sesuatu, tetapi saya tidak mengerti mengapa manfaatnya melebihi arsitektur Renderer.

Mungkin keren untuk memiliki render default abu-abu ke-4 untuk pengembang Skia yang akan 100% mengubahnya untuk memberikan desain yang kaya,
Untuk kompatibilitas mundur akan membiarkan 3 itu apa adanya tetapi tambahkan " gambar sendiri pengembang yang terhormat"_skia_render dan ambil tanggung jawab 90% untuk pengembangnya.

Jika konsep penyaji ingin dipertahankan, dapatkah dipikirkan untuk menghilangkan jembatan antara kode UI bersama dan penyaji melalui INotifyPropertyChanged dan pengendali acara? yaitu

• Alih-alih menyetel _property_ pada kontrol bersama dan peristiwa PropertyChanged disebarkan, dapatkah properti dipetakan dan disetel langsung pada perender platform?
• Alih-alih memanggil _method_ pada kontrol bersama dan peristiwa yang dipicu dan ditangani oleh perender, dapatkah metode dipetakan dan dilibatkan langsung pada perender platform?

INotifyPropertyChanged sangat bagus untuk desain MVVM dan model tampilan pasangan longgar, tetapi selalu terasa kikuk sebagai mekanisme jembatan antara kode UI bersama dan perender platform. Hal ini pada gilirannya akan menghasilkan kinerja yang lebih baik, lebih sedikit 'obrolan' antara UI bersama dan lapisan penyaji, serta pengalaman pengembang yang lebih baik.

Ini panjang tapi layak ditonton untuk beberapa "inside baseball" di Maui.
https://www.youtube.com/watch?v=_MGh3xipWm4

Sepertinya arsitektur Maui akan mendukung kontrol platform-rendered dan kontrol kanvas, dan selanjutnya @Clancey yang mulia akan terus bekerja pada set render berbasis skia untuk Maui yang tidak hanya akan bekerja dalam rasa MVU dari Maui tetapi juga untuk pola MVVM.

Sepintas Maui tampak seperti rebranding Forms, tetapi pada pemeriksaan lebih dekat itu adalah restrukturisasi arsitektur Forms untuk membuat lapisannya lebih longgar digabungkan dan dengan demikian mendukung banyak hal yang kami tanyakan di utas ini. Saat-saat menyenangkan di depan.

Ini sedikit keluar dari topik, tetapi merupakan sesuatu yang ingin saya tanyakan hanya karena relevansinya dengan hal yang tepat ini:

Bagaimana cara kerja memori dengan SKCanvasView (atau Skia secara umum)? Apakah masing-masing selalu mengambil memori sebanding dengan ukurannya? Apakah ini berubah jika tumpang tindih dengan yang lain?

Jika, misalnya saya memiliki kontrol gradien (perender yang ditulis dalam Skia) dan di atasnya saya memiliki tombol semi transparan (perender yang ditulis dalam Skia) apakah itu akan memakan memori dua kali lebih banyak, atau apakah konteks grafis entah bagaimana dibagikan? Bagaimana jika kontrol Skia tumpang tindih dengan kontrol non-Skia?

Saya telah mempertimbangkan untuk menerapkan beberapa kontrol grafis mewah dalam Formulir menggunakan Skia sebelumnya, tetapi tidak memahami cara kerja memori selalu menyebabkan cukup banyak kekhawatiran yang belum saya lakukan.

@GalaxiaGuy Saya pikir menggunakan kontrol skia tumpang tindih pada kontrol non-skia, seperti kontrol winform yang dihosting di kontrol wpf. Anda dapat melakukan ini, tetapi bukan yang terbaik.
Jika Anda memiliki dua kontrol yang dirender oleh SKCanvasView , konteks grafis tidak akan dibagikan. Cara terbaik adalah menggabungkan dua yang dirender dan menggambarnya di satu kanvas.
Dalam pengujian saya, kinerja SkiaSharp tidak terlalu buruk jika Anda hanya melakukan beberapa hal statis. Dan saya mencoba membuat beberapa animasi, penggunaan CPU di laptop saya sedikit tinggi.

Mengapa begitu banyak orang terobsesi dengan Skia? Spesifikasi rendering yang baik akan agnostik terhadap mesin rendering yang digunakan pada level rendah. Jika perender platform tertentu ingin menggunakan Skia (atau Direct2D atau OpenGL atau apa pun) itu seharusnya bukan sesuatu yang perlu dikhawatirkan oleh lapisan aplikasi.

Janji terbesar XAML dengan WPF berabad-abad yang lalu, adalah gagasan tentang Lookless Controls di mana grafik kontrol yang sebenarnya ditangguhkan ke template. Formulir Xamarin menggunakan XAML tanpa kemampuan ini, dan ini adalah titik terlemahnya, hanya beberapa tahun kemudian sebagian diperbaiki oleh spesifikasi Gambar.
Saya tidak berpikir bahwa kita memerlukan satu set antarmuka dan abstraksi atas komponen yang ada di berbagai OS dan kerangka kerja, tetapi kontrol yang benar-benar tidak terlihat berbasis XAML -

Janji terbesar XAML dengan WPF berabad-abad yang lalu, adalah gagasan tentang Lookless Controls di mana grafik kontrol yang sebenarnya ditangguhkan ke template. Formulir Xamarin menggunakan XAML tanpa kemampuan ini, dan ini adalah titik terlemahnya, hanya beberapa tahun kemudian sebagian diperbaiki oleh spesifikasi Gambar.

Sepakat! Dan Anda benar-benar membutuhkan sejumlah kecil rendering primitif untuk mencapai mungkin 99% dari semua yang dibutuhkan aplikasi:

• Perbatasan (termasuk opsi untuk bayangan jatuh dan tepi membulat)
• Garis / Elips / Persegi Panjang
• Render teks biasa
• Masukan teks biasa
• Rendering teks kaya
• Masukan teks kaya
• rendering HTML
• Penyaji gambar
• Penyaji Audio/Video
• Kuas Solid dan Linear / Radial Gradient

Platform rendering XF menjadi sangat membengkak karena setiap kali jenis kontrol baru ditambahkan ke kerangka kerja, itu dilakukan dengan penyaji baru daripada membangun di atas primitif yang ada dalam kerangka kerja.

Ya lebih banyak logika harus dipindahkan ke lapisan kerangka kerja, yang paling menantang adalah ketika datang ke kontrol item ( VirtualizingStackPanel sangat penting untuk memiliki penampil item yang dapat diskalakan tetapi sepengetahuan saya tidak pernah secara efektif porting di luar dari WPF karena sangat kompleks). Tetapi dengan WPF menjadi open source, banyak yang dapat di-porting ke MAUI sekarang dan saya pikir inilah saatnya ketika itu harus mulai terjadi.

Anda benar-benar membutuhkan sejumlah kecil rendering primitif untuk mencapai mungkin 99% dari semua yang dibutuhkan aplikasi.

Platform Uno menggunakan pendekatan ini.

@velocitysystems

Alih-alih menyetel properti pada kontrol bersama dan peristiwa PropertyChanged disebarkan, dapatkah properti dipetakan dan disetel langsung pada perender platform?

Itu juga merupakan tujuan besar dari perubahan ini. Setelah kita berada di sisi lain dari perubahan ini, penyaji tidak akan tahu apa artinya BindableObject atau INPC

Itu juga merupakan tujuan besar dari perubahan ini. Setelah kita berada di sisi lain dari perubahan ini, penyaji tidak akan tahu apa artinya BindableObject atau INPC

Jadi metode pada perender akan dipanggil oleh kerangka kerja setiap kali nilai BindableProperty berubah alih-alih perender harus berlangganan PropertyChanged ?

@legistek benar

Ini pada dasarnya membalikkan dependensi

Jadi penyaji hanya akan bekerja melawan IButton.

Dan kemudian System.Maui akan menambahkan referensi ke proyek penyaji yang bertentangan dengan sekarang bagaimana penyaji memiliki referensi ke Xamarin.Forms.Core

Saya memeriksa lonjakan yang kami miliki di sini
https://github.com/dotnet/maui/pull/66

Jadi Anda bisa melihat seperti apa ini

Saya akan melakukan streaming hari ini pukul 3:30 waktu PDT dengan @davidortinau dan kita akan berbicara tentang perender ramping

https://www.twitch.tv/microsoftdeveloper

Bergabunglah dengan kami! Coba lihat! Dan ajukan pertanyaan!

@PureWeen Sayangnya saya melewatkannya. Apakah akan ada rekaman yang tersedia di YouTube?

Itu juga merupakan tujuan besar dari perubahan ini. Begitu kita berada di sisi lain dari perubahan ini, penyaji tidak akan tahu apa arti BindableObject atau INPC.

Itu sangat besar, peningkatan substansial yang nyata. Tidak diragukan lagi dengan pindah ke Maui, model pewarisan kompleks yang digunakan di banyak penyaji akan dihapus demi pendekatan yang lebih komposisional?

Akan mengulas # 66 hari ini.

Melihat #66, bagus untuk melihat perender ramping dibangun dan dipanggil dengan 'umpan-dan-switch' daripada menggunakan refleksi. Hanya beberapa pemikiran:

• Akankah perender Slim mengatasi masalah GC, terutama di Android di mana ada ketidakcocokan antara siklus hidup kontrol terkelola dan asli? Ini terutama terlihat pada tampilan anak dalam tata letak tervirtualisasi yang mengarah ke ObjectDisposedException ditakuti.
• Akankah perender Slim menyebabkan penghentian Effect ? Efek dapat berguna, tetapi pada akhirnya mereka menambah kompleksitas dan potensi latensi lain untuk siklus hidup tata letak.
• Bagaimana cara kerja properti 'dua arah' dengan desain penyaji baru? Misalnya, katakanlah saya memiliki MediaElement dengan properti Posisi ( TimeSpan ). Setter memperbarui posisi saat ini, dan pengambil mengambil posisi saat ini dari pemutar media asli yaitu AVPlayer , MediaPlayer . Apakah ada desain untuk memetakan _getter_ dengan perender ramping?

Akankah perender Slim mengatasi masalah GC, terutama di Android di mana ada ketidakcocokan antara siklus hidup kontrol terkelola dan asli? Ini terutama terlihat pada tampilan anak dalam tata letak tervirtualisasi yang mengarah ke ObjectDisposedException yang ditakuti.

Kami punya beberapa ide di sini!! Kami ingin sedikit menyusun ulang strategi pembuangan untuk menyelesaikan sebagian besar jika tidak semua pengecualian ODE. Saat ini kami dengan sangat agresif membuang semua yang ada di Android/iOS, tetapi saya cukup yakin kami hanya dapat mengandalkan GC untuk melakukan apa yang dilakukan GC. Jika kita hanya memastikan untuk mereferensikan semuanya dan membiarkan GC melakukan pekerjaan yang seharusnya membantu dalam banyak kasus ini

Akankah perender Slim menyebabkan penghentian Efek? Efek dapat berguna, tetapi pada akhirnya mereka menambah kompleksitas dan potensi latensi lain untuk siklus hidup tata letak.

Ini jelas merupakan hal yang baik untuk dilihat saat kami mengembangkan ide ini. Setelah kita mencapai desain akhir untuk semua ini, kita akan melihat efeknya. Tapi, ya, saya bisa melihat efek yang sudah usang karena dimaksudkan sebagai cara untuk memanfaatkan elemen asli tanpa harus menjadi penyaji penuh. Pemeta pada dasarnya efek usang

Bagaimana cara kerja properti 'dua arah' dengan desain penyaji baru? Misalnya, saya memiliki MediaElement dengan properti Position (TimeSpan). Setter memperbarui posisi saat ini, dan pengambil mengambil posisi saat ini dari pemutar media asli yaitu AVPlayer, MediaPlayer. Apakah ada desain untuk memetakan pengambil dengan perender ramping?

Kami masih mengerjakan yang ini sedikit. Perbaiki saya jika saya salah @Clancey tetapi ActionMapper adalah pendekatan kami saat ini untuk ini ya? https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

Bagaimana cara kerja properti 'dua arah' dengan desain penyaji baru? Misalnya, saya memiliki MediaElement dengan properti Position (TimeSpan). Setter memperbarui posisi saat ini, dan pengambil mengambil posisi saat ini dari pemutar media asli yaitu AVPlayer, MediaPlayer. Apakah ada desain untuk memetakan pengambil dengan perender ramping?

Kami masih mengerjakan yang ini sedikit. Perbaiki saya jika saya salah @Clancey tetapi ActionMapper adalah pendekatan kami saat ini untuk ini ya? https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

Tidak tepat. Jadi ActionMapper adalah hal yang sama dengan PropertyMapper dengan pengecualian, mereka tidak dipanggil selama fase SetElement. Jadi, untuk hal-hal seperti WebView, GoBack. Anda tidak ingin memanggil itu selama inisialisasi tetapi itu masih sesuatu yang Anda butuhkan untuk berkomunikasi dengan Renderer.

Kami sudah mendukung pemetaan 2 arah. yaitu Masuk. Ketika peluang nilai teks pada entri. IEntry memiliki string Text {get;set;} dan kita cukup mengatur nilainya. Jadi untuk elemen media Anda memiliki 2 opsi. Salah satunya cukup mengatur kembali posisi/waktu ketika berubah. Jika Anda ingin menjadikannya sesuatu yang Anda minta sebagai gantinya. Kamu bisa melakukannya. Tampilan xplat memiliki akses ke penyaji. view.Renderer.NativeView as NativeMediaView Anda dapat menggunakan properti apa pun yang Anda inginkan!

Berikut adalah beberapa video dari streaming kami selama Build

@Clancey di sini akan lebih mendalam
https://www.youtube.com/watch?v=_MGh3xipWm4

Saya menyentuh mereka sedikit di sini dengan David
https://www.youtube.com/watch?v=lAmwjfZY1IM

Bagaimana cara kerja properti 'dua arah' dengan desain penyaji baru? Misalnya, saya memiliki MediaElement dengan properti Position (TimeSpan). Setter memperbarui posisi saat ini, dan pengambil mengambil posisi saat ini dari pemutar media asli yaitu AVPlayer, MediaPlayer. Apakah ada desain untuk memetakan pengambil dengan perender ramping?

Kami masih mengerjakan yang ini sedikit. Perbaiki saya jika saya salah @Clancey tetapi ActionMapper adalah pendekatan kami saat ini untuk ini ya? https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

Tidak tepat. Jadi ActionMapper adalah hal yang sama dengan PropertyMapper dengan pengecualian, mereka tidak dipanggil selama fase SetElement. Jadi, untuk hal-hal seperti WebView, GoBack. Anda tidak ingin memanggil itu selama inisialisasi tetapi itu masih sesuatu yang Anda butuhkan untuk berkomunikasi dengan Renderer.

Kami sudah mendukung pemetaan 2 arah. yaitu Masuk. Ketika peluang nilai teks pada entri. IEntry memiliki string Text {get;set;} dan kita cukup mengatur nilainya. Jadi untuk elemen media Anda memiliki 2 opsi. Salah satunya cukup mengatur kembali posisi/waktu ketika berubah. Jika Anda ingin menjadikannya sesuatu yang Anda minta sebagai gantinya. Kamu bisa melakukannya. Tampilan xplat memiliki akses ke penyaji. view.Renderer.NativeView as NativeMediaView Anda dapat menggunakan properti apa pun yang Anda inginkan!

Hal lain yang perlu dipertimbangkan di sini adalah Catatan yang akan datang di C#9. Keistimewaannya adalah mereka tidak dapat diubah dan memiliki pengakses properti init . Jadi untuk membuatnya dapat digunakan dalam pengikatan dua arah, mapper harus dapat mengembalikan instance baru menggunakan operator with .

Saya sangat berharap tampilan dapat diikat ke rekaman, karena ini membuat banyak hal menjadi lebih mudah dalam hal MVVM murni atau bahkan MVU murni.

Pertanyaan: diagram yang Anda posting memiliki kontrol Windows yang dirender oleh Windows.UI.* , tetapi seperti yang saya pahami, yang sekarang sedang dalam proses ditinggalkan dan tidak akan melihat pembaruan apa pun: semua peningkatan pada render desain yang lancar adalah berlangsung di Microsoft.UI.* sebagai bagian dari proyek WinUI. Bisakah Anda mengomentari ini?

Saya pikir pemetaan ke kontrol asli adalah kesalahan besar, ini adalah bagian mengerikan dari Xamarin.Forms, Anda tidak dapat membuat tata letak yang unik dan indah dengan mudah, Anda harus mengikuti konsep dan pendekatan kontrol WPF dan Flutter tanpa penampilan dengan render engine yang ditulis dalam C ++ menggunakan OpenGL / DirectX / Metal, karena memfasilitasi portabilitas, kinerja dan fleksibilitas selain tidak tergantung pada struktur platform yang terus berubah.

Masalahnya ada di sini untuk berbicara tentang Pemetaan Arsitektur/Properti baru. Bukan apa yang mereka petakan. Hanya untuk mengulang. Slim Render Architecture untuk native bukan berarti kita tidak akan pernah, dan tidak akan pernah bisa melakukan pendekatan draw control. Tapi ini memungkinkan kami untuk mencampur dan mencocokkan kontrol asli vs non-asli di mana jika Anda murni menggambar, itu lebih sulit. Saya berencana untuk terus bekerja pada kontrol berbasis Skia yang mengikuti Arsitektur Slim Renderer yang sama, termasuk lapisan gambar. https://github.com/Clancey/Comet/tree/dev/src/Comet.Skia/Handlers.

2¢ saya pada hal penyaji ini (yang saya akui saya tidak sepenuhnya mengerti, TBH):

Saya memiliki ide tentang bagaimana kami dapat mengimplementasikan kedua kontrol yang diberikan platform (misalnya membungkus UIButton) _dan_ kontrol tanpa tampilan (ala WPF) menggunakan kelas kontrol yang sama. Ini cukup sederhana, jujur: Mintalah kelas Tombol Maui menggunakan templat kontrol, dan hapus semua kode penyaji khusus platform darinya. Kemudian, sediakan template dalam kotak untuk Button yang berisi ButtonRenderer. ButtonRenderer adalah yang berbicara dengan Cocoa/UIKit/UWP/etc, dengan kode khusus platform untuk setiap toolkit UI, dan kelas Button yang digunakan oleh pengembang aplikasi hanya meneruskan propertinya ke sana. Jika pengguna ingin menggunakan tombol yang digambar khusus, maka mereka cukup mengganti template dan menggunakan kelas menggambar (apa pun yang akhirnya terlihat seperti) alih-alih ButtonRenderer, seperti yang kita lakukan di WPF. Sejujurnya saya tidak tahu apakah ini sudah mungkin (atau bahkan sudah digunakan) di Maui hari ini, karena saya tidak pernah meluangkan waktu untuk memahami Xamarin.Forms sedalam saya memahami WPF.

Katakan padaku apa yang kau pikirkan!

Saya mencoba memahami apa arti perender Slim untuk model aplikasi yang berbeda (MVVM, MVU, ...).

Diagram awal tampaknya memberi tahu bahwa setiap model aplikasi yang berbeda akan memiliki kumpulan perendernya sendiri.
Tapi menurut saya, akan lebih baik untuk memiliki satu set renderer per jenis rendering (misalnya render ke kontrol asli seperti XF, render ke kanvas, dll.).
Perender tidak perlu mengetahui model aplikasi, hanya perlu mengetahui nilai apa yang dipetakan ke properti mana sehingga dapat menerapkan pembaruan yang benar ke kontrol yang mendasarinya.
Hanya IButton akan diimplementasikan secara berbeda untuk setiap model aplikasi dan akan bertanggung jawab untuk memanggil fungsi yang dipetakan dari perendernya.

Ini penting karena perpustakaan pihak ketiga seperti Fabulous tidak akan memiliki tenaga kerja Microsoft untuk mengimplementasikan (dengan semua bug yang menyertainya) semua penyaji yang sesuai untuk setiap kontrol di setiap platform.

Poin lainnya adalah: antarmuka kontrol ( IButton ) harus getter-only untuk dikonsumsi oleh perender.
Renderer tidak menetapkan nilai dan setiap model aplikasi akan membentuk kontrol secara berbeda (BindableProperty, BindingObject, dll.).
Misalnya, Fabulous akan memiliki tampilan yang tidak dapat diubah. Hanya secara internal, apakah akan diotorisasi untuk mengatur mutasi ke instance IButton .

Dengan begitu, Fabulous dapat langsung menggunakan antarmuka IButton sebagai tampilan pembaca pada kamus internalnya sehingga perender dapat bekerja.

// 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 Semua yang Anda katakan adalah cara kerjanya :-)

Gambar di sana membingungkan sejauh penyaji.

Satu-satunya bagian dari ini yang perlu Anda perhatikan adalah Tombol Luar Biasa dan kemudian segala sesuatu yang lain dari sana akan kami tangani

Sebagian besar antarmuka hanya dapat dibaca

Ini adalah antarmuka yang digunakan oleh tombol
https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Views/IText.cs

Semua yang benar-benar ada pada Anda (sejauh penyaji) adalah memberi sinyal kepada penyaji bahwa ia harus menggunakan kembali IButton

Misalnya, pada versi BindableObject dari semua ini, kami hanya memanggil metode updateproperty Renderer di sini

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

Beberapa poin (segera?) @Clancey akan memiliki versi publik Komet yang dapat Anda lihat untuk melihat bagaimana dia melakukannya.

Saya akan memeriksa
https://github.com/dotnet/maui/blob/slim-renderer-samples

Anda mungkin dapat menambahkan kepala Fabulous.Core Anda sendiri ke sana dan kemudian mulai menambahkan implementasi ke antarmuka

@PureWeen Oh keren. Terima kasih, saya akan mencoba bermain dengan sampel yang Anda tautkan untuk melihat bagaimana hasilnya.

@PureWeen @Clancey Saya yakin tim Maui akan mengatasi semua ini, tapi tolong bisakah penyaji Slim yang baru lebih menyukai komposisi daripada pewarisan. Warisan berguna, tetapi sayangnya di XF telah membuat beberapa hierarki penyaji menjadi sangat kompleks dan sulit untuk dipertahankan.

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

memberikan 404, apakah itu pribadi?

@Rand-Acak

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

@velocitysystems

Saya yakin tim Maui akan mengatasi semua ini, tapi tolong bisakah penyaji Slim yang baru lebih menyukai komposisi daripada pewarisan. Warisan berguna, tetapi sayangnya di XF telah membuat beberapa hierarki penyaji menjadi sangat kompleks dan sulit untuk dipertahankan.

Begitulah cara mereka dibangun. Ada kelas dasar yang sangat tipis yang mewarisi langsung dari System.Object

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

Dan tidak memiliki ikatan asli.

Dari sana semuanya didefinisikan melalui apa yang pada dasarnya adalah Kamus

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

Yang pada dasarnya beroperasi seperti dekorator.

Anda dapat menghias pembuat peta dengan pembuat peta tambahan dan Anda dapat menyuntikkan fungsi Anda sendiri, dll.

Kami bertujuan agar 95 persen skenario pengguna tercakup hanya dengan menambahkan Fungsi Anda sendiri ke mapper atau hanya mengakses elemen asli secara langsung karena semuanya akan menjadi multi-target

@PureWeen Apa saluran yang paling tepat untuk membahas penerapan perender ramping dalam sampel Anda?

Saya punya beberapa pertanyaan seperti:

• Apakah nilai default akan ditentukan di tempat terpusat? Di XF, mereka saat ini ditentukan saat membuat bidang BindableProperty tetapi ini tidak akan ada tergantung pada model aplikasi.
• Akankah kelas Aplikasi juga menjadi (sebagian) sebuah antarmuka? Ini mendefinisikan banyak perilaku UI (sumber daya, menu, halaman utama) dan akan sangat bagus untuk diterapkan secara berbeda.
• Akankah Ukur/Atur/dll diekstraksi dari antarmuka kontrol? Saya rasa tidak masuk akal bagi model aplikasi untuk mengimplementasikannya secara berbeda.

Apakah nilai default akan ditentukan di tempat terpusat? Di XF, mereka saat ini ditentukan saat membuat bidang BindableProperty tetapi ini tidak akan ada tergantung pada model aplikasi.

Ini adalah pertanyaan yang bagus. @Clancey ? Tidak yakin apakah kita sudah mendefinisikan ini. Ada fase pengaturan awal di mana semua pembuat peta dipanggil dengan nilai properti saat ini (nilai default) tetapi saya tidak yakin apakah kami memiliki rencana untuk nilai default dan bagaimana itu akan digeneralisasi

Akankah kelas Aplikasi juga menjadi (sebagian) sebuah antarmuka? Ini mendefinisikan banyak perilaku UI (sumber daya, menu, halaman utama) dan akan sangat bagus untuk diterapkan secara berbeda.

Ya! Kami berharap untuk menciutkan semua kelas aplikasi (asli dan xplat) menjadi satu kelas aplikasi. Mengapa Anda bertanya tentang ini? Saya hanya ingin tahu kasus penggunaan Anda di sini sehingga kami dapat memastikan untuk mengatasinya

Akankah Ukur/Atur/dll diekstraksi dari antarmuka kontrol? Saya rasa tidak masuk akal bagi model aplikasi untuk mengimplementasikannya secara berbeda.

Pada titik ini itulah rencananya. Idenya adalah untuk mengekstrak semua kode tata letak kita sehingga tidak ada yang bergantung pada BindableObject/Property.. Dengan cara ini Blazor/Comet/other hanya dapat menggunakan StackLayout dan hasilnya akan sama.

Mengapa Anda bertanya tentang ini? Saya hanya ingin tahu kasus penggunaan Anda di sini sehingga kami dapat memastikan untuk mengatasinya

Saya belum sepenuhnya yakin dengan apa yang saya inginkan. Namun di Fabulous, saat ini kami tidak memiliki cerita yang bagus untuk mendefinisikan gaya global dan menu utama (seperti untuk macOS). Karena kami membiarkan pengguna kami mensubklasifikasikan kelas Aplikasi itu sendiri, pada dasarnya kami memberi tahu mereka untuk mendefinisikan sumber daya/menu seperti yang mereka lakukan di Xamarin.Forms klasik.

Jadi idealnya, semua properti Aplikasi yang terkait dengan UI juga akan menjadi bagian dari tampilan, dengan cara itu kami juga dapat menerapkan logika pembeda tampilan kami di dalamnya.

Sesuatu seperti itu

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 Pertanyaan lain: Siapa yang akan bertanggung jawab untuk memicu peristiwa seperti TextChanged , Toggled , dll.? Kontrol atau penyaji?

Satu hal yang menurut saya akan sangat menyederhanakan implementasi model aplikasi lain adalah kemungkinan untuk tidak memicu peristiwa perubahan status saat perubahan bersifat terprogram.

Misalnya, hari ini, TextChanged pada Entry dipicu baik saat pengguna menulis sesuatu atau saat kita melakukan MyEntry.Text = "New value"; .
Saya pikir bereaksi terhadap perubahan terprogram tidak terlalu berguna, dan implisit yang buruk untuk alasan tentang kode.

Ini juga menyebabkan loop tak terbatas di Android karena platform memicu acaranya dengan sedikit penundaan dan memaksa Fabulous untuk tidak sinkron tanpa kemungkinan untuk kembali.
Satu-satunya solusi yang kami temukan adalah berhenti berlangganan acara terlebih dahulu sebelum menetapkan nilai, lalu berlangganan kembali...

Sebuah pertanyaan penasaran. Ketika MAUI adalah arsitektur agnostik mengapa kontrol dinamai dengan nama arsitektur? Misalnya Pada diagram di atas kita memiliki Maui. Mvvm .ButtonRenderer.Android? @PureWeen @Clancey

XF memiliki sesuatu yang disebut Layout Terkompresi (Yang bermasalah)
Apakah kita sudah seperti hal (tanpa bug pasti!) di MAUI?

Saya melihat bagaimana orang bereaksi di utas ini tentang memiliki pendekatan Flutter/Skia untuk membuat UI dan saya sebagian besar setuju dengan mereka.
Saya sangat senang bahwa MAUI berpotensi memiliki dukungan untuk kontrol dan render kustom/bukan asli.
Namun, saya harus mengatakan bahwa kemampuan untuk bekerja dengan UI asli mengamankan kerangka kerja di sisi politik.
Dan ya, saya menunjukkan di Apple. Karena berita terbaru, saya tidak akan terkejut jika suatu saat karena alasan tertentu menggunakan Flutter akan dianggap sebagai 'mengeksploitasi fitur yang tidak didokumentasikan/dibatasi' atau 'tidak mengikuti pedoman UI Apple' dan seterusnya.

Saya melihat bagaimana orang bereaksi di utas ini tentang memiliki pendekatan Flutter/Skia untuk membuat UI dan saya sebagian besar setuju dengan mereka.
Saya sangat senang bahwa di MAUI berpotensi memiliki dukungan untuk kontrol dan render kustom/bukan asli.
Namun, saya harus mengatakan bahwa kemampuan untuk bekerja dengan UI asli mengamankan kerangka kerja di sisi politik.
Dan ya, saya menunjukkan di Apple. Karena berita terbaru, saya tidak akan terkejut jika suatu saat karena alasan tertentu menggunakan Flutter akan dianggap sebagai 'mengeksploitasi fitur yang tidak didokumentasikan/dibatasi' atau 'tidak mengikuti pedoman UI Apple' dan seterusnya.

Jika MAUI mendukung Web (seperti Flitter), maka kita selalu dapat merender ke WebView.
Apple sepertinya tidak akan pernah berani memblokir aplikasi berbasis WebView, karena beberapa perusahaan besar diwakili di AppStore hanya melalui WebView

Saya melihat bagaimana orang bereaksi di utas ini tentang memiliki pendekatan Flutter/Skia untuk membuat UI dan saya sebagian besar setuju dengan mereka.
Saya sangat senang bahwa di MAUI berpotensi memiliki dukungan untuk kontrol dan render kustom/bukan asli.
Namun, saya harus mengatakan bahwa kemampuan untuk bekerja dengan UI asli mengamankan kerangka kerja di sisi politik.
Dan ya, saya menunjukkan di Apple. Karena berita terbaru, saya tidak akan terkejut jika suatu saat karena alasan tertentu menggunakan Flutter akan dianggap sebagai 'mengeksploitasi fitur yang tidak didokumentasikan/dibatasi' atau 'tidak mengikuti pedoman UI Apple' dan seterusnya.

Jika MAUI mendukung Web (seperti Flitter), maka kita selalu dapat merender ke WebView.
Apple sepertinya tidak akan pernah berani memblokir aplikasi berbasis WebView, karena beberapa perusahaan besar diwakili di AppStore hanya melalui WebView

itu sudah bertentangan dengan pedoman - https://developer.apple.com/app-store/review/guidelines/#minimum -fungsionalitas

Setelah membaca sedikit ke belakang dan keempat seperti apa dunia MAUI yang baru ini, mohon untuk cinta semua yang suci benar-benar menulis sekali menggunakan mesin rendering di mana-mana seperti SKIA atau mesin rendering multiplatform lainnya, harus menerapkan kustom UI di setiap platform seperti di Xamarin Forms terasa tua dan seperti itu adalah solusi yang dibuat di lingkaran ketujuh neraka.

jika kompatibilitas mundur adalah suatu keharusan "hanya" membuat dukungan render baru dan modern sebagai cara untuk merender komponen yang lebih lama, saya telah melihat platform lain memiliki solusi yang rapi untuk ini, yang terbaru yang saya gunakan adalah di mesin UI unity di mana UXML modern baru memiliki Render IMGUI.

@jackie0100
saya sangat setuju

harus mengimplementasikan UI khusus pada setiap platform seperti di Xamarin Forms terasa lama dan seperti itu adalah solusi yang dibuat di lingkaran ketujuh neraka.

Adapun implementasi perender, bagaimana dengan ide tampilan asli IView IS A (bukan IView HAS A native view). yaitu warisan bukan komposisi? Ini akan menghasilkan arsitektur tercepat dan paling ramping dengan "Overhead Formulir" yang benar-benar nol. Anda pada dasarnya bekerja dengan tampilan asli murni, dan hanya antarmuka umum.

Kemudian Anda dapat melakukan hal-hal seperti, di atas tanah iOS, cukup berikan tampilan Anda menjadi UIView, dan tambahkan anak asli ke dalamnya (jenis apa pun yang Anda inginkan) karena IView adalah UIView. Demikian pula, jika Anda ingin melakukan 'penyematan asli', itu mudah karena IView adalah UIView, Anda bisa menambahkan salah satu IViews ke tampilan asli Anda karena keduanya sama. Ini akan secara besar-besaran memungkinkan interopabilitas <-> maui asli, dan dengan tingkat kinerja tertinggi dan konsumsi memori terendah.

Saya merasa seperti membuat prototipe ini sendiri. Mungkin proyek akhir pekan/malam...

Jika MAUI mendukung Web (seperti Flitter), maka kita selalu dapat merender ke WebView.

Tidak perlu WebView di iOS: dapat merender langsung di OpenGL atau Metal .

Atau gunakan Skia dengan OpenGL atau Metal di bawahnya.

kemampuan untuk bekerja dengan UI asli mengamankan kerangka kerja di sisi politik. [Apel]

Pada titik tertentu, Apple menghapus dari kebijakan tertulis mereka persyaratan untuk menggunakan widget UI asli. Saya tidak melihat cara praktis mereka akan membalikkan kebijakan kembali menjadi ketat.

Terlepas dari itu, menjadi _dapat_ bekerja dengan kontrol asli adalah pilihan yang baik.

@legistek

Mengapa begitu banyak orang terobsesi dengan Skia? Spesifikasi rendering yang baik akan agnostik ke mesin rendering ...

Meskipun saya sepenuhnya setuju tentang menjadi "agnostik", ada _lot_ detail yang harus diterapkan untuk merender UI interaktif apa pun - jika Anda langsung membuka OpenGL/Metal/Vulkan/mesin rendering tingkat rendah apa pun. Orang-orang terobsesi dengan Skia karena ini adalah _lapisan tengah_ yang efektif antara masalah UI aplikasi dan mesin rendering yang sebenarnya: Skia menangani _banyak_ dari apa yang harus dirancang dan diimplementasikan, jika semua yang Anda miliki hanyalah bare metal. Tidak ada alasan untuk menemukan kembali pekerjaan ini. Meskipun tidak boleh menjadi target _only_, ini adalah target yang sangat berharga dan matang, yang akan mempermudah, katakanlah, berpindah dari OpenGL ke Vulkan.

Saya juga menduga bahwa menargetkan Skia akan jauh lebih rumit daripada pemeliharaan Xamarin Forms dari dua hierarki widget paralel - widget lintas platform dan widget asli.

Skia bahkan mungkin mempercepat hari dimana .Net Maui berkinerja tinggi di browser . Sekali lagi, karena alih-alih membangun dari tingkat rendah, rendering Anda memulai abstraksi tingkat menengah yang sesuai. Itu akan menjadi kemenangan besar.

Halo semuanya, jangan lupa:
https://github.com/dotnet/maui/discussions/103

Setelah menonton video maui baru-baru ini, kecuali saya salah, tampaknya ada pergeseran untuk memiliki kontrol yang lebih bergaya dengan kontrol asli yang dilapisi dengan gambar yang dilakukan di sisi platform yang independen. Apakah itu skia atau semacam interop batch ke gambar kanvas asli, saya harap pendekatan ini dilakukan! Model renderer platform XF ironisnya selalu merugikan platform Microsoft UI paling banyak, karena paling jarang digunakan.

Saya juga akan membiarkan kemampuan kontrol untuk secara eksplisit tidak memiliki komponen asli dan untuk penyusun tata letak untuk mendeteksi ini, ini mungkin memungkinkan pengurangan otomatis dalam tampilan asli yang dibuat (yaitu jika semua kontrol dalam wadah adalah label maui yang digambar dengan skia, itu bisa membuat wadah menjadi SkView dan hanya memanggil operasi menggambar pada kontrol anak label), di Android yang akan memberikan peningkatan kecepatan dalam hal-hal seperti elemen daftar yang memiliki banyak gambar + kontrol teks misalnya.

Saya tidak mengerti apa itu penyaji.
Kalau program untuk menyerap perbedaan visual target disebut renderer, harusnya diserap oleh Xamarin dan MAUI sama sekali. Kalau tidak, saya kira itu Xamarin dan MAUI yang belum selesai, dan tidak akan pernah selesai.
Saya pikir pemrograman aplikasi harus lebih independen dari perbedaan dalam lingkungan target.

Saya tidak mengerti apa itu penyaji.
Jika program untuk menyerap perbedaan visual target disebut renderer, itu harus diserap oleh Xamarin dan MAUI secara bersamaan. Jika tidak, saya pikir itu adalah Xamarin dan MAUI yang belum selesai. Dan itu tidak akan pernah selesai.
Saya pikir pemrograman aplikasi harus lebih independen dari perbedaan dalam lingkungan target.