TImageList-Alternative? Resource-Datei? Performance?

[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