@jassmith ,

Ini adalah ide yang sangat bagus dari sudut pandang standarisasi XAML, dan akan memberikan fungsionalitas yang kuat, Namun, saya akan berhati-hati dalam menempuh jalan ini. Ini pasti akan berkontribusi pada tujuan keseluruhan untuk memindahkan Xamarin.Forms menuju Standar XAML (https://github.com/Microsoft/xaml-standard). Tapi, bersama dengan VisualStates, ada tanda tanya besar seputar seberapa berguna ini dalam kenyataan.

Akselerasi grafis di area semacam ini harus dipertimbangkan. Kurangnya akselerasi grafis sudah menjadi masalah di beberapa bagian sistem seperti animasi. Dugaan saya adalah bahwa jika Xamarin.Forms mengambil tanggung jawab untuk merender pencitraan vektor, maka akan dihapus dari platform yang mendasarinya - dan dipindahkan dari pemrosesan GPU ke pemrosesan CPU. Ini akan menjadi hit kinerja besar dalam beberapa kasus. Bukannya tidak boleh dilakukan, tetapi harus dipikirkan apakah pemrosesan dapat dibiarkan di tingkat GPU atau tidak alih-alih dipindahkan ke CPU. Konsumen perpustakaan XF perlu disadarkan tentang apa yang akan berjalan di platform asli, dan apa yang akan dirender oleh perpustakaan XF.

Ada juga pertanyaan tentang keseimbangan antara gambar asli dan perbedaan gambar lintas platform. Teks adalah poin penting. Haruskah teks dirender sama di semua platform? Yaitu haruskah rendering font diteruskan ke XF untuk menciptakan keseragaman di semua platform? Mungkin. Tapi, saya tidak merasa itu harus menjadi proyek keseluruhan untuk XF. Orang secara tidak sadar mendeteksi detail visual kecil. Detailnya mungkin dalam animasi atau sebagainya. Bahkan penyimpangan kecil dari norma pada platform tertentu dapat membuat pengguna merasa tidak nyaman. Jadi, tidak selalu merupakan ide yang baik bahwa semua gambar dibuat seragam. Avalonia tentu saja akan menempuh jalan itu, tetapi itu adalah kasus yang sama sekali terpisah, dan itulah titik perbedaan antara Bentuk Avalonia dan Xamarin.

Juga, satu komentar lagi adalah bahwa perawatan harus dilakukan untuk memastikan semua tipe primitif diberi nama yang sama, dan disejajarkan sedekat mungkin dengan platform lain seperti UWP, dan WPF agar sejalan dengan Standar XAML.

@davidortinau , apakah Anda memiliki pemikiran tentang ini?

Salah satu fitur hebat dalam desain material adalah Ripple. Apakah Anda berharap untuk mendukung ini?
Secara keseluruhan saya pikir ini fantastis!

Saya sangat suka arah ini. Untuk iOS saya menggunakan sel tampilan asli menggunakan elemen asli (i, > opsi), tetapi semakin saya menerapkan tema khusus, saya mendapati diri saya hanya meniru sedikit sel asli dan lebih mencari tema yang tampak bagus/berfungsi yang lancar dan konsisten untuk aplikasi tetapi tidak asli selain dari detail. Saya pikir jika pustaka rendering dasar yang sesuai digunakan GPU tidak akan menjadi masalah, baca Skia. Hal yang sama memberi daya pada Flutter.

Mungkin ini masalah yang terpisah, tetapi alangkah baiknya menjadikan SVG sebagai warga negara kelas satu pada saat yang sama. Mengaktifkan efek rapi seperti pewarnaan animasi untuk tombol gambar saat ditekan misalnya.

Pendapat saya adalah bahwa pada akhirnya Anda menginginkan kontrol yang kuat, kaya, asli (bukan asli!) yang mudah diprogram dengan perilaku lintas platform yang konsisten, dengan pengecualian aneh untuk mengakomodasi kekhasan platform asli. Misalnya efek riak untuk Android.

@ChaseFlorell sebenarnya saya lakukan. Idenya adalah Anda dapat x:Menamai hal-hal di templat dan kemudian menggalinya menggunakan FindByName. Setelah Anda memiliki elemen asli, Anda dapat menerapkan animasi padanya seperti yang lainnya, namun kemungkinan akan ada cara khusus untuk mendapatkan panggilan balik animasi. Saya masih mengerjakan detail persisnya. Dengan Skia melakukan menggambar, ini dapat dengan mudah mencapai 60FPS di android dan bahkan tanpa Skia Anda dapat mencapai 60FPS di platform lain.

@rogihee SVG benar-benar bukan format pengiriman maaf:/ Saya tidak ingin bertanggung jawab untuk mencoba membuat SVG secara konsisten lintas platform. Kapan mereka akan menambahkan petunjuk ke SVG ...

@jassmith , apakah ini akan kami akselerasi grafis perangkat keras?

Berasal dari Qt's QML, akan senang melihat ini. Dikombinasikan dengan beberapa kontrol bawaan yang jelas, dapat mengonversi banyak bidang.

Mungkin agak prematur atau layak untuk masalah lain, tetapi apa rencana cerita aksesibilitas/testabilitas untuk kontrol yang dibangun dengan ini?

@RichiCoder1 a11y tentu saja sesuatu yang perlu dikerjakan dengan benar. Idealnya elemen Teks akan secara otomatis mengatur sebagian besar properti yang diperlukan untuk kontrol sederhana.

apakah ini fitur untuk xf 4.0？

3.0 seri

@jassmith tidak ada apa-apa tentang menggambar dan shell di peta jalan

AFAIK peta jalan publik tidak memasukkan apa pun yang belum terjadwal sepenuhnya

akankah semua pratinjau ini di 2018？@jassmith

@juepiezhongren kami belum berkomitmen untuk melakukan proposal ini. Mereka disajikan di sini untuk diskusi terbuka tentang kelebihan, kekurangan, dll.

Saya mengambil dari minat Anda bahwa spesifikasi ini menarik bagi Anda. Maukah Anda membagikan beberapa contoh spesifik tentang di mana Anda melihat mereka membantu Anda saat membuat aplikasi dengan Xamarin.Forms? Masalah apa yang Anda lihat memecahkan ini? Peluang apa yang Anda lihat terbuka untuk Anda?

Setiap contoh dan kisah nyata yang dapat Anda bagikan akan sangat berguna dalam membantu kami memvalidasi bahwa ini dapat memberikan nilai nyata.

Seperti biasa, siapa pun dapat merasa bebas untuk mengirim email kepada saya jika diinginkan. david. [email protected]

Masalah terbesar bagi saya adalah jawaban "kami tidak dapat melakukannya dengan kerangka Formulir" yang harus saya berikan kepada calon pelanggan dan UX/UI. Ini mendiskreditkan kerangka kerja dan saya hanya mendapatkan begitu banyak peluang dengan pelanggan.

Bentuk tidak memiliki paradigma komposisi di mana kita pr. proyek dapat membangun UI menggunakan primitif UI. Ini berlaku untuk navigasi, animasi (termasuk hal-hal seperti animasi pahlawan), elemen UI, dan gestur.

Akankah saran ini memberi kita primitif UI komposisi platform-netral seperti itu?

@timahrentlov Kita perlu melihat diskusi dan melihat persis apa batasan itu dan alasan batasan itu. Tapi sejujurnya saya bahkan tidak berani berpikir atau melihat sejauh itu. Masalah yang saya lihat dengan Xamarin Forms adalah dari perspektif yang lebih sederhana: masih merupakan proyek dengan sumber daya pengembangan yang sangat terbatas. Tidak realistis atau tidak berguna untuk membahas apa yang bisa dilakukan, padahal sebenarnya tidak ada cukup tenaga dan bahan bakar. Saya tidak melihat intinya. Apakah mungkin Xamarin diam-diam masih berharap beberapa individu dari komunitas OSS akan mulai bekerja dan memperbaiki keadaan? Jangan salah paham, saya menghargai waktu dan upaya yang telah dilakukan Xamarin ke dalam Formulir Xamarin.

@davidortinau
lintas platform sulit untuk melihat desain visual yang khas, tampilan tombol yang unik, efek penghilangan placeholder yang unik, dll. Benar-benar menghindari aplikasi kami menjadi identik. Misalnya, pemberitahuan mac yang memudar, dengan sedikit ledakan, sangat mudah untuk mengesankan pelanggannya. Mengapa kami sangat menyukai wpf hari itu, salah satu alasan yang akan saya sebutkan, adalah template kontrol, di mana kami sangat menikmati jalur untuk keunikan kami, seperti tombol segi enam terpojok. Kami ingin xf membawa ini ke pengembang klien lintas platform.

@juepiezhongren jika Anda mencari penyesuaian UI semacam itu, saya rasa tidak ada kerangka kerja lintas platform yang dapat melakukan itu. Dan tentang WPF: itu ide yang buruk untuk mencampur WPF dengan ponsel.

tim saya juga menggunakan reaksi asli, di mana begitu banyak jser berkontribusi banyak, di mana setelah 3 bulan kami menyimpulkan bahwa itu tidak produktif sama sekali. Untuk xf, dengan kekurangan, dengan bug, tetapi pada dasarnya ini adalah solusi yang solid, eps x.native membuat semua api asli valid. Yang kurang hanya tampilan ubi, cusidering flutter' mafness terbaru. Selain itu, dengan shell, flutter tidak akan berguna, tanpa sesuatu seperti flutter.ios, flutter akan seperti rn dengan api asli penderitaan tanpa batas.

@opcodewriter
kami agak sering menggunakan skiashap, membuat kontrol khusus, kinerjanya memuaskan

@jassmith apakah Anda telah mempertimbangkan untuk mem-port materialShell ke wasm dengan menggunakan webgl, untuk skia, mungkin terlalu besar untuk diunduh

benar, kami tidak ingin melakukan pendekatan keras pada lib pihak ketiga mana pun untuk API gambar default. \bisa melakukan itu

dengan xamarin.mono dan shell in wasm, produk alfa apa pun akan menyebabkan kebangkitan dotnet di Cina, di mana kebencian terhadap dotnet terlalu banyak berlaku

@jassmith ada kabar baik tentang masalah ini?

berita apa yang kamu cari @juepiezhongren? Pada titik ini Spec diposting untuk meminta diskusi.

kami ingin melihat kapan draw dan shell dimasukkan ke roadmap@ChaseFlorell
rendering universal sudah berlaku untuk avalonia dan flutter

Garis waktu ini akan tergantung pada kecepatan pengembangan pribadi saya. Tujuannya di sini bukan untuk mengalihkan seluruh tim ke dalam upaya ini dan hanya membiarkan saya melakukannya. Anda dapat melacak cabang shell jika Anda ingin melihatnya bersatu. Setelah Shell akan datang menggambar.

Sebagai catatan, saya bermaksud untuk membuat gambar irisan vertikal dengan sangat cepat dan kemudian meminta bantuan komunitas jika mereka ingin menyelesaikannya lebih cepat.

Ini semua sangat bagus, tetapi apakah itu akan menggunakan akselerasi grafis?

@jassmith di ios, system.draw yang akan digunakan; di android, skiashharp akan digunakan || skiashharp untuk setiap hal?

@juepiezhongren itu akan mendukung banyak backend, jadi jika Anda ingin menggunakan Skia, ia akan menggunakan Skia, jika Anda ingin menggunakan API gambar asli, ia akan menggunakannya sebagai gantinya. Secara default itu akan menggunakan backend asli dan Skia akan ikut serta sehingga ketergantungan tidak dipaksakan pada Anda.

@jassmith benar-benar terhubung bahwa system.draw tersedia untuk ios sementara tidak untuk android

@juepiezhongren menambahkan dukungan untuk System.Drawing bukanlah sesuatu yang ada dalam lingkup saya di sini. Namun tidak ada yang akan menggunakan System.Drawing dengan spesifikasi ini.

pada dasarnya, menggambar akan menyebabkan jauh lebih sedikit render

Tidak juga, Gambar harus didukung oleh sesuatu yang membuatnya. Kecuali jika maksud Anda lebih sedikit kebutuhan untuk penyaji khusus, dalam hal ini ya, saya setuju.

Saya berada di kamp "lakukan sedekat mungkin dengan wpf/uwp", yang saya tahu tidak selalu merupakan posisi paling populer di sini.

TAPI, ini sepertinya kompromi besar antara benar-benar terlihat dengan kerangka yang melakukan SEMUA rendering, dan paradigma XF saat ini.

Saya berasumsi primitif akan memiliki rekan di setiap platform dan dengan demikian akselerasi perangkat keras tidak akan menjadi masalah. Windows/iOS/Android/etc masih merender persegi panjang, lingkaran, gradien, dan sejenisnya dan akan menggunakan akselerasi perangkat keras pada tingkat yang sama seperti yang sudah mereka lakukan. Ini hanya akan memberi kita kemampuan desainer kontrol untuk merancang kontrol kita menggunakan primitif daripada terjebak dengan ide tombol Apple vs Microsoft.

Apakah saya menyimpulkannya dengan benar?

@pmoorelegistek pada dasarnya itu idenya ya. Dan kami menangani Material terlebih dahulu terutama karena tidak memiliki Blur di belakang sebagai elemen desain utama. Ini berarti kami benar-benar dapat membuatnya berfungsi di mana saja (melihat Android Anda).

ketika saya menyelesaikan Shell v1 saya segera pindah ke ini

@jassmith Ini emas. Gunakan kontrol asli yang sesuai dengan desain UX dan dengan mudah menambahkan kontrol yang digambar seperti skia hanya untuk elemen desain (sebaiknya sedikit) yang membutuhkannya.

Tidak ada lagi pembicaraan "tidak bisa melakukannya di Xamarin Forms" dengan desainer dan pelanggan. Ini menghilangkan batasan desain sambil mempertahankan perasaan asli yang sebenarnya (tidak seperti flutter).

Saya akan senang melihat ini sebelum material shell. Ini memecahkan batasan nyata dari XF.
Shell adalah fitur ke-n untuk memulai dengan mudah/lebih cepat. Memulai _memulai_ telah menjadi fokus terlalu lama, tetapi fitur seperti ini untuk mendapatkan _lebih lanjut_ akan _mempertahankan_ pengembang XF tetap aktif.

Ini harus terjadi sebelum Material Shell karena Material Shell bergantung pada ini. Saya pikir Anda bermaksud mengatakan bahwa Anda lebih suka melihat ini sebelum Shell?

Shell tidak fokus untuk memulai lebih cepat/lebih mudah. Ini dimaksudkan untuk memodernisasi Halaman dengan cara yang tidak bisa kita lakukan dengan mereka menjadi kontrol mereka sendiri. Ini pada dasarnya dimaksudkan untuk menggantikan mereka sepenuhnya dan kami akan mendorong orang untuk mempertimbangkan porting. Shell berfokus untuk memberikan pengalaman yang jauh lebih lancar dan lebih kaya kepada pengguna akhir, animasinya dapat disesuaikan, dapat menunda/memuat lambat sebelum/sesudah animasi sehingga tidak menimbulkan cegukan. Ini menyediakan area konten overdraw 0 GPU di Android, bandingkan ini dengan halaman saat ini di mana overdraw hanya di bagian "red go fuck yourself" dari bagan di mana-mana.

Shell bukan tentang membuat orang memulai lebih cepat, ini tentang membuat aplikasi Anda lebih cepat. Dengan Shell Anda dapat, misalnya, menandai halaman/tab/grup sebagai "sering" dan mereka akan disimpan oleh sistem dengan asumsi pengguna mengunjunginya terus-menerus. Ini berarti mereka tidak akan memuat ulang ketika Anda menavigasi pergi dan kembali. Kita bisa melakukannya karena Shell memiliki seluruh hierarki halaman.

Ada juga beberapa pemikiran yang kami miliki tentang cara mengoptimalkan kinerja menggambar dengan Shell bahwa meskipun kami pasti tidak akan pernah membatasi menggambar ke Shell, akan berpotensi membuat menggambar jauh lebih efisien dengan Shell karena kami mungkin dapat melakukan semua gambar dalam satu lintasan. Butir garam diperlukan di sini karena lonjakan ini belum selesai, tetapi terlihat layak di atas kertas.

@weitzhandler Saya berharap untuk pindah ke ini dalam 4-6 minggu ke depan. Ini akan jauh lebih cepat untuk mengerjakan shell itu. Tak satu pun dari waktu-waktu itu diatur dalam batu.

+1

@jassmith https://github.com/nventive/Uno
Itu hebat.
uni-rendering sangat bagus

bentuk akan menjadi penjelajah radikal, sementara uno akan menjadi yang konservatif
kami mencintai keduanya

+1 Fitur hebat itu akan menyelesaikan banyak masalah UI khusus, kami ingin melihatnya secepatnya

@jassmith tampaknya undian harus dilakukan untuk 3.3.0？

Ada pembaruan tentang ini?

Bagi kami, ini adalah fitur paling menarik yang kami harap dapat diterapkan oleh Xamarin.

Kami mengembangkan sebagian besar aplikasi LoB, dan salah satu prioritas utama kami adalah kecepatan pengembangan.
Kami tidak terlalu peduli dengan tampilan dan nuansa asli selama ada UI menarik yang melakukan pekerjaan yang layak, merender dengan baik, dan membutuhkan waktu pengembangan yang lebih sedikit.

Harus menguji dan mengadaptasi setiap formulir dan halaman secara terpisah di setiap platform, adalah pembunuh waktu nyata, membutuhkan perubahan UI kecil untuk diperiksa tiga kali di semua platform bolak-balik.

Shell & Material Shell adalah berkah dan berita bagus, tolong dorong ini ke depan! Ini adalah satu-satunya hal yang akan membuat pengguna Anda pergi ke tempat lain (Uno, Flutter, dan lainnya).

berita sedih bahwa undian tidak akan muncul untuk 3.3

+1 untuk ini, berasal dari latar belakang uwp saya benar-benar ingin menggunakan XF tetapi memiliki kekurangan, saat ini saya mencoba bergetar tetapi pasti akan datang ke XF jika ini diterapkan ASAP.

Saya setuju ini fitur hebat dan harus diterapkan.. Saya juga akan menyertakan gaya untuk garis misalnya, garis padat, garis putus-putus, dll...

Ada berita? Rencana? Peta jalan?

Cukup lucu, tadi malam saya menemukan diri saya bereksperimen dengan penyaji kustom dan hampir menyimpulkan bahwa semua ini dapat dilakukan hanya dengan mendefinisikan primitif kita sendiri sebagai tampilan kustom dan membangunnya. Anda tidak perlu lebih dari Border, Ellipse, dan Line.
Saya ingin sekali melihat ini didukung secara resmi, tetapi saya tidak menunggu. :)

