Repaint beim Form-Resize beschränken

[G-Baumstamm]

Heyho,

ich habe eine Form, welcher ich mit der Free-Version der Alpha Controls einen Skin zugewiesen habe, außerdem sind u.A. noch eine PageControl und mehrere Buttons auf der Form.

Beim Resize der Form kommt es nun zu extremem Flackern bei den Buttons, der PageControl (der TabHeader bewegt sich deutlich sichtbar bestimmt 2mm rauf und runter) sowie den Rändern (man sieht z.B. deutlich, das erst eine Vergrößerung ausgeführt wird, der Bereich dann schwarz ist und anschließend übermalt wird).

Auch wenn ich den Skin deaktiviere besteht das Problem, wenn auch weniger stark.

Leider hab ich davon nicht so viel Ahnung, deswegen frag ich jetzt einfach mal ganz naiv ... Kann ich das Neuzeichnen der Form auf bestimmte Bereiche beschränken (z.B. nur den Rand, der grade resized wird), oder sonst irgendwas machen, so das das Resizen der Form vernünftig und sauber aussieht, so wie bei allen anderen Anwendungen auch ?

Meine Recherchen dazu haben mich bis jetzt kaum weiter gebracht, DoubleBuffered auf der Form und / oder einzelnen Komponenten ändert genau garnix. Ich hab gedacht, vlt könnte man ne Region erstellen und das Update auf diese beschränken, ob (und wenn ja vor allem wie) das geht hab ich aber keinen Plan ... vielleicht gibts auch noch bessere Lösungsansätze.

Hoffe jemand kann mir helfen, danke im voraus =)

Hinweis: Ich hab die Exe mal in nem Verzeichnis angehängt, damit ihr seht was ich meine. Bitte nicht auf die Buttons klicken (dann stürzt das Programm ab, da ich gewisse Pfade statisch gesetzt habe bzw. auf andere Programme zugreife), es geht nur um das resize. Hoffe das Ding läuft so wies is überhaupt auf anderen Rechnern ...

[Bummi]

Hast Du es mal mit DoubleBuffered probiert?

[stahli]

Ich denke, das Problem wirst Du nicht abstellen können.
Es gab mal eine Unit FlickerReduce.pas (o.ä.), die das Problem eingeschränkt hat, aber andere Probleme verursachen konnte. Unter D2009 waren die Optionsformulare z.B. teilweise nicht mehr nutzbar.

Dass es in geskinten Forms stärker flackert, ist nachvollziehbar, da dort natürlich aufwendiger gezeichnet wird und das länger dauert.

Welche "alle anderen Anwendungen" meinst Du denn, die das Problem nicht haben? (Delphianwendungen mit Skins?)

[blackfin]

Das Problem, dass es ab und an ein wenig flackert, haben meiner Meinung nach im gewissen Maß leider alle "geskinnten" Anwendungen.
(habe schon einige geskinnte Anwendungen erstellt...gerade bei vielen, etwas älteren OnBoard-Grafikchips mit schwindligen Treibern flackert es fast immer ein wenig...)
Dagegen kann man generell, bis auf DoubleBuffering wie es bereits gesagt wurde, nicht viel machen.

Um das Flackern einer geskinnten Anwendung unter Allen Umständen komplett abzustellen, vergiss AlphaControls, VCLSkin und Konsorten,
dafür gibt es dann nur einen vernünftigen Weg:

VCL wegschmeissen, SDL nehmen, eigene GUI-Library auf DirectX oder OpenGL bauen und damit dann die Anwendung erstellen....was aber zugegebenermaßen horrormäßig viel Arbeit ist und zudem die Grafikkarte dann DX/OpenGL-Treiber besitzen muss

[Thom]

Zitat von blackfin:

Um das Flackern einer geskinnten Anwendung unter Allen Umständen komplett abzustellen, vergiss AlphaControls, VCLSkin und Konsorten,
dafür gibt es dann nur einen vernünftigen Weg:

VCL wegschmeissen [...]

Weshalb denn das!?
Das eigentliche Problem liegt darin, daß generell in zwei Schritten aktualisiert wird: Auf WM_ERASEBKGND wird das Element mit der Hintergrundfarbe übermalt und in WM_PAINT neu dargestellt. Zwischen beiden Ereignissen liegt logischerweise etwas Zeit. Und genau die bewirkt das Flackern.
Dazu kommt noch, daß Steuerelemte - wenn diese nicht per WS_CLIPCHILDREN aus dem DC des Parents herausgenommen wurden - auch erst einmal gelöscht werden. Eine ähnliche Unsitte ist es, Controls bei der Darstellung erst einmal komplett zu löschen. Ein unrühmliches Beispiel dafür sind Grids. Anstatt zuerst die Zellen zu zeichnen, deren Bereich aus dem DC per Clipping herauszunehmen und dann die verbliebene Update-Region mit der Hintergrundfarbe zu füllen, wird meist erst einmal alles gelöscht.
Wurden solche Dinge beachtet, war es auch schon unter Windows 3.1 und einem 220 MHz-Prozessor möglich, flackerfreie Anwendungen zu entwickeln - und das völlig ohne Hardwarebeschleunigung. Auch mit VCL!
Wenn das Komponentenhersteller vergessen, ist das einfach nur traurig und zeugt nicht gerade von Kompetenz.

