Y a t'il plus rapide que l'API StretchBlt pour copier l'image DC de l'écran vers

Résolu
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013 - 19 nov. 2012 à 19:09
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013 - 24 janv. 2013 à 10:04
Bonjours, une question importante à mes yeux et peut-être aussi à beaucoup de personne :
En faite cette fois pour faire court je cherche un autre moyen que l'API StretchBlt pour copier l'écran de mon bureau vers une image DC(picturebox ou compatible peut importe), mais beaucoup plus rapide !
car je trouve StretchBlt TROP LENT
...
Sinon, je m'explique sur une boucle for i&...
avec bitblt et donc en copiant tout l'écran 1600x900 j'arrive à finir la boucle au bout de 0.468s
Avant de vous donner le score de StretchBlt, devinez combien il aurrait du mettre sur une image de 300x168 =
...
en faite j'ai déjà fait des procédure de redimensionnement de taille, et c'est pas trés compliquer, exemple :
pour avoir une image 2xplus petite, il faut lire les pixels une fois sur deux et faire avancer la position destination toujours de 1 :
position_source&=position_source&+2:position_destination&=position_destination&+1
donc la procédure devrais être deux fois plus rapide !
en faite non elle seras surtout environ 1,9xplus rapide, car un peut être ralentie par certain calcul....
en tout cas lorsque j'avais une procédure la dessus qui fonctionnez très bien j'avais presque la même puissance de gagner en fonction de son taux de taille :
entre 1600x900 et 300x168 il y a un taux de 28 donc je devrais à peu prêt être 25x plus rapide
que si je prend toute l'image !
et bien non, je sais pas pourquoi mais StretchBlt finie la boucle pour me donner une résolution de 300x168 en 0.823s, soit DEUX FOIS plus lent que bitblt, et 50x plus lent que ce que je m'attendais ?!
Pourquoi ???§,!!!!!
c'est pas juste ! et pas logique
...
ALORS y a t'il un autre moyen que StretchBlt pour prendre une image et la rétrécir à la fois ?!

16 réponses

ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
19 nov. 2012 à 21:47
Touche Enter utilisée en oubliant le lien !
Le voici ===>
Tapez le texte de l'url ici.


________________________
Réponse exacte ? => "REPONSE ACCEPTEE" pour faciliter les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement vous dire ce qu'elle contient. Je n'interviendrai qu'en cas de nécessité de développ
3
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
20 nov. 2012 à 12:04
Waooouuu, trop fort les grand esprit ce rencontre, avant même de lire tes deux dernier message Ucfoutu, j'ai réfléchie hier soir à mon problème où
bitblt = 0.468s
et
StretchBlt = 0.823s (alors qu'il me donne une image plus petite !
...
et la réponse m'est venue tout seul, et c'est exactement l'idée de ton lien !
ce servir de bitblt pour simuler un StretchBlt, en mettant bitblt de cette manière
for y...
for x...
bitblt
next x
next y

tans pis si on l'appelle plusieurs fois, au moins il travailleras avec 50 000 pixels pour 300x168
au lieu de travailler avec 1 440 000 pour 1600x900

alors je mis suit mis tôt, tôt ce matin et ,hi,hi,hi...
c'est cool, et j'ai déjà un très bon résultat, que je vais essayer d'améliorer et PROMIT je vous mettrez une source la dessus remplaçant StretchBlt
moi qui pensez avant de me coucher rester bloquer à 100 images/s pour du 300x168, et bien là j'ai déjà plus de 500 images/S




alors bye bye StretchBlt, à la poubelle
vive le classic, et vive Bitblt !
...
pour répondre à banana, cela fait 20 ans que je fais du vb6, si je doit me concentrer sur un autre language j’opterais plus pour du php+html+script, et peut-être Windev, mais Beurggg... pas de vb2012, j'ai faillie me sentir mal quand j'ai lue un très bon tuto vb2012, qu'est ce qu'il y a comme différence et de contrainte
...
non décider je mourrais avec vb6 pour le basic, et je renaitrais petit à petit avec les autres !
d'ailleurs je consolide ma puissance vb6 avec pas mal de class, et des DLL fabriqué en assembleur, alors j'ai pas peur de VB2012, qui rame sur certaine machine
de plus oui j'ai pas mal de logiciel sous VB6, dans 4 pour une entreprise ! Donc impossible de faire marche arrière ! ET l'vant je le verras surement pas avec VBxxxx.
...
Mais sinon une question qui me trotte dans la tête, il y aurais plus rapide que Bitblt(API windows fabriqué en C ou asm) pour copier une images entière dans un tableau de type 4 x octets en utilisant du framework ?!?
car c'est la vitesse là qui m’intéresse, mon application marche bien !
et est-ce que l'on peut incorporer du framework dans vb6, certains lien parle du 3.5 maximum pour vb6 mais je ne vois pas comment les mettres ?! je le déclare, je passe par l'onglet références ? Où alors c'est pas possible ?!
3
Utilisateur anonyme
19 nov. 2012 à 19:25
Bonsoir,

Tu devrais évoluer vers un autre langage. Pourquoi persister avec cet outil dépassé pour développer ?
0
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
19 nov. 2012 à 20:21
Bonjours banana, heu je ne comprend pas bien tu parle de quoi de vb6 ou dune api windows, car si tu parle de vb6, je ne voie pas comment vb2012 serais plus rapide avec stretchblt ?
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
Utilisateur anonyme
19 nov. 2012 à 21:32
Oui je parlais de vb6. Il y a maintenant des fonctions toutes faites dans le framework .NET pour remplacer des tas de lignes de code par une seule et ceci sans passer par les API. Et bien sur en une fraction de seconde. Donc ça répond à la question de ton sujet.

J'ai du mal à comprendre pourquoi des gens perdent leur temps à développer dans des langages obsolètes. A moins que ce soit pour reprendre une appli indispensable (dans une boîte par exemple), je ne vois pas l'intérêt.

Désolé d'avoir perturbé ce fil de discussion
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
19 nov. 2012 à 21:46
Bonjour,
Je crois quant à moi que l'on ne peut réellement discuter dans parfaitement connaître tous les aboutissants des deux fonctions concernées de l'Api de Windows. S'ils peuvent être souvent les mêmes, selon le choix de l'utilisateur, BitBlt sera alors plus rapide et suffisant. Mais BiBlt ne sera pas toujours capable de faire de ce que peut, elle, faire StretchBlt.
Une seule certitude :
1) chacune des deux sera plus performante que la méthode PaintPicture de VB6
2) BitBlt sera à préférer dans certains cas et StretchBlt ne pourra être évitée dans d'autres. Au développeur de choisir laquelle utiliser dans tel ou tel autre cas de figure (en fonction du résultat à obtenir).
Je n'ai absolument pas l'intention de me lancer ici dans un long exposé à ce propos. Je vais me contenter d'inviter à la lecture très attentive de ceci :


