Galerie der in MQL geschriebenen UIs - Seite 57

Neuer Kommentar
 
Реter Konow #:

@Nikolai Semko

...und 50ms Vollbild funktioniert bei mir auch. ....

Der Test ist sehr grob. Ich habe die Geschwindigkeit beim Öffnen eines Fensters mit drei fast gleich großen Leinwänden (Icon-Fenster) gemessen und kam auf ~70 ms. Wenn man die Fläche aller Leinwände (ohne Elemente) zusammenzählt, dann entspricht das in etwa der Fläche des Laptop-Bildschirms 17". Dies beinhaltet nicht die Fläche der Basis der Elemente und die Symbole selbst, die oben auf der Leinwand gezeichnet wurden. Also ja, ~50ms, um die Fläche eines fiktiven Vollbildschirms mit Farbe zu füllen. Ich habe es noch nicht genau gemessen. Warum, wenn der "Elefant" genau in der Mitte des Raumes steht? :)

 
Ich sprach von 50 ms bei einer überlasteten und nicht optimierten Schnittstelle. 3-10 ms sind normal.

Führen Sie dennoch ein Profiling durch. Sie werden eine Menge Entdeckungen in Ihrem Code machen.
 
Nikolai Semko #:
Ich sprach von 50 ms bei einer überlasteten und nicht optimierten Schnittstelle. 3-10 ms sind normal.

Führen Sie dennoch ein Profiling durch. Sie werden eine Menge Entdeckungen in Ihrem Code machen.
Nikolai, das sind nur Zahlen. Du brauchst genaue Angaben. Wenigstens die Bildschirmgröße. Dann können Sie genaue Berechnungen anstellen.
 
Das Zeichnen auf der Leinwand ist eine Array-Initialisierung. Es ist einfach, die maximale Geschwindigkeit herauszufinden - die Funktion mit der Array-Füllschleife wird sie offenbaren. Die Größe des Arrays sollte der Summe der Pixel des bedingten Bildschirms entsprechen.
 
Du bist wie Stirlitz, der nicht zum Kartoffelacker gehen wollte.
Mach das Profiling...
 
Nikolai Semko #:
Du bist wie Stirlitz, der nicht zum Kartoffelacker gehen wollte.
Mach das Profiling...
Ich habe es getan. Ich schicke dir ein Gif.
 


Sie benötigen eine eingehende Untersuchung der Zyklen innerhalb des Zeichenblocks. Ein oberflächliches Profiling gibt kein vollständiges Bild. Aber es ist schon klar, worum es geht. Ich schrieb hier

. Ich denke, ich liege nicht falsch.

(Entwurfsversion des Zeichenblocks, den ich für Tests verwende)
 
Реter Konow #:

...

Ich habe eine Idee, wie man den Code ändern und das Rendering um das 2 oder 3fache beschleunigen kann. Aber ich werde es nach der Hauptarbeit tun. ...

Ich habe die Komplexität der Aufgabe und den Wert des Endergebnisses analysiert.

Fazit: Es macht keinen Sinn, es zu tun.

Es macht keinen Sinn, das erste Zeichnen zu beschleunigen. 15 Fenster mit komplexen Grafiken und Bildlaufleisten in anderthalb Sekunden zu erstellen, ist ein normales Ergebnis. Die erste Zeichnung kann vor den Augen des Benutzers verborgen werden, indem sie vor dem Öffnen der Fenster ausgeführt wird. Optisch erscheinen die Fenster dann sofort nach einer halben Sekunde Pause. Natürlich nur, wenn er 15 Fenster auf einmal öffnen will, was unwahrscheinlich ist.

Sie müssen die Rückseite des Fensters nicht zeichnen. Es gibt einen Gewinn von ~20ms. Das klingt nicht beeindruckend.

Letzte Woche wurde das Wichtigste erreicht: die Verwendung gespeicherter Bilder bei allen Ereignissen außer dem ersten Build. Dies ist ein enormer Gewinn an Schnittstellengeschwindigkeit.

Der Rest der Verzögerungen hat mit dem Neuzeichnen von Fenstern zu tun, wenn sich der Fokus ändert, oder mit unnötigen Aufrufen. Das lässt sich leicht beheben. Ich möchte nicht, dass dieser große Gewinn wegen der Ladezeit, die nicht so wichtig ist, ignoriert wird. Ich habe jedoch meinen eigenen Schwerpunkt verlagert. Das sollten Sie auch.

Hier schließe ich die Frage nach der Geschwindigkeit des ersten Renderings, weil sie für die aktuelle Entwicklung irrelevant ist.

Nächstes Update am Sonntag. Ich werde einen Motor mit einem konzeptionell vollständigen Mechanismus der Software-Interaktion mit dem Benutzerprogramm ausrollen.
 
Реter Konow #:
Ich analysierte die Komplexität der Aufgabe und den Wert des Endergebnisses.

Die Schlussfolgerung war, dass es keinen Sinn machte.

Die Erstellung von 15 Fenstern mit komplexen Grafiken und Bildlaufleisten in anderthalb Sekunden ist ein normales Ergebnis. Es ist möglich, die erste Grafik vor dem Öffnen des Fensters zu zeichnen, so dass sie vom Benutzer nicht gesehen wird. Visuell erscheint das Fenster sofort nach einer halben Sekunde Pause. Wenn der Benutzer 15 Fenster gleichzeitig geöffnet haben möchte, ist dies natürlich unwahrscheinlich.

Sie müssen die Rückseite des Fensters nicht zeichnen. Es gibt einen Gewinn von ~20ms. Das klingt nicht sehr beeindruckend.

Letzte Woche haben wir unser Hauptziel erreicht: die Verwendung gespeicherter Bilder für alle Ereignisse außer dem ersten Build. Das ist ein enormer Geschwindigkeitsgewinn für die Schnittstelle.

Der Rest der Verzögerungen hing mit dem Neuzeichnen des Fensters bei Fokuswechsel oder unnötigen Aufrufen zusammen. Dies ist leicht zu beheben. Ich möchte diese wichtige Verbesserung nicht wegen der Ladezeiten ignorieren, die nicht so wichtig sind. Ich habe jedoch meinen Schwerpunkt verlagert. Sie sollten

Hier habe ich das erste Problem mit der Rendergeschwindigkeit beendet, weil es für die aktuelle Entwicklung nicht relevant oder wichtig ist.

Das nächste Update ist am Sonntag. Ich werde einen Motor mit einem konzeptionell vollständigen Mechanismus der Interaktion zwischen der Software und dem Benutzerprogramm vorstellen.

Ja, es ist sehr wichtig, zuerst eine voll funktionsfähige Software herauszubringen.

 
hini #:

Ja, es ist wichtig, zuerst ein vollständiges Programm zu veröffentlichen.

Das werde ich tun.
1...505152535455565758596061626364...71
Neuer Kommentar