TImageList-Alternative? Resource-Datei? Performance?

[Glados]

Ich habe aktuell das Problem, dass meine ImageListen mittlerweile etwas größer werden. Größer heißt hier 6 bis 20+ Icons in einer Liste.

Gibt es irgendeine Möglichkeit nicht auf diese ekelhafte ID einer Icons angewiesen zu sein bei der Zuweisung eines Icons für einen TButton oder eines TImage beispielsweise?

Gibt es vielleicht eine bessere Image-Liste wo man über in der Liste selber definierte Namen auf ein Icon zugreifen kann?
Das würde mein Leben erheblich erleichtern.

[Zacherl]

Leider nein. Zur Designtime keine Chance.

[Glados]

Das ist schade denn wie gesagt ist es richtig ekelhaft immer über die ID, die sich ändern kann, zu gehen.

Über eine Resource-Datei wäre noch eine Möglichkeit, oder?
Da kann ich über den Namen gehen und muss keine Reihenfolge einhalten.
Fragt sich nur wie die Performance ist denn zur Laufzeit greife ich aktuell schon ab und zu auf Bilder in der ImageList zu.

[Zacherl]

Zur Laufzeit kannst du dir natürlich einen entsprechenden Container basteln, der dir ein Bild anhand des Namens liefert. Du könntest theoretisch sogar von

Delphi-Quellcode:

TCustomImageList

und dem dazugehörigen Designtime-Editor ableiten um dir die Namen der Icons in einer (internen) extra Liste (am besten ein Dictionary für schnellen Zugriff) zu merken. Dann noch eine Funktion, welche dir den ImageIndex anhand des Namens liefert und voilla.

[Glados]

Limit, dass ich diese Erklärung verstehe. Demnach steht es bei mir außer Frage, dass ich das technisch umsetzen kann.

Was wäre hier der Vorteil gegenüber einer Resourcedatei?

[CCRDude]

Ich lade Icons zur Laufzeit aus den Resourcen in die TImageList, dann kann ich mir die Indizes beim Hinzufügen in Variablen speichern. Hilft natürlich nur bei der Zuweisung im Code, nicht im Designer.

[Glados]

Wäre auch ein Ansatz.

Hat das Laden aus einer Resourcedatei denn nennenswerte Performanceeinbußen?
Ich würde viele Icons bei Programmstart einmalig laden aber ein paar andere werden immer und immer wieder getauscht und somit neugeladen.

[Redeemer]

Es geht vermutlich sogar schneller.

[Glados]

Das wird jetzt aber interessant.
Warum genau ist es denn vermutlich schneller? Hat das was mit der Zugriffsart zu tun Code>Resource und Code>...>...>...>TImageList?

[Zacherl]

Zitat:

Zitat von Redeemer (Beitrag 1381310)

Es geht vermutlich sogar schneller.

Definitiv nicht - maximal gleich schnell. Rate mal, wo

Delphi-Quellcode:

TImageList

seine Icons abspeichert? :P

Zitat:

Zitat von Glados (Beitrag 1381308)

Ich würde viele Icons bei Programmstart einmalig laden aber ein paar andere werden immer und immer wieder getauscht und somit neugeladen.

Um wie viele variable Icons handelt es sich? Bei einigen Wenigen (< 100) würde ich sie gar nicht erst dynamisch laden. Einfach beim Programmstart komplett zur ImageList hinzufügen und dann über den Index bestimmen, welches Icon an welcher Stelle auftaucht.

[Glados]

Es sind maximal 10 die sich ändern... dafür aber gegebenenfalls oft.

Zitat:

Einfach beim Programmstart komplett zur ImageList hinzufügen und dann über den Index bestimmen, welches Icon an welcher Stelle auftaucht.

Das mit dem Index will ich ja unbedingt wegbekommen :P

(Resource schneller)

Zitat:

Definitiv nicht - maximal gleich schnell. Rate mal, wo TImageList seine Icons abspeichert?

