@Jassmith ,

Dies ist aus Sicht der XAML-Standardisierung eine sehr gute Idee und bietet leistungsstarke Funktionen. Ich wäre jedoch vorsichtig, diesen Weg einzuschlagen. Es wird definitiv zum Gesamtziel beitragen, Xamarin.Forms in Richtung XAML-Standard zu bewegen (https://github.com/Microsoft/xaml-standard). Aber zusammen mit VisualStates gibt es große Fragezeichen, wie nützlich dies in der Realität sein wird.

Die Grafikbeschleunigung in solchen Bereichen muss berücksichtigt werden. Die fehlende Grafikbeschleunigung ist bereits in einigen Teilen des Systems wie Animationen ein Problem. Meine Vermutung ist, dass, wenn Xamarin.Forms die Verantwortung für das Rendern von Vektorabbildungen übernimmt, es anschließend von der zugrunde liegenden Plattform entfernt wird – und von der GPU-Verarbeitung zur CPU-Verarbeitung verschoben wird. Dies wird in einigen Fällen ein massiver Leistungseinbruch sein. Es ist nicht so, dass es nicht getan werden sollte, aber es sollte darüber nachgedacht werden, ob die Verarbeitung auf der GPU-Ebene belassen werden kann, anstatt sie auf die CPU zu verlagern. Benutzer der XF-Bibliothek müssen darüber informiert werden, was auf der nativen Plattform ausgeführt und was von der XF-Bibliothek gerendert wird.

Es stellt sich auch die Frage nach dem Gleichgewicht zwischen nativer Zeichnung und plattformübergreifenden Zeichnungsunterschieden. Text ist ein wichtiger Punkt. Soll Text auf allen Plattformen gleich gerendert werden? Soll also das Font-Rendering an XF übergeben werden, um eine Einheitlichkeit über alle Plattformen zu schaffen? Vielleicht. Aber ich denke nicht, dass dies das Gesamtprojekt für XF sein sollte. Menschen erkennen unbewusst kleine visuelle Details. Die Details können in einer Animation oder so weiter enthalten sein. Selbst eine kleine Abweichung von der Norm auf einer bestimmten Plattform kann dem Benutzer Unbehagen bereiten. Es ist also nicht unbedingt eine gute Idee, alle Zeichnungen einheitlich zu gestalten. Avalonia geht sicherlich diesen Weg, aber das ist ein völlig anderer Fall, und das ist ein Unterschied zwischen Avalonia und Xamarin Forms.

Ein weiterer Kommentar ist, dass darauf geachtet werden sollte, dass alle primitiven Typen gleich benannt und so eng wie möglich an anderen Plattformen wie UWP und WPF ausgerichtet sind, um mit dem XAML-Standard in Einklang zu stehen.

@davidortinau , hast du Gedanken dazu?

Eines der großartigen Merkmale im Materialdesign ist die Ripple. Erwarten Sie, dies zu unterstützen?
Insgesamt finde ich das fantastisch!

Ich mag diese Richtung sehr. Für iOS habe ich native Ansichtszellen mit den nativen Elementen (i, > options) verwendet, aber je mehr ich benutzerdefinierte Themen anwende, imitiere ich nur ein bisschen die nativen Zellen und gehe mehr zu einem gut aussehenden/funktionierenden Thema, das flüssig ist und konsistent für die App, aber nicht per se nativ, abgesehen von Details. Ich denke, wenn die entsprechende zugrunde liegende Rendering-Bibliothek verwendet wird, wird GPU kein Problem sein, lesen Sie Skia. Dasselbe, was Flutter antreibt.

Vielleicht ist es ein separates Problem, aber es wäre schön, SVG gleichzeitig zu einem erstklassigen Bürger von Forms zu machen. Ermöglichen Sie nette Effekte wie zum Beispiel animierte Tönung für eine Bildschaltfläche beim Drücken.

Meiner Meinung nach möchten Sie am Ende leistungsstarke, reichhaltige, nativ aussehende (nicht per se nativ!) Steuerelemente, die einfach zu programmieren sind und sich plattformübergreifend konsistent verhalten, mit der seltsamen Ausnahme, um eine native Eigenart einer Plattform zu berücksichtigen. ZB ein Ripple-Effekt für Android.

@ChaseFlorell , das tue ich tatsächlich. Die Idee ist, dass Sie Dinge in der Vorlage x:benennen und sie dann mit FindByName ausgraben können. Sobald Sie das native Element haben, können Sie wie alles andere Animationen darauf anwenden, es wird jedoch wahrscheinlich eine spezielle Möglichkeit geben, einen Animationsrückruf zu erhalten. Ich arbeite noch an diesen genauen Details. Mit Skia beim Zeichnen kann dies auf Android leicht 60 FPS erreichen, und selbst ohne Skia können Sie auf den anderen Plattformen 60 FPS erreichen.

@rogihee SVG ist wirklich kein Versandformat, tut mir leid: / Ich möchte nicht dafür verantwortlich sein, SVG konsistent plattformübergreifend zu rendern. Wann werden sie den SVGs überhaupt Hinweise hinzufügen ...

@jassmith , wird dies die Hardware-Grafikbeschleunigung sein?

Ich komme aus Qt's QML und würde das gerne sehen. Kombiniert mit ein paar offensichtlichen eingebauten Steuerelementen kann viel Boden gewonnen werden.

Vielleicht ein bisschen verfrüht oder ein weiteres Thema wert, aber was ist der Story-Plan für Zugänglichkeit/Testbarkeit für Steuerelemente, der damit aufgebaut wurde?

@RichiCoder1 a11y ist sicherlich etwas, das richtig ausgearbeitet werden muss. Im Idealfall würde ein Textelement die meisten erforderlichen Eigenschaften für einfache Steuerelemente automatisch festlegen.

ist das die Funktion für xf 4.0?

3.0-Serie

@jassmith In der Roadmap steht nichts über Draw und Shell

AFAIK, die öffentliche Roadmap enthält nichts, was nicht vollständig geplant ist

werden all diese Vorschauen im Jahr 2018 angezeigt? @jassmith

@juepiezhongren Wir haben uns nicht verpflichtet, diese Vorschläge zu machen. Sie werden hier zur offenen Diskussion über ihre Vorzüge, Mängel usw. vorgestellt.

Ich entnehme Ihrem Interesse, dass diese Spezifikationen für Sie interessant sind. Würden Sie einige konkrete Beispiele dafür nennen, wo sie Ihnen beim Erstellen von Apps mit Xamarin.Forms helfen? Welche Probleme sehen Sie dadurch gelöst? Welche Chancen sehen Sie darin für Sie?

Alle Beispiele und Geschichten aus der Praxis, die Sie uns mitteilen können, wären äußerst hilfreich, um uns dabei zu helfen, zu bestätigen, dass dies einen echten Mehrwert bieten könnte.

Wie immer kann sich jeder gerne per E-Mail an mich wenden, wenn dies bevorzugt wird. David. [email protected]

Das größte Problem für mich ist die Antwort „Das können wir mit dem Forms-Framework nicht tun“, die ich potenziellen Kunden und UX/UI geben muss. Es diskreditiert den Rahmen und ich bekomme nur begrenzte Chancen bei einem Kunden.

Formen fehlt ein kompositorisches Paradigma, wo wir pr. project kann die Benutzeroberfläche mithilfe von UI-Primitiven erstellen. Dies gilt für Navigation, Animationen (inkl. Sachen wie Heldenanimationen), UI-Elemente und Gesten.

Wird uns dieser Vorschlag solche plattformneutralen kompositorischen UI-Grundelemente liefern?

@timahrentlov Wir müssen diskutieren und genau sehen, was diese Einschränkungen sind und was der Grund für diese Einschränkungen ist. Aber ehrlich gesagt traue ich mich gar nicht so weit zu denken oder zu schauen. Das Problem, das ich bei Xamarin Forms sehe, ist aus einer viel einfacheren Perspektive: Es bleibt immer noch ein Projekt mit sehr begrenzten Entwicklungsressourcen. Es ist unrealistisch oder nutzlos, darüber zu diskutieren, was getan werden könnte, wenn tatsächlich nicht genug Strom und Kraftstoff vorhanden sind. Ich sehe den Sinn nicht. Hoffet Xamarin vielleicht insgeheim immer noch, dass einige Personen aus der OSS-Community mit der Arbeit beginnen und Dinge reparieren? Verstehen Sie mich nicht falsch, ich respektiere die Zeit und Mühe, die Xamarin in Xamarin Forms gesteckt hat.

@davidortinau
Cross-Plattform ist schwer zu erkennen, charakteristisches visuelles Design, einzigartiges Erscheinungsbild der Schaltflächen, einzigartiger Platzhalter-Verschwindeeffekt usw. Wir vermeiden wirklich, dass unsere Apps identisch sind. Zum Beispiel ist es wirklich einfach, seine Kunden mit dem verblassenden Hinweis von mac mit einer leichten Explosion zu beeindrucken. Warum wir wpf an diesem Tag sehr lieben, ein Grund, den ich erwähnen möchte, ist die Steuervorlage, bei der wir Wege wegen unserer Einzigartigkeit so sehr genießen, wie z. B. ein eckiger Sechseckknopf. Wir möchten, dass xf diese plattformübergreifenden Client-Entwicklern zur Verfügung stellt.

@juepiezhongren Wenn Sie nach dieser Art von UI-Anpassung suchen, gibt es meines Erachtens kein plattformübergreifendes Framework, das dies tun kann. Und zu WPF: Es ist eine schlechte Idee, WPF mit Mobile zu mischen.

Mein Team verwendet auch React Native, wo so viele Jser viel beitragen, wo wir nach 3 Monaten zu dem Schluss kamen, dass es überhaupt nicht produktiv ist. Für xf ist es mit Nachteilen, mit Fehlern, aber im Grunde ist es eine solide Lösung, eps x.native macht alle nativen APIs gültig. Was fehlt, ist nur ein Ubi-Erscheinungsbild, das an die jüngste Mafness von Flatter erinnert. Außerdem soll Flattern mit Shell nutzlos sein, ohne so etwas wie flattern.ios soll Flattern wie rn mit nativem API grenzenloses Leiden sein.

@opcodewriter
Wir verwenden Skiasharp ziemlich häufig und machen eine spezielle Kontrolle, seine Leistung ist zufriedenstellend

@jassmith hast du überlegt, materialShell mit webgl nach wasm zu portieren, für skia ist es vielleicht zu groß zum herunterladen

Richtig, wir wollen keine Bibliotheken von Drittanbietern für die Standard-Zeichnungs-API in Anspruch nehmen. \könnte das machen

mit xamarin.mono und shell in wasm wird jedes alpha-produkt eine dotnet-renaissance in china auslösen, wo der hass gegen dotnet zu sehr vorherrscht

@jassmith irgendwelche guten Nachrichten zu diesem Problem?

Nach welchen Neuigkeiten suchst du @juepiezhongren? An diesem Punkt ist es eine Spezifikation, die veröffentlicht wurde, um eine Diskussion anzuregen.

wir wollen sehen, wann draw und shell in roadmap@ChaseFlorell aufgenommen werden
universal rendering gilt bereits für avalonia und flattern

Der Zeitplan dafür wird von meiner persönlichen Entwicklungsgeschwindigkeit abhängen. Das Ziel hier ist nicht, das gesamte Team in diese Unternehmungen abzulenken und nur mich damit zu verschonen. Sie können den Shell-Zweig verfolgen, wenn Sie sehen möchten, wie er zusammenkommt. Nach Shell wird Zeichnung kommen.

Als Anmerkung, ich beabsichtige, sehr schnell ein vertikales Stück Zeichnung aufzurichten und dann die Community um Hilfe zu bitten, wenn sie es schneller erledigen möchte.

Das ist alles sehr schön, aber wird es Grafikbeschleunigung verwenden?

@jassmith auf ios, zu verwendendes system.draw; auf Android, Skiasharp zu verwenden || Skisharp für alles?

@juepiezhongren unterstützt mehrere Backends. Wenn Sie also Skia verwenden möchten, wird Skia verwendet. Wenn Sie möchten, dass die native Zeichnungs-API verwendet wird, wird stattdessen diese verwendet. Standardmäßig wird das native Backend verwendet und Skia wird aktiviert, sodass Ihnen die Abhängigkeit nicht aufgezwungen wird.

@jassmith es ist wirklich verdrahtet, dass system.draw für ios verfügbar ist, nicht aber für android

@juepiezhongren Das Hinzufügen von Unterstützung für System.Drawing liegt hier nicht in meinem Zuständigkeitsbereich. Nichts wird System.Drawing jedoch mit dieser Spezifikation verwenden.

Im Grunde führt Draw zu weitaus weniger Renderings

Nicht wirklich, Zeichnungen müssen von etwas unterstützt werden, das sie rendert. Es sei denn, Sie meinen, dass weniger benutzerdefinierte Renderer benötigt werden. In diesem Fall stimme ich zu.

Ich bin im Lager "mach es so nah wie möglich an wpf/uwp", was, wie ich weiß, hier nicht immer die beliebteste Position ist.

ABER, das scheint ein großartiger Kompromiss zu sein zwischen dem totalen Aussehen, bei dem das Framework das GESAMTE Rendern übernimmt, und dem aktuellen XF-Paradigma.

Ich gehe davon aus, dass die Primitiven auf jeder Plattform Gegenstücke haben werden und daher die Hardwarebeschleunigung kein Problem darstellen würde. Windows/iOS/Android/usw. rendern immer noch Rechtecke, Kreise, Farbverläufe und dergleichen und verwenden die Hardwarebeschleunigung im gleichen Umfang wie sie es bereits tun. Dies würde uns Steuerelement-Designern nur die Möglichkeit geben, unsere Steuerelemente mit Hilfe von Primitiven zu entwerfen, anstatt an Apples Idee einer Schaltfläche im Vergleich zu Microsofts Vorstellung festzuhalten.

Fasse ich das richtig zusammen?

@pmoorelegistek das ist im Grunde die Idee ja. Und wir gehen Material zuerst an, vor allem, weil Unschärfe kein wichtiges Designelement ist. Das bedeutet, dass wir es tatsächlich überall zum Laufen bringen können (wenn Sie sich Ihr Android ansehen).

Wenn ich Shell v1 beendet habe, gehe ich sofort zu diesem über

@jassmith Das ist golden. Verwenden Sie native Steuerelemente dort, wo sie zum UX-Design passen, und fügen Sie einfach Skia-ähnliche gezeichnete Steuerelemente nur für die (vorzugsweise wenigen) Designelemente hinzu, die dies benötigen.

Keine „das geht nicht in Xamarin Forms“-Gespräche mit Designern und Kunden mehr. Dies beseitigt Designbeschränkungen und bewahrt gleichzeitig das echte native Gefühl (im Gegensatz zu Flattern).

Ich würde das gerne vor der materiellen Hülle sehen. Dies löst eine echte Einschränkung von XF.
Shell ist das n-te Feature für einen einfachen/schnelleren Einstieg. _Starten_ war viel zu lange der Fokus, aber Funktionen wie diese, um _weiter_ zu kommen, werden XF-Entwickler _an Bord halten_.

Dies muss vor Material Shell geschehen, da Material Shell davon abhängt. Ich glaube, du wolltest damit sagen, dass du das lieber vor Shell sehen würdest?

Shell konzentriert sich nicht darauf, schneller/einfacher loszulegen. Es soll die Seiten auf eine Weise modernisieren, die wir nicht tun können, wenn sie ihre eigenen Steuerelemente sind. Es ist im Grunde beabsichtigt, sie vollständig zu ersetzen, und wir werden die Leute ermutigen, eine Portierung in Betracht zu ziehen. Shell konzentriert sich darauf, Endbenutzern ein weitaus flüssigeres und reichhaltigeres Erlebnis zu bieten, seine Animation kann angepasst werden, es kann Dinge vor/nach Animationen verzögern/faul laden, damit sie keinen Schluckauf verursachen. Es bietet einen 0-GPU-Überziehungsinhaltsbereich in Android, vergleichen Sie dies mit aktuellen Seiten, auf denen die Überziehung überall nur im „roten, fick dich selbst“-Teil des Diagramms ist.

Bei Shell geht es nicht darum, Menschen schneller zum Einstieg zu bringen, sondern darum, Ihre App schneller zu machen. Mit Shell können Sie beispielsweise Seiten/Tabs/Gruppen als „häufig“ markieren und sie werden vom System beibehalten, vorausgesetzt, der Benutzer besucht sie ständig. Dies bedeutet, dass sie nicht neu geladen werden, wenn Sie wegnavigieren und zurückkommen. Wir können das tun, weil Shell die gesamte Seitenhierarchie besitzt.

Wir haben auch einige Gedanken darüber, wie wir die Zeichenleistung mit Shell optimieren können, die das Zeichnen mit Shell zwar niemals auf Shell beschränken werden, aber das Zeichnen mit Shell möglicherweise viel effizienter machen würden, da wir möglicherweise alle Zeichenvorgänge im selben Durchgang ausführen können. Hier ist ein Salzkorn erforderlich, da diese Spitze noch nicht fertig ist, aber auf dem Papier sieht es anständig aus.

@weitzhandler Ich hoffe, in den nächsten 4-6 Wochen dazu übergehen zu können. Dies wird viel schneller sein, um diese Shell zum Laufen zu bringen. Keine dieser Zeiten ist in Stein gemeißelt.

+1

@jassmith https://github.com/nventive/Uno
das ist großartig.
Uni-Rendering ist großartig

forms wird ein radikaler Entdecker sein, während uno ein konservativer sein soll
wir lieben beides

+1 Tolle Funktion, die viele Probleme mit benutzerdefinierten Benutzeroberflächen lösen wird, die wir so schnell wie möglich sehen möchten

@jassmith scheint, dass die Auslosung für 3.3.0 durchgeführt werden soll？

Gibt es hierzu Neuigkeiten?

Für uns ist dies das überzeugendste Feature, von dem wir hoffen, dass es Xamarin implementiert.

Wir entwickeln hauptsächlich LoB-Apps, und eine unserer obersten Prioritäten ist die Entwicklungsgeschwindigkeit.
Wir kümmern uns weniger um das native Erscheinungsbild, solange es eine überzeugende Benutzeroberfläche gibt, die gute Arbeit leistet, gut gerendert wird und weniger Entwicklungszeit benötigt.

Jedes Formular und jede Seite auf jeder Plattform separat testen und anpassen zu müssen, ist ein echter Zeitkiller, da jede geringfügige Änderung der Benutzeroberfläche auf allen Plattformen hin und her dreifach überprüft werden muss.

Shell & Material Shell ist ein Segen und eine großartige Nachricht, bitte treiben Sie dies voran! Dies ist das einzige, was Ihre Benutzer dazu bringt, woanders hinzugehen (Uno, Flutter und andere).

traurige Nachricht, dass die Auslosung für 3.3 nicht erscheinen würde

+1 dafür, aus einem UWP-Hintergrund kommend, möchte ich wirklich XF verwenden, aber es hat Nachteile, derzeit versuche ich Flattern, werde aber sicherlich zu XF kommen, wenn dies so schnell wie möglich implementiert wird.

Ich stimme zu, dass dies eine großartige Funktion ist und implementiert werden muss. Ich werde auch Stile für Linien hinzufügen, z. B. durchgezogene Linien, gepunktete Linien usw.

Irgendwelche Neuigkeiten? Pläne? Fahrplan?

Komischerweise habe ich erst letzte Nacht mit benutzerdefinierten Renderern experimentiert und bin fast zu dem Schluss gekommen, dass all dies erreicht werden kann, indem wir einfach unsere eigenen Grundelemente als benutzerdefinierte Ansichten definieren und darauf aufbauen. Sie brauchen nicht viel mehr als einen Rahmen, eine Ellipse und eine Linie.
Ich bin gespannt, ob dies offiziell unterstützt wird, aber ich warte nicht. :)

