Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 18

 

Leider sind die heutigen Versuche, das Problem der verzögerten Bildaktualisierung durch Speichern eines Arrays mit einer "digitalen Maske" zu lösen, nicht erfolgreich gewesen. Es ist aber auch kein Misserfolg. Es war einfach nicht möglich, eine endgültige Schlussfolgerung über die Ursache der Verzögerung zu ziehen und eine globale Lösung für das Problem zu finden.

Bei der Überlegung, wie man das fertige Bild im Speicher ablegen und mit seinen Bereichen arbeiten kann, bin ich verschiedene Möglichkeiten durchgegangen. Diejenigen, die ich für eine gute Lösung hielt, erwiesen sich bei näherem Nachdenken jedoch als unpraktisch.

Und so - meine Schlussfolgerungen:

1. Wenn Sie Bilder in Arrays speichern wollen, sollten Sie eine Menge Arrays haben. Das heißt, jede Ressource benötigt ein eigenes Feld mit konstantem Speicher. In meiner Implementierung könnte die Anzahl der Leinwände (Ressourcen, Leinwände) um ein Vielfaches größer sein als die Anzahl der Fenster.

Ich werde erklären, warum:

In einigen Fällen ist dieser Ansatz viel praktischer als das Zeichnen aller Fensterobjekte auf einem Canvas, z.B. beim Scrollen einer Tabelle in einem "Sichtfeld (VEIW BOX)"-Element, ist es praktisch, Tabellenelemente auf einem separaten Canvas innerhalb dieses Elements zu platzieren und diesen Canvas als ganzes Objekt zu scrollen. Die Bildlaufgeschwindigkeit ist schneller, so dass jedes dieser Elemente einen eigenen Kanvas enthält. Andernfalls muss das gesamte im Speicher abgelegte Bild des Fensters überschrieben werden. Das wird auf jeden Fall viel länger dauern.

Außerdem ist es ziemlich unbequem, alle Fenster auf eine Leinwand zu zeichnen, wie kann man sie dann verschieben? Angenommen, wir erstellen eine "Mega"-Leinwand für den gesamten Diagrammbereich. Alle unsere Fenster werden darauf gezeichnet sein. Nachdem wir die Fenster auf der Leinwand gezeichnet haben, werden wir versuchen, sie zu verschieben, aber dazu müssen wir das gesamte Bild dieser einzelnen "Mega"-Leinwand neu schreiben. Das Bild ist sehr groß und die Menge der zu überschreibenden Werte ist enorm. Selbst wenn das Bild gespeichert wird, müssen wir bei jeder Cursorverschiebung einen großen Bereich im Speicher überschreiben. Das ist natürlich ineffizient.

2. Als ich über eine Methode zum Speichern von Bildern und zum Arbeiten mit ihnen nachdachte, fiel mir die Funktion "ResourceReadImage()" ein. Diese Funktion liest die Ressource und setzt ihre numerische Maske in ein Array. Es ist also nicht notwendig, das Bild zu speichern, denn es ist bereits auf der Terminalebene gespeichert und kann mit dieser Funktion abgerufen werden. Dies vereinfacht die Aufgabe erheblich. Und so: Sie können das Bild mit "ResourceReadImage()" abrufen, es in ein Array übertragen und dann die Werte des Arrays ändern, die sich auf ein bestimmtes Element beziehen, das "unter dem Ereignis" der Schnittstelle liegt. Dieser Ansatz ist meiner Meinung nach viel attraktiver. Es stellt sich jedoch die Frage, wie lange es dauern wird , das Array mit Hilfe von "ResourceReadImage()" mit einem Bild zu füllen. Dies hängt natürlich auch von der Fläche des Kanvas ab. Vielleicht ist sie optisch gar nicht wahrnehmbar, aber in jedem Fall sollte sie nur einmal geladen werden, während sich der Cursor auf einem bestimmten Kanvas-Bereich befindet. Wenn Sie zu einer anderen Leinwand wechseln, können Sie das Feld löschen und das Bild der anderen Leinwand hochladen.

Wie auch immer, ich habe im Moment keine endgültige Lösung. Ich muss mit der Funktion "ResourceReadImage()" versuchen, die Ladezeit des Bildes zu messen und ein System für die Arbeit mit Bildbereichen im Array zu entwickeln.

Das ist alles für den Moment.
 

Реter Konow:

In meiner Implementierung der Schnittstelle kann die Anzahl der Leinwände (Ressourcen, Leinwände) um ein Vielfaches größer sein als die Anzahl der Fenster, was in der Praxis erforderlich ist.

Ihre Praxis erfordert dies.

Aber wie Ihre eigene Praxis zeigt, ist diese Umsetzung in Bezug auf Geschwindigkeit und Bequemlichkeit mangelhaft.

