Disegno e grafica in Wisej.NET

Disegno e grafica in Wisej.NET si apre con una decisione che viene prima di qualsiasi codice di disegno: dove vengono prodotti davvero i pixel. In questo modulo una sola lettura di telemetria viene mostrata su quattro superfici diverse di Visual Operations Studio, così puoi confrontarle fianco a fianco.

Chiedere a un'applicazione di disegnare un numero non è un requisito solo, sono quattro. Un quadrante su un cruscotto, un piccolo indicatore dentro una cella di griglia, un nodo su una mappa di topologia e un'immagine scritta su un file di report mostrano tutti lo stesso valore, eppure ognuno viene prodotto altrove e ognuno manda al browser qualcosa di diverso.

Un gestore Paint viene eseguito sul server, e il risultato finito viaggia fino al browser sotto forma di immagine. Il CellPaint fa lo stesso lavoro, confinato dentro i limiti di una sola cella. Un Canvas si comporta in modo diverso: invia comandi di disegno che il browser esegue da sé. Il disegno off-screen produce byte di immagine che nessun controllo mostra mai.

Nella pagina, tutte e quattro le superfici leggono un solo campo di telemetria, quindi nessuna di loro possiede il valore. Un pulsante cambia quel campo e aggiorna ogni superficie a modo suo: la label e la barra di avanzamento si limitano a leggerlo, il pannello disegnato viene invalidato perché il server lo ridisegni, il metodo che costruisce la scena del Canvas viene eseguito di nuovo, e viene prodotta una nuova immagine off-screen.

Il disegno personalizzato sta in fondo a una scala di decisione, non all'inizio. Parti da un controllo standard, poi dal markup ordinario, e solo allora da un gestore Paint, da una cella disegnata o da un Canvas. Il disegno off-screen viene dopo, e un ciclo di disegno nel browser resta riservato ai casi in cui i fotogrammi al secondo contano davvero.

Ridisegnare un Canvas significa svuotarlo e ricostruire l'intera scena a partire dal modello, perché la copia che ha il browser non è qualcosa su cui il server possa contare. Il renderer off-screen sta all'estremo opposto: un Bitmap, e una superficie Graphics creata sopra di esso, bastano a produrre un'immagine senza che sia coinvolto nessun controllo.

Esegui la pagina e premi il pulsante New reading. Lo stesso numero compare in tutti e quattro i punti nello stesso istante, e questo fa sembrare che sia una sola operazione. Non lo è. Ogni superficie ha appena messo in rete qualcosa di molto diverso per arrivarci, ed è proprio quella differenza il vero tema di questo modulo.

Adesso ridimensiona la finestra del browser. Tre superfici tornano da sole, perché è ancora il server a possedere quello che mostrano. Il Canvas torna vuoto, e resta vuoto finché il metodo di ridisegno non lo ricostruisce dalla lettura di telemetria che il server ha conservato. Quell'asimmetria è la conseguenza pratica del confine.

Nel primo lab costruisci tu questa pagina: un solo modello dietro quattro superfici, un unico pulsante che le aggiorna tutte, e una breve nota che registra che cosa attraversa la rete per ogni superficie e quali elementi grafici sopravvivono a un ridimensionamento.

Questo modulo costruisce un controllo disegnato come si deve. Il gauge di telemetria disegna un anello, le sue zone di soglia, un ago e una lettura numerica, e ognuna delle sue proprietà pubbliche fa il clamp di quello che riceve prima ancora di decidere se serva davvero un ridisegno.

Il tuo codice di disegno viene eseguito sul server, e il browser riceve l'immagine risultante. È comodo, ed è anche il motivo per cui un gestore copiato dentro sei pannelli costa caro: vengono prodotte sei immagini, vengono creati sei insiemi di oggetti di disegno, e avvengono ridisegni che nessuno ha chiesto.

Quindi prima misura, poi disegna. L'helper di geometria prende un rettangolo e restituisce i bounds dell'anello, gli angoli di apertura, i punti dell'ago e il rettangolo in cui sta l'etichetta. È aritmetica ordinaria, senza disegno dentro, e questo significa che puoi testare la parte difficile senza creare mai un controllo.

