problème avec GetDIB

Version imprimable

28/12/2006, 18h24
slylafone

problème avec GetDIB

Bonjour,

Mon but est d'imprimer une TBitmap sur le Canvas de TPrinter.
J'utilise donc les méthodes GetDIBSizes et GetDIB pour convertir le bitmap en DIB (puis j'utilise la fonction StretchDIBits, comme recommandé ici)

Cependant, sur Windows XP (et Window 2000 je crois) la fonction GetDIB échoue de manière assez aléatoire (assez rarement quand même). Ca fait un moment que je traine ce problème, et je ne suis pas le seul, mais je n'ai jamais trouvé LA solution... HELP !
30/12/2006, 18h53
yarp
J'ai beaucoup souffert avec les DIBs, je pense que le problème vient de la gestion de la mémoire par la carte vidéo (car c'est elle qui prends en charge le chargement conversion des images). Cela explique que cela fonctionne et parfois pas.
Ce qui ne va pas dans l'exemple c'est GetMem, FreeMem.
Voici ce que je fais à la place:
Code:

1 2 3 4 pBitmapHeader = (BITMAPINFO*)::HeapAlloc(::GetProcessHeap(),NULL,iMemNeeded); ... ::HeapFree(::GetProcessHeap(),NULL,pBitmapHeader);
ps Je n'utilise pas de TBitmap mais le principe est le même.

yarp
www.senosoft.com
08/01/2007, 13h07
slylafone

Ok merci beaucoup pour la réponse Yarp.
Je vais essayer t'intégrer ton astuce. Je serais très étonné si ça fonctionne mais tu as l'air de bien connaitre ce domaine.

Sinon une autre solution serait de charger le DIB à partir d'un fichier BMP (sans passer par un TBitmap donc)...
Et quelle classe utilises tu au lieu de TBitmap ?

Encore merci
08/01/2007, 16h55
yarp

Une classe perso (mon appli traite les images et je me suis inspiré à l'origine de PaintLib) mais qui revient in fine à charger un BITMAPINFO (je charge le BITMPAINFOHEADER et les Bits et après je reconstruit les Dibs seulement quand j'en ai besoin pour ne pas laisser le gourmand Windows gérer lui-même les Handles ;). D'ou j'avais besoin de construire les Dibs.

Comme je te le disais le caractère pseudo aléatoire provient de la différence de gestion de mémoire entre ton appli et celle de la carte vidéo, car quand tu alloue la mémoire pour un Dib c'est la carte vidéo qui prends en charge la conversion. Or les drivers de carte sont assez capricieux, pour le moins. HeapAlloc résoud le problème, car la mémoire "is not movable" et est Thread Safe (cf. Msdn), en bref ça fixe les drivers.
http://msdn2.microsoft.com/en-us/library/aa366597.aspx

Vu ce matin sur CodeGear et qui pourrait t'intéresser, "Printing a TImage":
http://dn.codegear.com/article/22018

Il y a du GetDiBits et du GlobalAlloc (que je te conseille de remplacer par les HeapAlloc comme ci-dessus), on touche au coeur du sujet.

yarp
www.senosoft.com

J'ai donc mis en place les HeapAlloc...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
bool __fastcall DrawBitmapToPrinterCanvas(Graphics::TBitmap *pBitmap, TCanvas *pCanvas, TRect rect)
{
    unsigned int headerSize, imageSize;
    BITMAPINFO *pBitmapHeader = NULL;
    void *pBitmapImage = NULL;
    int result = GDI_ERROR;
    try
        {
        GetDIBSizes(pBitmap->Handle, headerSize, imageSize);
        //pBitmapHeader = (BITMAPINFO *)malloc(HeaderSize);
        //??? pBitmapImage = (void *)malloc(ImageSize);
        pBitmapHeader = (BITMAPINFO*)::HeapAlloc(::GetProcessHeap(), NULL, headerSize);
        pBitmapImage = (void *)::HeapAlloc(::GetProcessHeap(), NULL, imageSize);
        if (GetDIB(pBitmap->Handle, pBitmap->Palette, pBitmapHeader, pBitmapImage))
            {
            pCanvas->Lock();
            result = StretchDIBits(pCanvas->Handle, rect.Left, rect.Top, rect.Width(), rect.Height(),
                          0, 0, pBitmap->Width, pBitmap->Height,
                          pBitmapImage, pBitmapHeader,
                          DIB_RGB_COLORS, SRCCOPY);
            pCanvas->Unlock();
            }
        }
    catch(...)
        {
        }
    //if (pBitmapHeader != NULL) free(pBitmapHeader);
    //if (pBitmapImage != NULL) free(pBitmapImage);
    if (pBitmapHeader != NULL) ::HeapFree(::GetProcessHeap(), NULL, pBitmapHeader);
    if (pBitmapImage != NULL) ::HeapFree(::GetProcessHeap(), NULL, pBitmapImage);
    return (result != GDI_ERROR);
}

