Come selezionare il sistema di disegno quando i requisiti non sono ancora noti?

In ogni caso, avrai bisogno di un codice di livello superiore. La domanda è: chi è più qualificato per scriverlo? Qualcuno con quasi nessuna esperienza nella zona o qualcuno che si guadagna da vivere scrivendo biblioteche usate da migliaia di persone? Non sto cercando di essere cattivi qui, ma hanno già risolto decine di problemi che non sono nemmeno a conoscenza dell'esistenza. Utilizza le API di livello superiore finché non sei qualificato e hai buoni motivi per sostituirle.

Inoltre, nella mia esperienza i peggiori colli di bottiglia tendono ad essere nel mio codice piuttosto che in quella libreria di terze parti che ho scelto di scegliere. Concentrati su cose come mantenere i dati nella cache invece di ricalcolarlo costantemente. Evita gli accessi al disco. Mantieni il codice GUI il più possibile disaccoppiato dal resto del sistema. Pensa al minimo che il tuo codice di disegno deve sapere per svolgere il proprio lavoro e utilizza interfacce ben definite per fornirlo.

Con un design decoupled decente, rendendoti conto che hai bisogno di qualcosa di più efficiente lungo la strada e l'implementazione di un nuovo meccanismo di rendering non dovrebbe essere come se fosse un compito come sembra.

Il mio consiglio sarebbe quello di scegliere il componente con cui voi e il vostro team siete più a vostro agio (che sia il più semplice o il più vicino a quello con cui avete lavorato in passato). Quindi, la tua più grande preoccupazione dovrebbe essere quella di disaccoppiare il più possibile il modello / logica dal rendering per poter reimplementare un nuovo sistema di rendering sulla stessa interfaccia in caso di necessità.

Non sei in un punto nel tempo in cui puoi fare l'ottimizzazione in quanto i requisiti non sono ben noti e non hai il sistema completo su cui lavorare, quindi qualsiasi ottimizzazione eseguita in questo momento è probabile che si perdano tempo.

make a more extensive demo so differences become more clear pick one, but put everything behind an interface so the implementation can be swapped later (might be quite some work)

Questo sarà necessario.

Questo controllo dell'interfaccia grafica "grafico" avrà i seguenti requisiti:

• Composizione rapida di immagini di testo e etichette
• Double-buffering (per evitare lo sfarfallio)
• Possibilità di mappare le coordinate del clic del mouse sugli oggetti grafici.
  • Prestare particolare attenzione alle situazioni in cui più oggetti grafici si sovrappongono. Una gestione insoddisfacente di questa situazione renderà inutilizzabile un'applicazione alla maggior parte delle persone.

while I had the impression the lower level options were somewhat faster to display.

Contrariamente a quanto si crede, alcuni framework di alto livello delegano il pesante sollevamento del rendering e della composizione dei pixel ai framework di livello inferiore (che quindi delegano all'hardware), quindi la differenza di prestazioni potrebbe non essere significativa.

La domanda principale è, quale algoritmo di composizione è utilizzato sotto il framework che sceglierai e se sarà sufficientemente veloce.

Fornisco due esempi di tali strategie di composizione:

1. Per ogni testo ed etichetta da disegnare sopra l'area di disegno, viene prima sottoposto a un singolo livello trasparente RGBA32. Tutti questi livelli vengono quindi composti sulla bitmap finale in un secondo momento.
2. Per ogni testo ed etichetta da disegnare, la bitmap "destinazione" è bloccata e i loro pixel vengono modificati direttamente. È necessario modificare solo i "pixel inchiostrati".

Queste strategie hanno diversi compromessi. (Il primo può essere parallelizzato, ma richiede più memoria (RGBA32) e più computazione (composizione), il secondo è seriale ma richiede meno memoria e calcolo.) Inoltre, alcune strategie sono più portabili al rendering GPU rispetto agli altri.

Poiché non siamo esperti di computer grafica, noi non sappiamo abbastanza per prevedere quale strategia vincerà, quindi ci affidiamo alla sperimentazione (demo estesa) per scoprire .

Per prima cosa, devi fare i conti con il fatto che non puoi scegliere la struttura giusta ora, perché non hai abbastanza informazioni. Quindi dovresti scegliere la struttura che minimizza il rimpianto se risulta essere quello sbagliato. In altre parole, scegli quello più flessibile.

Ad esempio, uno scenario da incubo è scegliere il framework di basso livello, quindi risulta che tutte le tue esigenze sono piuttosto standard. Trascorri molto tempo a scrivere, eseguire il debug e mantenere metodi prolissi e noiosi nel framework di basso livello, ma già esistono nel framework di alto livello. Bene, quello di alto livello ti permette anche di scrivere un codice di basso livello quando necessario? Potrebbe essere la scelta migliore.

In altre parole, se non sai se scriverà codice di alto livello o di basso livello, scegli un framework che vada bene per entrambi, piuttosto che uno che sia veramente ottimizzato per uno ma un disastro per l'altro. Tra un anno, saprai quale framework avresti dovuto usare e non sarà questo. Ma il più flessibile sarà solo un po 'peggio dell'ottimale. Hai bisogno anche di flessibilità nelle prestazioni: qualcosa che ti permetta di scrivere codice veloce se risulta necessario.

L'altra cosa che puoi fare è provare a mettere il tuo codice di disegno dietro un'interfaccia interna, per permetterti di cambiarlo più tardi, nel caso tu ne abbia davvero bisogno. Questo è più difficile di quanto sembri. Se scegli un framework di basso livello, la tua interfaccia si focalizzerà su concetti di livello inferiore. E - sorpresa! - spesso solo i concetti nel framework. Ma se segui questa strada, i test unitari sono un must. Prima di tutto, scrivere un test che esercita solo una determinata funzione ti costringerà a scrivere quella caratteristica in un modo che non è intrecciato con il resto del codice. E in secondo luogo, se in seguito dovrai scambiare il back-end, avrai un modo semplice per scoprire cosa hai rotto.

Un'altra cosa da guardare è, quale struttura ha il maggior slancio? Guarda gli archivi della mailing list. Sta succedendo molto? Forse una struttura sub ottimale diventerà migliore. In ogni caso, se finisci per spingere un framework in modi che non è destinato a essere utilizzato, è bene avere una community di esperti da chiedere.