Galleria di interfacce utente scritte in MQL - pagina 57

 

@Nikolai Semko

Nikolai, ora è arrivata inaspettatamente la risposta alla domanda"perché ci vuole così tanto tempo per disegnare una tela".

Le finestre sono costituite da due tele, di dimensioni quasi uguali. Quindi l'area di disegno deve essere moltiplicata per due. Ma questo è solo l'inizio.

Sullo spazio della finestra ci sono grandi elementi di scorrimento (V_BOX), che vengono anch'essi disegnati completamente riempiti con il colore originale. Cioè, se V_BOX occupa la parte principale della finestra, l'area di disegno dovrebbe essere moltiplicata per tre. Ma! ha una tela aggiuntiva. L'immagine viene fatta scorrere su tale tela. La base dell'elemento è solo una barra di scorrimento. In breve, l'area di disegno dovrebbe essere moltiplicata per quattro (soprattutto se la barra di scorrimento è lunga) e solo allora gli elementi vengono disegnati.

Sembrerebbe tutto... Possiamo mettere un punto,moltiplicando l'area della finestra per tre o quattro. Ma no!

Anche gli elementi stessi sono a più livelli. Ognuno ha una base. La base è sempre disegnata da zero, riempita con il colore originale. Poi vengono disegnate le cornici sulla base. Poi, le icone vengono disegnate sopra le parti già disegnate dell'elemento. Infine, i testi vengono disegnati sopra tutto.

Di conseguenza, l'utente vede solo il colore finale su ogni particolare pixel. Ma nel punto in cui si trova questo pixel i colori cambiano più volte, mentre l'intera finestra viene disegnata.


Ora moltiplicate questo risultato per 15 finestre.... Risulta chiaro che non c'è un bug particolare nel codice: ho misurato appositamente la velocità di esecuzione di parti del blocco di disegno e 50 ms per uno schermo intero funzionano anche per me. È solo che mi ritrovo con molte più schermate.


Ho un'idea su come modificare il codice e velocizzare il disegno di 2 o 3 volte. Ma lo farò dopo il lavoro principale.

Voglio ringraziarti per aver insistito nel controllare il codice. Avevi ragione. Questo è il caso in cui le critiche sono utili.

Inoltre, grazie ad @AndreyBarinov per il suggerimento sul testo. Forse riuscirò a trovare qualcosa.

Nikolai Semko - BeeXXI Corporation
Nikolai Semko - BeeXXI Corporation
  • 2024.07.15
  • www.mql5.com
Профиль трейдера
 
Реter Konow #:

@Nikolai Semko

...e 50ms a schermo intero funziona anche per me. ....

Il test è approssimativo. Ho misurato la velocità di apertura di una finestra con tre tele di dimensioni quasi uguali (finestra delle icone) e ho ottenuto ~70 ms. Sommando l'area di tutti i riquadri (senza elementi), si ottiene circa l'area dello schermo del portatile da 17". Questo non include l'area della base degli elementi e delle icone stesse, che sono state disegnate sopra la tela. Quindi sì, ~50ms per riempire di colore l'area di uno schermo pieno immaginario. Non l'ho ancora misurato esattamente. Perché, se l'"elefante" è proprio al centro della stanza? :)

 
Parlavo di 50 ms come interfaccia sovraccarica e non ottimizzata. 3-10 ms è normale

Fate comunque un po' di profiling. Farete molte scoperte nel vostro codice.
 
Nikolai Semko #:
Parlavo di 50 ms come interfaccia sovraccarica e non ottimizzata. 3-10 ms è normale

Tuttavia, fate un po' di profiling. Farete molte scoperte nel vostro codice.
Nikolai, questi sono solo numeri. Hai bisogno di dati specifici. Almeno le dimensioni dello schermo. Così si possono fare calcoli accurati.
 
