Re: [Chromium-dev] Chromium, DMX and OpenGL 2.0

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

> Also, I'm not clear on what all of the "props" and "chromium" props  
> values in the APIspec.txt file really mean. In particular, i dont'  
> understand what "nolist" means and whether a given function should use  
> it, and I'm not sure how to determine whether a given function should  
> be tagged "pack" or "extpack".

Off the top of my head...

The glNewList man page lists the functions that are considered to be "nolist":

>        Certain commands are not compiled into the display list  but  are  exe-
>        cuted immediately, regardless of the display-list mode.  These commands
>        are     glAreTexturesResident,      glColorPointer,      glDeleteLists,
>        glDeleteTextures,        glDisableClientState,       glEdgeFlagPointer,
>        glEnableClientState, glFeedbackBuffer, glFinish,  glFlush,  glGenLists,
>        glGenTextures,    glIndexPointer,   glInterleavedArrays,   glIsEnabled,
>        glIsList,     glIsTexture,     glNormalPointer,      glPopClientAttrib,
>        glPixelStore,     glPushClientAttrib,    glReadPixels,    glRenderMode,
>        glSelectBuffer, glTexCoordPointer,  glVertexPointer,  and  all  of  the
>        glGet commands.

Those, in a nutshell, are the "nolist" functions.  The "nolist" specifier is 
checked in the Python scripts that do automatic code generation, for example the 
"dlm" display list manager (which can track display lists itself, and has to 
know which functions are allowed to go into display lists) and the "tilesort" SPU.

The "checklist" specifier is related; it is used to flag commands that can 
either act as queries (which do not go into display lists) or rendering commands 
(which do), depending on the value of their parameters; think of glTexImage2D, 
which can be used with GL_PROXY_TEXTURE_2D to check whether the implementation 
can store a given texture, or with GL_TEXTURE_2D to actually affect rendering.

There are two levels of packing, one highly optimized path (where each command 
is packed as a single byte) and one "extended" path (where each command is 
packed as a single-byte CR_UNPACK_EXTEND opcode, with a four-byte "extended 
opcode" added to the start of the data stream).  Since only 254 optimized 
opcodes are available, some care in their choice is important; you want the 
opcodes that are used often, especially the ones with small data payloads anyway.

The "pack" and "extpack" indicators in APIspec.txt are used to make it easy to 
change that choice.  "pack" functions are compiled into the small opcodes, and 
"extpack" functions are relegated to the extended opcodes.

In general, you shouldn't change the current choices.  New opcodes should all be 
"extpack".

> It seems to me that all functions need  
> to be packed at some point, why would you label a function "nopack" ?

I confess to not knowing exactly what "nopack" means... I strongly suspect 
you'll never need to use it. ;-)

Bob Ellison
Tungsten Graphics, Inc.