N° de bogue : StretchBlt()/StretchDIBits() échec avec Stretch très volumineux

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.

111865
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
3.00 3.10 WINDOWS kbprg kbbuglist
Symptômes
Si le facteur d'étirement est important, par exemple, lors de l'étirement d'une très petite taille à une hauteur de grande taille, StretchDIBits() et StretchBlt() peuvent retourner zéro (0) et n'affiche rien. La même bitmap avec un étirement de plus petite s'affiche correctement.
Cause
La plupart des pilotes d'affichage n'implémentent pas leurs propres StretchBlt() ou StretchDIBits() afin GDI doit simuler ces appels. Partie de la simulation de GDI implique l'allocation de mémoires tampons de travail temporaire, qui sont limités à 64 Ko. Si la taille de la mémoire tampon de travail est calculée est supérieure à 64 Ko, la hauteur des rectangles source et destination sont contient jusqu'à ce qu'ils soient inférieure à 64 Ko. Le problème est que si GDI doit continuer à diviser la hauteur par deux (2) pour obtenir une mémoire tampon inférieure à 64 Ko, la hauteur de source ou destination pourrait finir par atteindre une ligne de numérisation. À ce stade, l'appel échoue, car il ne peut pas interrompre une ligne d'analyse dans les sous-unités.

StretchBlt() et StretchDIBits() ne sont pas conçus pour fournir l'étirement illimité. Toutefois, ils sont susceptibles d'échouer un peu plus prématurément à leur limitation de conception.
Résolution
Si StretchBlt() ou StretchDIBits() échoue sur un étirement de grande taille, une application peut diviser l'image bitmap source, étirer les éléments individuellement et positionnez-les correctement une fois étiré. Une autre solution consiste à effectuer un étirement de plus petit. Il n'existe pas de formule pour déterminer exactement ce que les bitmaps échouera à quelle taille étirement.
Statut
Microsoft a confirmé qu'il s'agit d'un bogue dans les produits Microsoft répertoriés au début de cet article.
Plus d'informations
Pour reproduire le problème, créez une image bitmap environ 2048 pixels de large par 16 pixels. Ensuite, affichez la bitmap avec l'exemple DIBVIEW à partir du Kit de développement SDK de Windows 3.1. Choisissez fenêtre de Stretch dans menu d'options de DIBVIEW, afin que la bitmap est étirée conformément à la taille de la fenêtre client. Lorsque la hauteur est plus d'environ 200 pixels, la bitmap ne s'affichera pas.
buglist3.00 buglist3.10 3.00 3.10 échouent zoom

Avertissement : cet article a été traduit automatiquement

Propriétés

ID d'article : 111865 - Dernière mise à jour : 01/11/2015 00:50:16 - Révision : 2.1

  • Microsoft Windows Software Development Kit 3.0
  • Microsoft Windows Software Development Kit 3.1
  • kbnosurvey kbarchive kbmt kbbug kbpending KB111865 KbMtfr
Commentaires