Quote: Original post by Simian Man
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?

Aha! A clue, Sherlock! Why is no one recommending to program in X directly?
But I went over that in a previous post.
Your question is a valid one. And I believe a simple game should not be affected by X in any noticeable way, unless you are using some weird features.
However, I can't help wondering what would happen if I decided to write, say, a 3D desktop. Sounds like a pretty useless program, given that we only have 2D viewport (i.e. our screens). But nevertheless, say I want to write something demanding, something that pushes X to the limits.
Or, for the sake of the argument, say I want to build a minimal, but specialized Linux distribution, with everything relying on GUI (because, the target would be the simple user). I want it to run on low-end hardware, in the spirit of good design and generally, in the spirit of UNIX, but I also want to it to have eye-candy. Not that brain-twisting, eye-hurting Motif, but KDE4/Compiz type of eye-candy. Obviously, if you're supporting low-end hardware, you've got some serious design problems to overcome.
Thus the choice of good software is important. The software that handles your graphics card is critical. And so, one would prefer to have something specialized, rather than all-purpose.
These are just some of the situations where X11's architecture needs to be reviewed. What would you use to model the above examples? Would you use X on low-end hardware, as opposed to DirectFB (or any other alternative)? Would you use the plethora of conflicting libraries and configuration issues with X11 to implement a 3D desktop, given that Compiz is so far the most impressive tool outthere and it still looks like it has a long way to go? (The Compiz quality is not an X11 issue by itself, but still, what if the underlying architecture would make things like 3D/2D drawing easier, simple and wicked fast? OS X did not rewrite it's graphics manager for nothing ;) )

Quote: Original post by Encryptor

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

Well, you were the one who brought up "what users really need".
What users really need is something that works, plays well with all their other software and, well, works. X can deal with those requirements pretty well.
That is why X is *the* standard solution. Not because it's particularly awesome, but because it works, people are used to it, and everyone already have all they need to be able to run X applications.

It's pretty much the same reason Windows developers are stuck with Win32. It's not pretty, but it's standard.
Or x86. Are you going to design your own CPU to run your application too, because x86 is too ugly to be optimal?

Quite often, "do what everyone else does" is actually one of the better solutions.

Quote:

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

And yet somehow quite a lot of people seem to manage to write fairly advanced applications based on X.

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

1: How is "non-elegant API" at all relevant to "what your users really need" (your own words)?
2: Non-elegant API's can be worked around by using one of the dozen or so libraries that completely wrap it, so you don't have to look at it.

Quote: I'll try to explain it shortly: the root of the problem is X. You fix the root, you have no problem.

Sure you do. You have the problem that you just replaced the root, and now everything above it just fell apart because the root it was expecting to communicate with doesn't exist. You have the problem that the one piece of infrastructure that *everyone* have in place has just been ditched.
In any case, I haven't really seen how you propose to "fix the root". What I've seen is that you want *your* application to not use X, for some vague reason (ugly API, can be dodged by using wrapper libraries, low performance, is a dubious claim at best, needless features don't actually seem harmful, and so on)
But really, what exactly is *fixed* by your specific application not using X?

Quote: Quite often, "do what everyone else does" is actually one of the better solutions.

I can't help remembering the saying 'When in Rome, do as Romans do'. There is a reason why this saying is constantly at debate tournaments. This is because it's a coin with 2 faces.

I must confess, you, sir, make some weird points.

Quote: That is why X is *the* standard solution.

Did I not mention I am looking for an alternative? The reason why I am looking for an alternative is precisely because I agree with the fact that X is currently the standard solution. What I do not agree with is replacing the word 'currently' with 'always' and 'standard' with 'optimal'.

Quote: Are you going to design your own CPU to run your application too, because x86 is too ugly to be optimal?

By your logic, no efforts should have been made to create the amd64 architecture. And yet, there is such an architecture. Is it possible that some of us are actually doubting the established dogma? That's one big no-no, isn't it?

Quote: And yet somehow quite a lot of people seem to manage to write fairly advanced applications based on X.

I think we've reached the idealist vs pragmatic situation here. You see fairly advanced applications based on X, I see 3-legged dogs who walk fairly fast.
You are happy with the current solution, I am searching for a better solution. There's nothing wrong with that. Constant searching for new solutions is what drives progress, don't you think?

Quote: How is "non-elegant API" at all relevant to "what your users really need"

Taking words out of the context isn't that interesting anymore.
My answer would be that the more 'non-elegant' an API is, the more time the developers have to spend learning it and it's little peculiarities, the more pressure they get from their bosses (assuming they work in a company). And when you get to this situation, the more pressure a developer gets, the more he will try to hack something together and release it to the manufacturer. The more hacks we get in our software, the higher the number of bugs. The higher number of bugs in a software, the more users are going to be unhappy with what they got. And here's where we arrive to the 'You get what you paid for' concept. And that is definitely not what users really need.

Quote:
Non-elegant API's can be worked around by using one of the dozen or so libraries that completely wrap it, so you don't have to look at it.

I mentioned this in a previous post: This gets you going, but does not fix the underlying problem. Some day, somebody is going to have to fix the root of the problem. You get these situation a lot in software, mostly because in a pragmatic world, 'now' is more important than 'some day', for numerous reasons (time,money, interest, etc). In an ideal world, the problems of 'some day' would be fixed 'now'.

Quote: Sure you do. You have the problem that you just replaced the root, and now everything above it just fell apart because the root it was expecting to communicate with doesn't exist. You have the problem that the one piece of infrastructure that *everyone* have in place has just been ditched.

I have already explained this. See my post above about Qt, SDL and DirectFB, and the link to YouTube. Again, replacing X is possible. Sure it'll break some things, but since most of the programs are based on toolkits (that were initially there to solve the Xlib problem), I wouldn't say that the effort would be phenomenal. Qt did it, and their library is huge. There is a DirectFB driver for Qt. How many tools are more complicated than Qt?

Quote: In any case, I haven't really seen how you propose to "fix the root".

In a previous post, I have acknowledged the fact that I do not possess the knowledge to "fix the root". It would probably be hard for any one person to do it. However, a team of developers should be able to accomplish this. Most of the time, these teams are found in big companies like Apple, Sun, IBM and Google.

Quote: What I've seen is that you want *your* application to not use X, for some vague reason (ugly API, can be dodged by using wrapper libraries, low performance, is a dubious claim at best, needless features don't actually seem harmful, and so on)