@Jassmith
Also werden zum Beispiel Line und Rectangle echte Aufrufe sein? (denn in dem Beispiel sehe ich Grid mit Ellipse als untergeordnete Ansicht). Wille
Kann ich einen TapGestureRecognizer an Rectangle anhängen, um das Tap-Ereignis zu verarbeiten?
Da dies reale Ansichten sind, wird es sich nicht nachteilig auf die Rendering-Geschwindigkeit auswirken, tatsächliche Ansichten zum Zeichnen von Primitiven zu haben?

@andreinitescu Ich glaube, die Absicht ist, dass sie echte Ansichten auf der Xamarin Forms-Seite sind, aber niemals nativ als Ansichten realisiert werden:

_ein Zeichenelement ist einfach eine Ansicht, die keinen Renderer hat_

Ein Renderer weiter oben in der Kette ( Drawing ? DrawingTemplate ?) ist also dafür verantwortlich, durch zeichenbare Nachkommen zu iterieren und sie zu zeichnen.

Ich würde vermuten, dass dies die gleichen Einschränkungen bedeutet, die für Layouts mit CompressedLayout.IsHeadless gelten (keine Gestenerkennung, keine Effekte, keine Transformationen usw.).

@GalaxiaGuy Ich denke in die gleiche Richtung, aber ich finde es etwas verwirrend, weil ich mich mit echten Ansichten wie Grid vermische. Ist es wirklich notwendig? Anstatt von View abzuleiten, warum nicht diese als abstrakte Zeichnungselemente haben (vielleicht eine abstrakte Basisklasse namens DrawingElement mit gemeinsamen Eigenschaften?)

