Galleria di interfacce utente scritte in MQL - pagina 53
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Rether, potresti considerare di cambiare il catalogo in inglese nelle prossime versioni? I file del codice sorgente contenenti i nomi dei cataloghi sono stati sostituiti con del testo.
Sì, certo. Ci ho già pensato. Farò una versione speciale con i nomi dei cataloghi in inglese.
Non sto controllando i file, ma solo i commenti qui. Ma questo 'ritardo' per me non sembra essere legato alla velocità, ma all'uso di ChartRedraw prima di creare completamente la nuova risorsa. Perché si blocca con una tela vuota e poi mostra la nuova tela.
Certo. Ci ho pensato. Farò una versione speciale che includa il nome del catalogo inglese.
Suggerirei di non fare una release speciale con cataloghi in inglese, ma di fare solo una di queste release in inglese, cambiando solo il nome del catalogo in inglese, e il passo successivo sarebbe quello di cambiare il nome del file in inglese, continuando a scrivere il codice sorgente in russo.
Sono d'accordo. Passerò gradualmente ai nomi inglesi delle directory. In questo modo sarà più razionale.
Non ho controllato i file, ma solo i commenti qui. Ma questo "ritardo" per me non sembra essere legato alla velocità, ma all'utilizzo di ChartRedraw prima che la nuova risorsa sia completamente creata. Perché lampeggia una tela vuota e poi mostra la nuova tela.
Idea interessante, proverò a testarla. Grazie.
E quindi, un aggiornamento...
Questo è un aggiornamento provvisorio. Rilascerò la prossima versione tra qualche giorno. Ci saranno nuove funzionalità per l'interazione del programma con i comandi.
Devo dire che lavoro su due versioni: la 2470 e la nuova. La maggior parte dello sviluppo avviene sulla vecchia build. La compilazione è più veloce: 4 secondi contro 26-32 secondi. La nuova build funziona in modo leggermente diverso e si nota visivamente. A volte è più veloce, a volte più lenta. Forse è solo una sensazione. È difficile trovare una differenza, ma a me sembra che ci sia. L'interfaccia della vecchia versione vola. Nella nuova. quasi vola. Forse penso che sia perché ci sono abituato.
Tuttavia, ci sono delle sfumature. Ad esempio, c'è un problema nel passaggio da un grafico all'altro, quando vengono restituiti valori errati di altezza e larghezza del grafico. Questo fa saltare la barra delle applicazioni. Sono riuscito a bypassare questo problema, ma poi la barra delle applicazioni non reagisce ad altri eventi di ridimensionamento del grafico. Alla fine ho deciso di lasciare le cose come stanno. La barra delle applicazioni salta quando si cambia il grafico (finché c'è un problema di restituzione di valori errati), ma si adatta normalmente ad altri eventi.
Ma non è tutto. Si scopre che gli eventi di ridimensionamento del grafico non arrivano istantaneamente e c'è una pausa di mezzo secondo. Questo ritardo si sovrappone al tempo di ridisegno della barra delle applicazioni e si ottiene un discreto ritardo. Qui sono impotente.
Dirò questo: naturalmente ho accelerato in modo significativo la grafica, ma ci sono ancora altre soluzioni non ottimizzate nel codice. Ci sto lavorando molto. La maggior parte riguarda la transizione del focus della finestra e la coda di ridisegno. Si verificano alcune chiamate non necessarie. La barra delle applicazioni è lenta. Ho sistemato ciò che avevo tempo di sistemare, anche se non tutto. Ma il resto è questione dei prossimi giorni. Per il resto, non c'è molto da migliorare... forse solo pettinare e profumare il codice per renderlo fragrante)).
In generale, se facciamo il debug di tutte le restanti soluzioni non ottimizzate - volerà... beh, nei limiti delle velocità disponibili per un programma MQL, ovviamente.
Prendete la release.
E quindi, un aggiornamento...
...
Mettiamola così: la grafica è stata notevolmente accelerata, ma ci sono ancora alcune soluzioni non ottimizzate nel codice. Ci sto lavorando molto. La maggior parte riguarda la transizione del focus della finestra e la coda di ridisegno. Si verificano alcune chiamate non necessarie. La barra delle applicazioni è in ritardo. Ho sistemato ciò che avevo tempo di sistemare, anche se non tutto. Ma il resto è questione dei prossimi giorni. Per il resto, non c'è molto da migliorare... forse basta pettinare e profumare il codice per renderlo fragrante)).
In generale, se si esegue il debug di tutte le soluzioni non ottimizzate rimanenti, il progetto volerà... beh, nei limiti delle velocità disponibili per un programma MQL, ovviamente.
Prendete il rilascio.
Voglio essere chiaro: qui stiamo parlando di velocità. Se si risolve il problema del ridisegno della finestra sull'evento di cambio di focus, la velocità dell'interfaccia sarà al limite superiore di un programma MQL. I ritardi della barra delle applicazioni possono essere parzialmente risolti. Ho trovato una buona soluzione: applicare alla meccanica della barra delle applicazioni il principio della finestra dinamica, che non rallenta quando si ridimensiona o viene trascinata dalla cornice. Si regolerà più velocemente e in modo più impercettibile. E, naturalmente, dobbiamo cancellare le ridisposizioni non necessarie. Questo è obbligatorio. Ma se gli eventi CHARTEVENT_CHART_CHANGE arrivano al programma con un certo ritardo, il ritardo visibile delle reazioni della barra delle applicazioni è inevitabile, anche se non c'entra nulla.
Per il resto, ci sono molte direzioni di sviluppo e miglioramento dell'interfaccia.
Ancora qualche parola sulla velocità dell'interfaccia.
Ho passato molto tempo a controllare i ritardi e a cercare freni al rendering. Il blocco responsabile del layout di kanvas è costruito in modo tale che, prima di inizializzare l'array che va a creare una risorsa nella funzione ResourceCreate(), definisce i confini del ciclo sui dettagli della finestra. Lo fa con l'aiuto di filtri di condizione configurati per controllare gli eventi in arrivo. A ogni evento che chiama il blocco vengono assegnati dei confini di disegno. Ad esempio, sull'evento della reazione dell'elemento al passaggio del cursore, viene attivato il filtro con i confini del ciclo solo sui dettagli di un particolare elemento. Il blocco seleziona solo i suoi dettagli sull'immagine ripresa. E durante il ciclo sui dettagli, disegna selettivamente solo questi ultimi tra il resto dell'immagine. Trova con precisione i punti in cui inizializzare e disegnare il dettaglio corretto dell ' elemento corretto. Allo stesso tempo, bypassa correttamente il resto dello spazio dell'immagine.
Ma l'accelerazione non è solo questa. Il blocco non inizializza i punti della tela se il loro colore corrisponde al valore richiesto. Inoltre, non "corre" attraverso l'array, ma "salta", superando le distanze. Questo riduce i cicli di centinaia di migliaia di iterazioni.
Non solo. Poiché l'array di immagini è globale (dichiarato a livello globale), memorizza sempre la modifica dell'ultima immagine. E se le modifiche continuano a verificarsi sullo stesso canvas, invece di cancellare ogni volta l'array, viene utilizzata l'immagine memorizzata. Se il nome della risorsa non cambia nell'evento successivo, non è necessario chiamare ResourceReadImage() e non è necessario inviare nuovamente l'array di canvas per riempirlo. Il blocco continua a lavorare con i dati rimanenti senza chiamare ResourceReadImage() e aggiorna l'immagine con ResourceCreate() dopo la modifica.
In questo modo si risparmia molto tempo sulle chiamate a ResourceReadImage(). E anche per svuotare e riempire l'array. È un buon uso della memoria globale, no?
Quando si ridisegnano le finestre, il blocco non viene chiamato affatto. I componenti della finestra vengono cancellati e creati e le risorse precedentemente salvate vengono collegate ad essi. Non c'è alcun rendering.
Con tutto questo, ci sono ancora dei ritardi, che sono inevitabili. Vi spiego cosa succede.
Alla prima apertura di una finestra, o alla prima apertura di una scheda, o all'evento di un elenco ad albero, o alla minimizzazione/disattivazione di grandi spazi, c'è un obbligatorio ridisegno completo delle tele. Fino al momento in cui si creano risorse di immagini che possono essere collegate/modificate in modo efficiente molte volte in seguito, è SEMPRE necessario disegnare un'immagine completa da zero. Il primo disegno è SEMPRE il più lungo. Non c'è nulla da salvare, non c'è un'immagine salvata. È quando si apre per la prima volta che si notano sempre dei ritardi. È inevitabile.
Tuttavia, anche in questo caso esiste una buona soluzione: spostare i ritardi dell'apertura delle finestre all'evento di caricamento. Cioè: nella fase di caricamento il costruttore in background disegna tutte le immagini e le salva nelle risorse in anticipo, in modo che tutto sia pronto all'apertura. In questo modo l'utente non vedrà alcun ritardo quando aprirà le finestre per la prima volta. Naturalmente questo è ottimo, ma c'è un aspetto negativo. Il ritardo della prima apertura si trasformerà in un ritardo di caricamento e il suo tempo aumenterà. È difficile dire di quanto. Credo che, in media, sia di un secondo. Dipende dall'interfaccia specifica.
Penso che questa opzione sia preferibile. Preferisco lasciare che il designer/interfaccia utente si carichi un po' più a lungo, ma non ci saranno più ritardi nell'apertura visiva.
Sono interessato a sentire le vostre opinioni in merito.
Aggiunto:
C'era l'idea di salvare le risorse dell'interfaccia dopo il primo caricamento in un file. In questo modo i caricamenti successivi saranno molto più veloci, perché le risorse necessarie sono già a disposizione del designer/motore. Devo pensarci su.