1. Wrapper libraries? Ok, consider this. I'll give you a piece of rotten meat and I'll put lots of ketchup on it. What will your attitude be towards the food?
2. Low performance is a dubious claim? The advantages of writing directly to the hardware, without going through a network library (read: socket checks, memory reads, tcp/udp/unix delays, filesystem writes, cpu cycles just to get the data to the graphics card.) should be obvious. What we lack here is actual testing. Hopefully this is going to change soon.
3. Needless features don't actually seem harmful. I might agree with that, as soon as we get those test results. I don't have them. You don't have them. Point 2 makes a theoretical description of what's going on, so that should serve as a theoretical proof that in no way is a network client/server architecture faster than communicating directly with the graphics card. This should have been a self-evident statement, but the details in Point 2 are there just in case. So, now that we all know X cannot be faster, let's talk about how much slower it is. No tests results? Too bad for both of us. At least I can say that X is a sub-optimal solution, which is exactly what I said in my initial post, when I explained my choice to search for an alternative solution.

Quote: But really, what exactly is *fixed* by your specific application not using X?

Well, for starters, allow me to say that I do not intend to fix something with my application, at least not something related to X. I don't know what led you to that conclusion. One of the consequences would be that there would be one more application that does not use X. Not a big deal, is it? But then, that's precisely why I posed my initial question. If I used an alternative to X, that would perform faster, I would have had a program that works faster, compared to an implementation on X. Consequently, I would have shown that using X for the same task would have been slower. And so, at least the set of tasks that are similar to the task I would solve with my program, would have been a good choice for 'Programs that work better without X'. And I'm talking about graphical programs, not command line program that benefit from no overhead of X11. Games, perhaps? Simulations? 3D desktops, maybe?
As you can see, nothing would be definitely fixed, but my intention is not to fix something. My intention is purely egoistic: have my program run better than any potential competitor by choosing reliable and fast software to depend on (that's why I asked about an alternative). That would be a good start. Just as in an economy: everyone acts in a selfish way, and we will all be better off. Of course, there's little to be selfish here, especially in the open-source world. But that's the fun of it: develop something better, and be proud of it. The rest will follow.
Again, no solution. Just corner stones.

Quote:
2. Low performance is a dubious claim? The advantages of writing directly to the hardware, without going through a network library (read: socket checks, memory reads, tcp/udp/unix delays, filesystem writes, cpu cycles just to get the data to the graphics card.) should be obvious. What we lack here is actual testing. Hopefully this is going to change soon.

You should first research into already available technologies, such as DRI, Direct Rendering Infraestructure, instead of taking the long path of your own solution.

http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure

Quote: Original post by HuntsMan

Quote:
2. Low performance is a dubious claim? The advantages of writing directly to the hardware, without going through a network library (read: socket checks, memory reads, tcp/udp/unix delays, filesystem writes, cpu cycles just to get the data to the graphics card.) should be obvious. What we lack here is actual testing. Hopefully this is going to change soon.

You should first research into already available technologies, such as DRI, Direct Rendering Infraestructure, instead of taking the long path of your own solution.

http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure

Thanks for the link!
I was researching the possibility to use DRI, but I was constantly running into statements like 'DRI is now a part of Xorg project" (or something to that extent). I visited the Xorg site, and it appeared DRI was tightly integrated into Xorg. Then I've heard of KDrive and tried to install that, but got confused with the docs and eventually gave up.
I might retry it at some point, but I'm thinking 'why install that client/server architecture? Isn't there something better?'
Apparently not. I'm satisfied with DirectFB so far.

Quote: Original post by Encryptor

Quote: Original post by HuntsMan

Quote:
2. Low performance is a dubious claim? The advantages of writing directly to the hardware, without going through a network library (read: socket checks, memory reads, tcp/udp/unix delays, filesystem writes, cpu cycles just to get the data to the graphics card.) should be obvious. What we lack here is actual testing. Hopefully this is going to change soon.

You should first research into already available technologies, such as DRI, Direct Rendering Infraestructure, instead of taking the long path of your own solution.

http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure

Thanks for the link!
I was researching the possibility to use DRI, but I was constantly running into statements like 'DRI is now a part of Xorg project" (or something to that extent). I visited the Xorg site, and it appeared DRI was tightly integrated into Xorg. Then I've heard of KDrive and tried to install that, but got confused with the docs and eventually gave up.
I might retry it at some point, but I'm thinking 'why install that client/server architecture? Isn't there something better?'
Apparently not. I'm satisfied with DirectFB so far.

Sure, but DRI kills your assertion that X11 has bad performance :)

