[Xcb] more on the libGL port to XCB

[Jeremy Kolb]

Jamey Sharp wrote:
> These are some observations on libGL and XCB, mostly directed at Jeremy;
> but I thought others (especially Josh) might be interested as well, as
> we have some things to learn about describing the X protocol still.
> 
> GLXSingle requests aren't real X requests. The real requests are
> identified by the GLsop ("single opcode") numbers. All of these need to
> be described in XCB's GLX protocol description. For example, NewList is
> a request with opcode 101 that has no reply; while GetClipPlane has
> opcode 113, has a reply with padding to the 32-byte mark, and a double
> following that.
> 
> Jeremy, you'll need to work out the correct descriptions of these 52
> requests, get them into glx.xml, and then make the appropriate
> indirect.c functions call those XCB functions directly. I expect the
> code will become a lot clearer if you do that.
> 

Okay, I distinctly remember being told that I didn't have to do these, 
but I don't remember by whom.  But in light of recent developments I 
probably should do this.  You mean generate requests for each?  I think 
I can handle that.  It should make everything else fit.

> 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.
> 
> List of variable-length structures aside, there's something interesting
> about the GLXRender-using code in libGL: it keeps a large buffer around
> to write the render commands into, so that it can avoid writing the
> 8-byte GLXRender request header over and over for each rendering
> operation. Well, the core X protocol has some requests where that's a
> good idea too, and they're tagged with a combine-adjacent="true"
> attribute in the XCB protocol description. If we (if I?) implement
> support for actually combining those requests inside of XCB, then libGL
> needn't do any buffering of its own. I've been meaning to re-implement
> that anyway (it worked a long time ago, but I broke it). So don't bother
> using the gc->pc buffer when you implement the GLrop calls, but do add
> combine-adjacent="true" to the XML for the Render request.
> 

For Render and RenderLarge?  I don't remember seeing combine-adjacent in 
the docs.

> 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.
> 
> Having finally reviewed it somewhat, I have some comments on the XCB
> description of GLX, for whatever they're worth, which may not be much.
> :-)
> 
>   * I think the "data" list in RenderCommand should maybe be a list of
>     CARD32s, because AFAICT it's always required to be a multiple of
>     four bytes long.
>   * Context tags and GLX pixmaps need to be declared as XID types.
>   * I assume visuals are the standard X type? Then they should be
>     VISUALIDs, not CARD32s.
>   * Similarly, the font in UseXFont should be of type FONT.
>   * Sadly, screens are almost certainly not of type SCREEN, but maybe
>     CARD32: type SCREEN is a large structure.
>   * QueryExtensionsString looks like maybe it's missing something?
> 

I'll take a look, you're probably right.  Actually there are probably 
places in the other extensions that I've done where things can be changed :P
> Hope some of that's useful.

YES!

> 
> --Jamey
> _______________________________________________
> xcb mailing list
> xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb


Jeremy