Daß in deinem Fall die Kapazität der TImageList nicht ausreicht, ist nachvollziehbar. Dennoch würde ich im NodeDataRecord nicht das eigentliche Bitmap speichern, sondern eine Id auf eine Liste bzw. auf die entsprechenden der
DB-Bildtabelle. Ob du jetzt im Node selbst das Icon austauschst oder in der Liste macht im Grunde keinen Unterschied – abgesehen davon, daß nicht bei jedem Zugriff auf den Data-Record das Bitmap aus dem Speicher gekramt werden muß, denn das wird ja nur einmal beim Aufbau des Baums benötigt.
Das mit der Geschwindigkeit hab ich jetzt nicht mit einem TreeView ausprobiert, aber mit Datenbanken. Wenn ich z.B. eine Tabelle, die zwei Blob-Felder (ein Bitmap und ein RTF-Text) beinhaltet, sortiere, ist das ohne diese beiden Blob-Felder entsprechend schneller: Je mehr Datensätze in der Tabelle, desto größer der Geschwindigkeitsvorteil. Die benötigten Felder lasse ich dann aus einer zweiten Tabelle nach Bedarf selektieren (z.B. im AfterScroll-Ereignis). Mit anderen Worten: Da ich die beiden Blob-Felder nur zur Anzeige, nicht aber zur Anwendung von Such- und Sortierkriterien benötige, muß ich die nicht mitschleppen. Aus diesem Grund gibt es bei vielen Komponenten wie z.B. auch beim VTV die beiden Schalter BeginUpdate und EndUpdate.
Meine Bilder im dargestellten VTV kommen ebenfalls aus einer Datenbank und sind zudem ziemlich groß. Beim Baumaufbau werden diese Bitmaps, die an anderer Stelle in Originalgröße benötigt werden, mit StretchDraw in die Bitmaps der TImageList kopiert, wonach letztere dann dem VTV zugewiesen wird.