Stuff

Apparently the small caption font entry in the non-client metrics has been tweaked in Windows 8 CP to use the same font size as for main caption bars, which is a bit out of proportion for where it is intended to be used. Here you can see the problem it causes in WinDbg, where all of the dockable windows now have huge caption bars. Even better yet, the old dialog that used to allow the non-client metrics to be adjusted -- somewhat hidden in Windows 7 under the Window Color link in Personalization -- seems to have been removed, so this can't be fixed easily. I hope this is fixed for RTM, because otherwise it kinda sucks to be punished for trying to do the right thing by using system UI parameters.

I seem to have a knack for asking questions that no one has an answer to. The most recent one has to do with Microsoft's Direct3D 10level9 technology, which lets you write Direct3D 11 applications that target DX9-class hardware. Specifically, I wanted to know the positioning of pixel centers. As usual, I couldn't find anything on this in the documented and online, so I had to do some investigation and testing.

Before I get to the results, some background. The way that conventionally 3D rendering works is by sampling on a regular grid -- if you imagine that you have a continuous image with all your polygons rendered out at infinite resolution and then drop a regular grid of pins onto it, the color beneath all of the pinpoints determines the color of the pixels of the final image. I say "conventionally" because once you throw in multisampling, centroid sampling, etc. it gets a bit more complex, although it's still sampling. The positions of these samples can also be thought as pixel centers. Now, as it turns out, the exact placement of these samples in the clip space coordinate system differs between rendering APIs:

OpenGL, Direct3D 10/11: for x in [0, width), center is at (x+0.5)/(2*width)-1

Direct3D 9: for x in [0, width), center is at x/(2*width)-1

Looking at this, you might think that the D3D9 placement is simpler and thus better, but in fact it's incredibly annoying. The reason is that the samples aren't centered, but are shifted up and left by half a pixel in the coordinate space. This means that, unlike the OpenGL placement, the coordinate space isn't symmetric about (0,0), and far worse, it makes your projection matrix dependent on viewport size. When setting up a regular 3D scene, the usual approach is to just ignore the problem and render with an uncompensated projection matrix. After all, who's going to notice if the image is shifted by half a pixel? Thankfully, Microsoft adjusted the coordinate system in Direct3D 10 to match OpenGL's half-integer samples, but everyone who still has to deal with D3D9 is stuck with this.

With 2D rendering, the story is different. In this case getting the mapping right is critical, and failure to do so can result in serious artifacts such as directional smearing with multiple passes. My favorite symptoms are one pixel gaps along two edges of the screen, missing corners on rectangles drawn using lines, and a 2x2 box filter blur across the entire image. Point sampling is often used as a hack to fix this problem, but that's dangerous because the half pixel offset means you're sampling exactly between texels -- and numerical accuracy issues can then introduce a lovely diagonal seam across your image. The right way is to adjust your projection matrix, and that means schlepping around the viewport-dependent offset all over the place as well as getting all the minus signs right (the Y offset is negated from the X offset!).

That brings us to 10level9, which is a special Direct3D 11 back end that interfaces to a Direct3D 9 device driver. Problem is, the pixel center offsets are different between D3D9 and D3D10/11, so the question I had was, do I need to correct for the offset? There were a few ways this could work out: