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
Dimitri, avant de juger quelque chose, il faut comprendre où tout a commencé...
Où tout cela a-t-il commencé ? En s'éloignant de la réalité ?
Une sortie de texte vers label 100 fois plus rapide qu'une sortie de texte vers kanvas, même si kanvas n'était même pas en train de défricher, il sculptait du texte sur du texte.
Je présenterai bientôt des tests, où Kanvas est aussi assez rapide. Et je vais également mettre à jour le code source correspondant dans KB. Il s'agit de limiter le nombre de mises à jour par unité de temps, comme je l'ai découvert plus tard. Voir les posts ci-dessus, cela y a été discuté. Commencez par ce billet : https://www.mql5.com/ru/forum/364640/page6#comment_21290218.
Je présenterai bientôt des tests, où Kanvas est aussi assez rapide. Et je vais également mettre à jour le code source correspondant dans KB. Il s'agit de limiter le nombre de mises à jour par unité de temps, comme je l'ai découvert plus tard. Voir les messages ci-dessus, cela y a été discuté. Commencez par ce billet : https://www.mql5.com/ru/forum/364640/page6#comment_21290218.
Et je ne suis pas en train de fantasmer, je mesure les performances du code qui s'appliquerait dans la réalité. Et je ne me soucie pas du tout de ce qui est rendu et de l'endroit où cela est rendu, je mesure la durée finale du programme.
Et je ne suis pas en train de fantasmer, mais de mesurer les performances d'un code qui serait appliqué dans la réalité.
Même une comparaison purement muette d'un seul appel à TextOut() est 70 fois plus lente que la sortie de texte sur l'étiquette.
Si vous ne voulez pas ou ne pouvez pas le comprendre, voici une citation :
Nikolaï a raison - l'édition des propriétés de l'étiquette n'a rien à voir avec le rendu de l'étiquette.
L'étiquette, comme tout autre objet sur le graphique, est dessinée dans un fil totalement différent et indépendamment du fonctionnement 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.Si vous ne voulez pas ou ne pouvez pas y donner un sens, vous obtenez un devis :
Et je vous ai déjà répondu ici
Et je vous ai déjà répondu ici
Allez-vous vous disputeravec le directeur de MetaQuotes ?
Allez-vous discuteravec le directeur de MetaQuotes ?
Nous ne sommes pas en désaccord.
Même une comparaison purement muette d'un seul appel à TextOut() est 70 fois plus lente que la sortie de texte sur l'étiquette.
Cela est dû au fait que le rendu du graphique est effectué dans un thread séparé. Alors que le traitement du tableau de pixels pourOBJ_BITMAP_LABEL est dans le même thread que l'application qui l'utilise, ainsi que le passage des pixels au bitmap. Par conséquent,OBJ_BITMAP_LABEL peut ralentir l'application, mais pas de manière significative si le bitmap n'est pas mis à jour trop souvent. Dans mes tests précédents, OBJ_BITMAP_LABEL provoquait des ralentissements importants pour la même raison. Mais si vous limitez la fréquence de mise à jour des bitmaps, le résultat est encore meilleur qu'avec les étiquettes. Et si vous limitez le taux de mise à jour du bitmap, il sera légèrement plus rapide queOBJ_BITMAP_LABEL (en raison du rendu dans un thread séparé).Simplement, il n'est pas logique de mettre à jour les objets plus fréquemment que ce que l'œil humain peut percevoir. D'où les décalages, tous les objets dans le graphique lorsque vous les mettez à jour trop souvent.