Looks like it. Doesn't invalidate the rest though ;)

An anti-X rant. Fun.

Quote:
1. Almost no documentation.

True.

Quote:
2. Modular? [...] If you really need 1000 little archives, provide a tool to manage them, don't throw them at me and expect me to be happy to spend more time on managing the dependency hell than to do actual work.

There you go. That didn't take me long to find even when I was unfamiliar with it. Though to be fair, I'm using this together with a custom Makefile that is tailored to my setup nowadays.

Quote:
3. Network transparency is inappropriate for users.

If it helps at all, think of X as a microkernel system, because that's exactly what it is nowadays (okay, with DRI it's actually a hybrid microkernel/exokernel system.. whatever).

Network transparency is a nice benefit that has negligible impact on the rest of the system.

Quote:
4. Xlib. Awful. Junk.

Newsflash: Xcb. Xcb has been the recommended library for new software that interfaces with X directly for years.

Quote:
There's a need for another graphics display system on *nix, and if DirectFB is not going to become one, somebody will write another one. I just hope they do it right this time. Trust me, if I had the knowledge, I would have been the first person to join the developers team.

History is littered with attempts to replace X, and those links are just the few I could find the links to immediately. They all (essentially) died, and what good they offered got picked up by X.org.

You could think of a number of reasons of why this is the case, but I can assure you that it is no conspiracy by X developers. I personally believe that there are three major reasons:

1. Graphics system development is hard. We're talking about mysterious bugs in minor revisions of hardware that you do not own and therefore cannot debug. We're talking about intricate details in specs that are hundreds of pages long and quite dense.

2. Graphics system development is not sexy, therefore few people are interested in it. Seriously, how many people enjoy tracking down a bug that turns out to be caused by a missing cache flush in the GPU? Or spending a couple of hours looking at batch buffer dumps in order to figure out the cause of a hard system lockup? Spending two hours to figure out why the 1D texture implementation causes wonky results in an odd corner case?

3. Those who don't understand X are doomed to reinvent it, badly. And they will obviously reimplement all the bugs that have been fixed in X over the years.

Executive summary: Yes, there are many things that are wrong with X, but
a) rewriting X from scratch is an extraordinarily stupid thing to do and
b) the X developers know that and are actively working on it. (Fun fact: several hundred thousand lines of legacy code have been removed from the X server source code.)

(Disclaimer: I'm one of the developers of the r300 DRI driver.)

Quote: Original post by Encryptor
(The Compiz quality is not an X11 issue by itself, but still, what if the underlying architecture would make things like 3D/2D drawing easier, simple and wicked fast? OS X did not rewrite it's graphics manager for nothing ;) )

Yeah they rewrote it because they wanted to own the UI experience not open source it. There are other reasons than technical that they chose what they did heck look at that Frankenstein kernel they glued together because they wanted to own the code rather than be open. OSX has horrible Threading performance because of it but they don't really care because they own the code and can fix it they can't "fix" the GPL.

X is "wickedly fast". It is faster than it's competition. While I understand the lack of documentation is annoying, the rest of your comments are incorrect/out of date you may wish to give X another shot or research a little more.

Thanks for the comments guys!
Now we're getting somewhere. I agree that rewriting X means, most of the time, going through the same annoying bugs again. However, that doesn't mean that the X team can't just say 'This is what it was. This is what it is now. New and improved.'

Now, if only you could point me to a tutorial on how to get a dumbed down version of X with DRI/DRM and a keyboard/mouse/nv driver I'll be the happiest person on earth. And I'm talking about '1. Get GCC. 2. Get these files from X.org'. I admit I haven't searched for such a guide for at least several months and I'll surely do this in a moment, but last time I checked - good luck finding such a guide.

Again, thanks for the input, I appreciate it.