Réaliser un projet de crowdsourcing sur Canvas - page 33
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
Dans cet exemple, le taux de rafraîchissement est normal. C'est pourquoi il ne ralentit pas.
Dans le gestionnaire des tâches, je vois Metatrader (32 bits).
Le problème du traitement asynchrone des données a-t-il été résolu ?Peut-être que la raison de vos retards a à voir avec la taille du bit ?
Parce que Metatrader n'est désormais conçu que pour x64.
Et selon les développeurs, les versions 32 bits ne seront plus publiées.
Je vois Metatrader (32 bits) dans le gestionnaire des tâches.
Et le problème du traitement asynchrone des données a-t-il été résolu ?Peut-être que la raison de la lenteur est liée à la capacité numérique de votre système ?
Eh bien, Metatrader est maintenant prévu pour x64 seulement.
Et selon les développeurs, les versions 32 bits ne seront plus publiées.
Je confirme que l'exemple de Nikolaï que j'ai mentionné charge le CPU lors du déplacement de n'importe quel objet de l'exemple, surtout s'il est effectué rapidement. La charge augmente de 35 à 40 %. Le test a été effectué sur un processeur 64 bits, Windows 7 64 bits et MT5 64 bits.
Qu'entend-on par traitement asynchrone dans notre discussion ?
Je peux voir Metatrader (32 bits) dans le gestionnaire des tâches.
Et le problème du traitement asynchrone des données a-t-il été résolu ?Peut-être que la raison de vos retards réside dans la capacité en bits du système ?
En fait, Metatrader est désormais personnalisé uniquement pour x64.
Et selon les développeurs, les versions 32 bits ne seront plus publiées.
Tous ces exemples sont sur MT4.
MT5 tire beaucoup plus, mais avec un mauvais redessin (par exemple une tasse), il charge aussi le processeur (j'ai vérifié). Le problème réside dans la fréquence et la superficie des redécoupages, qu'il faut réduire par tous les moyens. Si vous devez redessiner une cellule, alors c'est la seule cellule. Sinon, c'est un gaspillage de ressources (si, par exemple, une cellule doit être redessinée 10 fois par seconde, redessiner l'ensemble de la toile "tuera" le processeur et ce ne sera pas réaliste). Cependant, c'est déjà clair.
Laissez-moi vous expliquer. Une cellule de tableau comporte trois objets : la base, le texte et l'icône. Si le contenu d'une cellule change, nous devons effectuer trois boucles du canevas. Au premier cycle, nous redessinons la base, au deuxième cycle - le texte, au troisième - l'icône. C'est comme si on avait triplé la surface de la cellule. Si vous continuez à redessiner l'ensemble du kanvas dans cette optique, vous obtiendrez un sérieux ralentissement. Il est donc nécessaire de prendre en compte le nombre de cycles sur la surface de la toile à redessiner. Vous ne le voyez peut-être pas dans les primitives simples, mais il devient apparent dans les éléments complexes. Certains éléments comprennent 10 objets(une boîte d'entrée avec des boutons ou une liste de sortie ou une plate-forme de fenêtre) et il est possible de calculer combien de cycles sur un tableau de kanvas doivent être effectués lorsqu'on les repeint. Heureusement, ce redécoupage ne nécessite pas un taux de répétition élevé.
Le problème du traitement asynchrone n'a pas été résolu. Il y a eu quelques idées, mais aucune solution n'a encore été trouvée.
Dans l'ensemble, si nous voulons créer une interface graphique sur un canevas, nous devons la réaliser à partir d'éléments redessinables séparément. Sinon, le programme atteindra rapidement sa limite et les retards sur les opérations simples seront alors perceptibles.
Qu'entend-on par traitement asynchrone des données dans notre discussion ?
Si j'ai bien compris, en termes simples, il s'agit d'un système asynchrone (chasse aux ressources) ou multithread (ressources dédiées).
Je n'ai pas regardé le code des exemples de Nikolay mais en raison de l'absence d'asynchronie et de multithreading dansMetatrader, le code de redécoupage des pixels est exécuté de manière synchrone.
Et le traitement des données de sortie de Petera est très probablement effectué de manière synchrone également. Et dans les deux cas, il est probable que tout cela soit encore traité par cycles.
. Cela augmente la charge du processeur. Pour une réponse rapide avec moins de charge à la fois, le traitement des données et le redécoupage doivent être mis en parallèle.
Si j'ai bien compris, en termes simples, il s'agit de l'asynchronisme (course aux ressources) ou du multithreading (ressources dédiées).
Je n'ai pas regardé le code des exemples de Nikolay mais en raison de l'absence d'asynchronie et de multithreading dansMetatrader, le code de redécoupage des pixels est exécuté de manière synchrone.
Et le traitement des données de sortie de Petera est très probablement effectué de manière synchrone également. Et dans les deux cas, tout cela est susceptible d'être traité en boucle.
Cela augmente la charge sur le processeur. Pour une réponse rapide avec moins de charge à la fois, le traitement des données et le redécoupage doivent être mis en parallèle.
Pas vraiment)) Laissez-moi clarifier : j'ai le moteur qui se connecte à l'application utilisateur via une ressource. En d'autres termes, l'application utilisateur effectue ses calculs dans son thread et transmet les données au moteur (portant l'interface graphique), qui peut se trouver sur un graphique différent. Il gère les événements liés aux paramètres et les transmet à l'interface graphique. En d'autres termes, le traitement est divisé en deux fils. Cependant, ce ne sera pas le cas dans le constructeur que je vais afficher. L'application inclura le moteur à l'intérieur d'elle-même et tout sera dans un seul fil. Mais la charge sur le processeur sera la même. La dépendance de la vitesse par rapport à la séquence des fonctions ne fera que s'accroître.
Pas vraiment)) Laissez-moi clarifier : j'ai le moteur qui se connecte à l'application utilisateur via une ressource. En d'autres termes, l'application utilisateur effectue ses calculs dans son thread et transmet les données au moteur (portant l'interface graphique), qui peut se trouver sur un graphique différent. Il gère les événements liés aux paramètres et les transmet à l'interface graphique. En d'autres termes, le traitement est divisé en deux fils. Cependant, ce ne sera pas le cas dans le constructeur que je vais afficher. L'application inclura le moteur à l'intérieur d'elle-même et tout sera dans un seul fil. Mais la charge sur le processeur sera la même. La dépendance de la vitesse par rapport à la séquence d'exécution des fonctions ne fera que s'accroître.
C'est reparti... promesses, annonces, bavardages.
même déjà oublié - "kernel-engine" a été publié comme un logiciel décent ? ou comme une merde sous forme de pièces jointes aux commentaires
Si je comprends bien, en termes simples, il s'agit d'un système asynchrone (course aux ressources) ou multithreading (ressources dédiées).
Je n'ai pas regardé le code des exemples de Nikolaï, mais en raison de l'absence d'asynchronie et de multithreading dansMetatrader, le code de redécoupage des pixels est exécuté de manière synchrone.
Et le traitement des données de sortie de Petera est très probablement effectué de manière synchrone également. Et dans les deux cas, tout cela est susceptible d'être traité en boucle.
Cela augmente la charge sur le processeur. Pour une réponse rapide avec moins de charge à la fois, le traitement des données et le redécoupage doivent être mis en parallèle.
Toutes les opérations dans MT sont strictement synchrones et cela ne peut pas vraiment être changé à moins que les développeurs ajoutent des threads à l'application.
Il est assez surprenant que les développeurs essaient d'étendre les fonctionnalités de MT en termes de travail avec des bases de données, avec python, avec sharpe... mais ils proposent de faire tout ça dans le même fil... C'est juste incroyable.
C'est reparti... promesses, annonces, bavardages...
J'ai même oublié - le "kernel-engine" a-t-il été publié comme un logiciel décent ? ou comme une merde, en tant que pièces jointes à des commentaires ?
C'est bien pour toi. Je m'inspire de la lutte contre des gens comme vous, et ils perdent toujours.)) Tu me donnes de l'énergie et tu ne t'en rends pas compte.
C'est reparti... promesses, annonces, bavardages...
J'ai même oublié - est-ce que le "kernel-engine" a été publié comme un logiciel décent ? ou comme une merde sous la forme de pièces jointes aux commentaires
Max, sois discret.
Pas vraiment)) Laissez-moi clarifier : j'ai le moteur qui se connecte à l'application utilisateur via une ressource. En d'autres termes, l'application utilisateur effectue ses calculs dans son thread et transmet les données au moteur (portant l'interface graphique), qui peut se trouver sur un graphique différent. Il gère les événements liés aux paramètres et les transmet à l'interface graphique. En d'autres termes, le traitement est divisé en deux fils. Cependant, ce ne sera pas le cas dans le constructeur que je vais afficher. L'application inclura le moteur à l'intérieur d'elle-même et tout sera dans un seul fil. Mais la charge sur le processeur sera la même. C'est juste que la dépendance de la vitesse par rapport à la séquence des fonctions sera plus grande.
J'ai compris le point, application séparée, interface graphique séparée.
Mais le traitement des données de sortie dans l'interface graphique est de toute façon effectué de manière synchrone.
Ainsi, par exemple, l'application envoie 10000 éléments au GUI et le GUI traite tous ces éléments de manière séquentielle.
C'est là le problème. Il est nécessaire de paralléliser le traitement des éléments entrants et leur sortie dans l'interface graphique. Base, texte, icône.
D'autant plus qu'il y a trois cycles par cellule.