Dev Blog #6: Check it out: rendering efficiency, batch.
Inexcusable failed street talk aside, rendering efficiency - time taken to draw the contents of a Davenport document to the screen - is just as important as efficiency in the parser and live search.
You wouldn't think a few panels and bits of text would cause any problems - and on a modern desktop PC they probably won't. Davenport is targeting tablets, laptops and lower-end PCs, though, so it's worth taking a look to make sure Unity isn't doing something horrible.
As is so often the case, unfortunately, it is. This is a shot from the frame debugger showing the draw calls for a document containing fourteen notes:
That's 28 separate draw calls, two per note - which is fine, but will stop being fine when there are hundreds or thousands of notes in a document.
The problem is sorting. If two notes overlap, we want one to obscure the other. And because the font is a different material to the note background, we end up alternating: draw a background, change material, draw some text, change material, draw the next background, change material - you get the idea.
What we want is to draw all the backgrounds and then all the text, but that looks ugly when notes overlap: the backgrounds overlap properly, but then both sets of text are drawn afterwards and get muddled up with each other.
Fortunately there is a solution. If we position every note at a different distance, we can draw all the backgrounds in the right order, then draw invisible masks into the Z-buffer (each one closer to the camera than the last) then draw the text, again starting at the furthest and ending with the nearest. The invisible masks we drew will prevent text at the back from getting muddled up with text overlayed on it - and we end up with a frame debugger for the same scene that looks like this:
A 'dynamic batch' is where Unity realises it can condense multiple draw calls into one because they all use the same material and render settings. Now we just have one draw call for the backgrounds and masks, and one for the text.
You wouldn't think a few panels and bits of text would cause any problems - and on a modern desktop PC they probably won't. Davenport is targeting tablets, laptops and lower-end PCs, though, so it's worth taking a look to make sure Unity isn't doing something horrible.
As is so often the case, unfortunately, it is. This is a shot from the frame debugger showing the draw calls for a document containing fourteen notes:
That's 28 separate draw calls, two per note - which is fine, but will stop being fine when there are hundreds or thousands of notes in a document.
The problem is sorting. If two notes overlap, we want one to obscure the other. And because the font is a different material to the note background, we end up alternating: draw a background, change material, draw some text, change material, draw the next background, change material - you get the idea.
What we want is to draw all the backgrounds and then all the text, but that looks ugly when notes overlap: the backgrounds overlap properly, but then both sets of text are drawn afterwards and get muddled up with each other.
Fortunately there is a solution. If we position every note at a different distance, we can draw all the backgrounds in the right order, then draw invisible masks into the Z-buffer (each one closer to the camera than the last) then draw the text, again starting at the furthest and ending with the nearest. The invisible masks we drew will prevent text at the back from getting muddled up with text overlayed on it - and we end up with a frame debugger for the same scene that looks like this:
A 'dynamic batch' is where Unity realises it can condense multiple draw calls into one because they all use the same material and render settings. Now we just have one draw call for the backgrounds and masks, and one for the text.
Comments
Post a Comment