Ftd.- Editor sehr lange Bearbeitungszeiten seit Update

[H. Ww]

Hallo,

ich habe nach längerer Zeit mal wieder mit dem Führerstandeditor ( Version 3.5.9.12 ) gearbeitet. Die Zeiten zum Öffnen einer Textur unter" Instrument bearbeiten" dauert ungewöhnlich lange. Man hat das Gefühl da passiert nichts.
Getestet habe ich das auch mit einer älteren Version 3.5.8.6 , aber da dauert es neuderdings auch sehr lange . Kann es sein, dass es mit dem gesamten letzten Beta Update zu tun hat? Hat noch jemand diese Probleme ? Es sind die 64 Bit Versionen installiert.

MfG

[Carsten Hölscher]

Wenn man die Datei ein zweites Mal öffnet, ist sie vom ersten Laden noch im Dateicache der Festplatte und lädt sehr viel schneller. Also vorsichtig sein mit solchen Vergleichen.

Carsten

[H. Ww]

Wenn man die Datei ein zweites Mal öffnet, ist sie vom ersten Laden noch im Dateicache der Festplatte und lädt sehr viel schneller. Also vorsichtig sein mit solchen Vergleichen.

Carsten

Dem ist leider nicht so, denn die lädt jetzt auch beim zweiten oder dritten Mal leider nicht schneller. Ich habe jetzt immer zwischen 45-60 s bis die Datei öffnet. Das ging vorher deutlich schneller. Das Testen von einem Beta Update dient meines Erachtens auch dazu evtl. Fehler aufzuzeigen, wenn etwas nicht mehr so funktioniert wie zuvor. Was die Firma Hölscher dann damit anfängt bleibt ihr überlassen.

[Carsten Hölscher]

Der Code dafür ist seit Jahren unverändert, da muss man schon mal kurz schauen, ob es an was anderem liegen kann.
Also wenn Du wechselweise direkt nacheinander - ohne sonst was anderes am Rechner zu machen - neuen und alten Editor nimmst, dann geht ist das Laden immer beim neuen Editor deutlich langsamer als beim Alten?

Carsten

[Johannes]

Der Code dafür ist seit Jahren unverändert

Es ist ja auch seit Jahren langsam

Re: Liste der bekannten Programmfehler
(587) Führerstandeditor - Meldertextur bearbeiten: Fenster öffnet extrem langsam und unter hoher CPU-Last
(vermutlich auch im 3D-Editor). Grund ist, dass je nach Texturgroesse bis zu mehreren Millionen Mal die API-Funktion RedrawWindow ausgefuehrt wird, vermutlich einmal pro Pixel. Man sollte die Textur zunaechst in ein Offscreen-Bitmap zeichnen, bevor man sie darstellt.

Bugreport vom Juli 2015

[H. Ww]

Hallo Carsten,
die neuste Beta Version der ZusiSim exe ist installiert, und die neuste Version des Ftd. Editors. Hier gibt es lange Öffnungszeiten.

Mit einer älteren Version des Ftd. Editors wurde die Öffnungszeit nicht schneller.

Wo ein evtl. Fehler liegen könnte, welcher die Öffnungszeiten verlängert, weiß ich nicht. Am PC selbst wurde nichts verändert oder erneuert. Ich kann dir nur schreiben wie es sich verhält, und was ich versucht habe.

[F. Schn.]

Wo ein evtl. Fehler liegen könnte, welcher die Öffnungszeiten verlängert

Wahrscheinlich am Aufkommen von immer mehr HD- / UHD-Führerständen. Die Funktion war schon immer langsam, und zwar abhängig von der Texturgröße, und rein subjektiv kommt sie mir auch nicht langsamer vor als früher. Was Johannes da schreibt passt perfekt.

[Thomas U.]

Im 3D-Editor ist das ja nicht anders, wobei ich das Gefühl habe, dass es unter Win11 schlimmer geworden ist als mit Win7. Ein Testobjekt mit 4k-Textur braucht sagenhafte 2:40 Minuten, bis sich das "Mesh-Subset bearbeiten"-Fenster öffnet.

[Carsten Hölscher]

