Quote:Original post by Encryptor
Fair enough.
<rant>

I fail to see how any of that is valid. Don't interface with X yourself. Use a go-between like SDL. Problem solved.

Quote:Original post by Encryptor
1. Almost no documentation.

Check the man-pages, and doxygen.

Quote:
Xgl was released for over 2 years ago. And is now deprecated and all the functionality is in mainline Xorg. Google compiz.

Thanks for the info. I guess I should update my sources. I am glad the functionality is in mainline Xorg. Doesn't solve the other problems though.

Quote:
Do what everyone else does and use a window manager built on top of X11. You linked to the Qt site, why don't you use that? Or GTK+? Or any number of the vast numbers of window managers out there that are designed to simplify the process.

"Do what everyone else does". I like that. Those guys at Google should have never created another search engine. After all, Yahoo was working pretty well...
Oh and by the way, I am using Qt for most of my software. I just wish they rewrote the whole X server on Qt. That'd be fun ;)

Quote:
I fail to see how any of that is valid. Don't interface with X yourself. Use a go-between like SDL. Problem solved.

No, problem ignored. But thanks for the advice, I was actually looking into SDL. I might end up using it along with DirectFB.

Quote:
Check the man-pages, and doxygen.

RTFM is the first thing I do, sir. It's only a problem when the Developer Manual is missing.
The man-pages are just the short user manual. Helpful, but only to a certain point and I am way past that.
Doxygen? Did you mean http://people.freedesktop.org/~anholt/doxygen/xorg/ by any chance? While I agree it's a step forward, it's nowhere near doc.trolltech.com (just to repeat myself).

Quote:Original post by Encryptor
"Do what everyone else does". I like that. Those guys at Google should have never created another search engine. After all, Yahoo was working pretty well...

So you completely ignored the point.

Instead of doing the intelligent thing and using the tools which are more than adequate for the job, SDL, Qt, GTK+ etc you seem to think raw X11 is the only option so you decide to use a far inferior solution instead. Good thinking.

Quote:It's pretty simple to build a HW accelerated OpenGL app using X. It's NOT easy to build an equivalent app WITHOUT X.

I most certainly agree.
However, the question is whether that application would have run faster/better using an <currently non-existent> alternative to X, one that would concentrate on drawing?

Guys, I see your attitude: we have workarounds for everything you ranted about. We have Window Managers (what do window managers have to do with what I posted previously, I don't know...because I can run my applications without a window manager), we have SDL, we have Qt (and I'm a huge admirer of Qt), and we have a zillion other tools. Ooops. You forgot to say 'built on X'. They all have code to workaround the issues I posted (I guess except the documentation issue).
Do you know what will happen when somebody comes up with a fater/better solution than X? (granted, that has already happen in OSX, but it's arguable).
I am willing to bet that people are going to be reluctant to adopt it, because it's going to break their precious code built to live with X. And consequently, the users will not use any products that do switch to the new solution, because the tools they use did not switch. Thus, the new solution will either die, like Y Windows, or barely survive. I'm not sure where DirectFB is right now, but until nVidia has a driver for them, I'd say they're in the 'barely surviving' category.


With this in mind, I ask you not to be reactive, but rather proactive. Think of an alternative, don't go blindly saying "do what everyone else does' (with the implication that there is no need for something better). You don't need to be an expert in Philosophy to see that's a fallacy.

I am going to conclude that currently, there is nothing better than X, but I am going to hope a project like DirectFB is going to rise quickly. We DO need a specialized, hardware accelerated drawing library.

Thanks everyone for your replies, I appreciate your time and effort.

Quote:Original post by Cromulent

Quote:Original post by Encryptor
"Do what everyone else does". I like that. Those guys at Google should have never created another search engine. After all, Yahoo was working pretty well...

So you completely ignored the point.

Instead of doing the intelligent thing and using the tools which are more than adequate for the job, SDL, Qt, GTK+ etc you seem to think raw X11 is the only option so you decide to use a far inferior solution instead. Good thinking.

Sir, I don't think you've grasped the main point of my rant ;)
I'll try to explain it shortly: the root of the problem is X. You fix the root, you have no problem.
And please note that SDL, Qt and GTK all *do* work with DirectFB. Here's a link to prove it: . (I guess this link makes me lose the bet I was talking about earlier, but it's one bet I'll be more than happy to lose).

Do you see now we are NOT bound to X? Where's that alternative when you need it? :/

Quote:Original post by Konfusius

Quote:Original post by Encryptor

Quote:It's pretty simple to build a HW accelerated OpenGL app using X. It's NOT easy to build an equivalent app WITHOUT X.

I most certainly agree.
However, the question is whether that application would have ran faster/better using an <currently non-existant> alternative to X, one that would concentrate on drawing?

You fell into the same trap as I: Thinking that thinner management layers equal better performance. When drawing, the OpenGL calls don't neccesarily take the roundtrip around the machine, stopping by at the TCP/IP layer etc. In the cases that matter, they call directly the driver.

TBH I do not have much knowledge about X11/DRI/GLX, but when I tested X11 OpenGL with a game I played previously on Windows (Wolfenstein: Enemy Territory), I got a substantial frame boost (70 frames on FreeBSD/KDE compared to ~45 on Windows with a GeforceFX 5200). I think that shows that X11 is fast enough. API overhead is (wild guess) below the 1-2 percent range.

Part of my argument was that when you add 'Lack of Documentation' + 'Difficult/Non-intuitive Installation' + 'Needless features' + 'Non-elegant API' you end up with a (quoting myself) "suboptimal solution".
If you fix the "Needless features" (for regular users, that is) you still have the other problems to take into account. If one proves the network connections do not slow it down (i.e. it's done through a loopback socket/UNIX socket or something similar), and correct the other problems, noone would have any problems with using X. Myself included.
But I am of the opinion that fixing the 'Non-elegant API' requires a rewrite.
And 'Non-elegant' is a very polite way of describing it :)

Any suggestions?

Nobody is recommending you to program in X directly, hardly anybody does any more.

If you were to use GTK, QT or SDL for your application, how would the fact that these libraries rely on X affect you? What would be the noticeable problems that using X indirectly would cause?