Toile et étiquettes - page 8
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
Oui, je n'avais pas vu que c'était un tableau interne.
A en juger par le profilage, la source des freins, quand on fait défiler le graphique, se trouve dans cette ligne :
Profilage avec défilement actif :
Profilage avec mouvement actif de la souris sans défilement (sans que le LKM soit pressé) :
ZS : Donc la source des freins n'est pas les kanvas après tout, mais les objets.
Malheureusement, mon profilage de ce code ne donne rien. b2828.
Malheureusement, mon profilage de ce code ne donne rien. b2828.
On dirait qu'ils n'ont pas encore fini le profileur. J'avais l'habitude d'avoir un blanc parfois aussi. Mais maintenant ça marche.
Ça marche aussi avec celui-ci.
C'est la mauvaise approche. D'autant plus 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.
Je vois. Donc,en plus de mesurer dans le testeur, vous devrez mesurer dans la carte.
Je n'ai pas dit ça.
J'ai signalé les erreurs évidentes et expliqué le fonctionnement du système de rendu.
Eh bien, j'ai tout faux. Désolé.
On dirait qu'ils n'ont pas encore fini le profileur. J'avais l'habitude d'avoir un blanc parfois aussi. Mais maintenant ça marche.
celui-ci fonctionne aussi.
Je n'ai rien sur la b2830 aussi.
avec le modèle d'événement 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 exactement la même charge augmentait si je déplaçais la souris rapidement - je doute que Win10 ait radicalement changé le modèle d'événement, plus probablement le gestionnaire de tâches fonctionne d'une manière différente.
Vin10. Voici le tracé lorsque je déplace la souris dans la fenêtre de saisie de ce message texte avec le LKM maintenu enfoncé.
Voici sans le LKM
Vin10. Voici le tracé lorsque je déplace la souris dans la fenêtre de saisie de ce message texte avec le LKM enfoncé.
Voici sans le LKM.
pas évident
Voici le bureau virtuel avec Win7 - si je ne bouge pas la souris, cela charge le CPU de 3-4%.
si la souris bouge rapidement - 11-14% de charge
Je veux dire que la file d'attente des messages dans Win a toujours besoin d'être traitée, mais c'est des cycles CPU supplémentaires - google "C++ windows window" - n'importe quel manuel pour écrire une application windows en C++ en utilisant WinAPI, lisez là à propos du gestionnaire de messages.
non illustratif.
à partir d'une machine virtuelle sous Win7 - si vous ne bougez pas la souris, 3-4% de charge sur le CPU
si la souris bouge rapidement - 11-14% de charge CPU
Je veux dire que la file d'attente des messages dans Win doit toujours être traitée et cela prend des cycles de CPU supplémentaires - google "c++ windows window".
Pour exprimer les chiffres plus clairement, je ne fais rien - 10-15 fluctue, 17-30 quand je bouge.
Mais est-ce que cela doit entraîner un ralentissement de 2 fois de OnTimer, non bien sûr, sauf à 95-99% de charge.
Un manuel sur l'écriture d'une application Windows en C++ utilisant WinAPI, lisez-le à propos du gestionnaire de messages.
Mais est-ce que cela doit entraîner le doublement du ralentissement de OnTimer, non, bien sûr, sauf pour une charge de 95-99%.
timer est aussi un événement WinAPI, mais je doute que chaque programme MQL souscrive au timer du système - il émule l'environnement MQL(machine virtuelle).
Le gestionnaire de messages prend la part du CPU et ainsi de suite, mais n'est pas utilisé quand il n'y a pas de file d'attente. Pour les processus MT, il ne devrait pas y avoir de coupure du temps CPU à cette charge.
Il y a toujours une file d'attente dans une fenêtre active. C'est une supposition commune de feuille de café comment cette file d'attente est distribuée par le terminal entre les graphiques et ensuite entre les programmes MQL.
bien, en fin de compte - pour obtenir un mode de monopole et de ne pas traiter les messages - pas beaucoup d'options, le premier qui vient - application exclusive en mode plein écran, mais c'est une autre histoire, comme si la "bataille pour les ressources PC", alors vous avez juste besoin d'une API pour aller à l'échange et écrire votre application, et là, enregistrer la fenêtre ou non
ok, je ne suis pas intéressé par la recherche de pics de charge CPU - tant que nous sommes dans Vin, tout peut arriver, et cela me convient généralement.
timer est également un événement WinAPI, mais je doute que chaque programme MQL souscrive au timer du système - il émule l'environnement MQL(machine virtuelle).
ce n'est pas un fait. si vous vous rappelez qu'il y avait un bug avec le timer et le nombre de handlers dans le terminal, cela suggère indirectement que chaque timer dans MT pourrait bien être un wineplay système