Wie die Praxis zeigt, ist es bequemer, mit einer Leinwand zu arbeiten, und es gibt keine Hindernisse, vorübergehend ein Tabellenfenster auf die Leinwand zu zeichnen und dann BitBlt auf der Hauptleinwand zu verwenden.

Ich weiß nicht, warum Sie geplant haben "es muss viele Arrays geben. "Aber Sie sehen selbst, dass es eine Sackgasse ist.

 
o_O:

Das ist es, was Ihre Praxis erfordert.

Aber wie Ihre eigene Praxis zeigt, ist eine solche Umsetzung im Hinblick auf Geschwindigkeit und Bequemlichkeit mangelhaft.

Wie die Praxis zeigt, ist es bequemer, mit einer Leinwand zu arbeiten, und es gibt keine Hindernisse, vorübergehend ein Tabellenfenster auf die Leinwand zu zeichnen und dann BitBlt auf der Hauptleinwand zu verwenden.

Ich weiß nicht, warum Sie geplant haben "es muss viele Arrays geben, außerdem - unendlich viele... "Aber Sie sehen selbst, dass es eine Sackgasse ist.

Vielleicht haben Sie eine bessere Lösung gefunden. Ich würde es gerne sehen. Wenn Sie können, posten Sie ein Gif, wo man deutlich sehen kann, wie schnell die Elemente auf einen Klick reagieren. Ich werde mein Gif danach posten. Sie werden sehen, wovon ich spreche, und ich werde sehen, wovon Sie sprechen.
 
Реter Konow:
Vielleicht haben Sie eine bessere Lösung gefunden. Ich würde es gerne sehen. Wenn Sie können, posten Sie ein Gif, in dem Sie die Reaktionsgeschwindigkeit der Elemente beim Anklicken deutlich sehen können. Ich werde mein Gif danach posten. Sie werden sehen, wovon ich spreche, und ich werde sehen, wovon Sie sprechen.

Ich habe das Video nicht aufgenommen, aber ich schicke Ihnen ein Beispiel, eine schnelle Skizze.

Es gibt 600 Dropdown-Listen.

Bewegen Sie die Maus - mit jedem Ereignis und jeder Farbänderung wird die gesamte CCanvas neu gezeichnet. Sie erhalten diese Interaktivität.

Sie können die endgültige Größe in den Bitmap-Eigenschaften sehen - 1500x600 px (im Vergleich zu Ihren 800x500 und 250ms Verzögerung). Das entspricht 900.000 Pixeln, die alle sofort neu gezeichnet werden, so dass keine Sekunde vergeht.

Jede Liste wird zunächst auf einer eigenen Leinwand in ihrer eigenen Größe gerendert (damit sie nicht überläuft) und dann in das Gesamtbild eingepflügt. Wir haben also 600 ResourceCreate-Aufrufe pro Mausereignis.
Das bedeutet, wie Sie an der Reaktionsgeschwindigkeit sehen können, dass die Bilder ausreichen, um Zeichentrickfilme zu zeigen.

MT-Entwickler gaben zufriedenstellendes Werkzeug ohne Lags (ich meine ResourceCreate Bitmaps)

Dateien:
Gtest.ex5  150 kb
 
o_O:

Ich habe das Video nicht aufgenommen, aber ich sende Ihnen ein Beispiel.

Es gibt 600 Dropdown-Listen.

Bewegen Sie die Maus - bei jedem Ereignis und Farbwechsel wird die gesamte CCanvas neu gezeichnet.

Sie können die endgültige Größe in den Bitmap-Eigenschaften sehen - 1500x600 px (im Vergleich zu Ihren 800x500 und 250ms Verzögerung). Das entspricht 900.000 Pixeln, die alle sofort neu gezeichnet werden, so dass keine Sekunde vergeht.

Jede Liste wird zunächst auf einer eigenen Leinwand in ihrer eigenen Größe gerendert (damit sie nicht überläuft) und dann in das Gesamtbild eingepflügt. Wir haben also 600 ResourceCreate-Aufrufe pro Mausereignis.
Das bedeutet, wie Sie an der Reaktionsgeschwindigkeit sehen können, dass die Bilder ausreichen, um Zeichentrickfilme zu zeigen.

MT-Entwickler gaben zufriedenstellendes Werkzeug ohne Lags (ich meine ResourceCreate Bitmaps)

Nun, das ist gut genug, um Ihre Worte zu bestätigen... Ich wiederhole jedoch meine Frage von gestern: Wird das Bild gespeichert?

Ich habe gestern gesagt, dass es keine Verzögerung gibt, wenn Sie das einmal erstellte Bild speichern, nur einen bestimmten Bereich darin ändern und sofort an ResourceCreate() senden. Ihre Methode, mit Leinwand zu arbeiten, ist mir noch nicht bekannt. Ich weiß noch nicht, wie Sie zu diesem Ergebnis gekommen sind.

