I stumbled over this while porting font printing code from D3D to OpenGL.

I place all glyphs I potentially want to draw in an atlas which can have an arbitrary size depending on the resolution of the glyphs. In the case I tested, I ended up with an 243x211 atlas. In OpenGL the atlas looks "skewed" and I can't figure out why.

The problem does not appear if the atlas has a size of 256x201 for instance, without changing anything else. So I think the problem is directly related to the texture size. The data used to create the texture is allocated like this: data = new unsigned char[x * y]; So I'm not explicitly controlling the alignment or anything.

Any idea what could be going on here? Do I need glPixelStorei() in some form?

By default, pixel rows are required to be 4-byte aligned. I assume from your call to new that you're allocating single channel 8-bit images. That means your 243 pixel wide image is not a multiple of 4 bytes wide, so OpenGL assumes there's a byte padding after each row, since 244 is the next larger multiple of 4 bytes per row. Either pad your images accordingly, or set the unpack alignment to 1 with glPixelStore.

Do you know in what way this affects the texture data actually stored on the GPU. Will the driver automatically pad the texture if it doesn't fit the 4 byte alignment and is glPixelStore just an information how to decode the provided data, or will the texture actually reside in graphics memory like that?

Do you know in what way this affects the texture data actually stored on the GPU. Will the driver automatically pad the texture if it doesn't fit the 4 byte alignment and is glPixelStore just an information how to decode the provided data, or will the texture actually reside in graphics memory like that?

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.