Ogni setter di proprietà segue una sola ricetta: fai il clamp del valore in arrivo, confrontalo con quello corrente, esci subito se non è cambiato nulla, assegnalo e chiama Invalidate esattamente una volta. La stessa riga di codice aggiorna anche l'AccessibleDescription, così la lettura resta disponibile come testo e non soltanto come pixel.

Il gestore si protegge da un clip di dimensione zero, chiama il passo di misura una volta sola, poi disegna. Cinque dichiarazioni using coprono i cinque oggetti che questo codice crea e quindi possiede. La superficie Graphics che ricevi negli argomenti dell'evento non è uno di questi, e farne il dispose sarebbe un errore.

La proprietà degli oggetti risolve quasi tutte le domande scomode. I brush e le pen del framework sono condivisi e vanno lasciati stare, una pen statica tua non è sicura quando più sessioni disegnano insieme, e una chiamata al database, il caricamento di un font o un timer non hanno nulla da fare dentro un percorso di disegno.

Guardalo mentre gira. Si muove una lettura, quindi si invalida un solo gauge e viene prodotta una sola immagine. Gli altri due setter hanno confrontato i valori e sono usciti subito, ed è esattamente questo il punto. Poi un ridimensionamento ricostruisce ogni immagine dal nuovo clip, alla nuova dimensione.

Poi arriva il budget: tempo di processore sul server, memoria per la bitmap temporanea, e byte spediti a ogni ridisegno. Quando quei numeri smettono di giustificare i pixel, un controllo tematizzato è la risposta migliore. In ogni caso, i valori stessi devono restare leggibili come testo.

Nel secondo lab costruisci il gauge e il suo helper di geometria puro, ti proteggi da una dimensione zero e da un intervallo invertito, pubblichi la lettura tramite l'AccessibleDescription e registri nelle tue note quanto costa un ridisegno.

In questo modulo è la griglia a disegnare. Visual Operations Studio ora mostra mille macchine, e due delle sue colonne devono essere leggibili a colpo d'occhio, non un numero alla volta.

Ci sono tre modi per arrivarci. Un numero bound che nessuno legge è onesto ma inutile. Un controllo gauge in ogni riga è leggibile e rovinoso, perché sono mille controlli lato server vivi in una sola sessione. La terza opzione è una cella che si disegna da sola, e solo finché è davvero visibile.

UserPaint viene sempre prima di CellPaint: una cella o un'intera colonna viene messa in modalità disegnata dall'utente, e solo allora la griglia solleva per lei l'evento CellPaint. Gli argomenti dell'evento derivano dai normali argomenti di Paint, quindi portano la superficie Graphics e il rettangolo di clip, e aggiungono gli indici di riga e di colonna che ti servono per l'instradamento.

Una differenza conta più delle altre. Gli argomenti dell'evento di Wisej.NET non portano nessun aiuto per disegnare lo sfondo o il contenuto, quindi il tuo gestore è responsabile di tutto ciò che compare in quella cella. Copiare di peso un esempio Windows Forms non funzionerà. Sottoscrivi una volta sola sulla griglia e distingui le due colonne che sono tue.

Prima le guardie, poi il disegno. Un indice di riga negativo è un'intestazione e non una riga di dati, e una colonna che non è tua esce subito. Solo a quel punto prendi la geometria dal rettangolo di clip e leggi i valori che ti servono, in un solo passo, dall'oggetto a cui la riga è già bound.

Eseguendolo, sei righe visibili producono dodici chiamate al gestore: una barra colorata per soglia su Health, e un piccolo grafico a linee per Trend. La riga selezionata viene disegnata con i suoi colori, perché una cella disegnata che ignora la selezione sembra rotta nel momento stesso in cui qualcuno ci clicca sopra.

