GDI+ LockBits producing different strides with different 32bpp formats

Question

5.00/5 (1 vote)

See more:

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:

C++

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

The following call returns a stride of 4900 in bmData:

C++

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:

C++

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 4:47am

Ugly Moe

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

davidbakin · Answer 1 · 2014-03-01T15:20:00

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.