Ich habe eine weitere Frage: mit CCanvas Klasse zu erstellen oben Beispiel, könnten Sie das Prinzip der Implementierung dieser Lösung beschreiben?

Vielleicht werden dort bitweise Operationen verwendet, um das Bild zu verarbeiten. Ich habe mich noch nicht mit ihnen befasst.


P.S. Aber ich löse Geheimnisse gerne selbst...) Ich werde dieses Problem trotzdem lösen.

 
Реter Konow:
Kannst du das Implementierungsprinzip dieser Lösung beschreiben, indem du die CCanvas-Klasse für das obige Beispiel verwendest?

das Prinzip ist linear - gehen Sie die Liste der Steuerelemente durch und zeichnen Sie jedes an einer gewünschten Position auf der Leinwand.
Zum Zeichnen der Steuerelemente werden nur CCanvas-Funktionen verwendet. Ich habe nichts von mir selbst gezeichnet.

z.B. werden die Listen in eingeklappter Form als zwei Elemente gezeichnet - in diesem Beispiel Schaltflächen (dies ist in anderen Stilen anders)
werden die Canvas-Funktionen aufgerufen
FillRectangle // Hintergrund füllen
Rectangle // Rahmen um
FontSet // Schriftart setzen
TextOut // Ausgabetext

Es ist möglich, dass dort bitweise Operationen zur Verarbeitung des Bildes verwendet werden.

Nein.

Wird das Bild gespeichert?

ja, in dem Array, das sich in CCanvas befindet

Wenn Sie ein einmal erstelltes Bild speichern, nur einen bestimmten Bereich darin ändern und es sofort an ResourceCreate() senden, kommt es zu keiner Verzögerung.

nicht ganz richtig.

In meinem Beispiel wird das gesamte Feld neu gezeichnet. Bei jedem erneuten Zeichnen wird das Array geleert und die gesamte Leinwand neu gefüllt. Dann wird ResourceCreate aufgerufen.

 
o_O:

In meinem Beispiel wird das gesamte Feld neu gezeichnet. Das Array wird geleert und die gesamte Leinwand wird bei jedem erneuten Zeichnen neu gefüllt. Dann wird ResourceCreate aufgerufen.

Vielen Dank für die ausführliche Antwort.

Seltsamerweise ist es bei mir genauso. Das Bild des gesamten Fensters wird bei jedem Schnittstellenereignis vollständig neu erstellt. Sie wird in einem lokalen eindimensionalen Array erstellt, das nach Abschluss dieses Vorgangs an ResourceCreate gesendet wird.

Ich weiß nicht, warum es mich ausbremst... Morgen werde ich ein Gif veröffentlichen, in dem ich den Zusammenhang zwischen der Fenstergröße und der Reaktionsgeschwindigkeit der Elemente zeige.

Das ist alles sehr seltsam...

 
Реter Konow:

Vielen Dank für die ausführliche Antwort.

Seltsamerweise ist es bei mir genauso. Das Bild des gesamten Fensters wird bei jedem Schnittstellenereignis vollständig neu erstellt. Sie wird in einem lokalen eindimensionalen Array erstellt, das nach Abschluss dieses Vorgangs an ResourceCreate gesendet wird.

Ich weiß nicht, warum es mich ausbremst... Morgen werde ich ein Gif posten, in dem ich die Abhängigkeit zwischen der Fenstergröße und der Reaktionsgeschwindigkeit der Elemente zeige.

Das ist alles sehr seltsam...

Wenn es Ihnen nichts ausmacht, machen Sie eine Gif-Animation mit CPU-Last im Task-Manager. Oder es ist einfacher, eine kompilierte Datei zu posten, wieSergeev es getan hat. So können Sie es selbst testen.
 
Anatoli Kazharski:
Wenn es nicht schwierig ist, machen Sie eine Gif-Animation mit CPU-Last im Task-Manager. Oder es ist einfacher , die kompilierte Datei zu posten, wie esSergejew getan hat. So kann man es selbst testen.

OK, ich werde ein Video von der CPU-Last machen. Aber was die kompilierte Datei betrifft, so werde ich sie noch nicht veröffentlichen.

Ich schäme mich nur sehr für Wanzen...))

Ich verspreche, sie zu veröffentlichen, sobald ich sie repariert habe.

 
Реter Konow:

OK, ich werde ein Video von der CPU-Last machen. Aber was die kompilierte Datei betrifft, so werde ich sie noch nicht veröffentlichen.

Ich schäme mich nur sehr für Wanzen...)))

Wenn ich sie repariert habe, werde ich sie posten.

Gut. Nehmen Sie sich Zeit. )
Grund der Beschwerde: