Galleria di interfacce utente scritte in MQL - pagina 56

 
Andrey Barinov #:

Non sto usando la tela stock :).

E ho trovato più semplice implementare un'interfaccia multi-finestra su una sola bitmap. Ma a ciascuno il suo!

Ahimè, non in tutti i casi. Per i miei compiti è tecnicamente più facile lavorare con un insieme limitato di bitmap. E al 100% più veloce. Molto più veloce.

Ma per altri sviluppi altre soluzioni funzionano meglio e quindi sì, a ciascuno il suo. :)

 
Nikolai Semko #:
No Perth, ancora troppo. La vostra interfaccia con tutto il testo, le ombre, ecc. raggiunge un massimo di 50ms su un processore debole.
Cercate il bug.
Eseguite il profiling. Vedete quali funzioni consumano il 95% del tempo.
Forse state usando ChartGet o le funzioni XY (anche se non avete un legame con un grafico).
In ogni caso, eseguite il profiling. Ci vorranno solo 40 secondi.

Sì, ricontrollerò tutto. Ma non è questo il punto. Il blocco di disegno non si limita a disegnare. Al suo interno ci sono labirinti logici che elaborano gli eventi in arrivo. Sono necessari per determinare cosa disegnare e cosa non disegnare. Scegliere da dove prendere le immagini, dove e come sovrapporle. Se si trattasse di una semplice funzione di disegno di 100 linee, non ci sarebbe nulla da dire. Ma si tratta di un meccanismo massiccio per garantire che TUTTO venga disegnato.

Vale la pena di prenderlo in considerazione)).

 
Andrey Barinov #:

Non sto usando la tela stock :).

...

E questa è una piacevole sorpresa. :) L'autosviluppo è sempre bello. Anche se è imperfetto.

La classe Ccanvas non mi dispiace (ho persino incluso la sua funzionalità nei file del costruttore), ma non la uso ancora. La parola chiave è "ancora". Ho grandi progetti per essa. In futuro.

 
Verificherò la velocità di rendering di una tela verde vuota delle dimensioni del grafico e la posterò qui.
 
Реter Konow #:

Sì, ricontrollerò tutto. Ma non è questo il punto. Il blocco di disegno non si limita a disegnare. Al suo interno ci sono labirinti logici che elaborano gli eventi in arrivo. Sono necessari per determinare cosa disegnare e cosa non disegnare. Scegliere da dove prendere le immagini, dove e come sovrapporle. Se si trattasse di una semplice funzione di disegno di 100 linee, non ci sarebbe nulla da dire. Ma si tratta di un meccanismo enorme per garantire che TUTTO venga disegnato.

Vale la pena di prenderlo in considerazione)).

No, se implementato correttamente, il modello degli eventi non richiede più di un microsecondo (un milionesimo di secondo), anche se ci sono migliaia di controlli.
Cercate un bug.
E smettetela di stare sulla difensiva! Nessuno vi sta attaccando, vogliono solo aiutarvi.
Ho dei ritardi evidenti (>300 ms) a partire da 100 mila oggetti, e legati al prezzo-tempo.
 
Nikolai Semko #:
No, se implementato correttamente, il modello degli eventi non richiede più di un microsecondo (un milionesimo di secondo), anche se ci sono migliaia di controlli.
Cercate un bug.
E smettetela di stare sulla difensiva! Nessuno vi sta attaccando, vogliono solo aiutarvi.
Ho dei ritardi evidenti (>300 ms) a partire da 100 mila oggetti, e legati al prezzo-tempo.

Non sono sulla difensiva))) Ha ha. Sto solo spiegando. ))

Ok. Inizierò con un semplice test. Riempirò una tela a schermo intero con un colore e misurerò il tempo. Misurate la vostra funzione di rendering e poi sarà più chiaro se ho dei freni nel mio codice. Forse ci sono. Non sto discutendo. Ho bisogno di verificarlo.

 
Реter Konow #:

Non sono sulla difensiva). Ha ha. Sto solo spiegando. ))

Ok. Inizierò con un semplice test. Riempirò una tela a schermo intero con un colore e misurerò il tempo. Misurate la vostra funzione di rendering e poi sarà più chiaro se ho dei freni nel mio codice. Forse ci sono. Non sto discutendo. Ho bisogno di verificarlo.

Ho pensato che forse non hai mai lavorato con il profiling. Non lavori nemmeno con il debug.


 
Nikolai Semko #:

Ho pensato che forse non hai mai lavorato con il profiling. Non lavori nemmeno con il debug.


Non con il debug. Non posso farlo a causa del codice russo. Ho lavorato con il profiling. Ma molto tempo fa. Mi piace codificare alla vecchia maniera. È così e basta.

Lo farò domani. Negli ultimi giorni ho lavorato dalle 6:00 del mattino alle 10:00-11:00 di sera. A fasi alterne. Sono un po' stanco.
 
La velocità può probabilmente essere messa in secondo piano e l'ottimizzazione della velocità non è qualcosa che si può fare rapidamente, per ora è meglio migliorare la funzionalità.
 
hini #:
La velocità può probabilmente essere relegata in secondo piano e l'ottimizzazione della velocità non è qualcosa che si può fare rapidamente, per ora è meglio migliorare la funzionalità.
Beh, è sempre bello per un coder migliorare la velocità. E in generale sono d'accordo. È ragionevole. La corretta definizione delle priorità nello sviluppo è molto importante. Soprattutto in progetti così grandi. Per me è stato importante sapere quanto la velocità sia importante per gli utenti. Per così dire, per ottenere un feedback. La velocità di per sé non faceva parte dei miei piani iniziali. Volevo solo che gli utenti non soffrissero per i lag quando guardavano l'interfaccia. :)

Naturalmente, la funzionalità degli elementi rimane la mia priorità. Motore, elementi, bug. Questa è la cosa principale.