Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: GDI+
I am writing code to retrieve image data from OpenGL into a GDI+ Bitmap. While doing so I ran into something odd.
 
Given the following definitions:
 

Gdiplus::BitmapData  bmData;
Gdiplus::Rect        gRect(0, 0, 1225, 753);
 

The following call returns a stride of 4900 in bmData:
 
LockBits(&gRect,                      // Portion of bitmap to lock
         Gdiplus::ImageLockModeWrite, // We wish to write to the bitmap
         PixelFormat32bppRGB,         // Pixel format we want
         &bmData);                    // The locked bits
The following call returns a stride of 4904 in bmData:
 
LockBits(&gRect,                       // Portion of bitmap to lock
         Gdiplus::ImageLockModeWrite,  // We wish to write to the bitmap
         PixelFormat32bppPARGB,        // Pixel format we want
         &bmData);                     // The locked bits
 

Only the pixel format has changed, and in both cases the pixel format is 32-bit, but the stride is bigger than it needs to be for the second scenario. Also, using PixelFormat32bppARGB works similarly to the first version (stride is 4900).
 
I'm not sure if the data matches the stride, or if the stride is incorrectly calculated. Does anyone know?
Posted 28-May-13 5:47am

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

I think the clue is that 4900 is not divisible by 8 but 4904 is. I suspect that the reason is that GDI+, when using PixelFormat32bppPARGB, is chosing a representation - including stride - that is closer to that expected by some lower level API or manipulation, giving better efficiency overall at the expense of some (trivial) amount of space.
 
For example, perhaps it is using SIMD instructions to do the premultiplication of alpha, or some other alpha-related calculation, and wants to store/fetch things in quadwords rather than doubleword while not dealing with odd boundary conditions at the end of each scanline. On another system the hardware might prefer scanlines to be a multiple of 16 bytes...
 
This is the reason (as you discovered) you should always rely on the given values of stride and not what you calculate yourself.
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 200
1 PIEBALDconsult 150
2 BillWoodruff 148
3 Jochen Arndt 135
4 DamithSL 130
0 OriginalGriff 5,695
1 DamithSL 4,506
2 Maciej Los 4,007
3 Kornfeld Eliyahu Peter 3,480
4 Sergey Alexandrovich Kryukov 3,190


Advertise | Privacy | Mobile
Web03 | 2.8.141216.1 | Last Updated 1 Mar 2014
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100