Sind jetzt 2 Themen. Zusi-Versionsfrage scheint es dann ja nicht zu sein, sondern irgendwas am Rechner oder an der Textur muss der Grund sein.

Dass es unnötige Aufrufe gibt, schau ich mir mal an.

Carsten

[H. Ww]

Sind jetzt 2 Themen. Zusi-Versionsfrage scheint es dann ja nicht zu sein, sondern irgendwas am Rechner oder an der Textur muss der Grund sein.

Dass es unnötige Aufrufe gibt, schau ich mir mal an.

Carsten

Die Textur ist aus dem Zusi Bestand und 2048 x 2048 Pixel groß. Am Rechner wurde nichts verändert, ausser das die Beta Updates installiert wurden. Ein MS Update wurde auch zwischen der letzten Zusi Versionen und dem Update nicht installiert. Performance Einbrüche bei anderen Programmen gibt es auch nicht. Es bleibt spannend. Vielleicht findest du ja etwas .

MfG

[Carsten Hölscher]

Was soll ich denn da finden, Du schreibst ja hier, dass es keine Änderung mit dem Update der exe gab:

Hallo Carsten,
die neuste Beta Version der ZusiSim exe ist installiert, und die neuste Version des Ftd. Editors. Hier gibt es lange Öffnungszeiten.

Mit einer älteren Version des Ftd. Editors wurde die Öffnungszeit nicht schneller.

Carsten

[H. Ww]

Was soll ich denn da finden, Du schreibst ja hier, dass es keine Änderung mit dem Update der exe gab:

Hallo Carsten,
die neuste Beta Version der ZusiSim exe ist installiert, und die neuste Version des Ftd. Editors. Hier gibt es lange Öffnungszeiten.

Mit einer älteren Version des Ftd. Editors wurde die Öffnungszeit nicht schneller.

Carsten

Die ältere Version bezogen sich nur auf den Ftd.-Editor, nicht auf ZusiSim.exe. Fakt ist , dass sich die Zeiten mit dem Update bei mir verlängert haben. Warum weiß ich nicht, hatte eben sogar fast 2 min benötigt. Es bricht nicht die Welt zusammen, aber das Arbeiten mit dem Editor ist so nicht zielführend, schon ärgerlich.

MfG

[Carsten Hölscher]

Es geht in dem ganzen Thema doch um das Öffnen im ftd-Editor. Damit hat der Sim rein gar nichts zu tun.

Hatte mir das jetzt mal angeschaut: Im Editor wird der ganze Vorgang versehentlich beim Öffnen des Formulars ein 2. Mal ausgeführt. Das hab ich entfernt. Das Zeichnen auf ein 2. Bitmap bringt auch noch ein bißchen. Die Zeit geht dafür drauf, die Farben umzusortieren, da DX und Delphi eine andere RGB-Reihenfolge nutzen und der Alphawert entfernt werden muss. Das läuft aktuell pixelweise und ließe sich vermutlich durch irgendeinen schlauen Kniff beschleunigen, aber auf die Schnelle fiel mir nichts ein.

Carsten

[H. Ww]

Es geht in dem ganzen Thema doch um das Öffnen im ftd-Editor. Damit hat der Sim rein gar nichts zu tun.

Hatte mir das jetzt mal angeschaut: Im Editor wird der ganze Vorgang versehentlich beim Öffnen des Formulars ein 2. Mal ausgeführt. Das hab ich entfernt. Das Zeichnen auf ein 2. Bitmap bringt auch noch ein bißchen. Die Zeit geht dafür drauf, die Farben umzusortieren, da DX und Delphi eine andere RGB-Reihenfolge nutzen und der Alphawert entfernt werden muss. Das läuft aktuell pixelweise und ließe sich vermutlich durch irgendeinen schlauen Kniff beschleunigen, aber auf die Schnelle fiel mir nichts ein.

Carsten

Das ist super, dass du dich da gekümmert hast, vielen Dank dafür und ein schönes Wochenende.

MfG

[Johannes]

Das läuft aktuell pixelweise und ließe sich vermutlich durch irgendeinen schlauen Kniff beschleunigen, aber auf die Schnelle fiel mir nichts ein.

Vielleicht magst du den Code ja der hier versammelten Schwarmintelligenz zum Fraß vorwerfen?

