[Xcb] Is there anyone out there ?

[Jamey Sharp]

--up2r7mkFEYHJ3y+X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 09/29 08:30PM, kha wrote:
> Good to know you are still here, I have been following the mailing
> list and the CVS for a while and was a little bit scared by the total
> lack of anything new.=20
>=20
> Ok first I would really like to know what you are aiming at with XCB.
> What are your priorities, your main goals and objectives.

Well, we've tried to document those in the Usenix papers we've published
and on the TWiki (http://xcb.wiki.cs.pdx.edu/). If you have questions
about our goals, I'd like to hear them.

> 1) Cookies system going through SHM in a full assynchronious yet
> remanent form.  Allow me to explain : from what I understand right now
> cookies are sent with a priority

I'm having a really hard time understanding what you want, but I suspect
this is the problem: responses always come back from the server in the
same order as you sent the requests, and cookie forces always return as
soon as possible after the response arrives. There's no priority to set,
if I understand what you mean by that. Does this help?

> 2) Seamless integration : This is something I would love to see, for
> example OpenGL functions being accessible directly through XCB,

> Basically I am interressed in fast rendered eyes candies and a real
> API usable efficiently for game dev.=20

Well, that's something that needs work, and we'd love for you to play
with it. :-) I'm not entirely familiar with the details of 3D rendering
in X, but I believe we need somebody to implement the GLX extension in
XCB, and then to port Mesa (and ideally GLUT) to use XCB. With GLUT in
place, a lot of 3D apps would just run. (I don't even think they'd need
to be recompiled, but I'm not sure.)

So, want to give that a try? I'd suggest you start by reading Mesa/GLUT
sources and finding out what bits of Xlib it depends on, as well as
reading our papers on XCB and XCL (you probably won't use XCL, but it
might help you understand our choices better), and then finding a spec
for the GLX extension or whatever Mesa needs.

> or even functions that would adapt themselves wether a peculiar lib is
> supported or not (for instance transparencies or video being hand over
> to pure hardware routines if it is possible).  =20
>=20
> 3) Local X proxy. Basically for screen distribution or software
> transparencies, making XCB capable of keeping a certain amount of data
> inside itself in order to speed-up some request.

X does a lot of this on the server side already - for example, the
Render and Xv extensions handle translucent drawing and video,
respectively, and hardware-accelerate it where possible. XCB's job is to
deliver to the server requests asking that things actually be drawn, or
whatever. However, for the most part we want XCB to not interfere with
the instructions it is given by the application. Performance
optimizations are not XCB's job. The right thing to do is to build
libraries on top of XCB that implement these optimizations.

We've considered a few optimizations that could be useful, certainly. An
atom cache would be nice. Atom requests are such a small chunk of a
game, though, that I suspect you won't want to work on that. If you're
interested in eye candy, look at Cairo (http://cairographics.org/),
which makes it easy to draw pretty things with translucency and
anti-aliasing and everything, and can do the rendering on either the
client or the server as appropriate. Of course, it hides all the details
of rendering from the application.

> The only practical application I see would be to have a "screen
> buffer" in PNG for instance that could be very usefull for remote
> controll or screenshots. A more evolved idea would be that XCB keeps
> hierarchised informations (walpaper + picture of each windows) and
> allows you to show or send whatever object you choose.=20

If you want remote control, screen capture, and such, that sounds like
applications work: you write one remote control proxy server and you're
done. There are already too many screen capture apps available.

Now, if you want applications to be able to do migration and
replication, you need support in the toolkit, not in XCB. See Jim
Gettys' paper on migration and replication.
(http://www.usenix.org/publications/library/proceedings/usenix02/tech/freen=
ix/gettys.html)

> Ok that is about it for my desires (feel free to laugh at them if
> there are in any way unrealistic).

As much as I enjoy a good laugh, you've hit on a couple areas that X
could use having more people working on. Not everything you want belongs
in XCB, but getting OpenGL apps using XCB would be really cool, and give
us a lot more nice demo apps than we have now. :-)

> Now for how I can help you : Basically I know little of the X protocol
> (but I am learning fast a we speak), but I do know quite a lot in
> terms of memory sharing, and low level API.

Are you familiar with thread APIs in general, and POSIX threads in
particular? If you hack on the core of XCB - which you won't need to if
you just want to implement extensions like GLX - understanding mutexes
and condition variables would help.

There might be some shared memory stuff from the shared memory extension
that we need to work on, but I'm going to have to read the specs for
that again to figure out how it should work.

> I am mainly a windows programmer (feel free to laugh again),

There are some people interested in porting Cairo to the Windows API.
Once I commit the Cairo patch I'm working on now, you might consider
helping them out. (The more popular Cairo is, the more users XCB will
get, I expect. :-) But you'd rank higher in my estimation if you worked
on the 3D stuff instead. :-)

> and I program mainly in C++. But C is not a problem as long as
> we stay under the dreaded level 5 pointer (p******).

hehe... Darn. I love multiple levels of indirection though. They're so
much fun to torment my fellow CS students with. :-)

> I got a lot of books too, I love them and I am always hungry for more,
> so If you think there is a book I should (or must) read go ahead and
> tell me, I will.  =20

Everyone always tells me to get a copy of "the Digital Press" book about
the X protocol, but I never got around to it - I like softcopy better -
so I can't give you a better citation. Maybe somebody else on this list
can help.

Anyway, I'm really glad you're interested, and I hope you can help us
replace Xlib. Thanks for your comments.
--=20
Jamey Sharp <jamey@minilop.net> - http://minilop.net/

--up2r7mkFEYHJ3y+X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/eKtJNgAXSpyH6VcRAmETAJ952tfYgWyeO4fEdXn6F+CzjXZJagCfSq+L
LxIa2/t5bPuU2ZayCu5+O60=
=LCcf
-----END PGP SIGNATURE-----

--up2r7mkFEYHJ3y+X--