Toile et étiquettes - page 7

Nouveau commentaire
 
Mihail Matkovskij:

Existe-t-il une information quelque part où l'on peut en savoir plus à ce sujet ? Même si c'est assez clair pour moi, c'est quand même un sujet 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.

J'admets qu'avec peu d'étiquettes, leur utilisation a un avantage de vitesse par rapport aux kanvas, car BitMap est rempli en C++, pas en MQL5. Cependant, il est peu probable que la formation du texte soit la même dans le canevas également, car la formation du texte BitMap est effectuée par des fonctions de gain dans les deux cas. Je pense que dans le cas de Label, ces objets sont également revêtus de propriétés événementielles (ils peuvent être glissés et déposés avec la souris) et cela rend leur construction plus lourde au final.

 

Sur la vitesse de Canvas, il y a une question.


La carte vidéo est intégrée à l'unité centrale.


Exécuter un code comme celui-ci.

#include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit()
{  
  USAGE::MinInterval = 100 * 1000; // 100 ms.
  
  EventSetMillisecondTimer((int)USAGE::MinInterval / 1000);  
}

void OnTimer()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate(1200, 900, 200); // Вывели график нагрузки.
}

void OnDeinit( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

En bref, il mesure le temps d'exécution de OnTimer toutes les 100 ms. En outre, il trace un graphique des mesures dans OnTimer. Voilà ce que ça donne.

Il absorbe 15 à 20 %. Apparemment, c'est une carte graphique lente. Mais le problème est différent. Si je commence à secouer un graphique de prix avec une souris (en maintenant le bouton gauche de la souris enfoncé et en le déplaçant de gauche à droite), la charge est multipliée par deux. Il est clairement visible sur l'animation ci-dessus. Quelle est la raison de cette particularité ?


Encore une fois. OnTimer prend deux fois plus de temps si vous déplacez le graphique des prix avec la souris.

 
fxsaber:

Sur la vitesse de Canvas, il y a une question.


La carte vidéo est intégrée à l'unité centrale.


Exécuter un code comme celui-ci.

En bref, il mesure le temps d'exécution de OnTimer toutes les 100 ms. En outre, il trace un graphique des mesures dans OnTimer. Voilà ce que ça donne.

Il absorbe 15 à 20 %. Apparemment, c'est une carte graphique lente. Mais le problème est différent. Si je commence à secouer un graphique de prix avec une souris (en maintenant le bouton gauche de la souris enfoncé et en le déplaçant de gauche à droite), la charge est multipliée par deux. Il est clairement visible sur l'animation ci-dessus. Quelle est la raison de cette particularité ?


Encore une fois. Le OnTimer prend deux fois plus de temps si vous déplacez le graphique des prix avec la souris.

Il est fort probable que vos bibliothèques disposent du contrôle CHARTEVENT_CHART_CHANGE, afin de modifier la taille du canevas en cas de besoin (si la taille du graphique a changé), mais pour le découvrir, vous devez exécuter la fonction asynchrone ChartGet...
, qui est terriblement lente (jusqu'à présent).
Il serait plus logique pour MQ de séparer l'événement CHARTEVENT_CHART_CHANGE, et de faire un événement CHARTEVENT_CHART_SIZE_CHANGE distinct, par exemple. Il y a trop de choses dans l'événement CHARTEVENT_CHART_CHANGE : arrivée d'une nouvelle barre, défilement des barres, changement de l'échelle verticale des prix, redimensionnement de la fenêtre.

 
Nikolai Semko:
Il est tout à fait possible qu'avec un petit nombre d'étiquettes, leur utilisation présente des avantages en termes de vitesse par rapport à Kanvas, car BitMap est rempli en C++ et non en MQL5. Cependant, il est peu probable que la formation du texte soit la même dans le canevas également, car la formation du texte BitMap est effectuée par des fonctions de gain dans les deux cas. Je pense que dans le cas de Label, ces objets sont également revêtus de propriétés événementielles (ils peuvent être glissés et déposés avec la souris) et cela rend leur construction plus lourde au final.

En effet, les étiquettes peuvent être plus rapides. Cela dépend de combien il y en a dans le tableau... J'ai vérifié la mise à jour et j'ai été surpris par les résultats. La limite a été prise à partir de la fréquence d'images minimale agréable à l'œil, 24 fps, si je ne me trompe pas. J'ai obtenu environ 41 millisecondes. Mettez une limite à Kanvas et, oh miracle, j'ai été surpris. Ça passe vite, comparé à l'implacable mise à jour des étiquettes ! Mais lorsque j'ai imposé la même restriction pour l'affichage sur les étiquettes, il était encore plus rapide que l'affichage basé sur Kanvas. Mais je ne vais pas m'avancer, je présenterai tous les résultats des tests plus tard.

 
fxsaber:

Si je commence à secouer le graphique des prix avec la souris (déplacement vers la gauche et la droite avec le bouton gauche de la souris enfoncé), la charge double. Dans l'animation ci-dessus, elle est parfaitement visible. Quelle est la raison de cette particularité ?

Avec le modèle événementiel de Windows, même si vous déplacez rapidement la souris, la charge du processeur commence à augmenter, quelle que soit l'application en cours.

SZY : vérifié avec le gestionnaire de tâches de Win10... Je ne pense pas que Win10 ait changé radicalement le modèle d'événement, il est plus probable que le gestionnaire de tâches fonctionne différemment.

 
Nikolai Semko:

Il est fort probable que vos bibliothèques disposent du contrôle CHARTEVENT_CHART_CHANGE afin de modifier la taille du canevas en cas de besoin (si la taille du graphique a changé), mais pour le savoir, vous devez exécuter la fonction ChartGet asynchrone terriblement lente (jusqu'à présent)...
Cela conduit à un freinage.
Il serait plus logique pour MQ de séparer l'événement CHARTEVENT_CHART_CHANGE, et de faire un événement CHARTEVENT_CHART_SIZE_CHANGE distinct, par exemple. L'événement CHARTEVENT_CHART_CHANGE comporte de nombreux éléments : arrivée d'une nouvelle barre, défilement des barres, changement de l'échelle verticale des prix, redimensionnement de la fenêtre.

Rien de tout cela n'est dans le code ci-dessus.

 
Igor Makanu:

avec le modèle d'événement de Windows - même si vous déplacez rapidement la souris, la charge du processeur commence à augmenter, quelle que soit l'application qui était au premier plan

SZY : Je l'ai vérifié dans le gestionnaire des tâches de Win10... Je ne vois pas d'augmentation de la charge du CPU pour une raison quelconque, dans Win7 la charge augmentait sur le même PC si je déplaçais la souris rapidement - je doute que Win10 ait fondamentalement changé le modèle d'événement, il est plus probable que le gestionnaire de tâches fonctionne différemment.

Merci, je ne le savais pas. Surpris que la souris soit capable de ralentir de moitié le programme MQL.

ZS Est-ce que je suis le seul à avoir obtenu ce résultat ?
fxsaber:

Il absorbe 15 à 20 %. Apparemment, la carte vidéo est lente.

 
fxsaber:

Merci, je ne le savais pas. J'ai été surpris qu'une souris soit capable de ralentir de moitié un programme MQL.

Il est donc légitime d'avoir des décalages avec les tics et autres. Le HFT avec un tel modèle d'événement est comme un champ de mines.

 
fxsaber:

Rien de tout cela n'est dans le code ci-dessus.

Oui, je n'avais pas vu que c'était le tableau interne.
A en juger par le profilage, la source des freins lors du défilement du graphique se trouve sur cette ligne :

Profilage avec défilement actif :

Profilage avec mouvement actif de la souris sans défilement (sans le LKM appuyé) :

ZS : Donc la source des freins n'est pas le kanvas, mais les objets.

 
Mihail Matkovskij:

Vous auriez pu le vérifier sur la carte également. Cependant, j'ai pensé qu'il serait plus facile de le faire dans le testeur.

Cette approche est erronée. D'autant que le testeur visuel dispose d'un modèle de rendu différé différent, afin de ne pas ralentir complètement le processus de test.

Ainsi, comme vous l'avez dit, il faut plus de temps pour dessiner le texte des étiquettes que pour dessiner OBJ_BITMAP_LABEL.

Je n'ai pas dit ça.

J'ai signalé les erreurs évidentes et expliqué le fonctionnement du système de rendu.

1234567891011121314...18
Nouveau commentaire