Implementazioni alternative di funzioni/approcci standard - pagina 13
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
Questo è l'aspetto dell'inizio del blocco:
Per quanto ho capito, avete creato il vostro linguaggio interprete.
Come questo?
Un'altra domanda stupida:
ogni finestra generata con diversi elementi è una risorsa o molte?
Anche se un'analogia migliore sarebbe probabilmente HTML
Come ho detto prima, il vostro bambino ha bisogno di un costruttore grafico. Qualcosa come quello di Andrei Barinov.
Anche i tuoi video sono troppo lunghi. È necessario ridurli da 45 minuti a 5 minuti, o meglio ancora a 3 minuti.
Hai provato a trovare la risposta alla domanda da solo?
Suggerimento: nella ricerca su Google, inserire "DBL_MANT_DIG 53 52".
Sì, grazie. Trovato.
1. Per quanto ho capito, avete creato il vostro linguaggio interprete.
Come questo?
E una domanda stupida:
ogni finestra generata con diversi elementi è una risorsa o molte?
Anche se forse un'analogia migliore sarebbe il linguaggio HTML.
Come ho detto prima - la tua creatura ha bisogno di un costruttore grafico. Qualcosa come quello di Andrei Barinov.
Anche i tuoi video sono troppo lunghi. Da 45 minuti dovrebbero essere ridotti a 5 minuti, o meglio ancora a 3.
1. Sì, si scopre che la definizione di "interprete" si adatta meglio a ciò che ho creato (anche se nel processo di creazione non avevo idea di cosa fosse).
2. Ogni finestra formata è composta da diversi kanvase (risorse). I primi due sono una piattaforma Windows. Prima stavo usando un metodo di disegno diverso e quindi alcune parti erano semi-trasparenti e si poteva vedere il grafico attraverso di esse. Per evitare questo ho aggiunto un altro kanvas sullo sfondo. Poi la tecnica è migliorata, ma la tela rimane sullo sfondo. È cresciuta nella tecnologia ed è difficile liberarsene ora. Ma alla fine lo rimuoverò e la piattaforma della finestra sarà composta da una sola tela.
Inoltre, i "campi" (schede di immagini commutabili), sono tele indipendenti. Contengono immagini già pronte e quindi passano il più rapidamente possibile. Se dovessi disegnare tutto su un unico kanvas, inevitabilmente il cambio di immagine sarebbe più lento. Dovrei ridisegnare tutto da capo. Comunque, dopo averci pensato, sono giunto alla conclusione che questa è l'opzione migliore.
3. Visual Constructor era, ed è ancora, il mio obiettivo. Sono molto vicino all'inizio della sua realizzazione. C'è una comprensione della sua struttura. Ci sono tutti i concetti necessari per la sua attuazione. So come prepararlo. Ho solo bisogno di tempo.
ZS. La peculiarità del mio sviluppo è la spontaneità. Non avevo familiarità con gli interpertori o il linguaggio HTML, e non sapevo come funzionavano. Tuttavia, questo non mi impedisce di creare e fare cose simili. Penso che se funziona bene, continuerò a farlo. :)
A prima vista, sembra che tu abbia un uso molto sprecato della memoria. Potrei sbagliarmi, però.
Idealmente, il vostro compito dovrebbe avere solo una tela che supporta la trasparenza sul grafico dei prezzi.
Le prestazioni di MQL5 dovrebbero essere sufficienti per formare l'intera interfaccia al volo senza avere blocchi pronti in memoria, se la codifica è corretta.
Anche se non escludo la possibilità di sacrificare le risorse di memoria per aumentare le prestazioni di interfacce ingombranti.
Vedo un grande vantaggio nel suo approccio finora:
Sarà più facile per voi creare un costruttore grafico completo, poiché è più facile generare codice di markup piuttosto che il codice MQL stesso.
Ma è un compito elefantiaco.A prima vista, sembra che tu abbia un uso molto sprecato della memoria. Potrei sbagliarmi, però.
Idealmente, il vostro compito dovrebbe avere solo una tela che supporta la trasparenza sul grafico dei prezzi.
Le prestazioni di MQL5 dovrebbero essere sufficienti per formare l'intera interfaccia al volo senza avere blocchi pronti in memoria, se la codifica è corretta.
Anche se non escludo la possibilità di sacrificare le risorse di memoria per aumentare le prestazioni di interfacce ingombranti.
Vedo un grande vantaggio nel suo approccio finora:
Sarà più facile per voi creare un costruttore grafico completo, poiché è più facile generare codice di markup, non il codice MQL stesso.
Ma è un compito elefantiaco.C'è ancora un overrun di memoria relativamente piccolo. Hai ragione. Gli oggetti elemento come il testo o l'icona ricevono "immeritatamente" un numero di 235 proprietà nel kernel, mentre le loro proprietà sono molte volte inferiori. L'oggetto elemento principale, cioè la base, dovrebbe avere tutte le 235 proprietà, ma gli oggetti icona e testo hanno meno proprietà. Questo crea un eccesso di memoria.
L'idea è che se aggiungo altre 60 celle alla fila di oggetti dell'elemento principale, posso metterci le proprietà del testo e dell'icona. Questo renderebbe il nucleo più "largo", ma due terzi degli oggetti potrebbero essere rimossi.
Ci sarebbe un eccellente risparmio di memoria e un guadagno nella velocità di costruzione del kernel. Tuttavia, questo è tecnicamente difficile da implementare. C'è molto lavoro da fare. Finora, il consumo di memoria e il tempo di costruzione sono abbastanza accettabili. Ma non c'è limite alla perfezione...
Usare una sola tela non è una buona idea. È molto più facile usare una tela per ogni finestra e una tela per ogni campo. La tela generica deve essere ridisegnata molto più spesso. Per ogni cambio di immagine o per ogni spostamento di finestra. Sullo scorrimento... Bisogna tener conto del fatto che il ridisegno non è sempre veloce. Non è negli algoritmi, ma nella "sofisticazione" della grafica. Lasciatemi spiegare:
Se disegnate una semplice etichetta rettangolare (un quadrato, per esempio), è un ciclo su un array di pixel con le celle giuste inizializzate con il giusto valore (colore).
Se si disegna un quadrato con una cornice, si tratta di due cicli su un array di pixel.
Se si disegna un quadrato con una cornice e un'icona, sono tre cicli.
Se disegnate un quadrato con una cornice che ha un gradiente di superficie e un'icona che ha un'ombra, sono quattro o più cicli sulla matrice di pixel.
Quindi, più la grafica è ripida, più è necessario "stirare" questa serie di pixel in cicli, creando l'immagine giusta. Quindi, meno c'è bisogno di ridisegnare, meglio è.
Una tela per tutte le immagini, vi farà ridisegnare tutto continuamente. Pertanto, non è una buona soluzione.
ZS. Il compito è certamente elefantiaco, ma posso farlo. (Anche se mi farò aiutare).
ZS. Grazie per il video, è d'ispirazione! :)
Ridimensiona la finestra con il mouse?
Se sì, appare un quadrato rosso?
Ridimensiona la finestra con il mouse?
Se sì, appare un quadrato rosso?
Non capisco di quali piazze stiamo parlando.
La finestra dinamica può essere ridimensionata con il mouse. Come potrebbe essere altrimenti?
ZS: La finestra dinamica ha inizialmente una dimensione a schermo intero. Inoltre, viene "rifilato" alla dimensione richiesta. In altre parole, tutto il suo dinamismo si realizza nella dimensione massima della bitmap già creata.
Per continuare l'argomento dell'arrotondamento.
Ho scoperto che i moderni processori Intel che supportano il set di istruzioni SSE4.1 esteso hanno il comando di arrotondamentoROUND{PS, PD} . Sono sicuro che AMD ha qualcosa di simile.
https://ru.wikipedia.org/wiki/SSE4#SSE4a
http://o-ili-v.ru/wiki/SSE4
Questo significa che il compilatore MQL5 non usa questo comando a livello di CPU? Dal momento che il mio processore Intel Kaby Lake supporta questo set.
E c'è molto di più, anche la moltiplicazione scalare dei vettori.