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:

Zitat von blackfin (Beitrag 1137806)

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:

Zitat von Bummi (Beitrag 1137793)

Hast Du es mal mit DoubleBuffered probiert?

Zitat:

Zitat von G-Baumstamm (Beitrag 1137792)

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

Zitat:

Zitat von stahli (Beitrag 1137801)

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:

Zitat von blackfin (Beitrag 1137806)

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

[stahli]

Ja, die FlickerReduce musste nur in die uses aufgenommen werden.
Vermutlich wird das dann mit den AlphaControls nicht funktionieren.

Mit vertretbarem Aufwand wirst Du wohl keine Lösung finden.
Ich würde das dann so hinnehmen und nicht übermäßig dramatisieren ;-)

So oft wird der User die Formulargröße sicher nicht ändern bzw. sich nicht über etwas Flackern dabei aufregen.

[G-Baumstamm]

Auf die Gefahr hin damit zu nerven, wie siehts mit diesem Vorschlag aus ? ;)

Zitat:

Zitat von G-Baumstamm (Beitrag 1137904)

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 ...

Und hast schon Recht, is nicht so dramatisch wenns nicht geht, dann mach ich einfach ne Form die man nich resizen kann und gut is :P

Trotzdem, finde es verwunderlich, das es für sowas keine Lösung gibt, da muss der programmiertechnische "Murks" der da in dem Kram drin ist ja wirklich tief sitzen, wenn das selbst die Experten hier nicht umgehen können ... ;)

[stahli]

Zitat:

Zitat von G-Baumstamm (Beitrag 1137923)

Auf die Gefahr hin damit zu nerven, wie siehts mit diesem Vorschlag aus ? ;)

Zitat:

Zitat von G-Baumstamm (Beitrag 1137904)

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 ...

Nicht, dass ich wüsste.

Zitat:

Zitat von G-Baumstamm (Beitrag 1137923)

Trotzdem, finde es verwunderlich, das es für sowas keine Lösung gibt, da muss der programmiertechnische "Murks" der da in dem Kram drin ist ja wirklich tief sitzen, wenn das selbst die Experten hier nicht umgehen können ... ;)

Na ja, die VCL stammt vermutlich aus einer Zeit, in der man es schon genial fand, überhaupt Formulare zu nutzen und diese rezisen zu können. :stupid:

Mir fällt gerade ein: Ich habe mal ein Demovideo gesehen, in dem ein FireMonkey-Formular stufenlos vergrößert und dabei flackerfrei gezoomt wurde. Also die VCL ist wohl einfach in der Beziehung (und nicht nur da) recht veraltet.

[hoika]

Hallo,

gab es bei D7 schon Anchors ?
Wenn ja, nimm die mal komplett beim PageControl raus
setze die Werte direkt im FormResize.


Heiko

[G-Baumstamm]

Ja, Anchors gabs in D7 schon. Aber nein, hilft leider auch nich, weder wenn ich sie bei der PageControl oder bei der Form rausnehme und dann dynamisch oder auch garnicht setzte, keinerlei Effekt ...

[bernerbaer]

Hast Du es schon mit dem VCLFixPack von Andy versucht? (VCLFixPack)

Zitat:

...
QC #56252: TPageControl flickers a lot with active theming (7-2009)
...

[G-Baumstamm]

Auch das mit dem Fix Pack wird von meinen flackernden Komponenten völlig ignoriert ...

Das Übel scheint aber wirklich großteils auf der PageControl zu liegen. Buttons die da drauf sind flackern wie nen Blinklicht beim Resizen, die Buttons die weiter unten auf dem Panel sind verhalten sich völlig ruhig ...

[Bummi]

Pagecontrol war jetzt das Stichwort...
Wir hatten bei einem Projekt mit GDI+-Darstellung von Maschinendaten durch eigen Komponenten auch ein massives Flickerproblem mit PageControls. Wir haben es an den Stellen auf ein Panel mit einem eigenen Tabcontrol umgestellt, in welches Rahmenlose Forms (alClient) geladen wurden, beim Tabwechsel mit BringToFront ensprechend angezeigt. Das geflickere war damit Geschichte.

[blackfin]

Das kann ich bestätigen...PageControls haben bei uns auch immer die meisten Schwierigkeiten gemacht, wenn es ums Skinning geht..von Geflackere bis hin zu völligem Verschwinden der darauf liegenden Controls..also am Besten beim Skinning PageControls vermeiden, entweder selbst eine ähnliche Komponente schreiben oder eine elegante Lösung wie Bummi sie beschrieben hat verwenden :-)