________________________
Réponse exacte ? => "REPONSE ACCEPTEE" pour faciliter les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement vous dire ce qu'elle contient. Je n'interviendrai qu'en cas de nécessité de développ
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
20 nov. 2012 à 12:58
est-ce que l'on peut incorporer du framework dans vb6, certains lien parle du 3.5 maximum pour vb6 mais je ne vois pas comment les mettres ?!

Pour quoi faire ?
N'en déplaise aux fans (salut à eux) de VB.Net, cela ne t'apportera rien.
Aucun langage évolué basé sur Microsoft n'ira jamais plus vite que ce que permettent les fonctions de l'Api de Windows, dont il ne pourra de toutes manières éviter de se servir . Et : sauf à ce que l'on me prouve le contraire, VB.Net (langage évolué, lui également) se sert des fonctions de l'Api de Windows !
Re-salut aux "fans" de machin.net, s'ils pensent réellement que ce langage leur apporte, par rapport à VB6, autre chose qu'un plus grand confort (sans plus) de développement, hein
________________________
Réponse exacte ? => "REPONSE ACCEPTEE" pour faciliter les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement vous dire ce qu'elle contient. Je n'interviendrai qu'en cas de nécessité de développ
0
Utilisateur anonyme
20 nov. 2012 à 13:23
Bonjour à tous les deux.

