1 pièce(s) jointe(s)
Firemonkey (Delphi XE2) - Canvas vs controls -- soucis majeur?
Bonjour,
Je bute sur un gros soucis et je souhaiterai de tout cœur que ce soit moi qui rate l'évidence, parce qu'autrement, FireMonkey a un défaut de conception majeur, osons le mot! :calim2:
Le soucis est qu'il y a conflit entre les opérations que vous effectuez sur les canvas (d'un TImage par exemple) et le rafraichissement régulier qu'effectue Firemonkey sur les contrôles visuels.
J'ai bien entendu essayé de contourner le problème, mais je bute. Ma théorie est la suivante. FM fonctionne via DirectX en mode fenêtré. DirectX n'est pas threadsafe (de ce que j'en sais, mais quasi certitude). Le rafraichissement des controles visuels de FM se fait donc forcément dans le thread principal. Les opérations sur les canvas aussi du coup, puisque DirectX force à utiliser le thread principal.
Il n'y a apparemment aucune synchronisation entre le moment où FM déclenche les rafraichissement des contrôles visuels et la fin de la mise à jour des Canvas. Aussi régulièrement on a un conflit, qui est résolu par la mise en attente des Canvas, ce qui provoque visuellement un fort ralentissement visuel de leurs opérations.
Naïvement je pensais que le EndScene à effectuer sur le Canvas ou bien le BitmapChanged était en quelque sorte la synchronisation avec le reste des contrôles. Alternativement il faudrait que l'on puisse indiquer à FM de rafraichir les anims des contrôles uniquement quand on le dit, sur un go général.
En tout cas, le résultat est catastrophique. Si vous pensiez faire une application graphique ou un jeu en Firemonkey, vous pouvez oublier. Si je ne me trompe pas (et qu'il n'y a aucun moyen de contourner ce gros soucis), alors FM à un gros gros problème! :(
nb: j'ai essayé avec ou sans timer threadé, c'est encore pire...
Vous voulez la preuve? la voici, petite appli de test qui parle d'elle même
Version avec EXECUTABLE:
http://www.mediafire.com/?f9ojw4jx8rj5zuh
La version sans EXE en PJ de ce message.
