If I can find some time this weekend I'm thinking about trying a
PyOpenGL spike test with ctypes.  Wondering if guru-like peoples might
have some advice for how to proceed.  The spike test is basically to see
whether the "natural" processing of Numpy arrays currently seen in
PyOpenGL can be implemented with ctypes.

First question:

    How do I go about making a single incoming parameter (a Numpy array,
    a sequence of numbers, a sequence of sequences of numbers, or a
    string) map to multiple parameters for a function call?  (a pointer
    and a size).  If I'm reading ConvParam correctly, there is an
    assumption of a 1:1 mapping between parameters at the Python and C
    levels.  PyOpenGL is chock-full of these types of pointers (as well
    as ones that are of fixed size, but those should be easier to deal
    with), and the PyOpenGL API has alway done this argument expansion
    for the user as part of making the API more Pythonic.

    Generally these parameters expand into multiple adjacent parameters,
    though IIRC there are a few cases where the parameters are separated
    by some other unrelated parameter.

Second question:

    How should I go about registering these input converters?  Should I
    alter _CallProc to scan the argtypes looking for "expanding"
    parameters?  Something like a "work on arg X" field on the argtype
    which causes it to be called, not with the corresponding argument,
    but with the specified argument (with checking to make sure the
    specified argument is within range, of course).

    Or should I write a C wrapper that auto-expands the arguments before
    passing them in?

I'll have to do the actual converter functions down at the C level, as
PyOpenGL is extremely speed-sensitive, but I don't want to track too
much mud on the floors while doing it.  I especially do *not* want to
make ctypes dependent on Numpy and/or Numarray, I'd much prefer to make
the Numpy code something that can simply plug into the regular
argument-handling mechanism.  I think that, once the multi-parameter
functionality is available, that will be doable simply by swapping in a
different argtype handler for the functions when Numpy is available.

Third question:

    Should I put error-checking code into the return-type?  That is,
    would I define a return type glChecked( expectedType ) such that I
    first check for a glGetError() to decide whether to raise an error
    or produce the expected return type?

Goal would be to have something akin to:

    glVertexPointerd( array )
    argtypes = [
        glDoublePointerSize( ), # count's total size of argument
        glDoublePointerType( forArg = 0 ), # GL_DOUBLE
        glDoublePointerStride( forArg = 0 ), # 0
        glDoublePointer( forArg = 0 ), # argument converted to a pointer
    ]
    rettype = glChecked( void )

Calling...

    glVertexPointerd( GLint size, GLenum type, GLsizei stride, const
    GLvoid *pointer )

and checking glGetError to decide whether to raise a GL error or simply
return None.  Along the way it would also have to have some logic for
storing the (possibly newly created) data-pointer somewhere...

Similarly:

    glGetDouble( constant )
    argtypes = [
        glEnum,
        glDoublePointerForGet( forArg=0 ),
    ]
    rettype = glChecked( glArrayFromInput( fromArg=1 ) ) # and where
    does it get the size?

From what I can see, though, the return-value function doesn't have
access to the input parameter array?  May be that *part* of the system
will have to be done in a C (for speed) wrapper level around ctypes, but
I don't want to get into *too* much of that, or I'm losing much of the
benefit of using ctypes in the first place...

Anyway, suggestions/ideas welcome,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
ctypes-users mailing list
ctypes-users@[...].net
https://lists.sourceforge.net/lists/listinfo/ctypes-users