C'est bien vous avez raison. Le changement fait peur.
Je vais profiter du soleil cet après-midi.
Bonne continuation
0
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
20 nov. 2012 à 14:00
Pas du tout, j'ai pas peur, comme je l'ais dit !
Je préfère comme une grande partie sur internet, quittent à changer (VB.net NOT EGAL VB6)
prendre autre chose :
mes tentations : php+html+script, et peut-être Windev
sur internet tout le monde parle beaucoup de "Visual C.net"
...
et plus vrai qu'internet, j'ai un de mes amis travaillant dans une boite de 15 personnes qui construissent des logiciels depuis pas mal de temps, ils ont 3ans pour migrer de VB6(à80%) vers PHP+JAVA+...
mais ils sont tous d'une même voie, pas de VB.NET ! (à ce moment n’hésitez encore, il m'ont tellement surpris, que j'ai lue du VB.net, et houlalala qu'elle changement !
d'ailleurs bien regarder je trouve le PHP plus BASIC
...
Bref c'est pas pour t'embetter banana, nous disons juste haut et fort, ce que nous ressentons, à cet instant sur VB.net(on ne sait jamais, il n'y a que les imbéciles qui ne changent pas d'avis), et que VB6 c'est quand même de la bombe, cela résiste bien...
D'ailleurs si VB.net te convient tant mieux, et lorsque quelqu'un me demande sur qu'elle language qu'il peut ce lancer, je ne lui conseil pas VB6 ni VB.net mais putôt PHP+java+... ou Windev
il faut mieux penser aujourd’hui qu'il n'y a pas que windows, mais aussi mac os, Android, etc...
0
Utilisateur anonyme
20 nov. 2012 à 19:15
Je suggérais juste une évolution vers un langage plus moderne pour répondre à ton problème de rapidité.
Il ne s'agissait pas de comparer un langage à un autre vois-tu ?
mais ils sont tous d'une même voie, pas de VB.NET
Et tu ne leur as pas demandé pourquoi ?
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
20 nov. 2012 à 19:23
Sazlut, banana32,
Et tu ne leur as pas demandé pourquoi ?