Netter Job, nur richtiges Beispiel

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

Vielleicht wird es in 4.0 sein?

Drawing ist insofern gut, als es Steuerelemente implementiert, die Grafikprimitive unabhängig von der Zielplattform verwenden. Früher gab es NControl, aber dies hatte Probleme (aus Tagen vor Netstandard 2.0, vor SkiaSharp) und wird nicht aktualisiert.

Die Spezifikation 1. dupliziert die Funktionalität, die bereits in einer viel vollständigeren Form in Skiasharp implementiert ist, 2. fügt unnötige Komplexitätsebenen über XAML/Binding hinzu, die in das bereits nicht mehr wartbare Xamarin.Forms-Repository eingefügt werden.

Ein besserer Ansatz besteht darin, eine kleine Steuerelementbibliothek basierend auf skiasharp zu erstellen. NControl++

@jassmith @rogihee SVG ist wirklich kein Versandformat, tut mir leid: / Ich möchte nicht dafür verantwortlich sein, SVG konsistent plattformübergreifend zu rendern.

Skiasharp bietet SVG-Unterstützung.

Irgendetwas Neues darüber?

Irgendetwas Neues darüber?

Fragt sich auch, ob das noch passieren wird. Ich bin sehr im Lager, wenn ich mir ein unscheinbares plattformübergreifendes UI-Framework wünsche, und dies scheint der beste Weg zu sein, dies zu erreichen.