[Namenloser]

Ich hab jetzt nicht jeden Beitrag hier gelesen, aber weil eigenes GUI-Framework angesprochen wurde: Afair hat Andorra 2d sowas (wenn ich mich nicht irre sogar mit graphischem Form-Designer). Wäre vielleicht einen Blick wert.

[G-Baumstamm]

Heyhey,

Zitat:

Zitat von Bummi (Beitrag 1137979)

Pagecontrol war jetzt das Stichwort...
Wir hatten bei einem Projekt mit GDI+-Darstellung von Maschinendaten durch eigen Komponenten auch ein massives Flickerproblem mit PageControls. Wir haben es an den Stellen auf ein Panel mit einem eigenen Tabcontrol umgestellt, in welches Rahmenlose Forms (alClient) geladen wurden, beim Tabwechsel mit BringToFront ensprechend angezeigt. Das geflickere war damit Geschichte.

Danke für den Tip, das werde ich jetzt so machen ! Funktioniert soweit auch super, ein kleines Problem habe ich aber noch: Die einzelnen Forms habe ich einfach per CreateParented integriert, ist auch alles in Ordnung. Allerdings habe ich ihren Borderstyle natürlich auf bsNone gesetzt, was dazu führt, dass sie keine Scrollbars mehr anzeigen ... Also: jemand ne Idee wie ich die Form trotz bsNone zum anzeigen von ScrollBars bewege, wenn der Inhalt größer als die Form ist ? Eine Scrollbox möchte ich explizit nicht verwenden, da die Scrollbars der Form seltsamerweise die einzigen sind die mitgeskinnt werden & ich mir das überlagern von Windows-Scrollbars mit geskinneten um das Verhalten zu simulieren sparen möchte. Man kann doch bestimmt über CreateParams der Childform irgendwie einstellen, das sie trotzdem Scrollbars anzeigt, oder ?

Zitat:

Zitat von NamenLozer (Beitrag 1138015)

Ich hab jetzt nicht jeden Beitrag hier gelesen, aber weil eigenes GUI-Framework angesprochen wurde: Afair hat Andorra 2d sowas (wenn ich mich nicht irre sogar mit graphischem Form-Designer). Wäre vielleicht einen Blick wert.

Danke, ebenfalls interessanter Hinweis. Wenn ich Zeit & Lust habe werden ich mal versuchen mich da einzuarbeiten, für den Moment werde ich es aber weiter ohne probieren ;)

[Bummi]

wir arbeiten grundsätzlich mit Templates, deren überladene Konstruktoren deutlich umfangreicher als das folgende Beispiel sind (unter anderem wird ein Zeiger auf die Variable (kann nil sein) der zugewiesen wird, mit übergeben die im Destruktor wenn gesetzt "genilt" wird)

Delphi-Quellcode:

  Constructor Create(AOwner:TComponent;UseAutoScroll:Boolean=false);Overload;
    { Public-Deklarationen }
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}

{ TForm2 }

constructor TTemplate.Create(AOwner: TComponent; AParent: TwinControl;UseAutoScroll:Boolean=false);
begin
  inherited Create(AOwner);
  if Assigned(Aparent) then
      begin
        borderStyle := bsNone;
        Align := alClient;
        Parent := AParent;
        Show;
        AutoScroll := UseAutoScroll;
      end;
end;

[G-Baumstamm]

Das Problem besteht ja bei mir nicht in der Tatsache, dass ich die Form nicht eingebunden bekomme, sondern darin das ich trotz bsNone die Scrollbars der Form brauche (Autoscroll wird bei bsNone ignoriert).

[stahli]

Mit embedded Forms würde es wohl funktionieren:

Delphi-Quellcode:

    FormXyz.ManualDock(TabSheetXyz, nil, alNone);
    FormXyz.Align := alClient;
    FormXyz.Show;

(Im Beispiel setze ich das Formular übrigens in ein TabSheet und da flackern die Controls auch beim Resizen - ebenso wie GroupBoxen.
Ich nutze hier embedded Forms aus Gründen der Übersichtlichkeit und Projektaufteilung.)


Embedded Forms in TabControls flackern widerum nicht. Allerdings muss man dann dynamisch beim umblättern das passende Form einblenden.
Das habe ich so getan:

Delphi-Quellcode:

