Zeichnen und Grafik in Wisej.NET

Zeichnen und Malen in Wisej.NET beginnt mit einer Entscheidung, die vor jedem Zeichencode steht: wo die Pixel tatsächlich entstehen. In diesem Modul erscheint ein einziger Telemetriemesswert auf vier verschiedenen Oberflächen von Visual Operations Studio, sodass Sie sie direkt nebeneinander vergleichen können.

Eine Zahl zu zeichnen ist nicht eine Anforderung, sondern vier. Ein Rundinstrument auf einer Betriebsseite, eine kleine Anzeige in einer Grid-Zelle, ein Knoten auf einer Topologiekarte und ein Bild in einer Reportdatei zeigen denselben Wert. Doch jedes entsteht an anderer Stelle, und jedes schickt etwas anderes zum Browser.

Ein Paint-Handler läuft auf dem Server; das Ergebnis erreicht den Browser als fertiges Bild. CellPaint leistet dieselbe Arbeit, begrenzt auf eine einzelne Grid-Zelle. Die Canvas verhält sich anders: Sie sendet Zeichenbefehle, die der Browser selbst ausführt. Das Off-Screen-Rendering erzeugt Bildbytes, die kein Control jemals anzeigt.

Auf der Seite lesen alle vier Oberflächen dasselbe TelemetrySample-Feld; keine besitzt den Wert. Ein Button ändert dieses Feld und frischt jede Oberfläche auf ihre Weise auf: Label und Fortschrittsbalken lesen es einfach, das gezeichnete Panel wird invalidiert und vom Server neu gezeichnet, die Szenenmethode der Canvas läuft erneut, und ein frisches Off-Screen-Bild entsteht.

Eigenes Zeichnen steht am Ende einer Entscheidungsleiter, nicht am Anfang. Greifen Sie zuerst zu einem Standard-Control, dann zu gewöhnlichem Markup, und erst danach zu einem Paint-Handler, einer gezeichneten Zelle oder einer Canvas. Das Off-Screen-Rendering folgt darauf, und eine Zeichenschleife im Browser bleibt den Fällen vorbehalten, in denen die Bildrate wirklich zählt.

Eine Canvas neu zu zeichnen heißt, sie zu leeren und die ganze Szene aus dem Modell neu aufzubauen, denn auf die Kopie im Browser kann sich der Server nicht verlassen. Der Off-Screen-Renderer steht am anderen Ende: eine Bitmap und eine darüber erzeugte Graphics-Fläche genügen für ein Bild, ganz ohne Control.

Führen Sie die Seite aus und klicken Sie auf New reading. Dieselbe Zahl erscheint an allen vier Stellen gleichzeitig, als wäre es ein einziger Vorgang. Das ist es nicht. Jede Oberfläche hat dafür etwas ganz anderes auf die Leitung gelegt, und genau um diesen Unterschied geht es hier.

Ändern Sie nun die Größe des Browserfensters. Drei Oberflächen kehren von selbst zurück, denn der Server besitzt weiterhin, was sie zeigen. Die Canvas kommt leer zurück und bleibt leer, bis die Redraw-Methode sie aus dem gespeicherten Messwert neu aufbaut. Diese Asymmetrie ist die praktische Folge der Grenze.

Im ersten Lab bauen Sie diese Seite selbst: ein Modell hinter vier Oberflächen, ein Button, der alle vier auffrischt, und eine kurze Notiz dazu, was pro Oberfläche über das Netz geht und welche Darstellung eine Größenänderung übersteht.

Dieses Modul baut ein gezeichnetes Control richtig. Das TelemetryGauge zeichnet einen Ring, seine Schwellenzonen, einen Zeiger und einen Zahlenwert. Jede öffentliche Property begrenzt zuerst den übergebenen Wert und entscheidet erst danach, ob überhaupt neu gezeichnet werden muss.

Ihr Zeichencode läuft auf dem Server, und der Browser bekommt das fertige Bild. Das ist bequem, und genau deshalb ist ein in sechs Panels kopierter Handler teuer: Es entstehen sechs Bilder, sechs Sätze von Zeichenobjekten und Neuzeichnungen, um die niemand gebeten hat.

Also erst rechnen, dann zeichnen. Der Helfer GaugeGeometry nimmt ein Rechteck und liefert die Ringgrenzen, die Winkelbereiche, die Zeigerpunkte und das Rechteck der Beschriftung. Das ist gewöhnliche Mathematik ohne jeden Zeichenaufruf, und deshalb lässt sich der schwierige Teil prüfen, ohne je ein Control zu erzeugen.

