Qt On DirectFB 417
Ashcrow writes "The feasibility for DirectFB to replace XFree86 just a little stronger thanks Maurizio Monge very first alpha release of Trolltech's Qt library for use in DirectFB. You can check out some screenshots or go straight to the source. And yes, it has been released as Free Software."
Don't think so.... (Score:2, Insightful)
This is most likely to help TrollTech in the embedded space.
Re:Before all the flamers get in. (Score:1, Insightful)
To elaborate, speak for your own fucking self. I use X remote over SSH every goddamned day, and I would be fucked if the free Unix world moved over to DirectFB.
The good news is that they're not going to do that. If it ain't broke, don't fix it.
Background (Score:4, Insightful)
Boy, with that girl in the background, I about forgot to look at the transparency effects!
On a more serious note: this is good. Not that I want X replaced or anything, but a little copetition is always good. (Besides, why can't there be X-Free distro's and DirectFB distro's?)
Re:Before all the flamers get in. (Score:5, Insightful)
Yes, that might mean that only apps written for that gui would work.. but that gui could be, say, QT (as the article is about) or something else.
See OSX for an example. Can I run X apps? Sure, if I fire up the X server. ANd they run just how you expect them to, they look the right way, and everything... but the apps that work really well use the native display library, not X.... and they work even better. And no, it's not because the X server sucks, in fact, the X server is quite good.
We are adding so much stuff on top of X we have to question if we really need what X provides, and if it can't be better provided better another way.
Replacement of X (Score:1, Insightful)
Please don't confuse X (a protocol specification) and XFree86 (an implementation of X).
DirectFB Inherently Insecure? (Score:5, Insightful)
Not being familiar with it, the first thing I did was read the FAQ:
So. In order to get the supposed benefits of DFB, you have to run apps as root? I guess maybe you could log on as a user and su the DFB apps, but that's a pain. Why should a graphics lib muck up security? That seems inherently broken to me. If it really just abstracts graphics then there should be no problem with user apps running it.
This isn't really my area of expertise. Perhaps there's something I'm missing. Can anybody clue me in?
Re:err (Score:2, Insightful)
If he writes good code, sure, why not? Anyway, we're all human, and we're all sexual, in one way or another... what's the big deal?
Re:Before all the flamers get in. (Score:5, Insightful)
Why is it that (to my knowedge) nobody has done this at a higher level? If the client already has a QT library why not simply send over a 'draw widget' command to that library, creating a proxy out of the server's library.
Re:In somewhat related news (Score:1, Insightful)
Re:nice (Score:3, Insightful)
Re:Before all the flamers get in. (Score:1, Insightful)
All these X arguments are so boring, and all boil down to the same two false pretenses:
+ X Sucks because it allows remoting
+ X Rules because it allows remoting.
When in fact the remoting has little to do with X's suckiness, and the remoting basically sucks when compared with Citrix or something.
What's really needed is an X12 that has both good remoting and featureful local performance. But I'm not writing it, so whatever.
Re:Before all the flamers get in. (Score:3, Insightful)
1. remote displays are the thing that makes X "slow" and "bloated"
2. That X is slow and bloated in the first place (put GTK or QT on top of DirectFB and you'll see the same "slow" "bloated" behaviour)
3. That remote displays are some obsolete technology that no one really uses any more? (If that's the case, then how come even Microsoft have finaly started putting the functionality into it's desktop operating systems?)
Re:Before all the flamers get in. (Score:4, Insightful)
Re:Before all the flamers get in. (Score:3, Insightful)
Re:Before all the flamers get in. (Score:5, Insightful)
In the midst of citing reality, you're ignoring reality. First of all, Linux isn't the only OS that uses XFree86, X11R6, or another X11 based windowing system. Heck, it ain't even the only free OS that uses it.
Second, even supposing Linux will achieve it's goal of "World Domination", where everyone must use Linux or be branded a luser, it's still ignoring the fact that Linux is a Unix-like operating system, and to confine it to only the home based game machine is to deny it 95% of its potential.
Third, that "neat trick" doesn't cost you a damn thing if you don't need it. The only thing holding back XFree86 performance is the fact that it must operate in userland.
I've heard the phrase "why keep it of 95% of the people don't use it", referring to the remote network capabilities of X11. Well, why not turn that statement on its head? Why support SMP in Linux, if 95% of the users don't use it? Heck, why do I need snowchains for my car if 95% of the time I won't be driving in snow?
Fact of the matter is, most people using Linux, BSD or UNIX outside of the home will want and need the networking capabilities of XFree86. If you want Linux to be confined to home game machines, then go roll your own distro. But in the meantime a lot of us want the capabilities of XFree86.
Re:Before all the flamers get in. (Score:4, Insightful)
People have done things like that, and it sucked. The reason is that it requires any remote machine to have a compatible version of Qt and GTK and every other damned toolkit someone might want to use. This is an administration nightmare at best, and impossible at worst. (What if you have two apps, one on each machine, and they both require incompatible versions of some toolkit? Then you simply CAN'T display either app remotely without jacking up the other app, or adding some overwrought version management system. What if some app you use requires the very latest version of its toolkit for some interesting new widget it adds -- do you really want that to force an upgrade on every machine you might want to display that app on?)
To make this a little more concrete, let me make a little analogy. Imagine you have a web site, and you want to push more processing to the client. So, you change your dynamic PHP code into JavaScript code. Since you now no longer have the power to just say "this must run under version X of PHP, so we're putting that on our server", you have a choice: either make your app run in every javascript implementation that you might encounter, or place restrictions on what version(s) of javascript can be used to visit your site. If you had left it in PHP, there would be some disadvantages (slower, etc), but at least you'd know it would work with any browser.
Now, naturally, the "any browser" thing is a myth. There are quirks with different HTML implementations too. But this brings out an important point. Somewhat unlike HTML, the great thing about X11 is that it does something really simple. It doesn't concern itself with complex details like what a doubleclick means, what a button is, etc. It stays at a nice low level. As such, it's more easily possible to reach a point where it's matured and it's stable. The X11 that some person has on their machine will be compatible with everyone else's, by and large, because it's at a low level and can be stable and mostly unchanging.
So, while X11 isn't a paragon of simple, elegant, modern, clean design, it or something like it (with the same goals of sticking only to universal primitives, but maybe also with support for changing resolutions, etc.) is a very beneficial thing for the reasons similar to why Swiss banks are a beneficial thing.
Re:Terminate the Terminal (Score:3, Insightful)
For you maybe. I've worked in some very heterogenous environments where X was indispensible. I'd like to see more use of X. For example, I think it would be great if I could redirect the Tivo GUI to my desktop.
"It's worth remembering why X is a network-based system in the first place. The X server software we use now was originally meant to run only on a dedicated terminal."
X is a network based system because it is an advancement over the hardwired graphics systems that preceded it.
"I suspect that the X architects just took it as a given that most computing would always be done on time-sharing systems."
Whaddya call the whole Internet?
I don't see any need to dump X except for when space is at an absolute premium. We had enough to run it 15 years ago; we have more than enough now. The performance complaints only apply to a few apps, and they are handled to my satisfaction by DRI.
Thin client is well suited to remote display over a decent Net connection, but X rules the LAN.
This is not the time. (Score:3, Insightful)
Changeing the direction of the graphics environment right now isn't productive. It will delay the common use of Linux/FreeBSD on the desktop. As applications will need to be ported to the new system, instead of using that developer effort to produce new and better applications.
Perhaps even that killer app that makes the difference.
One other thing, one of the the most attractive features in the X11 desktop to corporate user is the remote display facilities. This is a major advantage over windows. It makes system administration a lot cheaper as application can be installed in one place. The admin cost is much more important to this group than the cost of hardware. Even if they needed twice as fast/memoryrich hardware to get the same performance on X11 they would prefer X11.
Once free software have higher market penetration on the Desktop we can change to better technology. But first we need to kill the competition from MS and Apple. X11 is good enough to do that, especially since the average desktop PC gets more and more memory and processing power.
The technology could still prove interesting for emedded devices where memory and processing power constraints still are more common.
Re:Sounds like a plan. (Score:5, Insightful)
This is a myth, and an XFree86 developer, board member, and one of the founders seems to agree:
I've even pissed off Keith and many others on the Core Team by pointing out that X is obsolescent. I've been working in the Windows world for years now, and client-server display systems are utterly irrelvent to the majority of real-world computer users. X needs to be replaced by a direct-rendered model, on which a backwards-compatible X server can be reasonably trivially implemented. [xfree86.org]
Nobody except people who use X over the network extensively are making claims such as yours. There are many people who do extensive GUI research and programing contradicting what you are saying. the KDE and GNOME projects have both showed interest in direct rendering models. There is a HUGE project of people doing exactly what the above link says. Implementing a direct rendered GUI with an X layer atop for remote display. There is no reason that X should treat everything (including local rendering) as a network socket connection when it can talk to the hardware directly. It is just too much overhead.
People making claims that the UNIX SOCKETS for local display don't involve overhead haven't made their evidence available. if this is true, explain yourself. There is real world proof that the DirectFB model is faster for local rendering, and until XFree86 either gets its own direct rendering model built into it for 2d rendering, and all the bells and whistles that DirectFB has (alpha blending with hardware acceleration, desktop/screen resloution switching on the fly, etc), you people claiming X's faults aren't with the protocol and implementation but with drivers are all blowing hot air.
the unix desktop CAN be faster. But X/XFree86 either needs to grow with the modern desktops, or it needs to be replaced on the desktop with something that works better. Either way, competition is a good thing, and I'm glad that DirectFB is making some headway. Porting QT/Free edition to DirectFB is going to make this competition even better, and the users will win out in the end.
I'm not bashing X here. I'm simply saying that there are better methods to locally render 2D applications. They do exist. They are being developed. The X protocol and XFree86 was designed for UNIX in a client/server networked environment. This is not how most modern computers use on their 2D desktop. I'm not saying XFree86 or the X Protocol needs to go. But if it wants to be _THE_ unix desktop for everyone, it needs to take into account the growing popularity of pure-local rendering environments. (There is no argument from me against it being _THE_ unix desktop in a client/server networked environment)
Re:Good start, but not useful yet (Score:5, Insightful)
Konqueror, KHTML et all already have releases built to not need X (kdenox cvs module).
Now, for the more desktop-ish apps this is certainly true, and X11 usage is (unfortunately) rather sprinkled about.
The biggest single piece is probably replacing kwin, followed by the dcopserver.
Re:Good. (Score:4, Insightful)
But rather than just flame, I'll present you with some reasons why you *perceive* Windows to be better.
A) Everyone tells you it's faster. Don't laugh this one off! The average human being rivals the cow when it comes to peer pressure. I've done some tests on my dual boot Win2k/FreeBSD machine. FreeBSD with KDE can do from powerup to surfing slashdot with Konqueror in 45 seconds, while powering up under Win2k to surfing Slashdot under Internet Exploder takes 60 seconds.
B) At work we're taking a i486 embedded device running X11R5 (R5 mind you!) and redesigning it from scratch to run WinXP Embedded on a 1Ghz P4. The new system *HAS* to use DirectX, because win32 is too damn slow. It does not have the performance that the i486/X11R5 has. They can't draw realtime *labels* and *graphs* faster than 15fps without it.
C) But that's speed. There can be a noticable response difference between the two, especially if your distro was asleep at the wheel when it came to default X settings. Why is Win95 more responsive than KDE or GNOME? Because the Win95 GUI DOESN'T DO ANYTHING! Even vanilla Blackbox has a higher feature set then it does! The win95 desktop can't even handle a jpg background without resorting to an ActiveDesktop hack, but most X window managers can use any image format you throw it at, and will scale the image without aliasing to boot.
D) A Qt application is no slower or less responsive under XFree86 than the same Qt application recompiled for win32. Try it and see! In fact, the only GTK+ application I use under Windows is *slower* than its XFree86 counterpart (GIMP).
E) If you see a significant performance increase under Win95/2k/XP, it's because it's an ActiveX application. It's bypassing the GUI completely. Please reread the previous sentence and attempt to comprehend it. See my note under B. We had to use ActiveX in our project because the WinXP GUI is too slow. Linux/BSD needs an ActiveX analogue, true, but that's no reason to dump X completely. Sometimes when you're playing Quake and feeling l33t because you're using Linus instead of Windows, then you want a good direct rendering engine. But it's completely pointless when you're running Scribus or GIMP. Perhaps DirectFB can fill this role for the times it's needed.
Re:DirectFB and non-english letters (Score:3, Insightful)
Since everyone wants to get rid of the X11 remote networking because "95% of people don't use it", then the obvious answer to your question is "if 95% of the people can get by with US-English keyboards, then the rest of you can go suck wind".
</sarcasm>
Re:Before all the flamers get in. (Score:5, Insightful)
Re:I can't believe people mod this up (Score:4, Insightful)
That's almost complete nonsense, but not quite. It's true, people that age usually aren't capable of doing an entire project well. They need someone with more experience to see the whole picture and sort the wheat from the chaff, to serve as something like an Editor - like Linus does for instance. But young people are perfectly capable of writing damn good code, and if you can't see that then it's you that doesn't have it - it being objectivity.
The *Real* Problem with X11 and the unix desktop (Score:3, Insightful)
The problem is The Clipboard (Drag And Drop, Cut and Paste Etc). It only does text! I can't cut and paste from Gimp to Open Office or Mozilla to Open Office. Here we have the two most important linux desktop application and dragging a gif from mozilla to open office doesn't work. It's just text!
I know this would be tough to implement with X Remote desktop since two applications being displayed on your X Server might be on different machines but can't we set up a drag and drop daemon on each machine that lets them talk to each other so open office on machine a could except some paste information from the machine that was running Mozilla via a xclient to xclient connection or from a low level cut and paste service that communicated from server to server? Anyway.. I hope somebody in KDE or Gnome land is listening here.
Re:Before all the flamers get in. (Score:4, Insightful)
With X the only memory needed on the server is the memory needed for the application itself, since all of it's drawing routines are done directly to the computer running the display.
Give it a try for yourself, Fire up the VNC Server on a unix system (Windows Users can't have 2 desktops on VNC anyway, so they don't get to complain), and check the memory usage for that, it should be approx Width X Height X Bits Per Pixel. (plus the overhead of VNC) Now compare that with the None needed for X, and I'll take X any day.
Re:Before all the flamers get in. (Score:4, Insightful)
While technically true, places that deploy masses of Linux desktops (Largo City, Florida for example) using cheap PCs as, essentially, X terminals weigh heavily against this.
Sure, average Joe Homeuser doesn't care if his GUI networks or not, any more that he uses Citrix on his home Windows box. But in the workplace where centralized configuration and personal desktop mobility are drivers of lower TCO, a network capable GUI is essential. WHy the fsck do you think companies spend all that money on the likes of Citrix anyway?
Re:Before all the flamers get in. (Score:4, Insightful)
I have found that people who hate the X Window System are people who don't understand it. Many come from a PeeCee background and still don't get the idea that the network means more than 'that drive over there on a server' and HTML.
Re:Before all the flamers get in. (Score:4, Insightful)
Do you really think business users are disturbed by too little FPS for 3 D shootere?!?
Yes, Motif is ugly. But it is not ugly because of X, but just because it is ugly. X is just a way to draw on a screen (locally or remotely). It is more than fast enough for any 2D needs one might have nowadays, even through a LAN. There are enough alternatives to Motif nowadays, but no single de facto standard has established itself yet. Do you think that by removing X and its network transparency, some elegant GUI toolkit suddenly establishes itself as de facto standard? Also on a direct FB it is possible to run many GUI toolkits.
There are more than enough hardware supported (2D) X windows drivers. How can you claim that X was designed for and ran well on a 8 Mhz 68000 CPU, and does not run well on current machines which are 100 times as fast?
As for people wanting desktop machines: "people" in fact want windows machines, because that is what they know and most are not interested in computers. However most incentives for introducing unix on the desktop in companies is to save cost, therefore the IT department/architecture forces the users whether they like it or not. Thus "thin clients" are introduced. Not the pure thin clients that are only a network terminal, but those that have the apps that are used most (office suite) installed locally and all other apps remotely, and running remotely via X.
That is a great solution, because it saves the IT department loads of local support and configuration. New version? No need to distribute software to 10000 desktops, just upgrade on a couple of servers. Why do you think even Microsoft has introduced "terminal server" after years of denial? Only when citrix got really popular they had to discover that many clients (i.e. large corporations) do want a mixture of desktop and thin clients.
Summary: it is an illusion and unfounded claim that X somehow prevents a migration to desktop unix. It is not because of, but rather in spite of X windows that migration to desktop unix is slow.
Re:Before all the flamers get in. (Score:1, Insightful)
The 2.6 scheduler and other improvements should help these programs seem more responsive by making them wake up more often. This is probably a better approach than "tons of threads" because ideally, you shouldn't have to have more threads than processors. This is all theoretical, of course. I've used it and frankly it's worse than 2.4 for some things. But. We'll see.
I do think that the current Unix/X approach to GUI toolkit design is a sound one. It is Unix-like in its simplicity; it is a sensible way of doing things. I hope that it will be able to perform better with scheduler advances, rather than it be replaced with a lesser model, more complicated than needed.
Another major problem is bloat. GNOME and KDE have become hideous. They include everything under the sun, and launch a couple dozen unnecessary daemons that don't even do much. Run a light, GNOMEless, KDEless setup and things are much better. Stay away from commercial distros that just try to imitate Windows, and do so poorly.
As for OpenGL... Check your drivers I guess? I have never had any problems with GL performance.
Re:Before all the flamers get in. (Score:4, Insightful)
The guy who chimed in on the xfree86.org mailing list said Motif looked like it did because it was designed to use the X protocol efficiently. Everyone else on the list seemed to agree that when a "modern style" GUI is used (i.e., one that looks more like Windows), the number of draw primatives just skyrockets, and performance suffers.
It is more than fast enough for any 2D needs one might have nowadays, even through a LAN.
I've used an X server running GUI apps through a lan and performance sucked.
There are more than enough hardware supported (2D) X windows drivers.
Alan Cox on the XFree86.org list said in his experience laggy GUIs were caused by lack of 2D hardware accelleration in the drivers being used. Many 2D accelleration techniques are apparently proprietary. Someone mentioned a couple of drivers (I think for ATI) where the author had reverse engineered the 2D hardware accelleration by hand tracing through the binary Windows drivers.
Needless to say, reverse engineering drivers by reading assembly language is a tedious process that doesn't happen for every card. There are lots of drivers out there. There are not a lot of good hardware accellerated drivers.
How can you claim that X was designed for and ran well on a 8 Mhz 68000 CPU,
Don't bug me, that's what the guy from DEC said on the list. One of their targets for a server was a Macintosh Plus (remember those?), that was a new machine at the time in the lab, circa 1986 or so IIRC. When they got X performance as good as the native Mac GUI, they felt the were doing well.
and does not run well on current machines which are 100 times as fast?
The whole list agreed here that the X desktop under both Gnome (GTK) and KDE (Qt) "feels laggy". I'm still running Windows becuase of this crap, I have no idea what a heavily loaded X server currently runs like.
As for people wanting desktop machines: "people" in fact want windows machines,
People (users, whatever) will notice a difference in performance however. If you go from a fast 2GHz machine that is at your beck and call, to a server that everyone shares, you are going to hit more slowdowns on that server. The server gets loaded with lots of people, usually at crunch time. For us it was running compile jobs. The server slows down just when you need it most, repsonse time decreases, users get frustrated, and upgrading the server is a major expense and hassle.
Adding users with a PC is easy. You buy them a new PC. No other users are impacted. There's a flat per seat charge, you never have to buy extra capacity until you actually need it. Performance never varies for each user. It's predicable and therefore people just like it better.
Yes, IT suffers with PCs, but that appears to be their lot in life. ;)
Re:Sounds like a plan. (Score:5, Insightful)
As has already been pointed out to you, said XFree86 developer has been out of touch for so long that he thought Red Hat hadn't contributed to X, and now works on Windows entirely doing AOL stuff. When he took part in the XFree-forum list, he got flamed, badly.
Nobody except people who use X over the network extensively are making claims such as yours.
Don't be so short sighted. Maybe the reason nobody uses network transparency on Windows is because it blows so many goats? Have you thought of that? Yet, Microsoft have still taken architectural backflips to make it work, see W2K Terminal Services etc. It's a lame, poor imitation of actual network transparency, but they sell it anyway.
Simply having worked in tech support, I can think of MANY times when being able to have an xterm launched to me, would have been a godsend, especially as said person could continue working while I also worked.
There is a HUGE project of people doing exactly what the above link says. Implementing a direct rendered GUI with an X layer atop for remote display
Which desktop uses that then? Cos AFAIK both MacOS X and Windows use a model similar to that of X internally. None of them are direct rendered.
People making claims that the UNIX SOCKETS for local display don't involve overhead haven't made their evidence available. if this is true, explain yourself.
Why don't you find out for yourself, instead of ranting on Slashdot? You know, there are indeed studies, performed under controlled conditions, that show the overhead of UNIX domain sockets is negligable. They even tried replacing them entirely with SHM segments at one point, but it made no difference. Domain sockets are one of the most heavily optimized IPC primitives in the kernel, and you are quite free to perform speed tests yourself. The only area that it makes any difference is when throwing large amounts of data through them, such as pixmaps (which is why we use the XSHM pixmap extension), and the memcpy may not be completed in the available timeslice. For small messages, ie the bulk of X traffic, there is no speed gain to be had.
There is real world proof that the DirectFB model is faster for local rendering
Er, that's so wrong. For most people, ie anybody without a Matrox G series card, it's far far slower.
until XFree86 either gets its own direct rendering model built into it for 2d rendering
and all the bells and whistles that DirectFB has (alpha blending with hardware acceleration, desktop/screen resloution switching on the fly, etc)
you people claiming X's faults aren't with the protocol and implementation but with drivers are all blowing hot air.
There are faults in every area of XFree/X11, nothing is perfect. The protocol needs some changes, which are being worked on, the driver interface needs to be broken to support proper save unders, and the scheduler is a dog. Needless to say however, DirectFB isn't a perfect work of art either. It's certainly useful, but right now it's not even competitive in terms of speed or features for 90% of users.
I'm not bashing X here
LMFAO. Yes you are. You've made many, many assertions, that you would know were wrong if you had actually sat down for a couple of weekends and done some basic research into the matter, like I have done. I have read boring reports, mailing lists archives, and chatted to various people involved, and so I'm pretty sure the impressions I have are accurate. There is nothing wrong with X as a local rendering mode
Re:This is why my users don't use XFree86 on win* (Score:1, Insightful)
I am forced to use a windows desktop machine at work, but cygwin, coupled with ssh X11 forwarding, makes it bearable.
I do this:
X -rootless &
export DISPLAY=:0
ssh -X -l dave server-1y
icewm &