@jassmith
Jadi Line dan Rectangle misalnya, akan menjadi tampilan nyata? (karena dalam contoh saya melihat ada Grid dengan Ellipse sebagai tampilan anak). Akan
Apakah saya dapat melampirkan add TapGestureRecognizer ke Rectangle untuk menangani acara tap?
Karena ini adalah tampilan nyata, bukankah memiliki tampilan sebenarnya untuk menggambar primitif akan merusak kecepatan rendering?

@andreinitescu Saya percaya tujuannya adalah agar mereka menjadi tampilan nyata di sisi Xamarin Forms, tetapi untuk tidak pernah direalisasikan sebagai tampilan asli:

_a menggambar primitif hanyalah tampilan yang tidak memiliki penyaji_

Jadi perender lebih lanjut dalam rantai ( Drawing ? DrawingTemplate ?) bertanggung jawab untuk mengulangi melalui turunan yang dapat digambar dan menggambarnya.

Saya kira ini berarti jenis pembatasan yang sama yang berlaku untuk Tata Letak dengan set CompressedLayout.IsHeadless akan berlaku (tidak ada pengenal gerakan, tidak ada efek, tidak ada transformasi, dll.)

@GalaxiaGuy Saya memikirkan hal yang sama tetapi saya merasa agak membingungkan, karena bercampur dengan tampilan nyata seperti Grid. Apakah itu benar-benar perlu? Alih-alih berasal dari View, mengapa tidak menjadikannya sebagai elemen gambar abstrak (mungkin memiliki kelas abstrak dasar yang disebut DrawingElement dengan properti umum?)