[Carsten Hölscher]

Hab's mal das Drumrum entfernt, Picture kommt aus der Komponente im Formular.

Code: Alles auswählen

D3DXCreateTextureFromFileEx( DXDevice,
                             pchar(Datei),
                             D3DX_DEFAULT,
                             D3DX_DEFAULT,
                             1,
                             0,
                             D3DFMT_A8R8G8B8,     
                             D3DPOOL_SYSTEMMEM,   
                             D3DX_FILTER_NONE,    
                             D3DX_FILTER_NONE,
                             0,
                             @Info,
                             nil,
                             Textur);

setlength(FarbenTemp, Picture.Bitmap.Width*Picture.Bitmap.Height);  // FarbenTemp:array of TD3DColor;
Textur.LockRect(0, t, nil, D3DLOCK_READONLY);         // t:TD3DLockedRect;
System.Move(t.pBits^, FarbenTemp[0], 4*length(FarbenTemp));
Textur.UnlockRect(0);
bmp:=Graphics.TBitmap.Create;
// hier geht >99% der Rechenzeit für die ganze Aktion rein:
for a:=0 to bmp.Height-1 do
begin
  for aa:=0 to bmp.Width-1 do
  begin
    bmp.Canvas.Pixels[aa, a]:=FarbeUmdrehen(FarbenTemp[a*bmp.Width+aa] and $ffffff);
  end;
end;
Picture.Bitmap.Assign(bmp);
bmp.Free;

[Christian Sch.]

Hallo Carsten,

gibt es denn für den Wert "D3DFMT_A8R8G8B8" des Parameters Format keinen Passenderen Wert?

D3DFMT_A8B8G8R8, D3DFMT_X8B8G8R8 springen mir da ins Auge.

oder

D3DFMT_UNKNOWN und D3DFMT_FROM_FILE

Quelle:
https://learn.microsoft.com/en-us/windo ... fromfileex
https://learn.microsoft.com/en-us/windo ... /d3dformat

Wie

Gruß
Christian

[Johannes]

Was macht man in so einem Fall?

0. Lauffähiges Programm aus dem Beispielcode herstellen …
1. Messen statt raten!


OK, TCanvas.SetPixel macht offenbar für jeden Pixel einen Systemaufruf, das ist nicht sehr effizient.

2. Lesen

In der Delphi-Dokumentation von TBitmap, Abschnitt "Drawing on the Bitmap" https://docwiki.embarcadero.com/RADStud ... the_Bitmap steht: "An efficient way to draw images when you need to access individual pixels is to use the Vcl.Graphics.TBitmap.ScanLine property. For general-purpose usage, you can set up the bitmap pixel format to 24 bits and then treat the pointer returned from ScanLine as an array of RGB.". Die Doku verlinkt auch auf ein Beispiel: https://docwiki.embarcadero.com/CodeExa ... e_(Delphi)

3. Umsetzen und erneut messen:


Das Laden geht jetzt so schnell, dass ich den Button 33x betätigen musste (statt vorher 4x), um überhaupt genügend Samples zu bekommen. Insbesondere fällt das Vertauschen der Farben nicht ins Gewicht, kann also fürs erste so bleiben. Wahrscheinlich könnte man das Ganze auch mit BitBlt o.Ä. lösen statt manuell, oder pf32Bit und eines der von Christian genannten Texturformate verwenden, aber so funktioniert es wie vorher und ist schnell genug. Obwohl Delphi gefühlt den langsamstmöglichen Code generiert.

Fertiger Code:

Code: Alles auswählen

function FarbeUmdrehen(F: TD3DColor): TRGBTriple;
begin
  Result.rgbtBlue := Byte(F);
  Result.rgbtGreen := Byte(F shr 8);
  Result.rgbtRed := Byte(F shr 16);
end;

procedure TForm1.Button1Click(Sender: TObject);
type
  TRGBTripleArray = ARRAY[Word] of TRGBTriple;
  PRGBTripleArray = ^TRGBTripleArray;
  PD3DColor = ^TD3DColor;
