Toile et étiquettes - page 6
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
Pourquoi voudrais-je tester des dessins graphiques dans un testeur de stratégie (en particulier dans une version spécialisée de visual pending), alors qu'il est préférable de le faire directement dans un graphique de travail ?
Et félicitations à ceux qui ne pensent pas à désactiver le tracé graphique de leurs robots dans le testeur non visuel.
Nikolay a raison - l'édition des propriétés des étiquettes n'a rien à voir avec le rendu des étiquettes.
L'étiquette, comme tout autre objet sur le graphique, est dessinée dans un fil complètement différent et indépendamment du travail du programme MQL5. Le robot peut seulement demander que le graphique soit à nouveau rendu de force, mais il ne peut pas mesurer le temps de rendu. Le dessin de graphiques avec des objets est complètement asynchrone.
Mais le rendu du canevas est facile à mesurer car il se fait directement dans le flux du robot et ensuite lors du rendu indépendant du graphique il reste à faire un BitBlit natif du bitmap prêt dans le contexte de la fenêtre. Cette opération est élémentaire et est bien accélérée par la carte vidéo.
Dans les étiquettes de texte, SetFont/TextOut dans les polices TTF est assez coûteux.Il s'avère que c'est 321 fois, si l'on en croit cette mesure.
Pourquoi voudrais-je tester des dessins graphiques dans un testeur de stratégie (en particulier dans une version spécialisée de visual pending), alors qu'il est préférable de le faire directement dans un graphique de travail ?
En même temps, félicitations à ceux qui n'ont pas pensé à désactiver le traçage graphique dans leurs robots de trading dans le testeur non visuel.
J'aurais pu le vérifier sur la carte aussi. Cependant, j'ai pensé qu'il serait plus facile de le faire dans le testeur de stratégie. En outre, j'ai eu une situation, que j'ai décrite ci-dessus, où l'affichage était basé sur CCanvas et cela a sérieusement ralenti l'Expert Advisor dans le testeur. Surtout que ça se voyait sur les tiques. Pour le démontrer dans le graphique, il faudrait faire une sortie de texte en boucle. Cela permet d'obtenir un taux de rafraîchissement élevé, comme c'est le cas dans mon conseiller expert avec optimisation hors ligne sur lequel je travaille actuellement. Et j'ai décidé de faire un affichage basé sur des étiquettes, car Canvas l'aurait ralenti. Parce que, comme vous l'avez noté, l'étiquette est rendue dans un thread différent, ce qui ne ralentit pas l'optimisation autonome de l'EA, qui tourne en boucle.
Il s'avère que, comme vous l'avez dit, il faut plus de temps pour dessiner le texte des étiquettes que pour dessiner OBJ_BITMAP_LABEL. Par conséquent, pour accélérer le processus, le rendu doit également être effectué dans un thread séparé. Mais comment ? Si cela n'est pas possible, alors du point de vue d'une applicationqui utiliseOBJ_LABEL, il est plus rapide que OBJ_BITMAP_LABEL...
C'est évident pour un programmeur expérimenté qui a étudié en détail ou qui connaît le terminal à fond ! Et comme je ne suis pas un développeur du terminal, mais que j'écris seulement des applications pour celui-ci, il se peut que je ne sache pas, comme la plupart des programmeurs, ce qui ne se trouve pas dans la documentation MQL.
Ceci est évident pour un programmeur expérimenté qui a étudié en détail ou qui connaît parfaitement le fonctionnement du terminal ! Et comme je ne suis pas un développeur du terminal, mais que j'écris seulement des applications pour celui-ci, il se peut que je ne sache pas, comme la plupart des programmeurs, ce qui ne se trouve pas dans la documentation MQL.
Et pourtant, vous essayez d'argumenter non seulement avec un développeur, mais avec le directeur de MQ.
Et pourtant, vous essayez d'argumenter non seulement avec un développeur, mais avec le directeur de MQ.
Je ne cherche pas à discuter, mais à savoir si OBJ_BITMAP_LABEL peut être rendu moins coûteux que OBJ_LABEL du point de vue de l'application utilisatrice !
Et j'ai décidé d'en faire un affichage basé sur des étiquettes, car Kanvas aurait ralenti les choses.
Je suis à peu près sûr de la raison pour laquelle votre toile ralentissait.
Parce que vous essayiez d'entasser plusieurs images dans une image de 30 millisecondes.
De toute façon, les images ne sont pas redessinées (ChartRedraw) plus souvent qu'environ 30 images par seconde.
Comme je l'ai dit ici, la différence entre kanvas text et Label est que le remplissage du tableau de pixels dans le cas des labels est asynchrone et n'est pas contrôlé par vous, donc le remplissage du tableau de pixels dans le cas des labels ne se produit pas plus souvent qu'une fois toutes les 30 millisecondes environ.
Mais cela peut arriver avec le canvas car il n'est pas asynchrone (remplissage de bitmap). Vous pouvez remplir le bitmap dix fois en 30 millisecondes, mais il ne sera affiché qu'une fois, et 9 fois il sera inactif.
Donc, comme discuté dansCanvas est cool ! le programmeur doit contrôler l'heure de démarrage du BitMap.
Un modèle de comportement pourrait être :
Je suis à peu près sûr de la raison pour laquelle ton kanvas ralentissait.
Parce que tu essayais de faire tenir plusieurs images dans une image de 30 millisecondes.
De toute façon, les images ne sont pas redessinées (ChartRedraw) plus souvent qu'environ 30 images par seconde.
Comme je l'ai dit ici, la différence entre kanvas text et Label est que le remplissage du tableau de pixels dans le cas des labels est asynchrone et n'est pas contrôlé par vous, donc le remplissage du tableau de pixels dans le cas des labels ne se produit pas plus souvent qu'une fois toutes les 30 millisecondes environ.
Mais cela peut arriver avec le canvas car il n'est pas asynchrone (remplissage de bitmap). Vous pouvez remplir le bitmap dix fois en 30 millisecondes, mais il ne sera affiché qu'une fois, et 9 fois il sera inactif.
Par conséquent, comme indiqué dansCanvas is cool ! le programmeur doit contrôler le temps de remplissage du BitMap.
Un modèle de comportement pourrait être le suivant :
Existe-t-il des informations disponibles quelque part où l'on peut en savoir plus à ce sujet ? Bien que tout soit clair pour moi, le sujet est tout de même intéressant ! Il reste maintenant à réaliser la variante de contrôle de la mise à jour des bitmaps et à la tester. Je serai surpris si le bitmap s'avère plus rapide que les étiquettes.
Voici un exemple, qui montre ce dont je parle. La base du script est tirée de la documentation ici .
Il commence avec un tableau aléatoire qui produit 100 fois 100 lignes et génère 100 étiquettes.
Les 100 premières images avec étiquette sont sorties.
Après cela, il produira 100 images avec des chaînes de toile.
La toile est la même.
Dans une boucle Le sommeil est documenté. Si la boucle contient Sleep(0), la situation sera tout à fait différente. Vous pouvez expérimenter un peu.
Tous les cadres et toutes les lignes sont numérotés pour le contrôle.
J'ai enregistré une vidéo et l'ai ralentie 30 fois. Vous pouvez constater que seules deux images sur 100 ont été rendues pour les étiquettes, de plus, dans la deuxième image, vous pouvez voir que les étiquettes proviennent de différentes images, c'est-à-dire que vous pouvez voir l'asynchronie fonctionner.
Ces valeurs pour l'étiquette sont donc fausses :
Kanvas, en revanche, produit environ 60-70 images sur 100. Cela s'est produit parce que la trame est formée un peu plus vite que 30 millisecondes et donc toutes les trames n'ont pas le temps d'être sorties, bien que toutes les trames soient formées.
Expérimentez avec les deux premiers paramètres
et le retard de cycle.
Si vous augmentez le nombre de lignes à sortir, vous risquez d'attraper l'erreur 4001. Il s'agit d'un bogue dans MQ lorsqu'il y a trop de sorties.