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 =)

[DrUArn]

Hi,

habe nicht viel Ahnung vom Thema. In einem Richedit mit vielen Schreibaktionen half dies:

Delphi-Quellcode:

LockWindowUpdate(self.Handle);

  //hier alle Zeichenaktionen

LockWindowUpdate(0);

Mfg Uwe

[Medium]

LockWindowUpdate soll jedoch genau für soetwas nicht verwendet werden.

Zitat von MSDN:

The purpose of the LockWindowUpdate function is to permit drag/drop feedback to be drawn over a window without interference from the window itself. The intent is that the window is locked when feedback is drawn and unlocked when feedback is complete. LockWindowUpdate is not intended for general-purpose suppression of window redraw. Use the WM_SETREDRAW message to disable redrawing of a particular window.

[...]

A locked window cannot be moved.

AFAIK ist ein Resize, mindestens im Falle des Anfassens links und/oder oben auch ein Move - das käme noch dazu. Ich hab die Tage auch irgendwo einen Blog von einem MS'ler gelesen, wo genauer erläutert wird, warum man LockWindowUpdate so sparsam wie möglich, und nur für o.g. Fall einsetzen sollte, finde ihn aber leider nicht mehr . Ein wesentliches Problem war dabei, dass man ggf. andere Anwendungen damit böse ärgern kann, bzw. man auch von anderen gut geärgert werden kann.