CreateCompatibleBitmap et CreateDIBSection (DC de Mémoire)

de ce que j'ai lu ici il semble que la plupart des Fenêtres des fonctions GDI sont accélérés. Ainsi, par exemple, un appel à BitBlt ou AlphaBlend utilise l'accélération matérielle si disponible. Il mentionne également que le contenu d'une fenêtre ne sont conservés que dans la mémoire vidéo. Maintenant c'est tout bon et vrai pour un fenêtre DC, mais comment puis-je utiliser un DC de mémoire qui réside dans la mémoire de carte vidéo? Et une fois que nous avons réalisé que la façon d'obtenir un accès direct aux pixels, je pense que ce serait la participation de 1. copie les données de la mémoire système de 2. modifier les données de pixel 3. copie de sauvegarde dans la mémoire vidéo.

J'ai essayé les deux approches, à la fois allouer de la mémoire système comme je peux le voir dans le gestionnaire de tâches...

  1. CreateCompatibleBitmap 
    HDC hDC = GetDC(NULL);
m_hDC = CreateCompatibleDC(hDC);
m_hBmp = CreateCompatibleBitmap(hDC, cx, cy);
ReleaseDC(NULL, hDC);

m_hOldBmp = (HBITMAP)SelectObject(m_hDC, m_hBmp);

    et ensuite appeler pour obtenir les bits

    GetBitmapBits(...)

    selon les différents commentaires, cela devrait en effet de créer le compatible bitmap en mémoire vidéo, mais pourquoi ne puis-je encore une augmentation de la mémoire système (même si je n'ai pas l'appeler GetBitmapBits)?

  2. CreateDIBSection 
    HDC hDC = GetDC(NULL);
m_hDC = CreateCompatibleDC(hDC);

BITMAPINFO bmi;
memset(&bmi, 0, sizeof(BITMAPINFO));
bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
bmi.bmiHeader.biWidth = cx;
bmi.bmiHeader.biHeight = -cy; //top-down
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = 32;
bmi.bmiHeader.biCompression = BI_RGB;
m_hBmp = CreateDIBSection(hDC, &bmi, DIB_RGB_COLORS, (void**)&m_pBits, NULL, NULL);

ReleaseDC(NULL, hDC);

m_hOldBmp = (HBITMAP)SelectObject(m_hDC, m_hBmp);

    dans ce cas, nous recevons le pointeur à l'bits immédiatement (m_pBits) il est donc évident que ces résider dans la mémoire du système...

Ou est-il une copie est conservée dans la mémoire du système pour les deux méthodes? Mais si je change de bits dans la mémoire du système à un appel à BitBlt aurait encore à vérifier/copie de la mémoire système à nouveau... pas très optimisé à mon humble avis.

EDIT: j'ai aussi essayé de créer de la mémoire du contrôleur de domaine à l'aide de la BeginBufferedPaint et GetBufferedPaintBits. Il alloue de la mémoire système comme bien, je suppose que c'est juste un wrapper pour les méthodes ci-dessus, mais les caches de la DC est donc un prochain appel n'a pas nécessairement de recréer une mémoire de DC. Voir Raymond Chen l'article.

EDIT #2: je crois que la vraie question est: Suis-je en train de faire le DC de mémoire de la création de corriger dans la méthode 1 ou 2 pour obtenir l'accélération matérielle opérations GDI? Pour moi tout semble rapide, et les deux méthodes fournissent la même vitesse trop, donc il n'y a pas vraiment moyen de le vérifier...

J'ai pensé qu'il réside toujours dans la mémoire du système et obtient seulement échangé dans la vidéo la mémoire lors du rendu de l'écran ...
De sorte que voudrait dire qu'on ne peut pas le créer dans la mémoire vidéo et le GDI n'est pas l'accélération matérielle en travaillant sur un DC de mémoire?
Les fonctions GDI pour blitting opérations d' sont l'accélération matérielle sous Windows 7 exclusivement. GDI+ est encore rendu logiciel, même sur Windows 7 et il est toujours beaucoup plus lent. Si vous faites quelque chose de complexe qui exige de performance de la réponse la plus simple est de ne pas utiliser l'interface graphique. Utiliser OpenGL ou DirectX si vous voulez un accès direct au matériel. GDI a été un sera toujours une abstraction.
De ce que j'ai lu fonctions GDI sont l'accélération matérielle sur toutes les versions de Windows à l'exception de Vista (à cause du pilote nouvellement introduit de conception). Je ne suis pas en utilisant GDI+ btw, et je ne recommande à personne de l'utiliser tout au plus, car ce n'est pas l'accélération matérielle dans Win7.
En outre, vérifier si la mémoire système est utilisé n'est pas un indicateur valide si oui ou non quelque chose est à l'accélération graphique matérielle. En fonction de la puce graphique, et même le pilote, la texture de données est stockée ou sauvegardés dans la mémoire système (par exemple, le comportement par défaut pour l'OpenGL). GDI est accéléré par le matériel tel qu'il est, mais vous n'avez pas de réel contrôle sur elle. Si vous la commande je suis d'accord avec AJG85 que vous devez utiliser une API graphique à la place.

OriginalL'auteur demorge | 2011-09-21

  1. 4

    Mémoire DCs ne sont pas créés sur un périphérique. Ils sont conçus pour mettre GDI de sortie dans la mémoire.

    De Dispositif De Mémoire Contextes sur MSDN:

    Afin de permettre aux applications de lieu de sortie dans la mémoire plutôt que de l'envoyer
    il à un réel de l'appareil, utilisez un périphérique de contexte pour les images bitmap
    opérations dites un contexte de périphérique de mémoire. Un DC de mémoire permet à l'
    système pour traiter une partie de la mémoire comme un périphérique virtuel.

    Si vous voulez l'accélération matérielle des graphismes en 2d, vous devriez envisager d'utiliser Direct2D.

    Aah qui rend les choses claires, et il dit aussi: Lors de l'affichage d'un DIB ou un DDB, créé à partir d'un DIB sur une palette de périphérique, vous pouvez améliorer la vitesse à laquelle l'image est tirée par l'organisation de la logique de la palette pour correspondre à la disposition de la palette système., Qui précise que la CreateCompatibleBitmap devrait être la méthode la plus rapide, mais depuis que mon système est exécuté en couleur 32 bits le CreateDIBSection à l'aide d'un 32-bit mise en page est tout aussi rapide (c'est le même format bitmap créée par les deux fonctions).
    De mon expérience avec Direct2D vs GDI de performance, je n'avais pas de recommander à l'aide de Direct2D. Il est lent, la même vitesse que le GDI.

    OriginalL'auteur MSN