Wenn das so ist und die TImageList eh nichts anderes macht, dann kann ich mir ja auch eine Funktion schreiben der ich den Namen der Resource übergebe, welche ich zurückerhalten möchte.
Dann bin ich die IDs los und kann frei laden und sortieren. Um doppelten Code zu vermeiden, würde ich alle Resource-Namen in ein Enum speichern.

[Uwe Raabe]

Wenn es sich ausschließlich um PNG Icons handelt, könntest du mit der

Delphi-Quellcode:

PngImageList

aus den PngComponents eventuell weiterkommen: Dort hat jeder Eintrag einen Namen.

Ich benutze diese Namen auch um den aktuell gültigen gültigen ImageIndex zu ermitteln und habe mir dazu einen kleinen Class-Helper geschrieben:

Delphi-Quellcode:

type
  TPngImageListHelper = class helper for TPngImageList
  public
    function FindImageIndexByName(const AName: string): Integer;
  end;

function TPngImageListHelper.FindImageIndexByName(const AName: string): Integer;
var
  itm: TCollectionItem;
begin
  Result := -1;
  for itm in PngImages do begin
    if SameText(itm.DisplayName, AName) then begin
      Result := itm.Index;
      Break;
    end;
  end;
end;

[Glados]

PNGs sind es nicht, aber ICOs. Muss sie dann halt alle umwandeln.
Ich werde mir das mal angucken. Wenn ich das richtig verstehe, bist du der Urheber dieser Komponente?

Stellt sich mir nur noch die Frage... PNGComponents oder simple Resourcedatei.

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1381314)

Es sind maximal 10 die sich ändern... dafür aber gegebenenfalls oft.

Zitat:

Einfach beim Programmstart komplett zur ImageList hinzufügen und dann über den Index bestimmen, welches Icon an welcher Stelle auftaucht.

Das mit dem Index will ich ja unbedingt wegbekommen :P

Schon klar, aber wenn du die ImageList beim Start der Anwendung mit Icons aus Resourcen füllst, kannst du ja jedem Icon beispielsweise den Resourcennamen zuweisen (bzw. dir in einer StringList mit identischen Indizes merken). Über einen einfachen Lookup in der StringListe findest du nun den ImageIndex des gewünschten Icons heraus.

Auf gar keinen Fall würde ich die Icons komplett dynamisch immer wieder neu laden und freigeben.

[nahpets]

Wie wäre es denn mit 'nem Nachfahren von TImageList?

Ein zusätzliches Attribut Names vom Typ TStrings, in das die Namen der Bilder kommen, in der Reihenfolge, in der sie in der Imageliste stecken.

Dann noch 'ne Methode GetImageIndexByName (oder so), die per IndexOf in den Strings nach dem Namen sucht und, durch die identische Sortierung, dann den passenden ImageIndex liefert.

Für die Methoden Add, Insert ... der ImageList könnte man Versionen schreiben, die zusätzlich auch noch den Namen als Parameter annehmen und in den Strings speichern.

Sowas in der Art?

Delphi-Quellcode:

Type
  TMyImageList = class(TImageList)
    fNames : TStrings;
  public
    { Public-Deklarationen }
    constructor Create(aOwner : TComponent);      override;
    destructor  Destroy;                          override;
    property Names : TStrings read fNames;
  end;
  
constructor tMyImageList.Create(aOwner : TComponent);
begin
  inherited;
  fNames := TStringList.Create;
end;

destructor  tMyImageList.Destroy;
begin
  fNames.Free;
  inherited;
end;

function tMyImageList.GetImageIndexByName(AName : String) : Integer;
begin
  Result := fNames.IndexOf(AName);
end;

end.

...
IrgendeineKomponenteMit.ImageIndex := ImageList.GetImageIndexByName('NameDesBildes');

Wenn man nicht den ImageIndex haben will, sondern direkt das Bild, dann schreibt man sich noch 'ne Methode GetImageByName, die analog zum ImageIndex halt das Bild liefert.

Der Aufwand dürfte insgesamt garnichtmal so hoch sein.