var
  lockedRect: TD3DLockedRect;
  textur: IDirect3DTexture9;
  bmp: Vcl.Graphics.TBitmap;
  x, y: Integer;
  hr: HRESULT;
  imageInfo: D3DXIMAGE_INFO;
  SrcColor: PD3DColor;
  DestRow: PRGBTripleArray;
begin
  hr := D3DXCreateTextureFromFileEx( lpd3ddevice,
                               pchar('test.dds'),
                               D3DX_DEFAULT,
                               D3DX_DEFAULT,
                               1,
                               0,
                               D3DFMT_A8R8G8B8,
                               D3DPOOL_SYSTEMMEM,
                               D3DX_FILTER_NONE,
                               D3DX_FILTER_NONE,
                               0,
                               @imageInfo,
                               nil,
                               Textur);
  if Failed(hr) then
  begin
    raise Exception.Create(IntToHex(hr));
  end;

  hr := textur.LockRect(0, lockedRect, nil, D3DLOCK_READONLY);         // t:TD3DLockedRect;
  if failed(hr) then
  begin
    raise Exception.Create(IntToHex(hr));
  end;

  try
    bmp := Vcl.Graphics.TBitmap.Create;
    try
      bmp.PixelFormat := pf24Bit;
      bmp.Width := imageInfo.Width;
      bmp.Height := imageInfo.Height;
      for y := 0 to bmp.Height - 1 do
      begin
        SrcColor := PD3DColor(PByte(lockedRect.pBits) + y * lockedRect.Pitch);
        DestRow := bmp.ScanLine[y];
        for x := 0 to bmp.Width - 1 do
        begin
          DestRow[x] := FarbeUmdrehen(SrcColor^);
          Inc(SrcColor);
        end;
      end;
      Image1.Picture.Bitmap.Assign(bmp);
    finally
      bmp.Free;
    end;
  finally
    textur.UnlockRect(0);
  end;
end;

[Johannes]

P.S. Spaßeshalber noch mit dem 32-Bit-Texturformat, d.h. DirectX und GDI übernehmen die Pixelschubserei für uns. Ich gebe zu, es ist nochmal deutlich schneller und der Code ist kürzer. Ich bin mir aber mit der Byte-Reihenfolge nicht so sicher – andererseits, im Test sind die Farben korrekt.

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
type
  TRGBQuadArray = ARRAY[Word] of TRGBQuad;
  PRGBQuadArray = ^TRGBQuadArray;
var
  lockedRect: TD3DLockedRect;
  textur: IDirect3DTexture9;
  bmp: Vcl.Graphics.TBitmap;
  y: Integer;
  hr: HRESULT;
  imageInfo: D3DXIMAGE_INFO;
begin
  hr := D3DXCreateTextureFromFileEx( lpd3ddevice,
                               pchar('test.dds'),
                               D3DX_DEFAULT,
                               D3DX_DEFAULT,
                               1,
                               0,
                               D3DFMT_A8R8G8B8,
                               D3DPOOL_SYSTEMMEM,
                               D3DX_FILTER_NONE,
                               D3DX_FILTER_NONE,
                               0,
                               @imageInfo,
                               nil,
                               Textur);
  if Failed(hr) then
  begin
    raise Exception.Create(IntToHex(hr));
  end;

  hr := textur.LockRect(0, lockedRect, nil, D3DLOCK_READONLY);
  if failed(hr) then
  begin
    raise Exception.Create(IntToHex(hr));
  end;

  try
    bmp := Vcl.Graphics.TBitmap.Create;
    try
      bmp.PixelFormat := pf32Bit;
      bmp.Width := imageInfo.Width;
      bmp.Height := imageInfo.Height;
      for y := 0 to imageInfo.Height - 1 do
      begin
        Move(
          (PByte(lockedRect.pBits) + y * lockedRect.Pitch)^,
          PRGBQuadArray(bmp.ScanLine[y])^,
          4 * imageInfo.Width)
      end;
      Image1.Picture.Bitmap.Assign(bmp);
    finally
      bmp.Free;
    end;
  finally
    textur.UnlockRect(0);
  end;
end;

[H. Ww]

Hallo Johannes, hallo Carsten,

das liest sich gut für mich, auch ohne Ahnung , und lässt hoffen.

MfG