Gui baut sich zu langsam auf

Hallo,
wie kann in in c# die GUI schneller aufbauen lassen?
Wenn ich eine Form mit vielen controls öffne, kann ich sehen, wie sie nacheinander erscheinen (das geht aber sehr schnell). Ausserdem habe ich so flicker-Effekte beim Resizing.

Wie kann ich dies Verbessern? Ich hab mal bei der Form DoubleBufferer auf true gesetzt, aber keine Verbesserung.

2. Habe ich einen Algorithmus, der umständerhalber einen Button auf Enabled, dann auf Disabled (Enables = false), dann wieder auf Enabled setzt. Dies erzeugt auch einen flickereffekt, obwohl ich davon ausging, dass die Form nicht neu gezeichnet wird (weil diese 3 zuweisungen innerhalb einer Methode passieren)

Was kann ich da machen um dies zu Verbessern? Danke

Hi!

Auf deine erste Frage: Ich nehme evtl. an, dass das an der Kompilierung in Maschinencode liegt. Theoretisch müsste sich die Form schneller aufbauen, wenn du sie ein zweites mal lädst, da der Code dann schnon compiliert ist.
Um dies wegzubekommen könntest du deine Assembly bei der Installation mit ngen precomilieren.

Auf deine zweite: Diese Effektre treten bei nur auf, wenn ich zwischenzeitlich etwas ganz anderes (meinetwegen in das Label) reinschreibe und dies wieder mit was anderem überschreibe. Es könnte daran liegen, dass dein Code alles überschreibt. Bei mir passiert soetwas nicht.

der Marcel

Hallo cmpxchg,

hast du das Problem auch, wenn du einen Release Build ohne Debugger laufen lässt (STRG+F5 im VS).

Die Ausführung von Programmen unter dem VS-Debugger kann dramatisch langsamer sein, als ohne.

Vorallem wenn man mit vielen Breakpoints, meheren Threads und Abfangen aller geworfenen Exceptions debuged.

Ich hatte da schon Code der auf 5% der Release-Geschwindigkeit lief (sehr nervig beim debuggen).

Cadi hat Recht was die GUI Geschwindigkeit betrifft. Geh einfach mal in dein Bin/Release Verzeichnis des Projekts und starte das Programm. Es sollte dann eigentlich schnell genug laufen.

Ansonsten würde mich auch interessieren, wie ich das Flickern beim Resizing weg bekomme. DoubleBuffer oder Bitmap-Blitting hilft evtl. bei eigenen Controls innerhalb eines festen Windows. Aber wenn man das Window selbst verschiebt oder dessen Grösse auf dem Desktop ändert, dann flickert es wie blöde.

Edit: Zumindest der Windows-Rahmen und die Titelleiste flackern weiterhin.

Gibt es da nicht diese zwei Funktionen: SuspendLayout und ... keine Ahnung .
Wenn ihr das Layout jetzt beim start des verschiebens suspended und beim beenden wieder freigebt, ob das was bringt. Sorry, mein Vorschlag ist etwas Laienhaft ausgedrückt, evtl auch falsch. Wäre jetzt nur meine erste Idee gewesen.

P.S.: Ist das kein Thema für den das "Forms"-Forum ?

SuspendLayout() geht nur für Child-Windows. Habe mich damit auch noch nicht sonderlich beschäftigt, habe aber die Vermutung, dass es nicht trivial bis unmöglich ist. Nicht ohne Grund flackert der Rahmen (soweit ich weiss) bei allen Anwendungen.

Naja, aber wenn man die Child-Windows schonmal nicht während dem Resize/Position berechnen muß, dann bleibt doch für den Parent mehr Power. Das wär meine logische Überlegung. Oder versteh ich da was falsch ?

Original von cmpxchg
...
Wenn ich eine Form mit vielen controls öffne
...

Was ist bei dir in dem Fall den eigentlich viel?
Weil es ist ja bekannt das es bei wirklich vielen Controls es problemen mit der Geschwindigkeit gibt, und es da besser ist, einzelne Controls in Usercontrols zusammenzufassen. Das bringt einiges an Geschwindigkeit.

@talla:
Kannst Du was zu meiner Idee sagen? Du kennst DIch besser aus und ich würd gern wissen, ob ich damit total daneben liege.

Original von Fil
Naja, aber wenn man die Child-Windows schonmal nicht während dem Resize/Position berechnen muß, dann bleibt doch für den Parent mehr Power. Das wär meine logische Überlegung. Oder versteh ich da was falsch ?

Es ist vermutlich keine Frage der Power. Das Problem liegt vermutlich eher am VSync des Desktops. Der müsste double-buffered sein, nicht nur dein Window.

Also Suspend/ResumeLayout sind auch immer die ersten Dinge an die ich denke, obs in dem Fall was bringt hängt halt wirklich von den Controls ab, aber was verschieben angeht, kann ich dir 100% Recht geben 😁

Super, danke. Dachte schon, ich müsste mich wieder mal in Bücher stürzen ...

Original von talla
Also Suspend/ResumeLayout sind auch immer die ersten Dinge an die ich denke, obs in dem Fall was bringt hängt halt wirklich von den Controls ab, aber was verschieben angeht, kann ich dir 100% Recht geben 😄 Dann sind wir aber wieder im Win2000 Zeitalter, wo nur der Rahmen und nicht die Inhalte mit verschoben/resized werden.

Werden sie schon, nur nicht während des verschiebens/resizens. D.h.: Nur einmal rechnen, statt bei jedem Resize-Event / Verschieben - Event.

gibt es denn eine möglichkeiet das man im programm das so einstellt, das die fenster beim verschieben und resize nicht neu gezeichnet werden?
also unabhängig von der windowseinstellung.

ich find das geflacker recht störend. doublebuffering und co ist alles drin aber flackert eben immer noch 🙁
z.b. dieser splitcontainer ist so ein kandidat

auch bricht bei mir teilweise die performance recht stark einwenn ich die neuen stripcontrols benutze 🙁

ich frag mich wie die jungs dsa bei paint.net gemacht haben, da läuft alles super fix... abr die haben da wohl mit etwas c/c++ nachgeholfen 😕

Original von sheitman
gibt es denn eine möglichkeiet das man im programm das so einstellt, das die fenster beim verschieben und resize nicht neu gezeichnet werden?
also unabhängig von der windowseinstellung.

SuspendLayout(), ResumeLayout(), davon reden wir doch schon ne Weile ...

hmpf..... is ja schon gut ^^

hab das grad mal implementiert und fkt so wie ich es gewollt hab 🙂

ich ha bdeshalb gefragt, weil ich das schon mal probiert hatte und dann hat das aber nicht den gewünschten effekt erbracht... allerdings war das mit einem usercontrol... naja... man möge mir vergeben für meine wiederholte frage 🙂

btw: ResizeBegin und ResizeEnd im zusammenhang mit den SuspendLayout und ResumeLayout wars 🙂
is jetzt wie bei den java anwendungen die ich kenne^^