Erreurs, bugs, questions - page 976
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
...
C'est étrange, j'ai l'image inverse :
J'ai obtenu ce résultat :
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Erreurs, bogues, questions
Renat, 2013.04.27 13:32
Je vais aussi faire les tests et écrire les résultats.J'ai complètement oublié que lors des tests d'étiquettes, le dessin est entièrement dérivé du système MQL5 et dessiné dans le fil de l'interface. Dans MQL5, seules les descriptions des étiquettes sont modifiées.
Lors du dessin d'un bitmap, tout le dessin est effectué dans MQL5 et seul un BitBlt unique très rapide reste dans le flux de l'interface.
En d'autres termes, le test est totalement incorrect, puisqu'il n'y a pas de test du tout pour la cartographie des étiquettes. L'actualisation du graphique est une commande asynchrone qui n'envoie qu'une notification au thread de l'interface pour effectuer le rendu. Comme vous pouvez le voir sur la capture d'écran avec les coûts de ChartRedraw.
Il est préférable de ne pas utiliser Argb_normalize, car il donne un coût supplémentaire pour la normalisation des couleurs. Il est préférable de peindre les choses simples en couleur pure.
Le canal alpha a un aspect esthétique. Lorsque du texte est affiché de manière "transparente" au-dessus de graphiques/balls, laconclusion évidente à tirer est qu'il y a séparation des usages.
Si vous souhaitez simplement afficher un message/des statistiques, l'étiquette texte est plus rapide. Dans lecas de la création de contrôles (tels que des boutons) - bitmap, et sans options. Vous pouvez ensuite remplir toute la zone rectangulaire avec une couleur solide, sans canal alpha/transparence, sans trop de frustration.
La suppression de la fonction ChartRedraw() de la boucle est incorrecte, car l'"opération atomique" de changement de propriété de l'étiquette de texte n'est pas gérée par le moteur vidéo du terminal de quelque manière que ce soit.
Oui, exactement de la même manière que le travail avec les tableaux n'est pas géré par le moteur vidéo.
Le problème est de trouver ce qui fonctionne le plus rapidement - changer un bitmap ou changer une étiquette.
création de perdus bitmap - c'est sûr.
et le rendu du tableau dans les deux cas est discutable et secondaire.
Pensez aux résultats. Vous voyez que 4 secondes par cycle de changement d'étiquettes ? ??? est un non-sens.
les changements d'étiquettes doivent être vérifiés purement sur le changement, sans interférer avec le sous-système de rendu du graphique.
sinon vous verriez des chiffres comparables avec un bitmap.
J'ai complètement oublié que lors des tests d'étiquettes, le dessin est entièrement dérivé du système MQL5 et dessiné dans le fil de l'interface. Dans MQL5, seules les descriptions des étiquettes sont modifiées.
Lors du dessin d'un bitmap, tout le travail est effectué dans MQL5.
Mais l'étiquette change toujours plus vite que le bitmap en termes de vitesse. En raison de la lenteur des fonctions GDI.
En d'autres termes, le test est complètement erroné, puisque la cartographie des marques n'est pas du tout testée. Le rafraîchissement du graphique est une commande asynchrone qui envoie uniquement une notification au thread de l'interface à dessiner. C'est ce que vous pouvez voir sur la capture d'écran avec les coûts de ChartRedraw.
Exactement.
Je pense que nous devons effectuer des tests dans le cadre de quelques tâches lourdes spécifiques . Qui prendra pour effectuer une tâche de référence comme celle-ci ?
- Dessiner un graphique (par exemple une onde sinusoïdale) en utilisant un ensemble d'étiquettes (rectangle) et en utilisant un bitmap.
- dessiner un tableau excel (rectangle+étiquette) et comme un bitmap.
et d'autres options où les graphiques MT peuvent être remplacés par des bitmaps.
vérifier le coût des ressources pour prendre en charge un bitmap et un grand nombre d' objets MT . + dépendance de la taille des zones à remplir.
Une autre chose que vous pouvez voir à partir du test des étiquettes est qu'il y a une opération d'écriture unidirectionnelle très économique sans étiquettes de lecture. Dans ce cas, il y a une pipérisation rapide maximale du flux de commande par écriture (nous utilisons délibérément un système efficace dans ce cas).
Mais si vous mélangez l'écriture avec la lecture de données d'objets, ce qui est souvent le cas dans le travail réel, la vitesse chute de façon spectaculaire.
Mise à jour : Dans l'exemple de test des marqueurs, il y a également une erreur critique - une seule modification va à un marqueur, et non 26. Jetez un coup d'œil au code source.
En d'autres termes, le test est totalement incorrect, car il ne teste pas du tout le mappage des étiquettes.
Les changements de balises doivent être testés uniquement pour les changements, sans que le sous-système de rendu des graphiques ne soit balayé.
Je ne suis pas d'accord, bien sûr. Argument : il est souhaitable pour l'utilisateur de voir le changement de situation (stats) aussi souvent que possible, à chaque tick. Par conséquent, après avoir mis à jour les statistiques, elles doivent être affichées = ChartRedraw().
C'est, pour ainsi dire, en termes d'application immédiate/de nature pratique de la performance.
Quant aux repères sphériques dans le vide, ils sont facultatifs.
mais la marque change toujours plus vite que le bitmap en termes de vitesse. A cause de la lenteur des fonctions GDI.
Ily a également uneerreur critiquedans l'exemple de test d'étiquette - une seule étiquette est modifiée, et non 26. Regardez la source.
Le texte change dans toutes (la moitié) des étiquettes, qui sont conçues pour afficher la valeur de l'indicateur, et non sa description. Quand vous exécutez le script, vous pouvez le voir.
Soit je ne vous comprends pas. De quelle ligne en particulier parle-t-on ?
Aucune méthode GDI n'est appelée.
Je veux dire TextOut. N'est-ce pas un système ?
Je comprends l'étiquette, je ne l'associe pas du tout à GDI.