[Zacherl]

An genau sowas dachte ich :) Wenn man dann noch den Designtime Editor überschreibt, kann man die Namen sogar direkt dort einpflegen und müsste nicht manuell mit Resourcen hantieren.

[Rollo62]

Zitat:

über die ID, die sich ändern kann,

Deshalb benutze ich dafür immer globale Ressourcen und Consts.

Delphi-Quellcode:

const 
  CIco_Hund   = 37;
  CIco_Katze  = 38;
  CIco_Maus   = 39;

Das ist für DI Experten vielleicht etwas anrüchig, erspart mir aber "Icon-Katastrophen" wenn sich mal wieder was ändert.

Das erleichtert natürlich nicht das Zuweisen im Designer, deshalb mache ich das auch lieber im Code.
Im Designer lege ich das dann eher nur als "Vorschau" an.

Rollo

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1381318)

Wenn ich das richtig verstehe, bist du der Urheber dieser Komponente?

Nicht direkt - ich habe die quasi auch nur geerbt.

[Glados]

Zitat:

Wie wäre es denn mit 'nem Nachfahren von TImageList?

Klingt gut.

Zitat:

Auf gar keinen Fall würde ich die Icons komplett dynamisch immer wieder neu laden und freigeben.

Stimmt auch wieder. Kann nämlich bei´mir schon öfter passieren, dass was geladen werden muss.

Jetzt muss ich mich nur noch entscheiden zwischen PNGComponents oder TMyImageList.
Bei Ersterem könnte ich sofort den Design Time Editor verwenden, müsste aber alle meine ICOs in PNGs umwandeln.

Ich glaube aber sogar fast, das PNGs irgendwie gängiger sind als ICOs.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1381331)

müsste aber alle meine ICOs in PNGs umwandeln.

Falls du nicht schon bereits ein passendes Tool dazu hast: In PngComponents gibt es eine Methode

Delphi-Quellcode:

ConvertToPNG

die das unterstützt.

[Glados]

Hatte vorher Irfanview getestet, aber die PNGs waren alles andere als identisch.
Habe es nun mit Photoshop und der Stapelverarbeitung gemacht. Für irgendwas muss das Adobe-Abo ja gut sein.

[Rollo62]

Hallo Uwe,

gibt es deine wundervollen PngComponents auch in einer FMX Version, um die dortige ImageList 1:1 zu ersetzen ?
(ich wette mal dagegen :stupid:)

Falls du da etwas planst würde ich gern den ersten Download machen :-D

Rollo

[Redeemer]

IrfanView unterstützt keine Alphakanäle, was für ICOs sehr wichtig wäre. Wer einen vernünftigen kostenlosen Konverter sucht, verwendet XnView. XnView unterstütztt beispielsweise auch JPEG2000, was leider nicht sehr weit verbreitet ist, sich aber gut für die Archivierung eignet.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1381346)

gibt es deine wundervollen PngComponents auch in einer FMX Version, um die dortige ImageList 1:1 zu ersetzen ?

Da die FMX-ImageList ja bereits von Haus aus PNGs in unterschiedlichen Auflösungen verwendet und die jeweiligen Bildchen sogar aus einzelnen Teilen zusammengesetzt werden können, erschließt sich mir jetzt eine Portierung der PngImageList nach FMX nicht so ganz (abgesehen davon, daß es sicher ziemlich aufwändig wäre). Da könnte man eher über eine Portierung der FMX-ImageList nach VCL nachdenken.

Was genau versprichst du dir denn von einer FMX-PngImageList, was mit Bordmitteln nicht auch schon ginge?

[Rollo62]

Hallo Uwe,

ich vermute mal das FMX das Bild im MultiBitmap, also als volles Raster-Bitmap speichert.
Es wäre evtl. sinnvoll das aus Speichergünden als komprimiertes Png im DFM zu belassen.
Habs jetzt nicht getestet, ich gehe aber mal davon aus das die Source-Images (auch in mehreren Auflösungen bei MultiBitmap) gespeichert werden.