Pekerjaan Bagus hanya sampel yang benar

<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>

Mungkin itu akan di 4.0?

Drawing bagus karena mengimplementasikan kontrol menggunakan grafik primitif yang tidak bergantung pada platform target. Dulu ada NControl tetapi ini memiliki masalah (dari pra-netstandard2.0, pra-SkiaSharp hari), dan tidak diperbarui.

Spesifikasi 1. menduplikasi fungsionalitas yang sudah diimplementasikan dalam bentuk yang jauh lebih lengkap di SkiaSharp, 2. menambahkan lapisan kompleksitas yang tidak perlu melalui XAML/Binding yang masuk ke dalam repo Xamarin.Forms yang sudah tidak dapat dipertahankan.

Pendekatan yang lebih baik adalah membuat perpustakaan kontrol kecil berdasarkan SkiaSharp. NControl++

@jassmith @rogihee SVG benar-benar bukan format pengiriman maaf:/ Saya tidak ingin bertanggung jawab untuk mencoba membuat SVG secara konsisten lintas platform.

SkiaSharp memiliki dukungan SVG.

Ada berita tentang ini?

Ada berita tentang ini?

Juga bertanya-tanya apakah ini masih mungkin terjadi. Saya sangat menginginkan kerangka UI lintas platform yang tidak terlihat dan ini tampaknya menjadi cara terbaik untuk mencapainya.

