Réaliser un projet de crowdsourcing sur Canvas - page 32
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 exactement comme ça que je l'ai construit. En gros, j'ai pris la bibliothèque standard comme base, parce qu'elle a des moments de transfert d'événements très bien élaborés et quelques autres choses. Anatoly crée des groupements pour chaque classe différente d'éléments, dans le groupement standard tout est réduit à un seul objet de base.
...
Dans ses exemples, Nikolay montre qu'il n'est pas nécessaire de s'embêter à stocker toutes les données des zones locales car le repeint de l'ensemble du canevas est si rapide, qu'il n'est pas nécessaire de descendre dans les détails et qu'il suffit de redessiner l'ensemble du canevas en une seule fois.Ce n'est pas si simple. Imaginez que vous ayez dessiné un grand tableau (un tableau entier), dont l'une des cellules change de valeur 20 fois par seconde. Si vous redessinez la totalité du canevas, la charge du processeur augmentera jusqu'à 40 % ou plus. C'est une façon tout à fait erronée de travailler avec une toile. Vous devez redessiner des éléments distincts, sinon les tableaux, les vitres et les différentes animations locales vont surcharger le processeur et ralentir l'exécution des autres fonctions (si elles sont dans un thread commun).
Les expériences de Nikolay jusqu'à présent prouvent le contraire. Il redessine tout le contenu de la toile en une seule fois, et c'est clairement visible dans le code.
Mais je suis toujours en faveur de changements locaux. Mais cette approche a ses propres difficultés, que je n'ai pas encore résolues.
Les expériences de Nikolay jusqu'à présent prouvent le contraire. Il redessine tout le contenu de la toile en une seule fois, et c'est clairement visible dans le code.
Mais je suis toujours en faveur de changements locaux. Mais cette approche a ses propres difficultés que je n'ai pas encore résolues.
Je considère Nikolay comme mon ami et il a atteint de grands sommets dans le travail avec la toile, mais il n'a pas encore fait d'expériences complètes avec les contrôles. En particulier avec les tables et le verre. En tout cas, je n'en ai pas connaissance.
Le résultat final est le suivant : Un canevas est un tableau de données. Les données sont modifiées et réenregistrées lors des événements de changement. Si le tableau comprend tous les pixels de l'espace du graphique - alors sa taille = hauteur*largeur du graphique. S'il y a un changement local des valeurs des pixels à l'intérieur du tableau, il n'est pas nécessaire de faire une boucle complète sur l'ensemble du tableau et de réinitialiser toutes les valeurs. Vous devez effectuer une boucle sur la zone modifiée, définir les valeurs et quitter la boucle. Sinon, quelle que soit la manière dont on la découpe, c'est une perte de ressources et de temps.
Et cette approche présente de nombreuses difficultés. Le principal est de créer ses propres objets entièrement fonctionnels, de les trouver et de les traiter sur sa propre toile. Le CCanvas interne ne convient pas pour cela. Il ne "verrait" pas vos éléments et vous ne pourriez pas y accéder par son intermédiaire. Il n'a pas cette fonctionnalité.
Je considère Nikolaï comme un ami, et il a atteint de grands sommets avec la toile, mais il n'a toujours pas fait d'expériences complètes avec les commandes. Surtout avec des tables et un gobelet. En tout cas, je n'en ai pas connaissance.
Le résultat final est le suivant : Un canevas est un tableau de données. Les données sont modifiées et réenregistrées lors des événements de changement. Si le tableau comprend tous les pixels de l'espace du graphique - alors sa taille = hauteur*largeur du graphique. S'il y a un changement local des valeurs des pixels à l'intérieur du tableau, il n'est pas nécessaire de faire une boucle complète sur l'ensemble du tableau et de réinitialiser toutes les valeurs. Vous devez effectuer une boucle sur la zone modifiée, définir les valeurs et quitter la boucle. Sinon, quelle que soit la manière dont on la découpe, c'est une perte de ressources et de temps.
Et cette approche présente de nombreuses difficultés. Le principal est de créer ses propres objets entièrement fonctionnels, de les trouver et de les traiter sur sa propre toile. Le CCanvas interne ne convient pas pour cela. Il ne "verrait" pas vos éléments et vous ne pourriez pas y accéder par son intermédiaire. Cette fonctionnalité n'existe pas.
Je comprends très bien tout cela et j'en suis bien conscient. J'ai créé mes propres classes d'objets et tout fonctionne bien.
Je comprends très bien tout cela et j'en suis très conscient. J'ai créé mes classes d'objets et tout fonctionne bien.
Dans ce cas, vous pouvez vérifier en créant un tableau et en le mettant à jour de deux manières : localement (chaque cellule séparément) et en une seule fois l'ensemble du tableau.
Les animations de Nikolaï ont généralement un faible taux de rafraîchissement, et donc, redessiner simultanément l'ensemble du canevas ne se traduit pas par un chevauchement. Mais si vous augmentez le taux de rafraîchissement jusqu'à 5 fois par seconde, vous pouvez constater une augmentation de la consommation des ressources du CPU. Si vous devez redessiner l'ensemble de l'animation, il n'y a pas d'issue, mais s'il s'agit d'une seule petite zone à l'intérieur, il vaut mieux se limiter à celle-ci.
La fréquence elle-même - 5 fois par seconde - peut se produire dans un tableau où les valeurs changent de manière asynchrone. Cette situation m'est apparue sur MT4, lorsque j'ai connecté la table au testeur via les ressources. Dans ce cas, à la vitesse 31, tous les paramètres changent si rapidement qu'un redessin incorrect du tableau entraîne une charge CPU de 50 % ou plus. Même le redécoupage local des éléments n'a pas permis de le sauver complètement. J'ai eu l'idée de ralentir la vitesse d'affichage des valeurs. Les valeurs elles-mêmes changeaient à un rythme naturel, mais elles étaient transmises aux cellules plusieurs fois moins fréquemment. Cela a résolu le problème.
Voici un exemple. 1000 cellules doivent changer de valeur à un rythme de 25ms. En réalité, les cellules changent de valeur environ une fois toutes les 500 ms et la charge du processeur est d'environ 50 %. (Il s'agit de MT4 et le tableau est dessiné).
https://www.mql5.com/ru/forum/293630/page160
Voici un exemple avec le testeur. Le tableau est dessiné, mais il ne sauve pas le processeur de la surcharge. :) (vitesse du testeur 31, mise à jour de la cellule complète (pas de saut de broche)).
https://www.mql5.com/ru/forum/293630/page148
Ce n'est pas si simple. Imaginez que vous avez un tableau de grande taille (pour l'ensemble du graphique) dont l'une des cellules change de valeur 20 fois par seconde. Si vous redessinez l'ensemble de la toile, la charge du processeur augmentera jusqu'à 40 % ou plus. C'est une façon tout à fait erronée de travailler avec une toile. Vous devez redessiner des éléments distincts, sinon les tableaux, les vitres et les différentes animations locales vont surcharger le processeur et ralentir l'exécution des autres fonctions (si elles sont dans un thread commun).
Je ne sais pas vraiment d'où vous tenez vos chiffres. Regardez l'exemple parfaitement simple de Nikolaï https://www.mql5.com/ru/forum/227736/page44#comment_13445909. Sur un kanvas de la taille d'un graphique, plusieurs objets sont générés et peuvent être glissés et déposés sur le graphique (sur le kanvas). Le kanvas entier est redessiné. Il n'y a pas de ralentissement du tout.
Je ne sais pas vraiment d'où vous tenez vos chiffres. Regardez l'exemple parfaitement simple de Nikolaï https://www.mql5.com/ru/forum/227736/page44#comment_13445909. Sur un kanvas de la taille d'un graphique, plusieurs objets sont générés et peuvent être glissés et déposés sur le graphique (sur le kanvas). Le kanvas entier est redessiné. Il n'y a aucun ralentissement.
Regardez les exemples ci-dessus.
J'ai inséré les liens vers les hyphes.Voici un exemple de ralentissement de la sortie des valeurs vers les cellules et de réduction de la charge sur le processeur :
https://www.mql5.com/ru/forum/293630/page148
Je ne sais pas vraiment d'où vous tenez vos chiffres. Regardez l'exemple parfaitement simple de Nikolaï https://www.mql5.com/ru/forum/227736/page44#comment_13445909. Sur un kanvas de la taille d'un graphique, plusieurs objets sont générés et peuvent être glissés et déposés sur le graphique (sur le kanvas). Le kanvas entier est redessiné. Il n'y a pas de ralentissement du tout.
Le taux de rafraîchissement dans cet exemple est normal. Il n'y a donc pas de ralentissement.