Jeder Property-Setter folgt einem Rezept: den eingehenden Wert begrenzen, mit dem aktuellen vergleichen, sofort zurückkehren, wenn sich nichts geändert hat, zuweisen und genau einmal invalidieren. Dieselbe Stelle frischt die AccessibleDescription auf, sodass der Messwert auch als Text verfügbar bleibt und nicht nur als Pixel.

Der Handler sichert sich gegen ein ClipRectangle ohne Größe ab, ruft die Messung einmal auf und zeichnet dann. Fünf using-Deklarationen decken die fünf Objekte ab, die dieser Code erzeugt und damit besitzt. Das Graphics aus den Ereignisargumenten gehört nicht dazu; es freizugeben wäre ein Fehler.

Der Besitz klärt die meisten heiklen Fragen. Brushes und Pens des Frameworks sind geteilt und bleiben unangetastet. Ein eigener statischer Pen ist unsicher, sobald mehrere Sitzungen gleichzeitig zeichnen. Und ein Datenbankaufruf, das Laden einer Schrift oder ein Timer haben im Zeichenpfad nichts zu suchen.

Sehen Sie zu. Ein Messwert ändert sich, also invalidiert ein Gauge, und ein Bild entsteht. Die beiden anderen Setter haben ihre Werte verglichen und sind früh zurückgekehrt — genau darum geht es. Eine Größenänderung baut danach jedes Bild aus dem neuen ClipRectangle auf, in der neuen Größe.

Dann kommt das Budget: Prozessorzeit auf dem Server, Speicher für die temporäre Bitmap und die Bytes, die jedes Neuzeichnen versendet. Wenn diese Zahlen die Pixel nicht mehr rechtfertigen, ist ein gethemtes Control die bessere Antwort. In beiden Fällen müssen die Werte als Text lesbar bleiben.

Im zweiten Lab bauen Sie das Gauge und seinen reinen Geometrie-Helfer, sichern Größe null und einen umgekehrten Wertebereich ab, veröffentlichen den Messwert über die AccessibleDescription und notieren die Kosten eines Neuzeichnens.

In diesem Modul zeichnet das Grid. Visual Operations Studio zeigt jetzt tausend Maschinen, und zwei seiner Spalten müssen auf einen Blick lesbar sein statt Zahl für Zahl.

Dorthin führen drei Wege. Eine gebundene Zahl, die niemand überfliegt, ist ehrlich, aber nutzlos. Ein Gauge-Control in jeder Zeile ist lesbar und ruinös, denn das wären tausend serverseitige Controls in einer einzigen Sitzung. Der dritte Weg ist eine Zelle, die sich selbst zeichnet, und das nur, solange sie wirklich sichtbar ist.

UserPaint kommt immer vor CellPaint: Eine Zelle oder eine ganze Spalte wird auf selbst gezeichnet geschaltet, und erst dann löst das Grid dafür sein CellPaint-Event aus. Die Ereignisargumente leiten sich von den gewöhnlichen Paint-Argumenten ab, tragen also Graphics und ClipRectangle, und ergänzen RowIndex und ColumnIndex für die Verteilung.

Ein Unterschied wiegt schwerer als alle anderen. Die Ereignisargumente von Wisej.NET bieten keine Helfer für Hintergrund oder Inhalt, Ihr Handler verantwortet also alles, was in dieser Zelle erscheint. Ein Windows-Forms-Beispiel unverändert zu übernehmen funktioniert nicht. Abonnieren Sie einmal am Grid und verzweigen Sie auf die beiden Spalten, die Ihnen gehören.

Sichern Sie ab, bevor Sie zeichnen. Ein negativer RowIndex ist eine Kopfzeile und keine Datenzeile, und eine fremde Spalte kehrt sofort zurück. Erst danach nehmen Sie die Geometrie aus dem ClipRectangle und lesen die benötigten Werte in einem einzigen Schritt aus dem Objekt, an das die Zeile bereits gebunden ist.

Im Lauf erzeugen sechs sichtbare Zeilen zwölf Aufrufe im Handler: ein schwellenwertgefärbter Balken für die Gesundheit und eine kleine Sparkline für den Trend. Die ausgewählte Zeile wird mit eigenen Farben gezeichnet, denn eine gezeichnete Zelle, die die Auswahl ignoriert, wirkt defekt, sobald jemand sie anklickt.

Scrollen Sie nun durch die tausend Zeilen. Jede neu sichtbare Zelle ruft den Handler erneut auf, und damit wird er zu einem heißen Pfad. Deshalb enthält er keinen Datei- oder Datenbankzugriff, erzeugt keine Schriften oder Bilder pro Zelle, und das Auslesen einer Zeile bleibt ein Schritt mit konstanter Laufzeit.