Pour l'instant, je ne sais pas si le problème est résolu. En fait, je n'arrive pas à reproduire le problème sur mon PC avec l'ancien ou le nouveau code.

Par contre j'aurai rapidement le retour de mes clients... En tout cas, merci énormément Yarp pour ton aide. J'ai passé pas mal d'heure à chercher une solution sur Internet et à retourner le problème dans tous les sens (fuite de mémoire ? problème de cerveau ?). Alors si ta solution fonctionne... :mrgreen:

A+

10/01/2007, 11h29
yarp

Imho I think so. Je distribue mon appli à des milliers d'exemplaires et si problème est en effet aléatoire (car dépends des cartes graphiques) je n'en ait plus entendu parlé depuis que j'utilise HeapAlloc. Si cela ne fonctionnait pas je te conseille en tout cas de travailler sur cette partie allocation de mémoire.
Il est vrai que le problème est rarement évoqué, voire pas du tout, et la connaissance que j'en ait est purement empirique. J'ai remarqué que à chaque sortie d'un nouveau modèle de la NVidia GeForce le phénomène se produisait, et que dès leurs premiers patchs il était résolu => ma déduction.

yarp
www.senosoft.com
13/01/2007, 14h26
slylafone

Bon eh bien un client (qui a assez souvent ce problème d'impression d'image) a eu un gros problème avec la nouvelle version lors de l'impression : Son PC a complétement planté... Il a dû couper l'alimentation pour pouvoir redémarrer :triste:

Il s'agit sûrement des HeapAlloc (je n'ai jamais eu ce genre de bug auparavant).
C'est bizarre car c'est le seul a avoir eu ce problème et c'est celui qui était le plus "touché" par le problème d'impression d'image.

Je pense qu'il y a quand un petit problème sur son PC : Et maintenant que j'y pense, lorsque je suis allé lui installer le logiciel, j'avais vu un message bizarre de windows : "Votre carte graphique ne dispose pas d'assez de mémoire" ou un truc dans le genre...

Au fait, est ce que mon code (message précédent) te semble bon yarp ?
13/01/2007, 21h00
yarp

Je vais le tester demain et te répondre. Le cas m'intéresse aussi ;)

A ma connaissance HeapAlloc n'est pas lié à la carte graphique mais encore faut-il que celle-ci ait la capacité de faire les opérations. GetDeviceCaps permet de savoir ce tu peux faire ou pas, mais là je ne pourrais pas t'aider beaucoup car je m'en suit peu servi.

Par contre je peux déja te dire que je n'avais pas mis les test de base qu'il faut appliquer chaque fois que tu appelles une fonction de l'API, donc déja ça manque. Il faut toujours tester la valeur de retour, en cas d'échec il faut mieux faire return que d'avoir un plantage.

Je pense de toute façon qu'il faut s'inspirer de l'article de CodeGear que j'ai cité dans ma première réponse, avec allocation de mémoire Heap.

Je regarde demain.

yarp
www.senosoft.com

