Metal与iOS坐标系一致时，为何仍需翻转Metal输出图像？

Great question—this is one of those sneaky gotchas that trips up even experienced Metal developers, so you’re not alone in scratching your head over this! Let’s break down the key pieces you might be missing:

1. You’re mixing up texture coordinate systems with render target coordinate systems #

The critical detail here is that Metal’s texture coordinate system (origin at top-left) is not the same as its render target coordinate system (origin at bottom-left).

You’re right that Metal textures use a top-left origin, matching your image editor. But when you render that texture to the screen (or a CAMetalLayer drawable), the render target itself uses a bottom-left origin—just like OpenGL’s traditional coordinate system.

So if you map your texture’s (0,0) (top-left) directly to the render target’s (0,0) (bottom-left), the entire image will appear flipped vertically. This has nothing to do with the texture’s internal pixel storage—it’s a mismatch between where you’re sampling the texture and where you’re drawing those samples on the output surface.

2. Image file storage vs. Metal texture memory layout #

Even if you account for the render target origin, there’s a second layer of confusion here: how image data is stored on disk vs. how Metal expects it in texture memory.

Most image editors save files with pixel data ordered top row first (the first bytes in the file correspond to the top of the image). But by default, when you create a Metal texture (or use MTKTextureLoader), Metal expects texture memory to be ordered bottom row first for common pixel formats like BGRA8Unorm.

Wait, but why does this matter if both the editor and Metal use top-left origin? Because when you load that top-row-first image data into a bottom-row-first texture, the top row of your image ends up in the bottom of the texture’s memory. So even if you fix the render target coordinate mapping, the texture itself is internally flipped unless you tell Metal to account for the image’s row order.

3. Sampler descriptor settings can hide (or exacerbate) this #

If you’re using a default sampler descriptor, Metal’s textureOrigin property is set to .upperLeft by default. But if your texture’s memory is actually storing pixels in reverse row order (because you loaded a top-row-first image without adjusting), the sampler will still sample from the "top-left" of the texture memory—which is actually the bottom of your original image.

To fix this, you have two straightforward options:

• When loading the texture with MTKTextureLoader, set the MTKTextureLoaderOptionOrigin to .upperLeft to tell Metal to flip the image data during loading so it aligns with the texture’s coordinate system.
• Or, in your fragment shader, flip the texture’s y-coordinate manually by using 1.0 - textureCoord.y instead of textureCoord.y when sampling the texture.

Quick example to tie it all together #

Suppose you have an image where the top-left pixel is bright red:

1. The image file stores that red pixel as the first byte in its data.
2. If you load it into a Metal texture without adjusting row order, that red pixel ends up in the bottom row of the texture’s memory.
3. When you render to the screen (bottom-left origin), mapping texture (0,0) to screen (0,0) draws the texture’s bottom-left pixel (your original red pixel) to the screen’s bottom-left—making the whole image look flipped.

Fixing either the texture loading order or the shader’s y-coordinate will make the image display correctly.

内容的提问来源于stack exchange，提问作者johnbakers