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
Dimitri, prima di giudicare qualcosa bisogna capire da dove è partito tutto...
Dove è iniziato tutto? Con una pausa dalla realtà?
Un output di testo su etichetta 100 volte più veloce dell'output di testo su kanvas, anche se kanvas non stava nemmeno pulendo, stava scolpendo il testo sul testo.
Presto presenterò dei test in cui anche Kanvas è abbastanza veloce. E aggiornerò anche il relativo codice sorgente nella KB. Si tratta di limitare il numero di aggiornamenti per unità di tempo, come ho scoperto più tardi. Vedi i post sopra, è stato discusso lì. Inizia con questo post: https://www.mql5.com/ru/forum/364640/page6#comment_21290218.
Presto presenterò dei test in cui anche Kanvas è abbastanza veloce. E aggiornerò anche il relativo codice sorgente nella KB. Si tratta di limitare il numero di aggiornamenti per unità di tempo, come ho scoperto più tardi. Vedi i post sopra, è stato discusso lì. Inizia con questo post: https://www.mql5.com/ru/forum/364640/page6#comment_21290218.
E non sto fantasticando, sto misurando le prestazioni del codice che si applicherebbero nella realtà. E non mi interessa affatto cosa e dove viene reso, sto misurando il tempo di esecuzione finale del programma.
E non sto fantasticando, ma misurando le prestazioni del codice che verrebbe applicato nella realtà.
Anche un confronto puramente stupido di una sola chiamata a TextOut() è 70 volte più lento dell'output di testo sull'etichetta.
Se non vuoi o non puoi capirlo, ecco una citazione:
Nikolai ha ragione - la modifica delle proprietà dell'etichetta non ha niente a che fare con il rendering dell'etichetta.
L'etichetta, come qualsiasi altro oggetto sul grafico, è disegnata in un thread totalmente diverso e indipendente dal funzionamento del programma MQL5. Il robot può solo chiedere al grafico di essere reso forzatamente di nuovo, ma non può misurare il tempo di rendering. Il disegno dei grafici con gli oggetti è completamente asincrono.
Ma il rendering canvas è facile da misurare poiché viene fatto direttamente nel flusso del robot e poi durante il rendering indipendente del grafico rimane da fare un BitBlit nativo della bitmap pronta nel contesto della finestra. Questa operazione è elementare ed è ben accelerata dalla scheda video.
Nelle etichette di testo SetFont/TextOut nei font TTF è abbastanza costoso.Se non si vuole o non si può dare un senso, si ottiene una citazione:
E ti ho già risposto qui
E ti ho già risposto qui
Avete intenzione di discuterecon il direttore di MetaQuotes?
Vuoi discuterecon il direttore di MetaQuotes?
Non siamo in disaccordo.
Anche un confronto puramente stupido di una sola chiamata a TextOut() è 70 volte più lento dell'emissione di testo sull'etichetta.
Questo perché il rendering del grafico è fatto in un thread separato. Mentre l'elaborazione dell'array di pixel perOBJ_BITMAP_LABEL è nello stesso thread dell'applicazione che lo usa, così come il passaggio dei pixel alla bitmap. Pertanto,OBJ_BITMAP_LABEL può rallentare l'applicazione, ma non significativamente se la bitmap non viene aggiornata troppo spesso. Proprio nei miei test precedenti, OBJ_BITMAP_LABEL ha causato rallentamenti significativi per lo stesso motivo. Ma se si limita la frequenza di aggiornamento della bitmap, il risultato è ancora migliore che con le etichette. E se si limita la velocità di aggiornamento della bitmap, sarà leggermente più veloce diOBJ_BITMAP_LABEL (a causa del rendering in un thread separato).Semplicemente, non ha senso aggiornare gli oggetti più frequentemente di quanto l'occhio umano possa percepire. Da qui i ritardi, tutti gli oggetti nel grafico quando li si aggiorna troppo spesso.