Olli Wang

Thanks for reply. The default value of `BGFX_CONFIG_TRANSIENT_VERTEX_BUFFER_SIZE` is big enough to not cause vertex buffer overflow. I tried to inspect and play with the `glnvg__fill()` function, and it seems...

Just generated a sample code at https://gist.github.com/olliwang/5454465c18bb601d2619f40aeddf96a0 And here's the difference tested on iPhone 6s+. PS. Both look the same when using `nvgStroke()` instead of `nvgFill()`. 

I thought the bug is caused by `m_textureDescriptor.pixelFormat` in `renderer_mtl.mm`. The pixel format is initialized as `MTLPixelFormatDepth32Float_Stencil8` in iOS correctly but changed to other at some point. It seems `nvgFill()`...

@bkaradzic It seems the pixel format changes after calling the `nvgluCreateFramebuffer()` function. I just wrote a simple test code and it won't change the pixel format if I commented out...

@bkaradzic Thanks, but it doesn't work. I added the following code to the `RendererContextMtl::submit()` method. if (m_textureDescriptor.pixelFormat != MTLPixelFormatDepth32Float_Stencil8) printf("Wrong Pixel Format\n"); else printf("Correct Pixel Format\n"); And `Wrong Pixel Format`...

@bkaradzic Unfortunately that doesn't work either. I found that the pixel format is changed because of this line: https://github.com/bkaradzic/bgfx/blob/master/src/renderer_mtl.mm#L2497

Found the solution. This line should also change to `MTLPixelFormatDepth32Float_Stencil8` https://github.com/bkaradzic/bgfx/blob/master/src/renderer_mtl.mm#L584 Now the pixel format is consistent in `RendererContextMtl::submit()` for iOS. Too bad this still doesn't fix the broken `nvgFill()`...

MetalNanoVG follows the style of the corresponded NanoVG project. To do what you suggested here, we need to touch the original NanoVG code and MetalNanoVG won't share the same `nanovg.c`...

Is it visible on a retina screen?

@olilarkin Are you using macOS older than 10.14? I saw the same effect on my old MacBook Air with macOS 10.13.x installed. However, the issue is gone after I upgraded...