@legistek Anda dapat menggunakan SkiaSharp untuk menggambar lintas platform tanpa tampilan. Apa keuntungan dari Xamarin.Forms khusus di pikiran Anda?

Ada sedikit lebih banyak kerangka kerja UI daripada menggambar.

Tapi utas ini membahas kerangka kerja gambar bukan kerangka kerja UI ...

Saya pikir itu sedang membahas kerangka gambar _untuk Xamarin Forms_.

SkiaSharp adalah kerangka menggambar untuk Xamarin Forms. Fakta itu juga berfungsi pada platform .Net UI lainnya tentu saja merupakan keuntungan bukan kerugian.

Dan seperti yang dikatakan di OP, SkiaSharp bisa menjadi mesin gambar yang mendasari pada platform individu tetapi ide dari proposal ini adalah untuk menambahkan lapisan abstraksi dan mendukung gambar melalui XAML dengan semua manfaatnya, yang paling menonjol adalah pengikatan data. Apa yang Anda sebut kompleksitas yang tidak perlu, saya sebut elegan.

Apakah ini masih hidup dan/atau akan digulirkan ke MAUI?

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap mencantumkan Bentuk, Jalur, dan Kuas seperti pada peta jalan untuk Xamarin.Forms 4.7.0.

Berita yang luar biasa! Terima kasih!