@legistek Sie können SkiaSharp für plattformübergreifendes Zeichnen ohne Aussehen verwenden. Was sind Ihrer Meinung nach die Vorteile eines Xamarin.Forms-spezifischen?

Zu einem UI-Framework gehört etwas mehr als Zeichnen.

Aber dieser Thread diskutiert ein Zeichnungs-Framework, kein UI-Framework ...

Ich dachte, es würde ein Zeichnungsframework _für Xamarin Forms_ diskutieren.

Skiasharp ist ein Zeichnungsframework für Xamarin Forms. Die Tatsache, dass es auch auf anderen .Net-UI-Plattformen funktioniert, ist sicherlich ein Vorteil, kein Nachteil.

Und wie im OP gesagt wurde, könnte Skiasharp durchaus das zugrunde liegende Zeichenmodul auf den einzelnen Plattformen sein, aber die Idee dieses Vorschlags besteht darin, eine Abstraktionsschicht hinzuzufügen und das Zeichnen durch XAML mit all seinen Vorteilen zu unterstützen, wobei der bemerkenswerteste die Datenbindung ist. Was Sie unnötige Komplexität nennen, nenne ich elegant.

Ist das noch am Leben und/oder wird es in MAUI eingeführt?

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap listet Formen, Pfade und Pinsel wie in der Roadmap für Xamarin.Forms 4.7.0 auf.

Wunderbare Neuigkeiten! Danke!