• Advertisement
Sign in to follow this  

OpenGL without X11

This topic is 3464 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone! I'm wondering what would be the best approach to code, say a trivial game, on Linux/BSD without relying on the X11 Windowing System? Suppose I don't want an X11 window, I will have my application take over the screen. From what I've understood, the way things work now, is as such: 1. I write code that uses some OpenGL functions. 2. Thus, I need to include opengl headers 3. I include the headers and now I want to compile my program. 4. So then there must be a library that provides GL.h. I believe a popular choice would be Mesa 3D. 5. I compile my program and link against Mesa3D. 6. I run the program. And point 6 is where I am a bit stuck. Will Mesa allow access to the graphics hardware? Does Mesa know about the hardware at all, or is it relying on some other library to deal with that, like for example DRI? So far I'm thinking DRI takes care of the hardware and Mesa takes care of OpenGL. But how do they work together? And is DRI usable without an X11 server? What about SDL? Is it a replacement for Mesa 3D or DRI? Or is SDL using/can use Mesa to do its drawing? I guess I need a brief explanation about what libraries to use in order to be able to draw graphics without X11. This whole Mesa/DRI/SDL(?) seems complicated and overwhelming, because all I want is to run an application that will draw something on the screen, on a computer that does/should not use X11. I still remember the good old Pascal/C days where I would specify #include <graphics.h> or 'uses graph;' and then call initgraph() to initialize the graphics. And then I could draw on that screen to my heart's content. I am of course looking to use 3D acceleration and OpenGL, and if I could get (roughly) the same simplicity and low-level access, I'll be more than happy. If you have any suggestions or corrections to the way I'm looking at things, please do reply. Any links and explanations will be appreciated! Thanks! P.S.: Where does the NVidia / ATI driver fit? Are they dependant on the X Server? Does NVidia supply any header files for us to use their driver?

Share this post


Link to post
Share on other sites
Advertisement
SDL can draw to the Linux framebuffer, but I'm unsure if OpenGL can be patched in.

I don't know a lot about the subject, but try Googling for things like 'opengl linux framebuffer' and see what you get. A few pages mention it, but no solid howto's or anything.

Share this post


Link to post
Share on other sites
There's a project called DirectFB whose goal is to provide accelerated framebuffer access on linux. This project also provides DirectFBGL which provides an OpenGL API. There seems to be a requirement for a Matrox card for the latter though.

I have no idea how well these projects work in practice or how stable they are, so YMMV.

Share this post


Link to post
Share on other sites
Thank you for your replies!
It seems that DirectFB is indeed the only feasible alternative so far and I think it's good enough for my purposes.
Thanks again for your answers.

Share this post


Link to post
Share on other sites
The thing you should ask yourself first and foremost is: Why do you want to disregard X?

Since the Linux/BSD desktop is fundamentally based on X and all advanced graphics drivers are written for X, writing a (graphics-based) game without relying on X makes about as much sense as writing a game for DOS.

If you don't want to deal with the X libraries directly, you can always use some intermediary like SDL, glut, or GLFW. In fact, SDL will just give you a simple frame buffer that you can work with, just like in the "good old days" that you seem to be missing.

cu,
Prefect

Share this post


Link to post
Share on other sites
Hi

You can use Mesa with linux framebuffer. There is glut support. Compile mesa from source with
make linux-fbdev

There is a fbdev api, but then your program will only work on this api. If you make your program use glut, then it will run on X or framebuffer.

mesa on framebuffer is not hardware accelerated.

For hardware accelerated, there is miniglx, but it is not complete. I have run it on a radeon 7500 card and got hardware acceleration without X.

Share this post


Link to post
Share on other sites
While I'm no expert, as I understand it nVidia and ATI drivers are X Server drivers only. What you are asking would essentially be the equivalent of trying to do hardware accelerated graphics under DOS rather than Windows. The point to remember is that X--just like windows--exists in large part to provide a unified framework for things like graphics drivers to be built on, and as such is really the only environment where you can reliably access them in a consistent way.

Is there a specific reason you can't use X? That might help in figuring out an answer that would be more useful.

Share this post