Wenn FMX das schon speicheroptimal ablegt hast du natürlich Recht, aber an ImageList fände ich einiges verbesserungswürdig.
Gegen eine optimierte Alternativ-Komponente hätte ich nichts einzuwenden :stupid:

Rollo

[Glados]

Zitat:

Gegen eine optimierte Alternativ-Komponente hätte ich nichts einzuwenden

Vielleicht baut ja irgendwann mal jemand eine deutlich verbesserte ImageList-Komponente.
PngComponents ist jedenfalls schon einmal ein guter Anfang. Nur der Design-Editor könnte schöner/benutzerfreundlicher sein.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1381397)

Es wäre evtl. sinnvoll das aus Speichergünden als komprimiertes Png im DFM zu belassen.

FMX speichert in diesem Fall das PNG-Format. Übrigens auch, wenn man das Image aus einem anderen Format geladen hat.

Zitat:

Zitat von Rollo62 (Beitrag 1381397)

aber an ImageList fände ich einiges verbesserungswürdig.

Dann beschreibe doch einfach mal deine Verbesserungsvorschläge. Vielleicht kann man da ja mal was machen.

[Rollo62]

Verbesserungsvorschläge:
Ich hatte die Vermutung das der interne Cache in 10.2 nicht mehr korrekt arbeitet, unter Android.
Das scheint jetzt in 10.2.1 behoben zu sein.

Der Editor wurde ja schon erwähnt, insbesondere das Verwalten und u.U. Generieren, Überlagern von Images in verschiedenen Scales.

Wenn ImageList intern mit den orginalen PNG arbeitet, die bei Benutzung entpackt und z.B. in diversen Layer in den Destinations benutzt werden können,
dann wäre es doch möglich und sinnvoll auch mit Vector-Primitiven in den Layern zu arbeiten.
Z.B. um in den Layern einfache Symbole sehr speichereffizient zu erzeugen, also die Sources für die Layer könnten entweder aus Bitmaps oder aus Vector-Primitiven erzeugt und kombiniert werden.
Meistens reichen einfache Primitive oder TPath Pfade für Icons aus.

Passt SVG auch noch ins Schema ?

Optimierung der Speicherverwaltung, z.B. wenn verschiedenste Images geladen werden, es sollte aber z.B. intern auf 256x256 begrenzt werden, könnteb die gespiecherten Sources optimiert skaliert werden, um auf die kleinere 256x256 zu kommen.

Optimierung der Image Index z.B. bei PNG, von 256 Bit auf 1 Bit wenn es S/S Bilder sind.

Ein oder mehrere Key-Colors könnten on-the-fly geändert werden, um zu Vermeiden das mehrere versionen Farb-Bilder gespeichert werden müssen.
Ein Basis-Image würde reichen, wo z.B. Farben entsprechend ersetzt werden.
Das wäre bei S/W Modus Bildern einfach machbar, bei Greyscale oder noch schlimmer Farbbilder müsste man die Farben etwas aufwändiger ersetzen.

Natürlich umgekehrt, das Ausgrauen von Farbbildern zu Greyscale ist einfach, gehört natürlich auch auf die Liste.

Die String-Namensgebung und Gruppierung von Bilderlisten, evtl der komplette Austausch von Bildgruppen (z.B. für Styling oder Sprachräume) wäre auch nett.

Das Arbeiten mit TeilBildern, aus einem größeren Quellbild wäre auch schön, also Ansprechen Teilbild 23 von 100, aus einer 10x10 Matrix.
Natürlich sollte diese MAtrix auch erweitert werden können wenn neue Icons hinzukommen.
Das macht das StyleObject doch schon, könnte man so ähnlich in die ImageList reinbauen, nur der Editor dazu müsste entsprechend verbessert werden.

Ja, jetzt kann man sagen Einiges sollte man in Photoshop machen, Einiges ist zu weit weg,
... aber genau solche Services wünsche ich mir eben von einer idealen Komponente.


Rollo