I’m trying to get Nuklear working with the SDL2_Renderer as its backend. There’s a demo of this in their repo at demo/sdl_renderer which I managed to compile and run. However, the window border and title doesn’t show up with Metal as the render driver, but it does with OpenGL as the render driver.
Here’s an image showing the difference, OpenGL on the left and Metal on the right:
I did an error check on the return from SDL_RenderGeometryRaw but the result was 0 at every call. I’m not sure how to debug this issue; it’s strange to me that some of the geometry (the widgets, in particular) does show up but the rest doesn’t (consistently so).
Some details of my setup: macOS Monterey 12.2.1, ARM64 (M1), Nuklear 4.9.6, SDL2 2.0.20 from Homebrew, clang 12.0.5 (target arm64-apple-darwin21.3.0)
Hypothesis: the first draw command each frame gets ignored for whatever reason. So, I threw in a synthetic RenderGeometry call with a single degenerate triangle before any Nuklear render calls. No change.
Next, I stepped through the nk_draw_for_each loop and rendered each iteration in a separate frame. What I found is that three calls were made each frame, one to draw the window background, the next to draw the widgets, and then finally one to draw the window border and that triangle at the bottom-right corner. Again, with OpenGL, the window and its border show up, but with Metal, only the widgets show up. This is still odd, because the widget geometry is more complex. Rounded corners = good, simple rectangles = bad.
Hypothesis: the triangles are wound the wrong way. So I iterated through the element indices, swapping every first and third. No change. Triangle winding is probably not an issue for 2D rendering.
Hypothesis: the renderer wasn’t being flushed often enough. So I manually flushed it. No change.
Hypothesis: one bad triangle was messing up the whole bunch. So I sent every triangle to RenderGeometryRaw separately. No change. Fused this with hypothesis 3 and flushed after every triangle also. No change.
@kbolino
looks strange …
if you compile SDL2 yourself, can you hard-code some
constant color in
src/render/metal/SDL_render_metal.m
METAL_QueueGeometry
Thanks to it, I found the problem: the clipping rectangle. The window background/border draw commands set a cliprect of {-8192, -8192, 16384, 16384} which worked fine in OGL and D3D but apparently confuses Metal. I clamped the cliprect to the viewport and it draws properly differently in Metal now.
This clamping might be causing other problems though… I didn’t think through the min and max. Anyway, this worked:
Addendum: it was not necessary to clamp w or h, only x and y had to be clamped. Also, I wouldn’t trust my choice of bounds above, since the cliprect is relative to the viewport. This is the better clipping choice:
The width and height change you suggest makes sense. It’s not necessary in this case (the cliprect being set here seems to mean “the entire viewport”) but would in other cases.
I haven’t built SDL from source, and I’ve never written any Objective-C, but I might be able to dig into it later.
Yeah, Metal doesn’t like it when the scissor rectangle is outside the viewport bounds IIRC.
The interesting thing is that, on macOS and iOS, OpenGL is now implemented as a layer on top of Metal. So the OpenGL layer must be validating the scissor rect, where Metal just tries to use it as-is.
If you try launching your app from Xcode, you can turn on Metal API validation and see what that says (up top, in the center status bar thing, where it says “YourApp > My Mac”, click on that, pick Edit Scheme, then under the Diagnostics tab turn on Metal API validation if it isn’t already)
-[MTLDebugRenderCommandEncoder setScissorRect:]:3635: failed assertion `Set Scissor Rect Validation
(rect.x(18446744073709543424) + rect.width(16384))(8192) must be <= render pass width(2400)
(rect.y(18446744073709543424) + rect.height(16384))(8192) must be <= render pass height(1600)
If I just ensure the x and y coords are not negative, I get:
-[MTLDebugRenderCommandEncoder setScissorRect:]:3635: failed assertion `Set Scissor Rect Validation
(rect.x(0) + rect.width(16384))(16384) must be <= render pass width(2400)
(rect.y(0) + rect.height(16384))(16384) must be <= render pass height(1600)
If I also apply the adjustment to the width and height suggest by @Sylvain_Becker, I get:
-[MTLDebugRenderCommandEncoder setScissorRect:]:3635: failed assertion `Set Scissor Rect Validation
(rect.x(0) + rect.width(8192))(8192) must be <= render pass width(2400)
(rect.y(0) + rect.height(8192))(8192) must be <= render pass height(1600)
Finally, if I incorporate knowledge of the viewport and clamp the width and height of the clip rect, the failed assertions go away. This is the adjustment code I had to apply in total:
I might peak under the hood tomorrow and see how viewports and clip rects are handled. It might also be necessary to clamp the viewport coordinates and dimensions.
