Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 19
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
.
Hier ist das Video, das ich zu veröffentlichen versprochen habe. Die Bildqualität ist schlecht, aber das hindert Sie nicht daran, die Reaktionsverzögerungen zu erkennen.
Tatsächlich gibt es im Terminal weniger Verzögerungen. Wenn der Rekorder eingeschaltet ist, ist alles doppelt so langsam. Auch der Prozessor wird viel mehr belastet.
Es ist also nicht möglich, aus diesem Video eine völlig objektive Vorstellung von der Reaktionsgeschwindigkeit zu gewinnen, aber es zeigt deutlich ein Muster zwischen der Aktualisierungsrate des Fensters und der Fenstergröße.
(Deshalb habe ich mehrere Fenster in verschiedenen Größen gemacht.)
Ich glaube, ich habe den genauen Grund für die verlangsamte Bildreaktion gefunden. Es ist der konstante Aufruf der Funktion ColorToARGB(). Bei jedem Ereignis und bei jedem Pixel rufe ich diese Funktion auf. Anstatt die Farben einmal zu berechnen und dann fertig zu verwenden, berechne ich sie immer wieder neu.
Ich glaube, das ist der Punkt.
P.S. Ich habe vergessen hinzuzufügen, dass die Gesamtzahl der Objekte in allen Fenstern 35 beträgt.
.
Hier ist das Video, das ich zu veröffentlichen versprochen habe. Die Bildqualität ist schlecht, aber das hindert Sie nicht daran, die Reaktionsverzögerungen zu erkennen.
Tatsächlich gibt es im Terminal weniger Verzögerungen. Wenn der Rekorder eingeschaltet ist, ist alles doppelt so langsam. Auch der Prozessor wird viel mehr belastet.
Daher ist es nicht möglich, aus diesem Video eine völlig objektive Vorstellung von der Reaktionsgeschwindigkeit zu gewinnen, aber ich kann eindeutig ein Muster zwischen der Aktualisierungsrate des Fensters und der Fenstergröße erkennen.
(Deshalb habe ich mehrere Fenster in verschiedenen Größen gemacht.)
Ich glaube, ich habe den genauen Grund für die verlangsamte Bildreaktion gefunden. Es ist der konstante Aufruf der Funktion ColorToARGB(). Bei jedem Ereignis und bei jedem Pixel rufe ich diese Funktion auf. Anstatt die Farben einmal zu berechnen und dann fertig zu verwenden, berechne ich sie immer wieder neu.
Ich glaube, das ist der Punkt.
P.S. Ich habe vergessen hinzuzufügen, dass die Gesamtzahl der Objekte in allen Fenstern 35 beträgt.
Ist es möglich, einen Blick auf den Quellcode zu werfen? Für mich, für meine Erfahrung.
Ist es realistisch, das Rendering in Canvas mit OpenCL zu beschleunigen?
Ja. OCL bietet die Möglichkeit, die Verarbeitung zu parallelisieren und mit Vektoren zu arbeiten - dies beschleunigt den Rendering-/Overlay-Prozess.
Lesen Sie mehr über die Verwendung von Vektoren in Mathemat's Artikel https://www.mql5.com/ru/articles/407
Ja. OCL bietet die Möglichkeit, die Verarbeitung zu parallelisieren und mit Vektoren zu arbeiten - dies beschleunigt den Zeichen-/Layering-Prozess.
Lesen Sie mehr über die Verwendung von Vektoren in Mathemat's Artikel https://www.mql5.com/ru/articles/407
Haben Sie die Geschwindigkeit von Erase() aus CCanvas und der PixelSet()-Schleife aus OpenCl verglichen? Theoretisch kann man mit einer guten Beschleunigung dummen Zeichencode ohne Zwischenspeicherung von Zwischenergebnissen und andere Komplexitäten erstellen.
Übrigens, mischen Sie die Schichten nach dieser Formel?
Ja, die Formel stammt von wikipedia, für jede Farbkomponente: Ergebnis = Hintergrund + (Vordergrund - Hintergrund) * Alpha;
Übrigens, es gibt ein Problem mit Erase in OCL. Es gibt kein Analogon von memset (im Gegensatz zu CUDA). Deshalb muss ich jetzt im Host ein Erase durchführen und das bereinigte Array über CLBufferWrite kopieren, was sicherlich nicht schneller ist als ein einfaches Erase.
Andererseits habe ich versucht, ein Aufgabenfeld für Arbeitseinheiten zu erstellen, indem ich 1 Punkt in das Feld geschrieben habe, aber ich kann mich nicht mehr an die Geschwindigkeit erinnern - es schien langsamer zu sein als die vorherige Methode.
Und in OCL 1.2 gibt esclEnqueueFillBuffer(), die das tut => nach MQL-Syntax sollte es CLBufferFill()sein
Dieser Wrapper ist jedoch nicht implementiert (da Version 1.1 portiert wird).
Ja, die Formel stammt von wikipedia, für jede Farbkomponente: Ergebnis = Hintergrund + (Vordergrund - Hintergrund) * Alpha;
Übrigens, es gibt ein Problem mit Erase in OCL. Es gibt kein Analogon von memset (im Gegensatz zu CUDA). Deshalb muss ich jetzt im Host ein Erase durchführen und das bereinigte Array über CLBufferWrite kopieren, was sicherlich nicht schneller ist als ein einfaches Erase.
Andererseits habe ich versucht, ein Aufgabenfeld für Arbeitseinheiten zu erstellen, indem ich 1 Punkt in das Feld geschrieben habe, aber ich kann mich nicht mehr an die Geschwindigkeit erinnern - es schien langsamer zu sein als die vorherige Methode.
Und in OCL 1.2 gibt esclEnqueueFillBuffer(), die das tut => nach MQL-Syntax sollte es CLBufferFill()sein
Dieser Wrapper ist jedoch nicht implementiert (da Version 1.1 portiert wird).
Im englischen Vic ist die Formel interessanter, man kann zwei durchscheinende Schichten mischen. Es ist möglich, eine durchsichtige Oberfläche und andere hübsche Dinge zu erstellen.
In meinem Fall brauchte ich das nicht, da sich alles richtig mischt. Alles, was sich unter der Schicht A befindet, kann als Substrat betrachtet werden, auch wenn sich darüber die Schicht B befindet, durch die das Substrat selbst durchscheint.