FireMonkey Sammelthread

[stahli]

Genau genommen fällt mir letztlich nur ein Grund für den aktuellen TAniIndicator ein:

Damit David I. in den früheren Werbevideos stolz eine Animationskomponente präsentieren kann, so dass die potentiellen Käufer natürlich unterstellen, dass man damit irgendwelche Aktivitäten der eigenen Anwendung darstellen kann.

Ich glaube inzwischen nichts mehr, was Emba präsentiert.
So verarscht habe ich mich noch von keiner anderen Firma gefühlt.

[Union]

Naja, jetzt gibt es ja die Umfrage. Die kannst Du ja entsprechend ausfüllen.

[stahli]

Zitat von Union:

Naja, jetzt gibt es ja die Umfrage. Die kannst Du ja entsprechend ausfüllen.

Wo findet man die?

[mkinzler]

http://www.delphipraxis.net/175723-t...ey-2013-a.html

[stahli]

@Thom

Ohne ProcessMessages klappt das bei mir nicht.
Anbei mal ein Testprojekt (XE3, ohne Exe) im Baustellenstatus.

Ich habe auch mal versucht, das Refresh in einen Thread zu packen.
Aber auch hier wird man ohne Syncronisation nicht weiter kommen.
In dem Fall könnte aber Invalidate reichen, wie ich es in meinem Framework einsetze.

[Thom]

@Stahli

Mit Threads sollte das nicht funktionieren. Soweit ich weiß, ist die GUI von FireMonkey auch nicht threadsicher. Sie baut unter Windows ebenfalls auf GDI auf, auch wenn einige Renderaufgaben von der Grafikkarte übernommen werden. Die vorgerenderten Abschnitte werden dann aber wieder als Bitmap zurück in den Hauptspeicher geholt und "ganz normal" angezeigt. Meiner Meinung nach ist dieses Konzept auch der Hauptgrund, weshalb trotz GPU-Unterstützung die Framerate unter FireMonkey so - ähmmm - verbesserungswürdig ist. Falls ich das falsch verstanden habe, kann mich jemand gern korrigieren. Ich hatte mir dieses Prinzip vor allem bei den Filtern bzw. Effekten angeschaut.

Um also die Oberfläche eines Formulars während lang andauernden Aktionen nicht einfrieren zu lassen, muß die Aktualisierung aktiv angestoßen oder die blockierenden Aktionen in einen Thread ausgelagert werden. In dieser Beziehung unterscheiden sich VCL und FireMonkey nicht.

Die Synchronisation von Threads geschieht über das Senden von Nachrichten:

Delphi-Quellcode:

unit FMX.Platform.Win;

procedure TPlatformWin.WakeMainThread(Sender: TObject);
begin
  if TThread.CurrentThread.ThreadID <> MainThreadID then
    PostMessage(FThreadSyncHandle, WM_NULL, 0, 0);
end;

Und solange diese nicht (vom Hauptthread) abgeholt werden, passiert hier ebenfalls nichts.

Ich schaue mir mal Dein Testprojekt an.

Ok. Gerade gemacht. Funktioniert doch auch ohne ProcessMessages... Das Problem in Deiner Demo ist, daß Du ProgressBar1.Max auf 100000 setzt. Damit da etwas Sichtbares passiert, brauchst Du einige Liter Kaffee.
Mit Sleep(50) hast Du rund 20 Schritte pro Sekunde. Macht für den gesamten Fortschrittsbalken 100000/20=5000 Sekunden oder 83,3 Minuten.

[stahli]

@ Thom

Danke für Deine Mühe.
Bin gerade noch mit meinem neuen Rechner beschäftigt. Delphi installiere ich als nächstes mit.

In meinem Testprojekt hatte ich zuerst nur ein Label getestet. Aus dem Test stammt die hohe Durchlaufzahl.
Da habe ich ohne ProcessMessages keinen Fortschritt gesehen. Später dann mit Progressbar und AniIndicator auch nicht.
Vielleicht hängt das auch von der Grafikkarte oder Leistungsfähigkeit des Systems ab?

