Re: [Chromium-dev] Display list management

[Robert E. <pa...@tu...>]

> I'm trying to understand what is the functionality of the dlm module in 
> Chromium.

"DLM" is the Display List Manager.  It provides for display list state roughly 
similar capabilities to what the state tracker provides for simple state, and 
can be used for similar purposes.

It is typically used to record the contents of all display lists in memory, for 
replay when necessary or for debugging issues involving display list contents. 
It can also be used to track state changes due to display list use (i.e., 
glCallList() can cause graphics state changes that are difficult to track any 
other way).

> Scanning the cr tree I found there are rather limited uses of it, 
> actually three SPUs: replicate, tilesort and expando
> 
> The first two fan-out one gl stream to several renderers, so I infer 
> that dlm is used to keep track of the display lists in these one-to-many 
> environments.

Right.  "tilesort" has options that allow it to send display lists "lazily", 
i.e. only to those hosts that need it.  In this case the display lists are 
cached on the host, and replayed as necessary.  "tilesort" also has an option to 
enable display list state tracking, which fixes some applications that rely on 
the use of state changes in display lists.

"replicate" is used for a specialized type of state replication for a particular 
VNC implementation.  This implementation uses an encoder module working beside 
the normal VNC stream in which the OpenGL command stream is encoded; the 
commands are then rendered on the remote viewer (instead of having the commands 
rendered locally and transmitted as pixmaps; this is a performance improvement 
for some applications).

The problem is that a new VNC viewer can attach at any time; and any new VNC 
viewer needs the entire OpenGL state (including display lists) sent to it so it 
can "pick up" already-started instances of OpenGL programs.  That's what the DLM 
is doing there.

> What about expando? The description indicates it "unfolds" a display 
> list. This will impact performance...in which scenario is this SPU 
> useful? debugging? does it have to do with correctness/conformance?

"expando" is something of a "toy" SPU, sort of like the "wet" SPU.  It provides 
an example implementation of how an SPU might use a particular feature, in a 
nominally valid but not terribly useful sort of way.  (It's certainly the case 
that the "wet" SPU is more fun than the "expando" SPU, though. :-)

Bob Ellison
Tungsten Graphics, Inc.