Ora scorri le mille righe. Ogni cella che diventa visibile richiama di nuovo il gestore, e questo trasforma il gestore in un percorso caldo. Ecco perché lì dentro non c'è nessun accesso a file o database, nessun font e nessuna immagine creati per cella, ed ecco perché leggere i valori di una riga deve restare un passo a tempo costante.

Poi fai il confronto onesto. Il markup di cella vince per testo, icone e accessibilità. Il disegno vince per la geometria che il markup non sa esprimere. E un tipo di cella vero vince ogni volta che l'utente deve interagire con la cella, non solo leggerla.

Nel terzo lab costruisci due colonne disegnate dietro un unico gestore protetto, leggi i valori di ogni riga in un solo passo, poi ricostruisci lo stesso indicatore di stato come cella di markup e metti per iscritto quale dei due spediresti davvero.

Visual Operations Studio ha bisogno ora di una vera superficie di disegno. Il Canvas di Wisej.NET ti dà dal C# il contesto di disegno bidimensionale del browser, con una condizione: non ricorda nulla.

Paint e CellPaint spediscono entrambi un'immagine finita, e il server sa che cosa contiene quell'immagine. Un Canvas invia invece comandi di disegno che esegue il browser. Sul server non resta nulla, e un ridimensionamento può cancellare il risultato, quindi la scena deve esistere da qualche parte che controlli tu.

Tradurre un esempio del browser richiede tre passaggi. Sistema le maiuscole, perché i membri sono quelli noti nella convenzione del C#. Sostituisci le stringhe di stile con tipi .NET, come colori e font. Converti gli angoli da radianti a gradi. Poi verifica che il membro esista davvero, invece di dare per scontato che tutto ciò che c'è nel browser sia stato riportato.

L'evento di ridisegno chiama esattamente un metodo. Quel metodo si apre svuotando l'intera superficie, e ogni forma comincia un percorso nuovo prima di disegnare. Salta quel passo e un tratto successivo si trascina dietro il contorno precedente: è uno dei modi più comuni in cui un esempio tradotto va storto.

Il testo si posiziona con le proprietà di allineamento e di linea di base invece di essere misurato, perché la chiamata di misura del browser non fa parte della superficie documentata. I gradienti sono oggetti a sé stanti: ne costruisci uno e poi lo assegni come stile di riempimento, invece di descriverlo inline ogni volta.

Ogni trasformazione sta fra un save e un restore. Così anche la regione di clipping, così la trasparenza, e così il tratteggio e l'ombra, perché sono tutti stato del Canvas e non argomenti di una singola chiamata. Racchiuderli fra parentesi impedisce a una sezione di sconfinare in quella dopo.

Cinque sezioni vengono emesse insieme in un solo update, perché il live update per impostazione predefinita resta spento. Accendilo solo quando una lunga operazione lato server deve mostrare i suoi progressi mentre lavora. Non è un modo per animare, e una richiesta per ogni fotogramma è l'architettura sbagliata.

Due modi di fallire vale la pena vederli di proposito. Ridimensiona la superficie e diventa vuota finché il ridisegno non la ricostruisce dal modello. Togli una chiamata a restore e tutto quello che viene disegnato dopo scivola fuori posto. Nessuno dei due si vede nel designer, ed è esattamente per questo che costano così tanto tempo.

Nel quarto lab disegni l'intero playground da un solo metodo chiamato dal ridisegno, racchiudi ogni trasformazione, aggiungi un clip, una sezione di trasparenza, un tratteggio e un'ombra, e porti un esempio del browser misurato in radianti nei gradi che la chiamata di rotazione di Wisej.NET si aspetta.

Il Canvas dimentica, e il modello non deve farlo. In questo modulo il playground del modulo precedente diventa un editor di topologia con selezione, trascinamento, pan e zoom, e ognuno di questi gesti deve sopravvivere a un ridisegno.

Un rettangolo nel browser non è una pompa. Il significato vive nell'oggetto scena sul server: i nodi, gli archi, quale sia selezionato, dove si trovi il viewport. L'input cambia quello stato, e un solo metodo di render trasforma lo stato in chiamate di disegno. Il renderer non decide mai nulla.