procedure TFormPlan.odTabControlTournamentsPlanShowRegister(Sender: TObject);

  procedure ShowForm(F: TForm);

    procedure DoShowForm(SF, F: TForm; FC: TodFormCtrl);
    begin
      if SF = F then
      begin
        if (SF.Parent <> PanelTournamentsPlan) or (not SF.Visible) then
        begin
          SF.ManualDock(PanelTournamentsPlan, nil, alNone);
          SF.Align := alClient;
          SF.Show;
        end;
        FC.od := odTabControlTournamentsPlan.ActiveOd;
        if Assigned(SF.OnShow) then
          SF.OnShow(Self);
      end
      else
      begin
        FC.od := nil;
        SF.Close;
      end;
    end;

  begin
    CourtTournament := odTabControlTournamentsPlan.ActiveOd as TodTournament;
    DoShowForm(FormPlanMelee, F, FormPlanMelee.odFormCtrl);
    DoShowForm(FormPlanSwiss, F, FormPlanSwiss.odFormCtrl);
    DoShowForm(FormPlanGroup, F, FormPlanGroup.odFormCtrl);
    DoShowForm(FormPlanKo, F, FormPlanKo.odFormCtrl);
  end;

begin
  if odTournament = nil then
    ComboBoxTournamentSystem.ItemIndex := -1
  else if odTournament.Data_Is_Melee then
    ComboBoxTournamentSystem.ItemIndex := 0
  else if odTournament.Data_Is_Swiss then
    ComboBoxTournamentSystem.ItemIndex := 1
  else if odTournament.Data_Is_Group then
    ComboBoxTournamentSystem.ItemIndex := 2
  else if odTournament.Data_Is_Ko then
    ComboBoxTournamentSystem.ItemIndex := 3
  else
    ComboBoxTournamentSystem.ItemIndex := -1;
  case ComboBoxTournamentSystem.ItemIndex of
    0:
      ShowForm(FormPlanMelee);
    1:
      ShowForm(FormPlanSwiss);
    2:
      ShowForm(FormPlanGroup);
    3:
      ShowForm(FormPlanKo);
  else
    ShowForm(nil);
  end;
  ComboBoxTournamentSystem.Enabled := ComboBoxTournamentSystem.Text = '';
end;

[Bummi]

Delphi-Quellcode:

sondern darin das ich trotz bsNone die Scrollbars der Form brauche (Autoscroll wird bei bsNone ignoriert).

ich habe leider kein D7 zu Testen zur Hand, der Code den ich eingestellt habe funktioniert unter unter D2010 + problemlos ....

[G-Baumstamm]

Vielleicht hab ich das auch einfach nur falsch umgesetzt, aber auch wenn ich die Form nach der beschriebenen Methode andocke bleibt das Problem, das die Form bei bsNone keine Scrollbars erzeugt bestehen ...

Edit: Menschliches Versagen beim Umsetzen von Bummis Code, funktioniert natürlich. Aber: Das Ding macht mich trotzdem fertig ... Wenn ich das genau so mache skinnt er die Scrollbars einfach nicht mit, ändere ich zum testen bsNone zu bsSizeable habe ich stattdessen ne Form mit Header ABER dafür mit geskinnten Scrollbars ...

[Bummi]

wenn Du den Code aus #22 erfolglos getestet hast muss ich Dich auf Montag vertrösten, im Büro habe ich noch ein paar VM's mit D7 ....

[stahli]

Kann natürlich auch sein, dass die AlphaControls (vielleicht auch nur in Verbindung mit D7) da nicht korrekt mitspielen. Ist ja auch ein seltener Sonderfall, solch eine Anwendung.

[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

[G-Baumstamm]

Mhh ... was mir jetzt noch einfallen würde, wäre

1) Über CreateParams (Style) zu sagen, das auch bei bsNone Scrollbars gezeichnet werden sollen, oder

2) Den Header durch irgendeinen Trick trotz bsSizeable nicht anzeigen

3) Entweder mit den Windows-Scrollbars leben, mit dem Formheader in der anderen Form oder geskinnte Scrollbars drüberzeichnen und das Verhalten imitieren.

Wobei ich natürlich glücklicher wäre wenn 1 oder 2 irgendwie machbar sind ... ^^

Edit: Wüsste nicht wie mir LockWindowUpdate helfen sollte, wenn meine Form entweder die falschen oder gakeine Scrollbars malt ...

[Medium]

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

Zitat:

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.