[PATCH xserver] use xcb struct in render

[Christian Linhart]

Hi Julien and all,

Thank you for your review.

I have a comment to your side-note about header file split:

On 01/11/15 11:30, Julien Cristau wrote:
> As a side note, I wonder if xcb shouldn't split its headers between the protocol structures on one side, and the client library bits on the other.

I am not sure, because there is very little stuff in generated files in libxcb that's really client-specific.

Here's why:

All the utilities for accessing the variable-sized part of protocol-objects, such as requests, replies and structs, may be useful in the server-side, too.

These utilities are for example list-access-functions or iterators,
and functions for deserializing switch-bitcase and switch-case.

Currently these are not yet generated for requests, but they are generated for replies and xcb-structs.
Generating them for requests, too, is probably very easy as the whole logic is already in place
in the generator.

Here's a simple example for render.c which is taken from function ProcRenderSetPictureClipRectangles:

This code
    return SetPictureClipRects(pPicture,
                               stuff->xOrigin, stuff->yOrigin,
                               nr, (xRectangle *) &stuff[1]);

can be changed to:
    return SetPictureClipRects(pPicture,
                               stuff->xOrigin, stuff->yOrigin,
                               xcb_render_set_picture_clip_rectangles_rectangles_length(stuff),
                               xcb_render_set_picture_clip_rectangles_rectangles(stuff) );

Therefore replacing a potentially error-prone construct like "(xRectangle *) &stuff[1]"
with a more typesafe construct that enables compile-time checking,
and is more readable.

( The "functions xcb_render_set_picture_clip_rectangles_rectangles_length"
and "xcb_render_set_picture_clip_rectangles_rectangles" are not yet generated,
but they will be generated if varsized-part-access-support code is generated for
requests in the same way which it is already generated for replies or structs. )

In case of lists with variable sized members, the xcb-functions become
even more useful to avoid bugs in the X-Server code.
For these cases, xcb provides iterators which provide an easy
way to safely iterate through such lists.
So, all pointer arithmetic and casting will be done in libxcb
by automatically generated code.

***

Conclusion:
It will be hard to discriminate between libxcb-code that's for client-side and code that's for the server-side.
Especially xcb-structs and events can be transmitted in both directions.

Of course we can still put the c-structs in extra headers,
but I guess there won't be much point to it because
the server will also need to include the headers with the function definitions.

In essence, libxcb will cease to be a pure client-side library but will become
an X-protocol abstraction library that's useful for client and server use.
I am pretty sure that this is possible with only minor modifications in libxcb.

If there's still a point to put the c-structs in an extra header, we should consider that.
( It will be a rather trivial change. We can do that after I'll get my Xorg-account
and after I'll have merged all pending patches. )

If there's a good way to split these headers in another way, we should also consider that.
We'll probably have better insights when the server-side XCB projects will be more progressed
and when we'll see what code from libxcb will actually be used in the Server.

What do you think?

Cheers,

Chris

P.S.:
There is a difficulty with terminology of the term "struct".
It can be used for "struct" objects which are defined in the xcb-xml protocol definitions
and for a struct as a construct of the programming language "C".
In this message I use "xcb-structs" and "c-structs" to differentiate.