DirectX - pagina 8

 
Реter Konow:

Ieri ho fatto un esempio di un tumbler con celle che si ridisegnano indipendentemente dall'intero canvas della finestra:https://www.mql5.com/ru/forum/333652/page4

Mostra che il ridisegno separato delle celle tiene il carico nei limiti del 20% (su video più a causa della registrazione video), SEMPRE se le celle sono ridisegnate TUTTO il tempo e a 40 fps. La normale dinamica del tumbler con questo approccio caricherà il 5-10% circa.

Il carico è elevato solo se si ridisegna un'area grande (~500*500 px) ad alta velocità senza pause (~40+ fps). Qualsiasi ritardo o riduzione dell'area di ridisegno ridurrà il carico molte volte.

Nel tuo esempio il vetro è abbastanza troncato, ovviamente, anche in profondità. È divertente, ma apparentemente il rendering di uno stack deve essere fatto su tutti i core con OpenCL, inoltre, poiché il calcolo è suddiviso in celle separate, ma qui sono un teorico.

 
Aleksey Vyazmikin:

Nel tuo esempio il bicchiere è abbastanza troncato, ovviamente, compresa la profondità. È divertente, ma apparentemente il disegno del becher dovrebbe essere calcolato su tutti i core con OpenCL, inoltre, poiché il calcolo è diviso in celle separate, ma qui sono un teorico.

Ok, farò un becher con più celle e controllerò di nuovo.

 
Реter Konow:

OK, farò un becher con più celle e controllerò di nuovo.

Basta non renderlo statico, ma dinamico.

 
Rafil Nurmukhametov:

Il processore si carica bene, nell'immagine precedente si può vedere una posizione aperta, la cornice intorno al prezzo è di colore magenta, lì la posizione è in deficit, nell'immagine sottostante la posizione è in surplus

La mia sensazione è che una tale immagine non dovrebbe formarsi più di 1-3 millisecondi. Se ci vuole più tempo, ci deve essere un bug da qualche parte.
 
Rafil Nurmukhametov:

Basta non renderlo statico, ma dinamico.

Cosa intende per "dinamico"? In modo che non tutte le celle cambino valore allo stesso tempo? Non capisco.

 
Nikolai Semko:
La mia sensazione è che una tale immagine non dovrebbe formare più di 1-3 millisecondi. Se ci vuole più tempo, c'è qualcosa di sbagliato da qualche parte.

Ora hai alzato il livello di perfezione... Perché non lo abbassa a 6-8 millisecondi?

 
Реter Konow:

Cosa intende per "dinamico"? In modo che non tutte le celle cambino valore allo stesso tempo? Non capisco.

In modo che il prezzo corrente si muova attraverso le celle e non nel mezzo come in mt5

 
Rafil Nurmukhametov:

per far muovere il prezzo corrente attraverso le celle, non nel mezzo come nella tazza mt5

Cioè senza centralizzazione. Bene, per gli strumenti futures questo è ciò di cui avete veramente bisogno. Ok. (Questo è solo un mockup per testare il carico).

 
Rafil Nurmukhametov:

Ora hai alzato il livello di perfezione... Puoi abbassarlo a 6-8 millisecondi?

è troppo. Anche 3 è troppo. 6-8 a 30 fps è il 20-30% del tempo della CPU.
Dovete usare ArrayCopy il più possibile dove possibile. Anche la trasparenza dovrebbe essere usata al minimo solo se necessario.
È possibile eseguirlo attraverso la profilazione e vedere dove la CPU perde il massimo.
Peter ha ovviamente ragione, dovresti ridisegnare localmente dove ci sono stati dei cambiamenti ma non ridisegnare l'intera tela ogni volta.
E usare DX in generale può alleggerire molto la vostra CPU
 

OK, fatto il vetro nell'editor. Ci ho messo due ore. C'è molta confusione. È possibile accelerare il processo di un fattore quattro aggiungendo degli strumenti.

Testato.

Il risultato: meno del 20% del carico con cambiamento costante in tutte le celle di domanda e offerta, e una cella di prezzo, a 40 fotogrammi al secondo. (Il carico aumenta del 5-7% quando la registrazione è abilitata).


Ripeto la mia opinione - in condizioni reali il carico sarebbe del 5 - 10 per cento a seconda dell'attività del mercato.

File:
GUI_Expert.ex5  600 kb
Motivazione: