Erreurs, bugs, questions - page 975
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
...
tol64
Croyez-moi,je n'ai pas le moindre motif devous décevoir ou de me tromper. Dans ma première expérience, j'ai observé un bitmap dans le testeur. Malheureusement, je ne peux pas le reproduire. :(
Je voudrais également attirer l'attention des développeurs sur les différences dans l'affichage des polices de caractères :
À gauche, vous voyez le bitmap et à droite, les étiquettes. Lebitmap a un rendu de police légèrement plus gras, bien que tous les paramètres soient les mêmes.
La question n'est pas critique. Mais afin de prêter attention. :)
Je voudrais également attirer l'attention des développeurs sur les différences d'affichage des polices de caractères
À gauche, le bitmap, à droite, les étiquettes. Lebitmap a un rendu de police légèrement plus gras, bien que tous les paramètres soient les mêmes.
La question n'est pas critique. Mais pour l'ordre, il faut faire attention. :)
Je me suis trompé. Les performances des bitmaps sont inférieures de 16 % à 25 % à celles des balises (en fonction du nombre d'éléments), mais pas d'un ordre de grandeur, comme je l'ai écrit précédemment.
Non. Pourtant, votre test est incorrect.
Vous utilisez ChartRedraw après chaque modification. Donc en fait, vous testez 10000 fois ChartRedraw. Ce n'est pas bien.
La tâche consiste à déterminer ce qui change le plus vite : les étiquettes ou les bitmaps. Et pas leur production ultérieure sur le graphique.
Voici les résultats du test si vous laissez ChartRedraw à l'intérieur d'une boucle.
Temps de mise à jour de la bitmap = 40980.
Il est temps de mettre à jour les étiquettes = 41777.
(c'est-à-dire que le bitmap est même légèrement plus rapide que les étiquettes).
Et je veux que vous notiez, que le nombre d'étiquettes et la largeur du bitmap en présence de ChartRedraw à l'intérieur d' une boucle - n'affecte rien. Ainsi, la fonction ChartRedraw est la plus lente dans cette situation.
---
Si vous retirez ChartRedraw de la boucle, vous obtiendrez des chiffres complètement différents.
Temps de rafraîchissement du bitmap = 5788.
Temps de mise à jour des étiquettes = 234.
donc le terminal avec les balises est 20 fois plus rapide que le bitmap
et ici, bien sûr, nous pouvons déjà voir la dépendance de la hauteur du bitmap. pour 100 marques :
Temps de mise à jour de la bitmap = 51355.
Temps de mise à jour des étiquettes = 1108.
50 fois la différence
et voici un bitmap de taille 250*20. c'est-à-dire ne pas changer les coordonnées des marques.
on obtient
Temps de rafraîchissement de la bitmap = 25054.
La différence avec les notes de cent est de 25 fois.
Ainsi, comme vous pouvez le constater, le bitmap est vraiment lent à travailler.
sans ambiguïté, que le travail cyclique constant avec des tableaux + WinGdi TextOut + création de ResourceCreate = inférieur aux objets MT natifs par au moins un ordre, voire 50 fois.
C'est pourquoi vous ne devez pas refuser les objets MT. Comme il sera probablement très pratique pour dessiner des graphiques et des histogrammes.
Et quel drapeau pour définir l'épaisseur de la police avez-vous utilisé pour le bitmap ?
La valeur par défaut est 0, je ne la fixe pas explicitement. Vous pouvez le voir dans le code source ci-joint.
Des "jeux" supplémentaires avec différents drapeaux n'ont pas non plus conduit à l'uniformité.
...
L'objectif est de savoir si les étiquettes ou les bitmaps se modifient plus rapidement. Pas leur sortie ultérieure sur le tableau.
...
Le retrait de la fonction ChartRedraw() de la boucle est incorrect, car l'"opération atomique" de modification de la propriété de l'étiquette de texte n'est en aucun cas gérée par le moteur vidéo du terminal.
Ce n'est qu'en appelant ChartRedraw() que la fenêtre entière est dessinée, y compris le chevauchement mutuel des images de canal alpha de différents objets.
Cette hypothèse est strictement confirmée par le profileur de code sur le script avec des étiquettes de texte.
Comme pour le bitmap, le goulot d'étranglement est la fonction TextOut().
...
Comme pour le bitmap, le goulot d'étranglement est la fonction TextOut().
C'est plus clair : ))
C'est la façon de rendre les choses plus claires : ))
Je suis d'accord. :)
...
Voici les résultats du test si vous laissez ChartRedraw à l'intérieur de la boucle.
Temps de mise à jour de la bitmap = 40980.
Temps pour rafraîchir les étiquettes = 41777.
(c'est-à-dire que le bitmap est même légèrement plus rapide que les tags)
C'est étrange, j'ai l'image inverse :
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.
La vitesse est également directement et fortement influencée par la carte vidéo, car nous utilisons pleinement ses fonctions 2D. Par exemple, sur les ordinateurs portables faibles dotés de cartes graphiques rudimentaires , le rendu est lent et la différence entre les méthodes de sortie est importante.