Die Abläufe im FMX habe ich teilw. auch mal nachvollzogen, aber dann schnell aufgegeben.
Es wirkt alles sehr umständlich bis planlos.

[Thom]

Seid mal nicht ganz so streng.

Auch in der VCL funktioniert die grafische Ausgabe nicht, solange die Nachrichtenverarbeitung blockiert wird. Hier hilft ja bekanntlich der Aufruf von Application.ProcessMessages , was auch unter FireMonkey möglich ist. Dann werden auch alle Animationen abgearbeitet und Veränderungen des Formulars sichtbar gemacht.

Wer aus irgendwelchen Gründen Application.ProcessMessages nicht verwenden möchte (zum Beispiel, damit der Anwender nicht inzwischen wild auf dem Formular herumklicken kann) könnte auch folgenden Classhelper verwenden, der nur die Animationen weiterlaufen läßt und veränderte Elemente aktualisiert:

Delphi-Quellcode:

type
  TCustomFormHelper = class helper for TCustomForm
    procedure Repaint;
  end;

procedure TCustomFormHelper.Repaint;
var
  N: Integer;
  UpdateRect: TRectF;
  Child: TFmxObject;
begin
  if Assigned(FMX.Types.AniThread) and Assigned(FMX.Types.AniThread.OnTimer)
    then FMX.Types.AniThread.OnTimer(nil);
  if ChildrenCount>0 then
  begin
    UpdateRect:=TRectF.Empty;
    for N:=0 to ChildrenCount-1 do
    begin
      Child:=Children[N];
      if (Child is TControl) and not TControl(Child).UpdateRect.IsEmpty then
      begin
        if UpdateRect.IsEmpty
          then UpdateRect:=TControl(Child).UpdateRect
          else UpdateRect.Union(TControl(Child).UpdateRect);
      end;
    end;
    if not UpdateRect.IsEmpty
      then PaintRects([UpdateRect]);
  end;
end

Verwendet werden könnte er wie in meinem ersten Beispiel:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Time: Cardinal;
begin
  AniIndicator1.Visible:=true;
  AniIndicator1.Enabled:=true;
  try
    Time:=TThread.GetTickCount;
    while TThread.GetTickCount-Time<=5000 do
    begin
      Sleep(50);
      Label1.Text:=FloatToStr(TThread.GetTickCount-Time);
      Repaint;
      //Application.ProcessMessages;
    end;
  finally
    AniIndicator1.Visible:=false;
    AniIndicator1.Enabled:=false;
  end;
end;

P.S.:
TProgressBar funktioniert damit übrigens auch ohne Probleme!

[Thom]

Ich habe gerade beim Lesen der (XE3-)FireMonkey-Quelltexte einen neuen Geniestreich der Entwickler entdeckt:

Delphi-Quellcode:

unit FMX.Platform.Win;

function WndProc(hwnd: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
[...]
begin
[...]
        WM_LBUTTONUP:
          begin
            [...]
              GetCursorPos(P);
              ScreenToClient(Wnd, P);
              LForm.MouseUp(TMouseButton.mbLeft, KeysToShiftState(wParam), P.X, P.Y);
            end;
          end;
[...]
end;

Da ist doch tatsächlich jemand auf die Idee gekommen, die Koordinaten aller (!!!) Mausereignisse per GetCursorPos() zur ermitteln, statt aus lParam auszulesen. Im Klartext bedeutet das, daß nicht die tatsächlichen Koordinaten - zum Beispiel bei einem Klick - geliefert werden, sondern die, die bei der Auswertung der Nachricht aktuell sind. Das hat zur Folge, daß bei schnellen Bewegungen oder Verzögerungen auf Grund eines stark beanspruchten Hauptthreads reale und per Ereignishandler gelieferte Werte meilenweit auseinanderliegen können.
Genial!

[Union]

Diese Genialität steckt auch noch in XE4. Viel besser jedoch sind die dort enthaltenen TODOs sowie auskommentierten Korrekturversuche.

Zitat:

Hey, hört mal auf zu programmieren, das Marketing hat RTM definiert!