Das wird bei
DirectX noch zusätzlich dadurch verkompliziert, dass Texturen in unterschiedlichen "Pools" residieren. Prinzipiell können sie im VRAM, und im Host-
RAM liegen, die Art des Pools definiert dann, wie
DirectX mit der Textur umgehen soll wenn gerendert und/oder vom Host gelesen und/oder geschrieben wird. Ans VRAM kommst du spätenstens nicht mehr ran.
Es wäre aber auch SEHR ungewöhnlich, wenn
DirectX da was verhackstückeln sollte. Sobald also die Daten über die
API als Textur/Surface korrekt geladen sind, ist es fast sicher, dass das Problem dahinter sitzt - also entweder in deinem Code, oder in dem von DelphiX. In beiden Fällen jedoch müsste dafür eine Änderung am Surface bewusst vorgenommen werden, so dass
DirectX entsprechend neue Daten aus dem Host-
RAM in die Textur übernimmt.
DX Ressourcen sind nur änderbar, wenn sie zuvor gelockt wurden. Da wäre dann evtl. dein Ansatzpunkt: Alle Stellen, an denen etwas zwischen einem Lock und Unlock auf ein Surface ausgeführt wird, sind potentielle Kandidaten. Sowohl in deinem Code, als auch im Source von DelphiX. Mit viel Pech hast du es dann sogar mit einem Multi-Threaded Problem zu tun, bei dem ein Thread über seinen "Kompetenzbereich" hinweg kritzelt, während irgendwo anders ein Lock aktiv ist. Das wäre schon ziemlich ekelig
. Erste Amtshandlung bei sowas: Bereichsprüfung anschalten, und wenn die wo anschlägt ist man meist fast schon am Ziel.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)