Probablement pour les mêmes raisons que les miennes : lourd (à tous coups. Je parle du poids à distribuer) et très souvent lent (même par rapport à VB6 !)
Je comprends donc assez bien que, changer pour changer, "on" pense à changer pour autre chose
J'irais même à préciser : tout sauf du Microsoft, qui me parait bien trop enclin à faire jouer au jeu de l'âne et de la carotte (je ne serais pas surpris que VB.Net ne soit qu'un tremplin utilisé dans le dessein de "faire passer" à C++ ).

________________________
Réponse exacte ? => "REPONSE ACCEPTEE" pour faciliter les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement vous dire ce qu'elle contient. Je n'interviendrai qu'en cas de nécessité de développ
0
ucfoutu Messages postés 18038 Date d'inscription lundi 7 décembre 2009 Statut Modérateur Dernière intervention 11 avril 2018 211
20 nov. 2012 à 21:07
Je voudrais ajouter ceci, banana32,
Je ne suis pas un "défenseur" de VB6, mais le défenseur des droits (dont les miens) de l'acheteur d'un logiciel.
Je ne suis pas non plus un détracteur de VB.Net, mais de la politique de "forcing" manifestement observée par son vendeur, ... au demeurant : celui qui vendait VB6.
Je suis en droit de penser qu'il y a là manoeuvre et que rien n'empêchera alors demain le même vendeur d'abandonner, comme il l'a fait avec VB6, le produit qu'il veut aujourd'hui imposer en remplacement de VB6. Il le fera alors logiquement comme il a abandonné VB6 : en s'arrangeant pour ne plus le vendre, ne plus le supporter, etc ... tendant ainsi à "forcer la main" à nouveau, au profit d'un autre de ses produits. C'est ce que j'appelle précisément le jeu de "l'âne et de la carotte". J'en ai été la victime UNE fois (avec VB6) en payant ce produit, mais également en m'investissant dans son langage. Il n'y aura pas une DEUXIEME fois. Je ne suis pas le seul, loin de là, à adopter cette position. Si Microsoft passait par là et lisait le présent message ===>> qu'il en tire l'enseignement adéquat



________________________
Réponse exacte ? => "REPONSE ACCEPTEE" pour faciliter les recherches.
Pas d'aide en ligne installée ? => ne comptez pas sur moi pour simplement vous dire ce qu'elle contient. Je n'interviendrai qu'en cas de nécessité de développ
0
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
22 nov. 2012 à 17:26
Même si je suis entièrement d'accord avec ucfoutu, je tient un signalé qu'un langage évolué n'est pas forcement plus rapide, d'ailleurs, même si un jours je passe à plus évolué à VB6, j’essayerais toujours d'être proche du code du CPU ou du GPU, éviter les intermédiaire, surtout là où j'ai le plus besoin de puissance !
VB6 ou C++ avec DLL en .ASM = SUPER SAYEN
la programmation la plus orienté objet n'apporte pas plus de rapidité, mais plus de confort ou de possibilité déjà toutes prêtes !
Mais avec mes procédure perso, mon VB6 deviens un VB6++
...
je suis entrain de stabilisé ma vitesse et j'ai donc gagné 3 à 6 fois la vitesse qu'avec StretchBlt !!!

voici un aperçu fixe de ma procédure :


Create_objet_bitmap lx&, 1, 32, DC&, Adresse_du_bitmap&, NEW_Handle_DC&, NEW_Handle_Bitmap&

SelectObject NEW_Handle_DC&, NEW_Handle_Bitmap&

saut_ly! ly& / New_ly&: saut_lx! lx& / New_lx&

For y2! = 0 To ly& - 1 Step saut_ly!
BitBlt NEW_Handle_DC&, 0, 0, lx&, 1, DC&, Capture_ecran_X%, CInt(y2!) + Capture_ecran_Y%, vbSrcCopy

COPYMEMORY2 ByVal Adresse_du_bitmap&, le_futur_rgb(Y& * New_lx& + 3), New_lx& - 1, 4, SAUT_, saut_lx! * 1024, OPERATEUR_AND_, 16777215

Y& = Y& + 1
Next y2!

DeleteDC NEW_Handle_DC&
DeleteObject NEW_Handle_Bitmap&

En faite c'est juste dommage de ne pas avoir tout de même l'adresse ou est afficé les pixels de l'écran, car là sinon
...
bon je retourne sur mes procédure à bientôt pour la nouvelle source ECRAN_TO_RGB et la copymemory2 en .DLL
0
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
8 déc. 2012 à 20:06
Rebonjour, je suis toujours sur ma procédure ecran_to_rgb qui copie l'écran 32bits, et redimensionne à la taille que l'on veut pour mettre dans un tableau de 24bits !!!
Je suis content car j'ai presque terminé, encore quelque test, puis l'utilisation et je mettrez en ligne, en attendant je retire une chose que j’aurais put faire comprendre, comme quoi StretchBlt c'est un mettre à la poubelle,... En faite Non, et je n'avais pas compris ce que Ucfoutu voulais me dire à ce sujet(il faut que je lise un peu plus entre les lignes )
Voilà en faite 5 mode à moi qui prend la même taille d'écran et la redimensionne à la même taille:

1 = 150/s beaucoup moins de qualité
2 = 95/s moindre qualité
3 = 71/s qualité normal
4 = 41/s avec StretchBlt en mode aliasing
5 = 15/s avec StretchBlt en mode anti-aliasing

comme vous pouvez le voir j'ai réutiliser StretchBlt, car j'en ais besoin quand même grâce à sa trés bonne qualité d'image, surtout sur le dernier mode ! Mais cela fait tout de même presque 5xplus lent que mon mode normal !
heureusement j'en ais besoin que dans certaine condition de taille redimensionné !
je vous redonne l'utilisation de l'API StretchBlt avec ses options, car il n'est pas facile de trouvez cela sur internet !

Private Enum StretchBltModes
BLACKONWHITE = 1 ' Mode pas defaut, améliore la lisibilité des ecriture noir !
WHITEONBLACK = 2 ' Mode améliore la lisibilité des ecriture blanc !
COLORONCOLOR = 3 ' Mode améliore la lisibilité des ecriture color !
HALFTONE = 4 ' Mode avec Anti-aliasing(3xplus lent)
MAXSTRETCHBLTMODE = 5 ' Mode améliore la lisibilité des ecriture color et blanc(beaucoup trop de blanc sur les côté) !
End Enum 'les mode les plus intéréssant sont le 1 et 5
Private Declare Function SetStretchBltMode Lib "GDI32" (ByVal hDC As Long, ByVal nStretchMode As StretchBltModes) As Long
Private Declare Function StretchBlt Lib "GDI32" (ByVal hDC As Long, ByVal X As Long, ByVal Y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hSrcDC As Long, ByVal xSrc As Long, ByVal ySrc As Long, ByVal nSrcWidth As Long, ByVal nSrcHeight As Long, ByVal dwRop As Long) As Long

et pour l'utiliser :
If qualite_1_a_5 = 5 Then
SetStretchBltMode NEW_Handle_DC&, HALFTONE
Else
SetStretchBltMode NEW_Handle_DC&, BLACKONWHITE
End If
StretchBlt NEW_Handle_DC&, 0, 0, New_lx&, New_ly&, DC&, Capture_ecran_X%, Capture_ecran_Y%, Capture_ecran_X2% - Capture_ecran_X% + 1, Capture_ecran_Y2% - Capture_ecran_Y% + 1, vbSrcCopy

voilà, en cas pourquoi StretchBlt était beaucoup plus lent, il y a derrière beaucoup plus qu'un simple redimensionnement...
à plus
PS : Avez-vous donc toujours plus rapide que StretchBlt avec son mode Anti-aliasing, car 15 images par secondes, là c'est tout de même très lent ???
je suis prêt avec travailler en OpenGl ou directX s'il le faut !
0
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
24 déc. 2012 à 10:26
...et on continue :
j'ai réussi à reproduire en basic l'effet anti-aliasing de StretchBlt (indentique !)
en faite c'était simple :
exemple pour réduire une image de 1600x900 vers 900x450(donc là, deux fois plus petit en x et y)
il faut pas sauter 1 pixels, à chaque lecture :
mem_desti(0)=mem_source(0):mem_desti(1)=mem_source(2):mem_desti(2)=mem_source(4)
car là, oui on réduit l'image mais on oublie des pixels essentielle !
Imaginez que vous voulez réduire un text, avec des lettre comme le "I", ou le "T", vous avez une chance sur deux de louper la barre du milieu !
Pourtant on veut rétrécir !
mais il faut lire tout de même tout les pixels, en faite il faut faire une "MOYENNE" de tout les pixels sources pour donner quelques pixels desti :
mem_desti(0)=(mem_source(0)+mem_desti(1))/2,... pour faire simple, mais c'est un peu plus complexe
en faite vous devez grouper les R, puis les G, puis les B pour pouvoir faire une couleur !
pour une image de 1600x900 vers 900x450, on va prendre 4xpixels donc 12xcouleur pour en avoir qu'un seul donc 3xcouleur !

je vous donne lecture de ma procédure, même si elle ne vous servira à rien, elle vous mettera sur la piste :

Public Sub Rgb_to_Rgb_Effet(ByRef mem_rgb_source() As Long, ByRef mem_rgb_desti() As Long, ByVal new_lx&, ByVal new_ly&)
'cette procédure rezize, est l'egal en qualité de StretchBlt en mode halftome(anti-alising)
' mais elle est beaucoup plus lente, il faut la créer en assembleur !

lx& mem_rgb_source(0): ly& mem_rgb_source(1)
ReDim Preserve mem_rgb_desti(lx& * ly& + 3)
mem_rgb_desti(0) lx&: mem_rgb_desti(1) ly&
mem_rgb_desti(2) = mem_rgb_source(2)
saut_ly! ly& / new_ly&: saut_lx! lx& / new_lx&
carre& = (saut_ly! * saut_lx!)
For Y2! = 0 To ly& - 1 Step saut_ly!
pos2& Y& * lx& + 2: pos& Y2! * lx& + 3
For X2! = 0 To lx& - 1 Step saut_lx!

'X& X& + 1: mem_rgb_desti(pos2& + X&) mem_rgb_source(pos& + X2!)
couleur& 0: couleur_R& 0: couleur_G& = 0: couleur_B& = 0
For y3& = 0 To saut_ly! - 1
For x3& = 0 To saut_lx! - 1
' couleur& = couleur& + mem_rgb_source(pos& + X2! + x3& + y3& * lx&)
couleur& = mem_rgb_source(pos& + X2! + x3& + y3& * lx&)
couleur_R& = couleur_R& + couleur_to_rgb_turbo(couleur&).red
couleur_G& = couleur_G& + couleur_to_rgb_turbo(couleur&).green
couleur_B& = couleur_B& + couleur_to_rgb_turbo(couleur&).blue
Next x3&
Next y3&
couleur_R& = couleur_R& \ carre&
couleur_G& = couleur_G& \ carre&
couleur_B& = couleur_B& \ carre&
X& X& + 1: mem_rgb_desti(pos2& + X&) RGB(couleur_R&, couleur_G&, couleur_B&)

Next X2!
X& 0: Y& Y& + 1
Next Y2!
End Sub

et cela marche !
maintenant à moi de trouver le moyen pour la passer cela en assembleur DLL et battre StretchBlt !
j'espère y arriver
faut dire que la fourchette de puissance et mince entre Bitblt et StretchBlt il y a 6x la différence de puissance, j'ai peu de marge, et dans mon calcul VB il y a beaucoup de division le cauchemar des programmeurs en terme de puissance !
0
rebixav Messages postés 130 Date d'inscription dimanche 16 décembre 2007 Statut Membre Dernière intervention 28 janvier 2013
24 janv. 2013 à 10:04
je fait une bref de début de conclusion sur un StretchBlt plus rapide !
cela y est j'ai réussie en assembleur un StretchBlt deux fois plus rapide, j'ai pas pus faire mieux, mais je trouve déjà cela trés bien ! Et en plus de trés bonne qualité !
j'espère en finir au plus vite avec tout mes travaux pour vous donner ma procédure Ecran_to_RGB qui prend tout en compte, avec 4 niveau de qualité et des puissance allant de 2 à 10 fouis plus rapide !
merci à bientôt
0
Rejoignez-nous