While it may seem natural to compare renderable items to the old set of UI DAG objects, they have very different purposes. Existing UI DAG objects are not data containers but were instead designed to provide an artificial split of “UI functionality” from “non-UI functionality.” They mix together evaluation, translation drawing and non-drawing functions, all within one construct. As there is no renderer, each UI object acts as its own renderer.
Similarly, render items and the old set of draw requests should not be thought of as equivalent. A draw request can be considered to be anything without strict rules for what it can draw, for what data is required, and for the relationship between the two. As an example, it is quite easy to create a draw request which indicates that it will draw a wireframe, but instead pass data for control points, and end up drawing filled triangles. There are no real rules as to when node evaluation occurs, so data may be calculated on-the-fly at draw time.
In terms of resource management, all geometry in the old system is CPU based and there is no equivalent to geometric consolidation in the old system. Additionally, there is minimal support for GPU textures and output buffers and no support for GPU shaders and GPU states.
The internal render loop has the up-front overhead of always traversing through the scene (or at least the parallel DAG UI hierarchy) to re-evaluate and re-extract draw requests. Categorization is also employed in the old system but can be ignored at will as UI objects are ultimately responsible for how to categorize, update and draw. The render loop for the most part is closed except for some basic multi-passing. More details and comparisons will be given when discussing each interface.