Il render converte le coordinate mondo in coordinate schermo applicando prima lo zoom e poi lo scostamento di pan. L'hit testing deve eseguire quella conversione all'indietro, riportando la posizione del puntatore in coordinate mondo prima di confrontarla con un nodo. Il Canvas non offre nessun test di punto dentro un percorso su cui appoggiarti, quindi questa aritmetica è tua.

Parti dal modello. Nodi e archi portano identificatori stabili e la propria geometria, e la scena che li contiene vive per sessione, mai in un campo statico modificabile che tutti gli utenti condividerebbero. L'hit test percorre la lista all'indietro, così il nodo disegnato per ultimo, e quindi sopra agli altri, è quello che l'utente ottiene.

I tre gestori del puntatore fanno pochissimo. MouseDown converte e fa hit test, MouseMove trascina la selezione oppure fa il pan del viewport, MouseUp chiude il gesto. Ognuno di loro cambia lo stato e poi chiama l'unico metodo di render. L'evento di ridisegno chiama lo stesso metodo, ed è per questo che un ridimensionamento si limita a ricostruire la scena.

Quando ridisegnare costa troppo, scendi lungo una scala: prima meno primitive, poi salta quello che è fuori schermo, poi semplifica la geometria, poi metti in cache gli strati che cambiano di rado. Spostare il ciclo nel browser è l'ultimo passo, non il primo, e il live update resta spento per il render principale.

Nel browser il clic viene convertito in coordinate mondo, trova la seconda pompa, la marca come selezionata e disegna. Guarda il contatore delle richieste salire mentre trascini. Quel numero è quanto costa davvero un trascinamento lato server, ed è la misura che ti dice quando fermarti.

Fai zoom attorno al puntatore e la selezione continua a cadere sul nodo giusto, perché la conversione inversa tiene conto del nuovo zoom. I nodi fuori dal rettangolo visibile vengono saltati del tutto. E il tasto tab insieme ai tasti freccia raggiunge ogni nodo, così l'editor non richiede un mouse per essere usabile.

Nel quinto lab costruisci la scena per sessione, fai hit testing in coordinate mondo, mantieni tutti e tre i gestori che chiamano un solo metodo di render, escludi quello che è fuori schermo, aggiungi il percorso da tastiera e registri il punto in cui sposteresti l'interazione dentro il browser.

Questo modulo produce un file invece di una schermata. Operations vuole la stessa topologia come immagine da conservare, generata su un server che sotto non ha un sottosistema grafico del tipo tradizionale.

Nessuna delle tre superfici precedenti può farlo, perché a ognuna serve un controllo vivo e una sessione viva. Anche la libreria ovvia è esclusa: Microsoft ha reso il suo pacchetto di disegno classico specifico per Windows a partire da .NET 6, e l'interruttore che riabilitava gli altri sistemi è stato rimosso in .NET 7.

Tre nomi descrivono una cosa sola, e tenerli distinti ti risparmia un pomeriggio. Il pacchetto a cui fai riferimento è la distribuzione gestita, l'assembly su disco è la libreria di disegno gestita, e il namespace che il tuo codice usa è quello di sempre. È un motore di rendering gestito, non un wrapper sopra il livello grafico della piattaforma.

Il renderer prende una scena e una dimensione di output e restituisce byte. Crea un Bitmap, ottiene sopra di esso una superficie Graphics, disegna gli archi, i nodi e le etichette con pen, brush e un path, e salva il risultato in un flusso di memoria in formato portable network graphic. Nessun controllo compare da nessuna parte.

La matrice delle piattaforme vale la pena impararla a memoria. La misura dei font è gestita ovunque. Il disegno è gestito sul .NET moderno su ogni sistema operativo, e ripiega sul livello della piattaforma sul .NET Framework e nella build del designer. Non vincolare mai un deployment multipiattaforma a un target solo per Windows per far sparire un problema di disegno.

