EXEMPLE D'UTILISATION DE SETDIBITSTODEVICE
vecchio56
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
22 août 2010
-
19 mai 2006 à 00:35
gabuzomeuh Messages postés 53 Date d'inscription jeudi 31 juillet 2003 Statut Membre Dernière intervention 28 mars 2007 - 12 août 2007 à 19:14
gabuzomeuh Messages postés 53 Date d'inscription jeudi 31 juillet 2003 Statut Membre Dernière intervention 28 mars 2007 - 12 août 2007 à 19:14
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/37657-exemple-d-utilisation-de-setdibitstodevice
https://codes-sources.commentcamarche.net/source/37657-exemple-d-utilisation-de-setdibitstodevice
12 août 2007 à 19:14
Moi je comprends pas pourquoi define BYTEWIDTH = 4*((3*TABWIDTH+3)/4) c'est a dire (TABWIDTH*3)+3.
Pourquoi + 3 ?
Qqn peut m'expliquer ?
Merci
22 mai 2006 à 22:48
22 mai 2006 à 21:03
myZeroMemory() boucle autant de tours que d'octets, pas terrible, il faut dérouler afin de faire le moins de sauts de code possible, c'est le plus pénalisant pour les perfs.
Exemple avec 8 octets (2 DWORDs) par tour:
__declspec(naked) void __fastcall bnZeroMemory(void *destination, UINT size)
{ // ECX destination, EDX size
__asm {
test edx, edx
mov eax, edx
je short zeroEXIT
and eax, 7
sub edx, eax
jz short finHUIT
parHUIT:
mov dword ptr[ecx], 0
mov dword ptr[ecx+4], 0
add ecx, 8
sub edx, 8
jnz short parHUIT
finHUIT:
test eax, eax
je short zeroEXIT
parUN:
mov byte ptr[ecx], 0
inc ecx
dec eax
jnz short parUN
zeroEXIT:
ret 0
}
}
22 mai 2006 à 16:21
Désolé SAKingdom, je me suis égaré quand j'ai vu qu'on parlait d'optimisation.
22 mai 2006 à 15:06
lpBits[tmp]=bluelevel;
lpBits[tmp+1]=greenlevel;
lpBits[tmp+2]=redlevel;
tmp += 3;
Le but de cette source est en partie d'expliquer comme le calcule des positions dans le buffer s'effectue. Si je fais tmp += 3, sa reviend à expliquer une méthode pour dessiner des rectangles. Hors avec ce que j'explique et avec un peut d'imagination, on peut tout faire avec ça même du 3D.
22 mai 2006 à 13:15
Si on fait le tout en 1 'lea' alors no probleme.
Regarde "Agner Fog" (google), MASM32 inclut un fichier sur les optimisations.
Manuels Intel: http://brunews.free.fr/brunews/download/Intel.rar
Michael Abrash explique aussi tout cela dans ses bouquins.
22 mai 2006 à 12:21
S'il est vrai que les optimisations de compilations sont efficaces, on ne sait pas trop ce que fait réellement chaque compilateur. De plus, pour mon boulot, j'utilise les mêmes algos sur plusieurs plateformes differentes et donc plusieurs compilateurs differents (et plus ou moins evolués selon la plateforme). Donc, à la base, mieux vaut que j'optimise au max mon code sans trop savoir ce qu'a dans le ventre chaque compilateur.
Je n'ai plus que de vague souvenir de l'assembleur, mais il me semblais qu'un shift soit fait qu'en 1 seul cycle.
Il est vrai qu'avec la puissance actuelle des PC ainsi que les optimisations des compilateurs pour PC, j'ai délaissé l'assembleur depuis près de 10 ans.
En tout cas ton info est très interressante.
Si tu as des liens parlant des optimisations, je suis prenneur.
22 mai 2006 à 11:16
le but ici est d'indiquer au compilo de mettre un 'lea' donc pas de forcer un shift plus couteux en cycles.
22 mai 2006 à 11:09
22 mai 2006 à 11:01
Sans chercher midi à 14h, ton code peut être facilement optimisé en faisant :
int y 0; int x 0;
int tmp = (TABHEIGHT-1) * bytewidth;
for (y = 0; y < TABHEIGHT; y++)
{
int tmp2 = tmp;
for (x = 0; x < TABWIDTH; x++)
{
//Écriture dans le tableau de couleurs des 3 octects de couleur (BGR)
lpBits[tmp]=bluelevel;
lpBits[tmp+1]=greenlevel;
lpBits[tmp+2]=redlevel;
tmp += 3;
}
tmp = tmp2 - bytewidth;
}
Sur mon micro, ta fonction originale mets à peu près 2ms, avec les changements que je te propose, => env 1,2 ms
au passage pour BruNews, on pourrait en plus faire :
(TABHEIGHT-y-1)*BYTEWIDTH+x+(x<<1) (ah, les vieux souvenir du DOS avec son mode 320x200)
21 mai 2006 à 00:54
21 mai 2006 à 00:49
tmp = (TABHEIGHT-y-1)*BYTEWIDTH+x+x*2
21 mai 2006 à 00:43
21 mai 2006 à 00:41
21 mai 2006 à 00:35
21 mai 2006 à 00:27
21 mai 2006 à 00:23
imul edx,edx,3
C'est de la daube ce imul, au moins 12 cycles, remplacer par:
mov edx, dword ptr[x]
lea edx, [edx+edx*2]
20 mai 2006 à 23:48
mov eax,15Eh
sub eax,dword ptr [y]
lea ecx,[eax*4-4]
imul ecx,ecx,107h
mov edx,dword ptr [x]
imul edx,edx,3
add ecx,edx
mov dword ptr [tmp],ecx
20 mai 2006 à 22:35
xor ebx, ebx ;;; y = 0
lblFOR:
;;; divers codes
inc ebx
cmp ebx, TABHEIGHT
jb lblFOR
for (y = TABHEIGHT - 1; y >= 0; y--)
mov ebx, TABHEIGHT - 1
lblFOR:
;;; divers codes
dec ebx
jns lblFOR
On voit ici que boucler VERS 0 est toujours meilleur que DEPUIS 0, à transformer tant que faire se peut.
A part cela, il faudrait vérifier comment le compilo a généré la multiplication par 3 dans:
tmp = (TABHEIGHT-y-1)*bytewidth+3*x;
Si tu vois un "mul 3" alors remplacer par un "lea eax, [eax+eax*2]"
bytewidth : ne me semble pas être recalculé donc mettre en constante dans un #define, tu éviteras un accès mémoire dans les boucles pour chaque ligne vue plus haut.
20 mai 2006 à 22:01
20 mai 2006 à 21:57
20 mai 2006 à 21:42
20 mai 2006 à 21:28
20 mai 2006 à 21:26
20 mai 2006 à 17:54
19 mai 2006 à 21:17
Merci pour ReleaseDC.
19 mai 2006 à 19:05
Ps: T'oublie un ReleaseDC()
Bon code.
19 mai 2006 à 03:14
19 mai 2006 à 01:55
19 mai 2006 à 00:37
19 mai 2006 à 00:35
Effectivement c'est beaucoup plus rapide de faire ca que de faire des SetPixel
En général, je n'utilise SetPixel que quand il y a une ou deux pixels à changer.
Dans ton exemple, je pense que FillRect sera encore plus rapide