Danach der ehrliche Vergleich. Markup in der Zelle gewinnt bei Text, Icons und Barrierefreiheit. Zeichnen gewinnt bei Geometrie, die Markup nicht ausdrücken kann. Und ein echter Zellentyp gewinnt immer dann, wenn die Benutzerin mit der Zelle arbeiten und sie nicht nur lesen soll.

Im dritten Lab bauen Sie zwei gezeichnete Spalten hinter einem abgesicherten Handler, lesen die Werte jeder Zeile in einem Schritt, bauen dieselbe Statusanzeige noch einmal als Markup-Zelle und halten fest, welche der beiden Sie wirklich ausliefern würden.

Visual Operations Studio braucht jetzt eine echte Zeichenfläche. Die Canvas von Wisej.NET öffnet Ihnen den zweidimensionalen Zeichenkontext des Browsers aus C# heraus, mit einer Bedingung: Sie merkt sich nichts für Sie.

Paint und CellPaint senden beide ein fertiges Bild, und der Server weiß, was darauf zu sehen ist. Die Canvas sendet stattdessen Zeichenbefehle, die der Browser ausführt. Auf dem Server bleibt nichts zurück, und eine Größenänderung kann das Ergebnis löschen. Die Szene muss also dort leben, wo Sie sie beherrschen.

Ein Browser-Beispiel zu übersetzen braucht drei Durchgänge. Passen Sie die Schreibweise an, denn die Member sind die vertrauten in der C#-Konvention. Ersetzen Sie die Stilzeichenketten durch .NET-Typen wie Color und Font. Rechnen Sie Winkel von Radiant in Grad um. Prüfen Sie zuletzt, ob es den Member wirklich gibt, statt anzunehmen, alles aus dem Browser sei übernommen worden.

Das Redraw-Event ruft genau eine Methode auf. Diese Methode leert zuerst die ganze Fläche, und jede Form beginnt einen neuen Pfad, bevor sie zeichnet. Lässt man das weg, zieht ein späterer Strich die vorige Kontur mit — einer der häufigsten Fehler beim Übersetzen eines Beispiels.

Text wird über TextAlign und TextBaseline positioniert statt vermessen, denn der Messaufruf des Browsers gehört nicht zur dokumentierten Oberfläche. Farbverläufe sind eigenständige Objekte: Sie bauen einen und weisen ihn dann als Füllstil zu, statt ihn jedes Mal direkt zu beschreiben.

Jede Transformation steht zwischen Save und Restore. Ebenso der Clipping-Bereich, ebenso die Transparenz, ebenso Strichmuster und Schatten, denn all das ist Zustand der Canvas und kein Argument eines einzelnen Aufrufs. Diese Klammer verhindert, dass ein Abschnitt in den nächsten überläuft.

Fünf Abschnitte gehen gemeinsam in einer Aktualisierung hinaus, denn LiveUpdate bleibt standardmäßig aus. Schalten Sie es nur ein, wenn eine lange Serveroperation ihren Fortschritt zeigen soll. Es ist kein Mittel zum Animieren, und eine Anfrage pro Einzelbild ist die falsche Architektur.

Zwei Fehler sollten Sie absichtlich sehen. Ändern Sie die Größe der Fläche, und sie bleibt leer, bis Redraw sie aus dem Modell neu aufbaut. Entfernen Sie einen einzigen Restore-Aufruf, und alles danach Gezeichnete verrutscht. Keiner von beiden zeigt sich im Designer, und genau deshalb kosten sie so viel Zeit.

Im vierten Lab zeichnen Sie die ganze Spielwiese aus einer Methode, die Redraw aufruft, klammern jede Transformation, ergänzen einen Clip, einen Transparenzabschnitt, ein Strichmuster und einen Schatten und portieren ein Beispiel von Radiant in die Grad, die der Rotate-Aufruf von Wisej.NET erwartet.

Die Canvas vergisst, das Modell darf es nicht. In diesem Modul wird die Spielwiese aus dem vorigen Modul zu einem Topologie-Editor mit Auswahl, Ziehen, Verschieben und Zoomen, und jede dieser Gesten muss ein Neuzeichnen überstehen.

Ein Rechteck im Browser ist keine Pumpe. Die Bedeutung liegt im Szenenobjekt auf dem Server: die Knoten, die Kanten, was ausgewählt ist, wo der Viewport steht. Eingaben ändern diesen Zustand, und eine einzige Render-Methode macht daraus Zeichenaufrufe. Der Renderer entscheidet nie etwas.

