Diskussion zum Artikel "Grafische Interfaces X: Das Standard Chart-Steuerelement (Build 4)" - Seite 3
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Sie irren sich. Ich habe in den Kommentaren oben schon ausführlich genug beantwortet, warum das so gemacht wurde.
Jetzt verbraucht es nicht mehr so viele Ressourcen (jetzt auch in Windows 10 ). Haben Sie den Artikel (und auch die Kommentare) gelesen?
//---
P.S. Übrigens ist der CPU-Ressourcenverbrauch in verschiedenen Terminals (MT4/MT5) und Betriebssystemversionen (Windows) unter gleichen Bedingungen sehr unterschiedlich. Unter Windows 7 zeigte sich das MetaTrader 4 Terminal deutlich besser als MetaTrader 5. Leider kann ich Ihnen jetzt keine Zahlen nennen, da ich bereits komplett auf Windows 10 umgestiegen bin.
Was die Optimierung angeht, so habe ich noch nicht alle Möglichkeiten ausgeschöpft. Es gibt immer noch etwas zu optimieren und ich weiß auch, wie.
Um ein beschleunigtes Scrollen von etwas zu implementieren und um die Farbe eines Objekts unter dem Cursor fließend zu ändern, ist ein Timer notwendig. Hier ist alles richtig.
Aber es kann nicht sein, dass er im Ruhezustand bis zu 10 Prozent Ressourcenverbrauch verursacht. Das Problem liegt also woanders. Worin besteht es?
Das heißt, bei jedem Timer-Ereignis prüfen Sie die Ereignisse aller Oberflächenelemente? Und warum?
Was ist in dieser Überprüfung enthalten, das den Prozessor belasten kann?
Wenn man z.B. den Mauszeiger im Bereich eines sauberen Charts bewegt, auf dem sich überhaupt nichts befindet (grafische Objekte und MQL-Anwendungen), steigt der CPU-Verbrauch bereits auf 6-7%:
Vor dem Test:
Während des Tests:
Um einen beschleunigten Bildlauf zu implementieren und die Farbe des Objekts unter dem Cursor fließend zu ändern, ist ein Timer erforderlich. Hier ist alles richtig.
Aber es kann nicht dazu führen, dass im Ruhezustand bis zu 10 Prozent der Ressourcen verbraucht werden. Das Problem liegt also woanders. Worin besteht es?
Das heißt, bei jedem Timer-Ereignis prüfen Sie die Ereignisse aller Oberflächenelemente? Warum eigentlich?
Jetzt ist es so implementiert, dass nur in dem Moment, in dem der Cursor bewegt wird. Und das ist nur in Windows 10. In Windows 7 war dies nicht der Fall.
Und wenn Sie die von Ihnen vorgeschlagene Methode verwenden, dann werden die gleichen Kosten für die Vorbereitung eines Arrays mit den Elementen, über denen sich der Cursor jetzt befindet, ausgegeben + einige andere Probleme treten auf. Ich habe diese Methode bereits getestet und sie aufgegeben, da sie keinen wirklichen Gewinn bringt.
Es gibt noch einige andere Möglichkeiten, aber die müssen noch getestet werden. Wenn es einen Gewinn gibt, wird er in einem der nächsten Artikel vorgestellt.
Wenn man z.B. den Mauszeiger im Bereich eines sauberen Charts bewegt, auf dem sich überhaupt nichts befindet (grafische Objekte und MQL-Anwendungen), steigt der CPU-Verbrauch bereits auf 6-7%:
Vor dem Test:
Während des Tests:
Diese Tatsache kann leider nicht optimiert werden.
Die Überprüfung der Zustände von Steuerelementen bei Timer-Ereignissen (meiner Meinung nach zu häufig. Statt 16 ms. kann man auch 25 ms. einsetzen) sollte jedoch den Ressourcenverbrauch in keiner Weise erhöhen, wenn während dieser Überprüfung keine ressourcenintensive Aktion durchgeführt wird.
...
Was ist an diesem Test, das den Prozessor belasten kann?
...
Die Überprüfung der Zustände von Steuerelementen bei Timer-Ereignissen (ich denke, das ist zu häufig. Statt 16 ms. kann man auch 25 ms. einstellen) sollte jedoch den Ressourcenverbrauch in keiner Weise erhöhen,
wenn während dieser Überprüfung keine ressourcenintensive Aktion durchgeführt wird.
Jetzt ist es so implementiert, dass nur im Moment der Bewegung des Cursors. Dies ist nur in Windows 10. In Windows 7, war dies nicht der Fall.
Und wenn Sie die von Ihnen vorgeschlagene Methode verwenden, dann werden die gleichen Kosten für die Vorbereitung eines Arrays mit den Elementen, über denen sich der Cursor jetzt befindet, ausgegeben + einige andere Probleme treten auf. Ich habe diese Methode bereits getestet und sie aufgegeben, da sie keinen wirklichen Gewinn bringt.
Es gibt noch einige andere Möglichkeiten, aber die müssen noch getestet werden. Wenn es einen Gewinn gibt, wird er in einem der nächsten Artikel vorgestellt werden.
1. und hier sind Sie bereits falsch. Die Vorbereitung des Map-Arrays mit den Koordinaten und Größen der Elemente sowie die Anpassung ihrer Werte bei der Bewegung von Fenstern erhöht die Belastung des Prozessors nicht wesentlich, da die Arbeit nur bei der Bewegung des Cursors und nur beim Greifen des Fenstergriffs erfolgt. Bei allen anderen Bewegungen des Cursors wird die Funktion zur Neuberechnung der Koordinaten nicht aufgerufen.
2. Bei einer einfachen Bewegung des Cursors wird die Lokalisierungsfunktion aufgerufen, die eine Schleife durch die Karte der Elemente zieht und das Objekt unter dem Cursor findet. Dieser Vorgang ist rein rechnerisch und belastet den Prozessor nicht.
Реter Konow:
Das Vorbereiten eines Map-Arrays mit den Koordinaten und Größen der Elemente sowie das Korrigieren ihrer Werte bei Fensterbewegungsereignissen erhöht die Belastung des Prozessors nicht wesentlich, da die Arbeit nur beim Cursorbewegungsereignis und nur beim Ergreifen des Fensterhandles erledigt wird.
Deshalb ist es auch nicht sinnvoll. Das Ziel ist nicht, die Belastung des Prozessors zu erhöhen, auch wenn sie unbedeutend ist, sondern im Gegenteil, sie zu verringern. Es stellt sich heraus, dass ich mich nicht geirrt habe. )
Neuzeichnen des Diagramms zur Darstellung von Änderungen.
Warum sollte das gesamte Diagramm neu gezeichnet werden, wenn Änderungen Punkt für Punkt, bezogen auf ein bestimmtes Element, vorgenommen werden können?
Sie können die Notwendigkeit von Änderungen alle 16 ms überprüfen (die Überprüfung wird nicht geladen), aber die Änderung nur bei Bedarf auf jedes einzelne Objekt anwenden und nicht das gesamte Diagramm neu zeichnen.
Warum sollte das gesamte Diagramm neu gezeichnet werden, wenn Änderungen Punkt für Punkt in Bezug auf ein bestimmtes Element vorgenommen werden können?
Nach jeder Änderung im Diagramm müssen Sie die Funktion ChartRedraw() aufrufen, um eine sofortige Anzeige zu erhalten. Dasselbe gilt für das Zeichnen auf dem Canvas. Daher werden die Änderungen zunächst an allen Elementen vorgenommen und erst dann wird das Diagramm neu gezeichnet.
Konow-Tag:
Sie können die Notwendigkeit von Änderungen alle 16ms überprüfen (Überprüfung wird nicht geladen), aber die Änderung nur bei Bedarf auf jedes einzelne Objekt anwenden und nicht das gesamte Diagramm neu zeichnen.
Im Moment wird in der Ruhephase alle 16ms nichts neu gezeichnet. Es ist ja nicht so, dass der Benutzer mit dem Mauszeiger Kreise auf dem Diagramm ausschneidet, ohne anzuhalten. Bei der derzeitigen Implementierung übersteigt der CPU-Ressourcenverbrauch nicht 6-7 %.
Nach jeder Änderung im Diagramm müssen Sie die Funktion ChartRedraw() aufrufen, um eine sofortige Anzeige zu erhalten. Dasselbe gilt für das Zeichnen auf dem Canvas. Deshalb werden Änderungen zuerst an allen Elementen vorgenommen und erst dann wird das Diagramm neu gezeichnet.
Das ist sehr, sehr seltsam. Ich habe keinen einzigen Aufruf der Funktion ChartRedraw() in meiner Implementierung der Schnittstelle.
Ich wusste bis jetzt nicht wirklich, warum sie benötigt wird: ..... Ich arbeite mit Canvas (Bitmap-Objekten) ohne sie.
Nehmen wir an, dass die Funktion ChartRedraw() notwendig ist, - dann stellt sich heraus, dass jede Änderung jedes Objekts ein komplettes Neuzeichnen aller Objekte erfordert?