DirectX - page 9
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
OK, j'ai fait le verre dans l'éditeur. Ça m'a pris deux heures. C'est beaucoup d'agitation. Vous pouvez accélérer le processus par un facteur de quatre en ajoutant des outils.
Je l'ai testé.
Le résultat : moins de 20% de la charge avec un changement constant dans toutes les cellules ask et bid, et une cellule price, à 40 images par seconde. (La charge augmente de 5 à 7 % lorsque l'enregistrement est activé).
Je répète mon opinion - dans des conditions réelles, la charge sera de 5 à 10 % selon l'activité du marché.
Quel type de processeur avez-vous ?
Est-ce que vous écrivez l'écran en utilisant les outils MQL ?
Comment les données arrivent-elles dans le verre à des fins de simulation - à partir d'un fichier ?
Quel type de processeur avez-vous ?
Est-ce que vous écrivez l'écran en utilisant les outils MQL ?
Comment les données arrivent-elles à des fins de simulation - à partir d'un fichier ?
Le processeur est vieux - i3.
Le curseur est créé dans un éditeur visuel maison écrit en MQL. Il est accessible au public mais doit être amélioré. Il n'est pas terminé, mais des fenêtres simples peuvent être créées relativement rapidement et facilement.
Les données proviennent de l'EA. Il s'agit de nombres aléatoires envoyés aux cellules du verre par la fonction de minuterie.
Le processeur est un vieux i3.
La pile est créée dans un éditeur visuel maison, qui est écrit en MQL. Elle est disponible publiquement, mais doit être améliorée. Il n'est pas terminé, mais des fenêtres simples peuvent être créées relativement rapidement et facilement.
Les données proviennent de l'EA. Ce sont des nombres aléatoires envoyés aux cellules de la pile par la fonction de temporisation.
Il y a donc 4 threads, et 1 thread est à 25%, c'est-à-dire que la charge sur l'écran est maximale, et il y a probablement des chutes d'images.
Où peut-on consulter cet éditeur ?
Si c'est à partir d'une minuterie, alors vous ne pouvez pas estimer une charge différente. Et quel est le taux de génération de valeur par seconde ?
1. Donc 4 threads, et 1 thread est à 25%, c'est-à-dire que la charge dans la capture d'écran est maximale, et il y a probablement des chutes d'images.
2. Où peut-on consulter cet éditeur ?
3. si c'est à partir d'une minuterie, alors vous ne pouvez pas estimer une charge différente. Et quel est le taux de génération de valeur par seconde ?
1. J'ai déjà fait un bécher de travail et j'ai vérifié - la charge était de 1 - 5%. Je ne trouve pas ce code maintenant...
2.https://www. mql5.com/ru/blogs/post/733700 (Il y aura une mise à jour puissante demain, si j'ai le temps.
3. 40fps (25ms).
Pris une boucle vide avec Sleep et un shader vide. Sur une fenêtre 900x900, la charge du CPU est inférieure à 20% à 20 fps.
Cool ! Il ne reste plus qu'à maîtriser...
DirectX n'est pas vraiment intéressant, mais j'ai construit une table et WinForms en C# en 15 minutes.
A partir de MQL5, je lance un tableau avec des données double[] une fois toutes les 5 ms, je ne vois aucune charge sur le CPU, peut-être que je cherche au mauvais endroit, mais ça fonctionne bien
DirectX n'est pas vraiment intéressant, mais j'ai construit une table et WinForms en C# en 15 minutes.
Je lance un tableau de données double[] toutes les 5 ms à partir de MQL5. Je ne vois pas de charge sur le CPU, peut-être que je regarde au mauvais endroit, mais cela fonctionne bien.
Rien ne change. Veuillez effectuer le contrôle de la manière que je vous ai montrée avec le tumbler.
Et comment pouvez-vous lancer un tableau toutes les 5 ms alors que la fréquence minimale du timer est de 15 ms ?Et comment puis-je lancer un tableau toutes les 5 ms si la fréquence minimale du timer est de 15 ms ?
ce n'est pas important (16 ms est le délai minimum possible de Win), de toute façon l'appel de la dll fonctionne dans le même thread que MQL, jusqu'à ce que l'appel soit terminé MQL dormira.
je me demande aussi pourquoi la charge du processeur n'est pas visible, et bien parfois MT a jusqu'à 2% de charge, très peu - je l'ai fait tourner sur un ordinateur portable, il a un processeur faible.
ce n'est pas important (16 ms est le délai minimum possible de Win), de toute façon l'appel de la dll fonctionne dans le même thread que MQL, jusqu'à ce que l'appel soit terminé MQL dormira.
Je me demande aussi pourquoi la charge du processeur n'est pas visible, parfois elle est de 2%, très peu - j'ai utilisé un ordinateur portable, il a un processeur faible.
Et où sont les changements dans le tableau ? Est-il en train d'être redessiné ?