[G-Baumstamm]

Yoyo,

Zitat von Bummi:

Hast Du es mal mit DoubleBuffered probiert?

Zitat von G-Baumstamm:

DoubleBuffered auf der Form und / oder einzelnen Komponenten ändert genau garnix.

Zitat von stahli:

Welche "alle anderen Anwendungen" meinst Du denn, die das Problem nicht haben? (Delphianwendungen mit Skins?)

Damit meinte ich nur alles andere ... seien es Browser, Office-Programme, Musik-Programme, die IDE, einfach alles eben ... eigentlich hab ich noch nie ein Programm gesehen wo der Page-Control-Header auf und abhüpft wenn ich die Form resize ...

Zitat von blackfin:

VCL wegschmeissen, SDL nehmen, eigene GUI-Library auf DirectX oder OpenGL bauen und damit dann die Anwendung erstellen...

Wenn ich das nur könnte, mein Lieber ... leider ist das aber fernab von allem was ich auch nur ansatzweise hinkriegen könnte ...

@Thom: Deine Erklärung klingt logisch, ich hab mich schon immer gefragt wieso immer alles neu gezeichnet werden muss, und ob man das nicht irgendwie effizienter gestalten könnte ... aber kann ich da als "Anwender" im Nachinein noch irgendwas machen ?

Zusammenfassend: Eure Antworten sehen ja ziemlich duster aus, trotzdem hatte ich eigentlich nicht vor so schnell aufzugeben *g*

Um nochmal auf meinen Ausgangsvorgang zurückzukommen: kann man nicht irgendwie ne Region definieren, und diese dann für die Dauer des Resizens vom Update ausschließen? Also ganz naiv einfach eine Methode finden, Rect(0,0,500,500) [oder wie viel man halt braucht, nur so als Beispiel] in nen Handle zu transferieren und den dann mit LockWindowUpdate oder der entsprechenden Message während des Resizens einfach in Ruhe zu lassen ? Wie gesagt, ich hab davon nicht viel Ahnung, weiß der Geier ob das irgendwie geht, ob das Sinn machen würde oder obs da was besseres gibt ...

Aber danke schonmal für eure Antworten, freut mich das es so viele Leute gibt die bereit sind, sich mit den Problemen anderer auseinander zu setzen =)

[Satty67]

Ich weis nicht, ob es bei Dir zutrifft (wegen Skins), aber ich hab' festgestellt, das ParentBackground:=False bei mir oft hilft, wenn DoublePuffered versagt.

[stahli]

Das gibt es aber nicht bei Buttons (und m.E. sowiso nicht unter D7).

Die Optimierung der VCL-Controls-Darstellungen wäre wohl auch ein Punkt pro VCL-Überarbeitung.
Damit würde man allerdings die Kompatibilität alter Formulare gefährden.
Vielleicht soll ja auch FireMonkey einen entsprechenden Wechsel einläuten, aber diesbezüglich bin ich noch etwas skeptisch.

Mit D7 kannst Du mal die FlickerReduce.Pas testen (wenn Du sie noch irgendwo findest).
Ich fand sie damals hilfreich (allerdings ohne Skin-Controls). Unter D2009 allerdings dann nicht mehr.

[blackfin]

@Thom:
Du hast schon recht mit deinen Worten. Ich meinte aber mit "VCL wegschmeissen" eher, dass man kaum drumherum kommt, das ganze selbst von Grund auf zu bauen, wenn man es richtig machen will.
Die ganzen SkinControl-Komponenten, die es käuflich gibt, sind leider meist "All-In-Wonder" Tüten, die in allen erdenklichen Fällen funktionieren müssen, und deswegen haben sie oft lahmen Code drin und sind kaum optimiert.
(Wenn man sich den Sourcecode von so manchen SkinControls ansieht, ich will hier keine Namen nennen..hust...sieht man das schon...)

Man muss die VCL natürlich nicht wegschmeissen, um es auch vernünftig machen zu können, allerdings würde ich dann gleich auf SDL+DirectX oder SDL+OpenGL gehen, wenn ich mir alles selbst bauen würde und die VCL hinter mir lassen.
Das meinte ich damit. Zwar mega viel Arbeit, aber durchaus interessant und man lernt viel, ohne den Ballast der VCL mitzuschleppen, bei der man eh jedes Control modifizieren müsste.

[G-Baumstamm]

Die VCLFlickerReduce.pas muss ich doch nur bei uses mit aufführen, oder ?

Wenn ja, dann bringt es leider auch garnix ...

Auch das mit dem ParentBackground leider keine Veränderung. Grr. Das Ding will nich