Due decisioni determinano poi se tutto questo sopravvive al deployment. Risolvi il font attraverso una catena che finisce su qualcosa che distribuisci tu, invece di dare per scontato che un font esista sull'host. E tieni esattamente una sola implementazione di disegno nel grafo dei riferimenti, perché due che risolvono gli stessi nomi di tipo sono un problema che non ti divertirà diagnosticare.

Eseguilo. L'export disegna off-screen in circa trentaquattro millisecondi senza alcun controllo coinvolto, e i byte vengono consegnati al browser come download. Limita però la dimensione richiesta: una bitmap larga quattromila pixel e alta tremila costa più o meno quarantotto megabyte prima ancora che tu abbia disegnato qualcosa.

Ora il container. Lo stesso test passa su Linux, niente si collega alla libreria grafica nativa della piattaforma, e le due immagini vengono identiche byte per byte, perché il font ha viaggiato con l'applicazione invece di essere preso in prestito dall'host.

Nel sesto lab costruisci il renderer senza controlli, gli dai una catena di fallback per i font, scarichi l'immagine dalla pagina, controlli i riferimenti in cerca di una seconda implementazione di disegno, e registri le tue evidenze su Windows e su Linux insieme a quello che implicano per i target mobile e desktop.

Questo è il capstone. Sei moduli hanno costruito quattro superfici di rendering in Visual Operations Studio, ognuna corretta per conto suo. Spedirle significa metterle d'accordo fra loro, e dimostrare che lo siano.

Al momento ogni superficie tiene le proprie soglie, i propri colori e la propria idea di dove stiano le cose. Sposta una volta sola la linea di warning e l'immagine esportata contraddice in silenzio la schermata da cui è stata generata. Non è un difetto di rendering; sono quattro copie della stessa regola di business.

Il rimedio sono tre livelli. Un modello visuale tiene lo stato semantico: valori, stati, selezione. Un livello di geometria trasforma quello stato e una dimensione in forme, ed è aritmetica pura. Poi un renderer per superficie, ognuno con le primitive che gli si addicono, perché forzarli dentro un'interfaccia condivisa non aiuta nessuno.

Poi, mettiti d'accordo sui numeri prima di ottimizzare qualsiasi cosa. Un controllo disegnato dovrebbe restare sotto i cinque millisecondi circa. Un ridisegno completo del Canvas sta nell'intervallo fra sedici e cinquanta millisecondi. Un export può permettersi di essere più lento di entrambi, purché mentre gira non blocchi mai la sessione di un altro utente.

La chiamata di geometria prende il modello e una dimensione e restituisce forme, e la chiamano entrambi i renderer, così nessuno può divergere. Accanto a loro, un piccolo helper di metriche registra la durata di un render, la dimensione dell'output e quanti oggetti della scena sono stati disegnati. Senza quei tre numeri, la messa a punto è tirare a indovinare.

Poi disegna di proposito gli stati anomali. Dati vuoti, una superficie senza dimensione, un intervallo il cui minimo supera il massimo, un font che manca: ognuno di questi dovrebbe degradare in qualcosa di leggibile invece di sollevare un'eccezione. E un export fallito deve arrivare all'utente come un messaggio, non come uno spazio vuoto dove ci si aspettava un'immagine.

Cambia un valore e tutte e quattro le superfici lo seguono: il gauge disegnato, le celle disegnate, la topologia sul Canvas e l'immagine esportata. Accanto a loro sta una semplice tabella che elenca ogni lettura, ed è questo che rende l'informazione disponibile anche a chi non può usare la grafica.

Infine le evidenze. Il gauge disegnato è sceso da circa undici millisecondi a quattro, l'export da più o meno trecentodieci millisecondi a centoventotto, e la matrice di test copre Windows, Linux, i target Hybrid e tre browser. Vale anche una decisione misurata di non ottimizzare, purché sia messa per iscritto.

Il lab finale è il capstone: un solo modello dietro tutte e quattro le superfici, un helper di metriche, un'ottimizzazione che hai misurato prima e dopo, quattro percorsi degradati che falliscono con grazia, e le note che spiegano l'architettura e il confine che rispetta.