[Xcb] more on the libGL port to XCB

[Josh Triplett]

Jamey Sharp wrote:
> The GLrop ("render opcode") case, which is much more common, is also
> going to need a little bit of work. The current XCB description of
> GLXRender won't quite work, because we've never implemented support for
> lists of variable-length structures in requests, and RenderCommand is a
> variable-length structure. Possibly we should just add support for that;
> PolyText8 and PolyText16 in the core protocol have the same problem,
> IIRC, and you can see we just kind of kludged around it. The same kludge
> will work here, and might be the best choice, at least for now.

The best solution is clearly to support it.  That shouldn't be *too*
hard; it just requires recursively determining lengths and adding new
parts to the xcb_parts variable, rather than just assuming that any list
is just one part with a length of (list length expression)*sizeof(list
item type).

> Hey Josh? I think PolyLine can't have combine-adjacent set. The behavior
> of two PolyLine requests is different from that of one request with the
> two lists concatenated. I think FreeColors and StoreColors could have it
> set, though, and there may be others. ...There's a question in this
> paragraph somewhere, but darned if I know what it is.

I just used that flag everywhere the M4 descriptions had the equivalent.
 Not having the flag where it would be semantically correct will just
cause less optimized communication, whereas having it where it is not
semantically correct will cause *incorrect* communication.  Not being an
expert on the *semantics* of the X protocol requests, I don't know if it
would be correct for those requests or not.

- Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050329/fcc5edb4/signature.pgp