Errori, bug, domande - pagina 975

 

Mi correggo. Le prestazioni delle bitmap sono inferiori ai tag del 16%-25%(a seconda del numero di elementi), ma non di un ordine di grandezza, come ho scritto prima.

Probabilmente ci sono stati errori/inefficienze nel codice quando si è imparato lo strumento per la prima volta.

Il codice è allegato.

tol64

Credetemi,non ho un solo motivoper ingannarvi = me stesso. Nel mio primo esperimento ho osservato una bitmap nel tester. Purtroppo non riesco a riprodurlo. :(

 
voix_kas:

...

tol64

Credetemi,non ho un solo motivoper ingannarvi = me stesso. Nel mio primo esperimento ho osservato una bitmap nel tester. Purtroppo non riesco a riprodurlo. :(

Ok. Aspettiamo che gli sviluppatori implementino questa funzione e poi la testeremo correttamente. )))
 

Vorrei anche attirare l'attenzione degli sviluppatori sulle differenze nella visualizzazione dei caratteri:


A sinistra c'è la bitmap e a destra le etichette. Labitmap ha una resa leggermente più audace del carattere, anche se tutte le impostazioni sono le stesse.

La domanda non è critica. Ma per l'ordine prestare attenzione. :)

 
voix_kas:

Vorrei anche attirare l'attenzione degli sviluppatori sulle differenze nella visualizzazione dei font

A sinistra c'è la bitmap, a destra le etichette. Labitmap ha una resa dei caratteri leggermente più audace, anche se tutte le impostazioni sono le stesse.

La questione non è critica. Ma per l'ordine è necessario prestare attenzione. :)

E quale flag per impostare lo spessore del carattere hai usato per la bitmap?
 
voix_kas:

Mi correggo. Le prestazioni delle bitmap sono inferiori del 16%-25% rispetto ai tag (a seconda del numero di elementi), ma non di un ordine di grandezza, come ho scritto prima.


No. Eppure il tuo test è errato.

Usate ChartRedraw dopo ogni modifica. Quindi in realtà state testando 10000 volte ChartRedraw. Questo non è giusto.

Il compito è quello di scoprire cosa cambia più velocemente: le etichette o le bitmap. E non la loro successiva uscita in classifica.

Ecco i risultati del test se si lascia ChartRedraw dentro un ciclo.

Tempo di aggiornamento della bitmap = 40980.
Tempo per aggiornare le etichette = 41777.

(cioè la bitmap è anche leggermente più veloce delle etichette).

E voglio che notiate che il numero di etichette e la larghezza della bitmap in presenza di ChartRedraw all'interno di un ciclo - non influenza nulla. Quindi, la funzione ChartRedraw è la più lenta in questa situazione.

---

Se rimuovete ChartRedraw dal ciclo, otterrete numeri completamente diversi

Tempo di aggiornamento della bitmap = 5788.
Tempo di aggiornamento delle etichette = 234.

quindi il terminale con i tag è 20 volte più veloce della bitmap


e qui, naturalmente, possiamo già vedere la dipendenza dell'altezza della bitmap. per 100 segni:

Tempo di aggiornamento della bitmap = 51355.
Tempo di aggiornamento delle etichette = 1108.
50 volte la differenza

ed ecco una bitmap con dimensioni 250*20. cioè non cambiare le coordinate dei segni.

otteniamo

Tempo di aggiornamento della bitmap = 25054.

La differenza con i cento marchi è di 25 volte.


Quindi, come potete vedere la bitmap è davvero lenta per quanto riguarda il lavoro con essa.

inequivocabilmente, che il lavoro ciclico costante con gli array + WinGdi TextOut + creazione di ResourceCreate = inferiore agli oggetti MT nativi di almeno un ordine, o anche 50 volte.

Ecco perché non si dovrebbe rifiutare gli oggetti MT. Come probabilmente sarà molto comodo per disegnare grafici e istogrammi.

Документация по MQL5: Операции с графиками / ChartRedraw
Документация по MQL5: Операции с графиками / ChartRedraw
  • www.mql5.com
Операции с графиками / ChartRedraw - Документация по MQL5
 
tol64:
E quale flag per impostare lo spessore del carattere hai usato per la bitmap?

Il valore predefinito è 0, non lo imposto esplicitamente. Potete vederlo nel codice sorgente allegato.

Un ulteriore "gioco" con diverse bandiere non ha portato all'uniformità.

 
sergeev:

...

L'obiettivo è scoprire se le etichette o le bitmap si modificano più velocemente. Non la loro successiva uscita sul grafico.

...

La rimozione della funzione ChartRedraw() dal ciclo non è corretta, perché l'"operazione atomica" di modifica della proprietà dell'etichetta di testo non è in alcun modo gestita dal video-motore del terminale.

Solo quando si chiama ChartRedraw() viene disegnata l'intera finestra, inclusa la sovrapposizione reciproca di immagini con canali alfa di oggetti diversi.

Questa ipotesi è strettamente confermata dal profiler di codice sullo script con etichette di testo.

Come per la bitmap, il collo di bottiglia è la funzione TextOut().

 
voix_kas:

...

Come per la bitmap, il collo di bottiglia è la funzione TextOut().

Questo è più chiaro: ))

 
tol64:

Questo è il modo per renderlo più chiaro: ))

Sono d'accordo. :)

sergeev:

...

Ecco i risultati del test se si lascia ChartRedraw all'interno del ciclo.

Tempo di aggiornamento della bitmap = 40980.
Tempo per aggiornare le etichette = 41777.

(cioè la bitmap è anche leggermente più veloce dei tag)

Strano, ho l'immagine opposta:

 

Argb_normalize è meglio non usarlo, perché dà un costo extra per la normalizzazione del colore. È meglio dipingere le cose semplici con un colore puro.

Anche la velocità è direttamente e fortemente influenzata dalla scheda video, poiché stiamo facendo pieno uso delle sue caratteristiche 2D. Per esempio, su portatili deboli con schede grafiche rudimentali , il rendering è lento e la differenza nei metodi di output è grande.

Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы индикаторов / Стили рисования - Документация по MQL5