Il disegno sulla tela è un'inizializzazione dell'array. È facile scoprire la velocità massima: la funzione con il ciclo di riempimento dell'array la rivelerà. La dimensione dell'array deve corrispondere alla somma dei pixel dello schermo condizionato.
 
Sei come Stirlitz che non voleva andare al campo di patate.
Fai il profilo...
 
Nikolai Semko #:
Sei come Stirlitz che non voleva andare al campo di patate.
Fai il profilo...
L'ho fatto. Ti mando una gif.
 


È necessario uno studio approfondito dei cicli all'interno del blocco di disegno. Una profilazione superficiale non fornisce un quadro completo. Ma è già chiaro qual è il punto. Ho scritto qui

. Credo di non sbagliare.

(versione in bozza del blocco di disegno, che uso per i test)
 
Реter Konow #:

...

Ho un'idea su come modificare il codice e accelerare il rendering di 2 o 3 volte. Ma lo farò dopo il lavoro principale. ...

Ho analizzato la complessità del compito e il valore del risultato finale.

Conclusione: non ha senso farlo.

Non ha senso accelerare il primo disegno: un secondo e mezzo per costruire 15 finestre con grafica complessa e barre di scorrimento è un risultato normale. Il primo disegno può essere nascosto agli occhi dell'utente eseguendolo prima di aprire le finestre. Visivamente, le finestre appariranno immediatamente dopo una pausa di mezzo secondo. Se ovviamente l'utente vuole che si aprano 15 finestre contemporaneamente, il che è improbabile.

Non è necessario disegnare il lato posteriore della finestra. Ci sarà un guadagno di ~20ms. Non sembra impressionante.

La scorsa settimana è stato raggiunto l'obiettivo principale: utilizzare le immagini salvate in tutti gli eventi, tranne che nella prima build. Si tratta di un enorme guadagno in termini di velocità dell'interfaccia.

Il resto dei lag ha a che fare con il ridisegno delle finestre quando si cambia focus o con chiamate non necessarie. Soluzioni facili. Non voglio che questo grande guadagno venga ignorato a causa del tempo di caricamento, che non è così importante. Tuttavia, ho spostato la mia attenzione. Dovrebbe essere così.

Chiudo qui la questione della velocità del primo rendering, a causa della sua irrilevanza e irrilevanza per lo sviluppo attuale.

Prossimo aggiornamento domenica. Presenterò un motore con un meccanismo concettualmente completo di interazione del software con il programma utente.
 
Реter Konow #:
Ho analizzato la complessità del compito e il valore del risultato finale.

La conclusione è stata che non aveva senso.

Creare 15 finestre con grafica complessa e barre di scorrimento in un secondo e mezzo è un risultato normale. È possibile disegnare la prima grafica prima di aprire la finestra, in modo che non venga vista dall'utente. Visivamente, la finestra apparirà immediatamente dopo una pausa di mezzo secondo. Naturalmente, se l'utente vuole avere 15 finestre aperte contemporaneamente, questo è improbabile.

Non è necessario disegnare il retro della finestra. Ci sarà un guadagno di ~20ms. Non sembra una cosa straordinaria.

La scorsa settimana abbiamo raggiunto il nostro obiettivo principale: utilizzare le immagini salvate per tutti gli eventi, tranne che per la prima build. Si tratta di un'enorme accelerazione dell'interfaccia.

Il resto dei ritardi era legato al ridisegno della finestra quando si cambiava focus o a chiamate non necessarie. È facile da risolvere. Non voglio ignorare questo importante miglioramento a causa dei tempi di caricamento, che non sono così importanti. Tuttavia, ho spostato la mia attenzione. Dovreste avere

Qui ho chiuso il primo problema della velocità di rendering perché non è rilevante o importante per lo sviluppo attuale.

Il prossimo aggiornamento è previsto per domenica. Presenterò un motore con un meccanismo concettualmente completo di interazione tra il software e il programma utente.

Sì, la cosa più importante è che prima esca un software completamente funzionante.