Dessin sur form - Page 1

J'aurais besoin de pouvoir dessiner des trucs pixel par pixel sur une form, j'ai donc commencé par prendre un TImage, et comme je m'y attendais un peu, c'est super lent. En dessinant à même la form (Form.Canvas.Pixels[x,y] := color), c'est pas mieux.

Y'a quoi comme solutions (autre que "code ton propre composant" si possible ) qui pourraient aller un peu plus vite ?

tu dois pouvoir dessiner dans un objet image en ram, et coller l'image dès qu'elle est complète

Euh, tu crée un bitmap (32 bits de préférence, mais 16 c faisable aussi), ensuite ya une propriété Scanlines qui te permet d'accéder au bitmap directement en mémoire (Je me rapelle jamais de l'ordre des composantes, alors faudra que tu trouves ça en éxpérimentant, c pas super difficile)
Ensuite suffit que tu dessines le bitmap sur la form.

Autrement ya aussi DirectX (mais c du delphi alors... :/) ou OpenGL (:/) qui te permettent de dessiner des trucs assez rapidement.

ué DirectX et OpenGL déjà exit, c'est trop lent. pour le coup du bitmap, cad que je fais mes operations sur un TBitmap et une fois terminé je le load en un coup ?

vala

ué c ça. Tu peux même afficher le bitmap au fur et à mesure mais ça ralentit sensiblement le processus...
Mais DirectX et OpenGL trop lents...

pkoi pas, v essayer

[edit] Heu... qqun peut m'expliquer pkoi j'ai dit trop lent à propos d'ogl et dx ?
Trop gros (dans le sens de "trop bourrin" pr ce que je veux faire), certainement pas trop lent

moi j'ai lu trop lent à développer.

Heu nan je sais vraiment pas pkoi j'ai marqué ça

d'ailleurs pour en revenir au sujet, y'a 10 ans, on utilisait des enregistrements de base et des vues (espèce de représentation graphique des membres d'une classe) afin de gagner en rapidité, c'est plus lourd à cause de la redondance d'info (la structure + l'«écran») mais c'est plus rapide à l'exécution et (dans le cas à l'époque) beaucoup mieux adapté aux traitements déportés (client serveur de traitement ac moniteur transactionnel)

Si ton contrôle n'est pas visible pendant que tu traces, tu peux dessiner beaucoup plus rapidement. Mais il faut évidemment le mettre en AutoRedraw pour que tu voies quelque chose quand tu le remets en visible.

La méthode de GoldenCrystal impose aussi un Refresh() une fois le dessin terminé, mais c'est effectivement (beaucoup) plus rapide. Par contre j'ai utilisé un Bitmap 24bit, ça me semble plus naturel avec 3 couleurs entre 0 et 255.

ué, mais en 32 bits ça peut être plus rapide, parce que chaque pixel fait un long. En 24 bits, y'a des masques à appliquer (ou alors accéder aux pixels en deux temps, un word d'abord, puis l'octet manquant ensuite).

Enfin ça c'est assez théorique, parce qu'il me semble qu sur énormément de systèmes quand tu dis 24 bits en fait le buffer est alloué pour du 32bits et géré comme tel. Faudrait voir la doc des appels que tu utilises, ou la doc des appels systèmes utilisés par les appels que tu utilises.

Ué mais pas forcément... Un bitmap 24bits aura toujours un buffer 24bits quoi qu'il arrive
Le truc c'est surtout qu'en plus de la facilité d'accès pour le 32 bits, la conversion pour l'affichage (sauf si l'affichage est en 24 bits, ce qui n'est plus utilisé depuis pas mal de temps il me semble) est relativement triviale vu que la plupart des pc ont un affichage en 16/32 bits. Je sais pas exactement comment tout ça fonctionne sous windows, mais dans mes souvenirs le bitmap 24bits était plus lent à afficher que le bitmap 32bits. (enfin je vais aller vérifier, si ça se trouve ct l'inverse )

Au besoin ça devrait pas être d'une difficulté insurmontable pour changer ça

Et puis la différence risque d'être nettement moins flagrante que celle entre l'accès pixel par pixel et cette méthode.

Beuh, dans le source que je viens de regarder j'utilisais TBitmap.Pixels pour le rendu en temps réel et en fait c rapide (sachant que j'affichais le bitmap à chaque étape importante dans la progression)
(Par contre ct de mettre le format à 32 bits (pas testé avec 24 bits en fait) au lieu de laisser le réglage par défaut () qui rendait le truc lent, allez savoir pourquoi (#flemme# de recompiler alors je ferai pas de tests ))

-

remontage éhonté, surtout pour un post qui n'a rien à voir avec les posts précédents.

DirectDraw c'est obsolète

-

DirectX Graphics (aka Direct3D)

18:54 GoldenCrystal - Posté : 28-09-2004 M X
20:51 Orion_ - Posté : 06-12-2004 M X


Merci Orion_, prochain coup tu regardes la date..