La vitesse de décodage incroyable de GDI + et sa vitesse de tirage terrible!

Question

Merci pour les réponses & # 65292; En fait, je ne suis pas perplexe à propos du tirage au sort 1024 * 768 pixels, c'est plus lent que 100 * 100 pixels ... C'est si simple une logique .. Ce qui m'a rendu perplexe, c'est que l'algorithme d'interpolation de DrawImage peut être très lent, alors qu'il existe de nombreux algorithmes plus performants, et que son décodeur semble pouvoir décoder à partir d'un fichier jpg avec une certaine résolution, il est vraiment cool, je le recherche parfois lib gratuit pour faire cela ...

C'est vraiment étrange! J'ajoute le code suivant dans la méthode Paint. c: \ 1.jpg est un fichier jpg 5M, environ 4000 * 3000

// ------------------------------------------------- -----------------

HDC hdc = pDC->GetSafeHdc();
bitmap = Bitmap::FromFile(L"c:\\1.jpg",true);
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,200,200);

Ce qui précède est vraiment rapide! même en temps réel! Je ne pense pas que décoder un fichier JPG de 5 m puisse être aussi rapide!

// ------------------------------------------------- -----------------

HDC hdc = pDC->GetSafeHdc();
bitmap = Bitmap::FromFile(L"c:\\1.jpg",true);
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,2000,2000);

Le code ci-dessus devient très lent

// ------------------------------------------------- -----------------

Si j'ajoute Bitmap = Bitmap :: FromFile (L "c: \ 1.jpg", true); // dans la construction

partir

    Graphics graphics(hdc);
    graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
    graphics.DrawImage(bitmap,0,0,2000,2000);

dans la méthode OnPaint, Le code est toujours un peu lent ~~~

// ------------------------------------------------- ---------------------

Comparé au décodage, le processus drawImage est très lent ...

Pourquoi et comment ont-ils fait cela? Microsoft a-t-il payé aux responsables du décodeur le double du salaire que ceux chargés de l’écriture de drawingImage?

Answer 1

Vous n'avez pas besoin de décoder les fichiers JPG si vous réduisez le facteur 8. Les images JPG sont constituées de blocs de 8 sur 8 pixels transformés au format DCT. La valeur moyenne de ce bloc est le coefficient 0,0 du DCT. Donc, réduire un facteur de 8 est simplement une question de jeter tous les autres composants. Réduire encore davantage (par exemple, 4000 - 200) consiste simplement à passer de 4000 à 500, puis à une réduction normale de 500 à 200 pixels.

Answer 2

Alors, vous vous demandez vraiment pourquoi

graphics.DrawImage(bitmap,0,0,200,200);

est plus rapide que

graphics.DrawImage(bitmap,0,0,2000,2000);

Correct?

Le fait que vous dessiniez 100 fois plus de pixels dans le second cas pourrait y être pour quelque chose.

Answer 3

Il est possible que le décodage soit différé jusqu’au besoin. C'est pourquoi c'est si rapide.

Peut-être que sur le boîtier 200x200, GDI + décode seulement assez de blocs pour peindre en 200x200 et sur 2000x2000, ils décodent plus.

Les routines graphiques contiennent toujours des optimisations obscures que vous ne pourriez jamais connaître.

Peut-être que le réflecteur vous le dira?

Answer 4

Juste une supposition, mais pourriez-vous essayer de dessiner avec 4000x3000 ou 2000x1500? Peut-être que le fait que 4000 et 3000 soient divisibles par 200 accélère le tout et que le fait que 3000 ne soit pas divisible par 200 le ralentit (bien que cela puisse être vraiment étrange).

Généralement, effectuez un profilage ou une mesure du temps. Si 2000x2000 est environ 100 fois plus lent que 200x200, tout va bien. Et ne vous inquiétez pas si 2000x2000 est trop lent. Si votre écran présente une résolution de 1024x768, vous ne pouvez pas voir l’ensemble de l’image. Vous devez donc choisir la partie de l’image visible à l’écran et la dessiner. 1024x768 est 5 fois plus rapide que 2000x2000.