Bon eh bien voilà un code qui fonctionne à tous les coups (pour l'instant plus de problème :king:) ... Un grand merci à yarp pour m'avoir mis sur la voie.

Je pense que ce code mérite de figurer dans la FAQ ou dans les sources. (j'ai cherché pendant plusieurs jours cette solution).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
bool __fastcall DrawBitmapToPrinterCanvas(Graphics::TBitmap *pBitmap, TCanvas *pCanvas, TRect rect)
{
    int w = pBitmap->Width;
    int h = pBitmap->Height;
    HDC h_dc = pBitmap->Canvas->Handle;
    HDC h_mem_dc = ::CreateCompatibleDC(h_dc);
    HBITMAP h_mem_bmp = ::CreateCompatibleBitmap(h_dc, w, h);
    HBITMAP h_old_bmp = ::SelectObject(h_mem_dc, h_mem_bmp);
    int result = GDI_ERROR;
 
    //copy the image on the memory dc
    ::BitBlt(h_mem_dc, 0, 0, w, h, h_dc, 0, 0, SRCCOPY);
 
    //delete the mem dc
    ::SelectObject(h_mem_dc, h_old_bmp);
    ::DeleteDC(h_mem_dc);
 
    //get memory for a BITMAPIFO structure
    HANDLE h_bmp_info = ::GlobalAlloc(GHND, sizeof(BITMAPINFO) + (sizeof(RGBQUAD) * 256));
    BITMAPINFO* bmp_info = static_cast<BITMAPINFO*> (::GlobalLock(h_bmp_info));
    //set up the structure
    memset(bmp_info, NULL, sizeof(BITMAPINFO) + (sizeof(RGBQUAD) * 255));
    bmp_info->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
    bmp_info->bmiHeader.biPlanes = 1;
    bmp_info->bmiHeader.biBitCount = 16; //ou 32
    bmp_info->bmiHeader.biWidth = w;
    bmp_info->bmiHeader.biHeight = h;
    bmp_info->bmiHeader.biCompression = BI_RGB;
 
    //find out how much memory for the bits
    if (::GetDIBits(h_dc, h_mem_bmp, 0, h, NULL, bmp_info, DIB_RGB_COLORS))
        {
        //Allocate memory for the bits
        HANDLE h_bits = ::GlobalAlloc(GHND, bmp_info->bmiHeader.biSizeImage);
        void *bits = ::GlobalLock(h_bits);
        //this time get the bits
        if (::GetDIBits(h_dc, h_mem_bmp, 0, h, bits, bmp_info, DIB_RGB_COLORS) != 0)
            {
            //send the bits to the printer
            result = StretchDIBits(pCanvas->Handle, rect.Left, rect.Top, rect.Width(), rect.Height(),
                          0, 0, w, h,
                          bits, bmp_info,
                          DIB_RGB_COLORS, SRCCOPY);
            }
        ::GlobalUnlock(bits);
        ::GlobalFree(h_bits);
        }
    //clean up
    ::DeleteObject(h_mem_bmp);
    ::GlobalUnlock(bmp_info);
    ::GlobalFree(h_bmp_info);
    return (result != GDI_ERROR);
}

02/02/2007, 18h35
yarp

Bravo, et désolé de ne pas avoir donnée suite, pas mal de boulot et de soucis moi aussi.

Par contre je suis surpris que GlobalAlloc fonctionne mieux que HeapAlloc (j'avais utilisé GlobalAlloc dans une version intermédiaire puis je suis passé à HeapAlloc).

Ce qui est sur, c'est que ce code mérite de figuer dans la FAQ.

yarp
www.senosoft.com
09/02/2007, 10h11
yarp

Je me suis penché sur le problème HeapAlloc/GlobalAlloc aujourd'hui. La doc du MSDN est claire à ce sujet.

"Les fonctions globales sont plus lentes que les autres fonctions de gestion de la mémoire et n'ont pas autant de possibilités. Par conséquent, les nouvelles applications doivent utiliser les fonctions Heap. cependant, les fonctions Globales sont encore utilisées par DDE et le clipboard".

J'en déduit que pour une imprimante, ou pour certaines imprimantes, le protocole de communication devait être similaire à DDE/clipboard et ne supportait que GlobalAlloc.

Moralité: Le Msdn dit que ça marche mieux avec HeapAlloc sauf quand ça ne marche pas. Mais ne nous dit pas (du moins pas ici) comment reconnaitre les périphériques (cartes vidéos, imprimantes) qui ne supportent pas HeapAlloc.