Link to post
Share on other sites
Fair enough.
I do not want to use X because I believe it's a suboptimal solution to what your users really need. It's not modular - it's dissected. I ranted for about 3 pages and then I realized it's not going to help. I'll just write several weaknesses of X and I can say that it's because of these weaknesses that I think Xorg has served it's time and needs to be replaced. This is the main reason why I am looking for an alternative.
And now, the weaknesses, from the point of view of a person who has spent less time changing and recompiling the BSD kernel from scratch (along with GNU tools) then modifying X. I got it to work eventually, but the process did not impress me at all.

1. Almost no documentation. Compare the website X.org with doc.trolltech.com. A documentation should provide a thorough description of all the project's components, an API documentation with description for each function, tutorials to help new users and various examples with screenshots to illustrate the working of the example.
What does X.org have? A wiki. Thanks god they created links for developers, otherwise we would be bound to the search function, which, by the way, is as helpful as a google search for X.org.
Maybe all you X fans can read the developers mind and automagically know what comes from where, how to put it in the right place and how to use it, but we, mortals, like to have a consistent and helpful documentation. Computer Science 101 should teach you about the importance of good documentation.

2. Modular? Huh? Well, splitting something up into 1000 little archives is NOT modularization. Out of these 1000 libraries, 999 are required for the server to work.
Check the Xorg site for what is required to build the X server and then try to do it from scratch. One has to first decipher the cryptic error messages in the makefiles, then go through the dependency hell and then recompile, only to find another annoying error message.
At this point, I would rather prefer to have a monolithic tool with plugins.
I don't want the process to necessarily be easy, but I do want it to be intuitive and documented. It's too much to ask, apparently. 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.

3. Network transparency is inappropriate for users. Grandpa and his 15 year-old grandson want to check their e-mail, they don't need to login via ssh and start a KDE session.
John the Hacker and his colleague at work, the Great Sysadmin, do need to login remotely and do find X forwarding useful. See a difference in the intended audience? Well then why don't you build something that gets rid of multiple network screens (servers/clients, etc), sockets and ridiculous configuration files and performs one basic thing: draws on the god damn screen. Isn't specialization the fundamental concept of UNIX? Let's follow it, shall we?

4. Xlib. Awful. Junk. Guys, I am no Linus Torvalds, but I can tell you that is some ridiculously stinking stuff. Thanks God there's Qt (or GTK, if you were about to feel offended).
And yet again: NO DOCS! Oh, oh, wait.. There's a book printed in 1997 about Xlib.. and another about plugins and extensions. Have you checked the price? 200$. Xlib is making it's way into 'Collector's Edition'. "Look, grandson, I've got a book about Xlib. The only one left in the Universe."
Hold on.. there's a tutorial on the web, on some Chinese server: the only resource for such a huge and widely used tool. Good job!
Of course, they're OK with it, they've developed the API so they know it. We, the people, can only admire the lack of documentation.

I guess this is it. I can't really complain about anything else. It works fine so far. Now if only nVidia or AMD would make some quality drivers.
By the way, my favorite quote about X is from Wikipedia:
"Mike Paquette, one of the authors of Quartz, explained why Apple did not move from Display PostScript to X, and chose instead to develop its own window server, by saying that once Apple added support for all the features it wanted to include in to X11, it would not bear much resemblance to X11 nor be compatible with other servers anyway".

First, this means Apple did not want to work on improving X, and thus making Linux a better place. They chose to develop their own servers.
Second, this means that, in Apple's eyes and at that time, X was lacking the necessary features to be used in an operating system that focuses on quality.
In other words, "it's crap and we're not going to use it".
Right now, Quartz is doing advanced stuff, and we're still waiting for Xgl.

Yeah, yeah, I know the usual excuse: "It's free, so don't complain". OpenGL is free. Did you hear anyone complaining about how bad it works? That's because it works well! In fact, it works so well, that it's as good as (if not better than) the proprietary DirectX.

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.

[Edited by - Encryptor on July 27, 2008 4:01:48 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Encryptor
Right now, Quartz is doing advanced stuff, and we're still waiting for Xgl.

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Encryptor
1. Almost no documentation.

Check the man-pages, and doxygen.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
It's pretty simple to build a HW accelerated OpenGL app using X. It's NOT easy to build an equivalent app WITHOUT X.

First get the program working, then make it work better. ;)

[Edited by - Konfusius on July 27, 2008 4:48:52 PM]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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? :/

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 ;) )

Share this post


Link to post
Share on other sites
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).

[/quote]
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement