I am currently trying to implement a Spritebatch class for use with Direct3D 10 (through SharpDX). It's just meant as an easy way to do my 2D UI drawing, though of course any speed increases are welcome. As far as I understand the goals are:
1) As little data sent to the GPU as possible
2) As few Draw calls on the GPU as possible.
Now, as this is just about 2D rendering, I can acomplish goal 1 by using instancing (Create one quad in a vertex buffer, and use a second buffer for the specific data per sprite (transform, color etc...). Would using a geometry shader to expand a single vertex to a quad offer any advantage? Wouldn't it just incure GS overhead for the benefit of storing just 1 vertex instead of 4? I see people using it for billboarding but I fail to see the advantage it offers...
Now 2 is the tricky part. All the elements have the same geometry, and by using the vertex shader I can manipulate it to properly place the quad. But they also require the same texture if they are to be drawn in a single draw call. Now, If they all had the same dimensions, I could use a texture2Darray, but this certanly isn't the case with UI elements. A texture atlas is another choice, but since I want to support various display resolutions (i.e. scale up/down the texture), I need mipmapping, and mipmapping with texture atlases leads to color bleeding.
Just using a texture atlas and adding some pixel gutters seems to be the norm , but there is something missing here... Text.
Unless I use my own bitmap font engine, and add the fontbitmap to the same atlas, plus take care of drawing the text "myself" with the aforementioned quad (don't forget kerning unless I want monospaced fonts).. oh, and bitmap fonts look like crap anyway when scaled... then there is no point in even trying to "batch" the drawing of UI textures, since there is always going to be a bunch of text drawing calls interspaced between them. Either everything is in the atlas, or if I use ID3DXFONT10, then no point in bothering.
Now, I won't be sure unless I implement and profile the various algorythms, but am I off the mark on any of the aforementioned? Maybe just making a simple spritebatch without expecting too much from the "batching" aspect is the way to go, since it will only offer a (by way of pulling a number out my *ss) 20-30% reduction in draw calls, for something that really doesn't have that many calls to begin with (i.e. the UI).
Edited by gfxCahd, 13 December 2013 - 05:03 AM.