Das Rendering rechnet Weltkoordinaten in Bildschirmkoordinaten um: erst der Zoom, dann die Verschiebung. Die Trefferprüfung muss diese Umrechnung rückwärts laufen lassen und die Zeigerposition zurück in Weltkoordinaten bringen, bevor sie sie mit einem Knoten vergleicht. Die Canvas bietet keine Punkt-im-Pfad-Prüfung, diese Mathematik gehört Ihnen.

Beginnen Sie beim Modell. Knoten und Kanten tragen stabile Kennungen und ihre eigene Geometrie, und die Szene lebt pro Sitzung, niemals in einem veränderlichen statischen Feld, das alle Benutzer teilen würden. Die Trefferprüfung geht die Liste rückwärts durch, sodass der zuletzt und damit obenauf gezeichnete Knoten gewinnt.

Die drei Zeiger-Handler tun sehr wenig. MouseDown rechnet um und prüft den Treffer, MouseMove zieht die Auswahl oder verschiebt den Viewport, MouseUp beendet die Geste. Jeder ändert Zustand und ruft dann die eine Render-Methode. Redraw ruft dieselbe Methode auf, und deshalb baut eine Größenänderung die Szene einfach neu auf.

Wird das Neuzeichnen zu teuer, arbeiten Sie eine Leiter ab: erst weniger Primitive, dann Culling für alles außerhalb des Bildes, dann einfachere Geometrie, dann Zwischenspeichern selten wechselnder Ebenen. Die Schleife in den Browser zu verlegen ist der letzte Schritt, nicht der erste, und LiveUpdate bleibt beim Haupt-Rendering aus.

Im Browser wird der Klick in Weltkoordinaten umgerechnet, findet die zweite Pumpe, markiert sie als ausgewählt und rendert. Beobachten Sie den Anfragezähler beim Ziehen. Diese Zahl ist der wahre Preis eines serverseitigen Ziehens, und sie sagt Ihnen, wann Schluss sein sollte.

Zoomen Sie um den Zeiger herum, und die Auswahl trifft weiterhin den richtigen Knoten, denn die umgekehrte Umrechnung berücksichtigt den neuen Zoom. Knoten außerhalb des sichtbaren Rechtecks werden ganz übersprungen. Und die Tabulatortaste zusammen mit den Pfeiltasten erreicht jeden Knoten, der Editor braucht also keine Maus.

Im fünften Lab bauen Sie die Szene pro Sitzung, prüfen Treffer in Weltkoordinaten, lassen alle drei Handler dieselbe Render-Methode aufrufen, ergänzen Viewport-Culling und den Tastaturpfad und halten fest, ab wann Sie die Interaktion in den Browser verlegen würden.

Dieses Modul erzeugt eine Datei statt eines Bildschirms. Der Betrieb möchte dieselbe Topologie als Bild zum Aufbewahren, erzeugt auf einem Server, unter dem kein klassisches Grafiksubsystem liegt.

Keine der drei bisherigen Oberflächen kann das, denn jede braucht ein lebendes Control und eine lebende Sitzung. Auch die naheliegende Bibliothek fällt aus: Microsoft hat System.Drawing.Common ab .NET 6 als Windows-spezifisch gekennzeichnet, und der Schalter für andere Systeme fiel mit .NET 7 weg.

Drei Namen beschreiben eine Sache, und sie auseinanderzuhalten spart einen Nachmittag. Das Paket, das Sie referenzieren, heißt Managed.System.Drawing, die Assembly auf der Platte heißt System.Drawing.Managed, und der Namespace in Ihrem Code bleibt der vertraute. Es ist eine verwaltete Rendering-Engine und keine Hülle über der Grafikschicht der Plattform.

Der Renderer nimmt eine Szene und eine Ausgabegröße und liefert Bytes. Er erzeugt eine Bitmap, holt sich darüber eine Graphics-Fläche, zeichnet die Kanten, die Knoten und die Beschriftungen mit Pens, Brushes und einem Pfad und speichert das Ergebnis als PNG in einen Speicherstrom. Ein Control kommt darin nirgends vor.

Die Plattformmatrix sollten Sie sich merken. Die Schriftvermessung ist überall verwaltet. Das Zeichnen ist im modernen .NET auf jedem Betriebssystem verwaltet und fällt nur im .NET Framework und im Designer-Build auf die Plattformschicht zurück. Binden Sie eine plattformübergreifende Auslieferung nie an ein reines Windows-Zielframework, um ein Zeichenproblem loszuwerden.

Zwei Entscheidungen bestimmen dann, ob das die Auslieferung übersteht. Lösen Sie die Schrift über eine Kette auf, die bei einer Datei endet, die Sie selbst mitliefern, statt eine Schrift auf dem Host vorauszusetzen. Und halten Sie genau eine Zeichenimplementierung im Referenzgraphen, denn zwei, die dieselben Typnamen auflösen, ergeben ein Fehlerbild, das Sie ungern suchen.

Führen Sie es aus. Der Export rendert off-screen in etwa vierunddreißig Millisekunden, ganz ohne Control, und die Bytes gehen als Download an den Browser. Begrenzen Sie aber die angeforderte Größe: Eine Bitmap mit viertausend mal dreitausend Pixeln kostet rund achtundvierzig Megabyte, bevor Sie überhaupt gezeichnet haben.

Jetzt der Container. Derselbe Test besteht unter Linux, nichts ist gegen libgdiplus gelinkt, und die beiden Bilder sind byteidentisch, weil die Schrift mit der Anwendung ausgeliefert und nicht vom Host geborgt wurde.

Im sechsten Lab bauen Sie den Control-freien Renderer, geben ihm eine Fallback-Kette für Schriften, laden das Bild von der Seite herunter, prüfen die Referenzen auf eine zweite Zeichenimplementierung und halten Ihre Belege aus Windows und Linux fest, samt dem, was daraus für die mobilen und die Desktop-Ziele folgt.

Das ist das Abschlussprojekt. Sechs Module haben in Visual Operations Studio vier Rendering-Oberflächen gebaut, jede für sich korrekt. Sie auszuliefern heißt, sie miteinander in Einklang zu bringen und das auch zu belegen.

Im Moment hält jede Oberfläche ihre eigenen Schwellen, ihre eigenen Farben und ihre eigene Vorstellung davon, wo etwas sitzt. Verschieben Sie die Warnschwelle einmal, und das exportierte Bild widerspricht still dem Bildschirm, von dem es stammt. Das ist kein Renderfehler, sondern eine Fachregel in vier Kopien.

Die Abhilfe sind drei Schichten. Ein visuelles Modell hält semantischen Zustand: Werte, Status, Auswahl. Eine Geometrieschicht macht aus diesem Zustand und einer Größe Formen, und sie ist reine Mathematik. Dann ein Renderer pro Oberfläche, jeder mit den Primitiven, die zu ihm passen, denn eine gemeinsame Schnittstelle hilft hier niemandem.

Einigen Sie sich als Nächstes auf Zahlen, bevor Sie irgendetwas optimieren. Ein gezeichnetes Control sollte unter etwa fünf Millisekunden bleiben. Ein vollständiges Canvas-Neuzeichnen gehört in den Bereich von sechzehn bis fünfzig Millisekunden. Ein Export darf langsamer sein, solange er nie die Sitzung einer anderen Benutzerin blockiert.

Der Geometrie-Aufruf nimmt das Modell und eine Größe und liefert Formen; beide Renderer rufen ihn auf, also kann keiner abdriften. Daneben hält ein kleiner Metrik-Helfer fest, wie lange ein Rendering gedauert hat, wie groß die Ausgabe war und wie viele Szenenobjekte tatsächlich gezeichnet wurden. Ohne diese drei Zahlen ist Optimieren Raten.

Zeichnen Sie danach die schlechten Zustände absichtlich. Leere Daten, eine Fläche ohne Größe, ein Wertebereich, dessen Minimum größer ist als sein Maximum, eine fehlende Schrift: Jeder Fall soll zu etwas Lesbarem herabstufen, statt eine Ausnahme zu werfen. Und ein gescheiterter Export soll als Meldung bei der Benutzerin ankommen, nicht als leere Stelle.

Ein Wert ändert sich, und alle vier Oberflächen folgen ihm: das gezeichnete Gauge, die gezeichneten Zellen, die Canvas-Topologie und das exportierte Bild. Daneben steht eine schlichte Tabelle mit jedem Messwert, und genau sie macht die Information auch für jemanden verfügbar, der die Grafik gar nicht nutzen kann.

Zum Schluss die Belege. Das gezeichnete Gauge fiel von etwa elf Millisekunden auf vier, der Export von rund dreihundertzehn Millisekunden auf hundertachtundzwanzig, und die Testmatrix deckt Windows, Linux, die Hybrid-Ziele und drei Browser ab. Auch eine gemessene Entscheidung, nicht zu optimieren, zählt, solange sie aufgeschrieben ist.

Das letzte Lab ist das Abschlussprojekt: ein Modell hinter allen vier Oberflächen, ein Metrik-Helfer, eine Optimierung mit Messung davor und danach, vier herabgestufte Pfade, die sanft scheitern, und die Notizen, die die Architektur und ihre Grenze erklären.