[Xcb] Is there anyone out there ?

[kha]

Quoting Jamey Sharp <jamey@cs.pdx.edu>:

> 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. 
> > 
> > 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?
> 
Ok it is not really a priority system, but from what I understood there is a "as
soon as you can" cookie and a "I NEED IT NOW" cookie. 

My concern is that cookies being sent to the manager are "lost" to the app.
Which can lead to an app requesting a "ININ" cookie while its demand is actually
being processed. Another thing that bothers me is that for some small yet
reccurent requests a cookie has to be sent each time. A shared memory segment
would allow to let an app keep track of its requests and would also permit to
repeat the same task infinitly without actually reissuing the cookie.
Technically this system would definitly involve some rewriting. But I think it
could be worth it. 



> > 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. 
> 
> 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.)
Glut is not a good idea as far as I am concerned. Glut goal is to mask the local
layer for display and events scan so that protability is reached easily (opening
a window and scanning keys is the same under windows GLUT and GLUT Linux).
But GLUT doesn't bring any GL function, it si just a layer to hide. And hiding
the functions and API we just wrote seems a little akward. But I can implement
GLU and Glaux in XCB if you want, that should give XCB the all bunch of GL
functions that exist out there, and leave plenty of space if someoen actually
want to write a GLUT lib on top of it. 

>
> 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.
> 
I think Mesa is gonna be Ok since I already studied it quite a lot. It doesn't
depend that much on the Xlib in hardware accelerated mode (but software mode is
another matter). Pluging into DRI should be the hard part on this one.  


> > 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).   
> > 
> > 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.
> 
Ok I see. I did not know about Cairo. I will take a look. 


> > 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. 
> 
> 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/freenix/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 very familiar with POSIX threads (but my education doesn't allow me to tell
what I think about them, especially when it comes to POSIXier thread if you see
what I mean...)

If you need info about shared memory, please ask, because IPC and memory sharing
and events syncing is definitly my part. I also have no problem with mutex.
Basically If it works in console mode and looks even just loosely like BSD I
tend to have a little background on it. 

> > 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. :-)
> 

Yeah, I must have had a teacher like you I guess, and the result was not wanting
to do anything but Java for years. 

> > 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.   
> 
> 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.
> -- 
> Jamey Sharp <jamey@minilop.net> - http://minilop.net/
> 

Thanks for your time, I will take a look at Cairo right now, and then I will
start to see how to put some OGL into XCB. 

Kha 
--