Qt On DirectFB

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

Comments

Good start, but not useful yet

[lakeland]

Now I guess we get to find out how much KDE assumes X11. Because there aren't many QT only apps out there.

Before all the flamers get in.

[mindstrm]

Consider this: What do you really NEED X for. Try to think bigger than unix for a minute.

Yes, X has remote display. That's a really useful and flexible feature in some situations, no doubt about it. And from a technical point of view, it's extremely elegant.
In reality, though, to a great many linux users, it's a neat trick that you don't necessairly NEED.

We use QT or whatever and try to design desktop systems (KDE, Gnome) which really just use X as a way to load up graphics primitives... those same systems could equally work on something else, with some great benefits in terms of speed.

From a GUI perspective, if you use all KDE apps, for instance, things have a very nice consistent feel to it. Same with gnome. When you start mixing things, plus mixing in old X apps, you just detract from an overall experience.. so let's come out with a fast, standard display system taht's NOT x.... and use X rootless for those legacy applications we need.

Re:Before all the flamers get in.

[tomstdenis]

so first port motif, pango, gtk, etc... to DirectFB and then you can say "drop X, use DirectFB".

I mean its like saying "drop linux kernel, use QNX kernel" :-)

Tom

Re:Before all the flamers get in.

[Natalie's Hot Grits]

"The good news is that they're not going to do that. If it ain't broke, don't fix it."

Well, considering one of the founders of the XFree86 Project (and board members) has said that the *nix desktop needs to be replaced by a direct rendered model with an X interface on top of it (exactly the same thing but with faster local rendering at the cost of nothing) I would like to call bluff on your "If it ain't broke, don't fix it."

Because according to (at least one) XFree86 founder, it is broke, and it does need to be fixed.

Re:Before all the flamers get in.

[goatboy_14]

GTK has already been ported to DFB.

Re:Before all the flamers get in.

[EvilTwinSkippy]

Network transparency is a beautiful thing. I admit, my needs are a little exotic, but I happily run my computer from several dumb terminals (stripped down laptops).

Why maintain a stable of computers when you can have one ubermachine (and of course a few cruddy ones for DNS and webcaching.) The wife has a copy of Win4Lin for Quicken and Office. And I never have to worry about being booted off the "good" computer.

Hell, with my cable tuner in the big computer I can actually watch TV over the wireless. That is of course, if I had cable. I'm practicing living on Internet and DVD's alone. Apparently I missed something called "Reality TV."

Re:Before all the flamers get in.

[edwdig]

SGI's toolkit works like that. Next time you have access to an SGI, try running Jot remotely. Won't work unless you're on another SGI.

I guess the problem is figuring out whether or not the library is remotely present, and falling back gracefully if it isn't.

Re:Before all the flamers get in.

[dubious9]

Yes, I'd much rather have alpha channel transparency than remote display. I assume DirectFB has an alpha channel because it is so prominant on their screenshoot, but is it really or is it the fake freeX86 transparency?

This is the only piece of "eye candy" that I miss from XP/2000 and I find that it is actually useful. And why after all this time hasn't X gotten an alpha channel? It seems like a lot of poeple would like this feature. Plus it makes using a terminal soooo much easier on the eyes.

Re:Before all the flamers get in.

[slyall]

I would not be happy to give up remote display. Not going to happen.

There is no reason why you can't run a X server over the top of a directFB desktop. This would enable applications that support the new system to run fast locally while X based Apps (remote and local) can take to the X server.

There are plenty of X servers for Windows and MacOS that plenty of people use already.

Re:Before all the flamers get in.

[caseih]

Isn't this backwards, going back to a dumb (albeit accelerated) framebuffer? X does much more than just push pixels. If you take a look at how Microsoft does their gui these days, you'll find that it's a lot more like X these days than a framebuffer.

I own a zaurus and was initially impressed with the Qtopia/OPIE user interface. That is until I hit that one design flaw: They write directly to the framebuffer. This means I can't mix and match gtk programs with qt programs. This means I can't develop any non-free apps at all, since QT is GPL and that's the only thing you can run on Qtopia.

As I disected QT/E, I found that it pretty much had to duplicate many things that X does well, like windowing. Yep. And event handling and exposure stuff. Personally I think the Qtopia guys would have been much better off using the mini KDrive X server and use a modified version of QT/X11.

As soon as I can, I'm blowing away Qtopia and not going to OPIE but rather to GPE, which is based on X. A much better solution. Check out their screenshots if you don't believe me how well X fits a handheld.

My point here is that I don't think this directfb idea gives me any more advantage than X does. Sorry. Furthermore, we'd just need an X server on top of directfb anyway to run our main apps, and that is essentially duplicating the drivers that X11 already uses to talk to the framebuffer.

The best improvement I think we could bring to X11 would be a special mode where each window is a live opengl surface. That way we wouldn't need to do "exposure" events and other things. Window dragging would be silky smooth. Other 3d effects could follow. Forget the frame buffer.

Re:Before all the flamers get in.

[mark_space2001]

Why maintain a stable of computers when you can have one ubermachine

The thing is, while this is excellent advocacy, almost no one actually does this. Most people, at home, in a small business, or in a large corporation, have desktop machines, not thin client GFX servers. And they want to keep them.

There's a few legacy apps where X is required, but MS own's 90% of the desktop, and the desktop is not migrating to any *nix until the *nix's drop their 10 year old X server technology and move to something more modern.

I've lurked on several X formums for a while now, and there's seems to be a common thread. While X was written to run well on a very low end machine (one person said they had helped develope X on a 8 MHz 68000 CPU), everyone agrees that the current X desktop is rather laggy on much higher end machines. This has two reasons: lack of hardware accelleration support (good video card drivers for X are really hard to find) and the fact that modern apps do not do what X was designed to do.

Motif is a graphical desktop specification that is designed to run well on top of X. But no one likes the way Motif looks anymore, at least no one used to Windows or Apple GUIs. After 10 years, it' time for something new, IMO.

Re:Before all the flamers get in.

[Baki]

X has the extentions protocols/API's for that. For example 3D (openGL) was added later to extend the X protocol with more high level primitives, and there are many more.

The drawback is that such X clients only work if the remote client has the appropriate extentions loaded.

It is well possible to develop QT or GTK X extentions. However for normal uses on a LAN any 2D application is fast enough to make it totally superfluous, and thus it makes to sense to throw away compatability with all X servers. Only for 3D, for video streaming and other special applicaions it makes sense.

Re:Before all the flamers get in.

[SiChemist]

I would like to also point out that the human eye can only see 12 frames per second. Motion pictures are shot at 24 frames per second. The picture on your CRT refreshes 60 times per second. Any difference you percieve in frame rates above 24 are in your head, above 60 are REALLY in your head because you aren't seeing them.

While I like the power that X provides and agree (at least in part) with your earlier posts, I have to call you on this one. I can see a difference between a monitor running at 60Hz refresh and one at 85Hz. It is especially apparent when viewing large white areas (like a blank word processing document) and on larger monitors. I can also see the jerkiness that accompanies 24 frame motion pictures as compared to 60 field (30 Frame) television when there is a great deal of motion. I can tell the difference when I see a 50 field (25 frame) tennis match televised via satellite from Europe compared to the NTSC standard. I can tell if a video game is running at 30 frames versus 60 frames, but above 60 I don't notice a difference.

That having been said, I have walked past monitors with a noticable flicker and the person using it doesn't complain. Even when I call attention to it and up the refresh rate, they can't tell the difference between the two. I suspect that sensitivity to refresh rate is highly variable among individuals.

Sounds like a plan.

[Meat Blaster]

While I've grown accustomed to X-Windows' ideosynchronities, I've always thought that it would be a good idea to reengineer the whole system from scratch to take advantage of today's hardware and UI concepts. X-Windows 4 has been a vast improvement, but I'm talking about something more like OS X where the whole thing is rewritten to be very smooth and responsive to user input.

If this is a step in that direction, and it sounds like it is, I'm all for a decent alternative that isn't slowed down by having to be a swiss army knife. Especially if it makes resolution switching, 3D graphics, and direct screen drawing less of a hassle.

Re:Sounds like a plan.

[warrior]

I've always thought that it would be a good idea to reengineer the whole system from scratch to take advantage of today's hardware and UI concepts.

Good idea, I've thought the same thing. I wrote a GUI toolkit for X, and a window manager, so I've got a good idea of how the whole thing works. I quit working on it as I was frustrated that I couldn't do some of the neat things I see in OS-X on X (that sounds funny, doesn't it?). Soooo...

I started from scratch writing an OpenGL based display server. I'm using a lot of ideas from X, but throwing out a lot of cruft and adding lots of enhancements. All of the drawing is double-buffered -- no more Expose events!!!! :) All of the drawing is also hardware accelerated. I've figured out a way to do this very well, without context switching the gfx hardware. One possible method will allow many clients to draw at once and keep a constant framerate (by not context switching/swapping buffers within a certain timeslice, these are very costly operations).

Some of the ideas I am keeping are the idea of "internalizing" graphics buffers to the server where they can be shared among other applications. I'm also keeping the idea of a replacable window-manager like shell.

For fonts I'm using Freetype. Standard image format is png. The display is also hardware-resolution independent and colordepth independent. Right now I'm being setback by the fact that I can't get X working on my new laptop (anyone know a modeline for WUXGA+ 1920x1200@60Hz, for Compaq X1000?). For communication I'm using named pipes/shared mem.

So far, my numbers are better than these.

I'd also like to implement creating server-side macros so a client can pass one command to the server and execute a whole set of drawing routines atomically. Oh, and the source is definately going to be open. Any of this sound like a good/bad idea?

Cheers,
Mike

Re:Sounds like a plan.

[Arker]

People making claims that the UNIX SOCKETS for local display don't involve overhead haven't made their evidence available.

I don't think anyone has claimed that at all.

Of course there is overhead involved in that abstraction, but there is overhead plenty of places. With modern hardware it's trivial. You can run X on a 486 just fine, and if the overhead isn't too much there then why would you worry about it on a newer 'puter?

Lots of people complain about X in ignorance, because what they're complaining about, when you look at it, isn't X at all. It's bloated crap they insist on running on X. It's libraries compiled with silly options. It's Xfree86, in some cases, which is simply one implementation of X, and has some weak spots. People, innocently, then generalise that because one poorly configured or designed system that happens to use X runs poorly for them, that something must be wrong with X itself, but that does not follow.

If you throw that same bloated software on a FB, it's going to be just as slow and bloated. If you compile your libraries with debug symbols on and use them on FB, it's going to be just as much a ridiculous memory hog as it was on X. If you don't use (or don't have) a good accellerated driver for your video card, changing from X to a FB isn't going to fix the problem.

FB makes sense for embedded applications where you really don't have room for X. But on a regular workstation, you have more than adequate resources to run it and run it well. If it's not running well, the problem is not X itself, and changing from X to a less sophisticated, capable, and mature system isn't going to address the real problem, except possibly by sheer accident.

In somewhat related news

[Anonymous Coward]

Eugina has released some screenshots of the New Redhat Severn desktop.

Don't be betting on it either way...

[Svartalf]

1) DirectFB supports GTK+ as well- I suspect Fltk's on the way as well.

2) You CAN have X apps under DirectFB with XDirectFB.

3) They're posting rather impressive framerates under Quake III:Arena with the DirectFBGL layer code.

4) Qt's ALREADY in the embedded space- QtEmbedded is what they're using on the Zaurus.

directfb

[Pflipp]

Maybe it's just the nature of the post, but I looked at the DirectFB screenshots (on DirectFB.org), and I see everything from GNOME 2 to WindowMaker to the GIMP, translucency, etc., etc., while I've never heard of DirectFB before.

Great. Now let's see how I get this on my Debian... hmm... I guess it would take a whole other Debian "port".

Hey; it would be cool to combine Linux + DirectFB + GNUstep (+ "3rd party" Free SW) into a MacOSX wannabe distro. It's not a problem if that would still mean it's lacking more than half of the basic OSX functionality; it's the other, Free half that makes the thought interesting!

The best solution

[Anonymous Coward]

Plan 9's. The graphics, mouse and keyboard devices are standard devices that can be mounted from a remote filesystem; the advantage being the windowing system does not need to handle the network layer. And since each process has its own filesystem namespace, you have a bunch of different consoles and each program accesses its one at /dev/cons.

The entire system, including the default program that runs in the window the equivalent of xterm [Far89] with `cutting and pasting' between windows is well under 90 kilobytes of text on a Motorola 68020 processor, about half the size of the operating system kernel that supports it and a tenth the size of the X server [Sche86] without xterm.

The components of Plan 9 are connected by a common protocol based on the sharing of files. All resources in the network are implemented as file servers; programs that wish to access them connect to them over the network and communicate using ordinary file operations. An unusual aspect of Plan 9 is that the name space of a process, the set of files that can be accessed by name (for example by an open system call) is not global to all processes on a machine; distinct processes may have distinct name spaces. The system provides methods by which processes may change their name spaces, such as the ability to mount a service upon an existing directory, making the files of the service visible in the directory. (This is a different operation from its UNIX namesake.) Multiple services may be mounted upon the same directory, allowing the files from multiple services to be accessed in the same directory. Options to the mount system call control the order of searching for files in such a union directory.

8½ serves a set of files in the conventional directory /dev with names like cons, mouse, and screen. Clients of 8½ communicate with the window system by reading and writing these files. For example, a client program, such as a shell, can print text by writing its standard output, which is automatically connected to /dev/cons, or it may open and write that file explicitly. Unlike files served by a traditional file server, however, the instance of /dev/cons served in each window by 8½ is a distinct file; the per-process name spaces of Plan 9 allow 8½ to provide a unique /dev/cons to each client. This mechanism is best illustrated by the creation of a new 8½ client.

From here

Windows or holes in the walls?

[Yaa 101]

This reminds me of a long going project that was once called Berlin and is renamed Fresco along the way...
Though their ambitions were higher with making a new windowing system...

They still exsist at:

http://www2.fresco.org/

Re:Windows or holes in the walls?

[Anonymous Coward]

Think what you will, but please listen. The reason the Fresco project is moving so slowly is because we are seriously under-manned and we are always looking for volunteers. I see a time where Fresco will be something great, much more than X could ever be. But this is only if we all chip in and help out.

-Stefan Seefeld
Fresco architect and lead developer

Terminate the Terminal

[fm6]

Well, there is the odd moment when it's a nuisance to not be able to run a remote X application. Like when you want to log into another system and run GVIM. But yeah, you're right, it's not worth keeping X around just for those rare circumstances, all of which have another solution.

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. Some of these were actually manufactured (I think there might even be some still in production) but X Terminals were never cheap enough to compete with single-user computers for most applications. I suspect that the X architects just took it as a given that most computing would always be done on time-sharing systems. Hey, don't snear at them. That was about the time that Intel almost went under...

Re:nice

[DaBj]

Yes, and for running desktop clients off of one server X is excellent.
Running it as a local desktop it is, however, not that excellent.

So basicly, the same people who whine that Windows sucks, especially all the legacy code from the Windii of old are now whining when the *nix legacy code that is X is beeing replaced?
Did I miss something? I think it's a great idea.

Re:DirectFB Inherently Insecure?

[nologin]

Well, unless you want to make a major hack to the kernel itself, the only way you are going to access the Linux framebuffer is to do so as root. Just look at how X works... It has to run as root so it can spawn a basic graphical display for you to use.

I suspect (since I have not tried it myself) that the problem with the DFB apps is that they don't come with the rendering abstraction layer that X provides (think client-server model). So every application needs to be root to write directly to the framebuffer. Sure, it will increase the rendering speed, but it sacrifices security while doing that.

You can't save it till you need it

[sig]

The idea of saving the network abstraction layer of X "till you NEED it" is flawed. If we design all of our applications without it, then when the occasion comes up (for some it may be rare, but I use it every day) it will be too much trouble to retrofit those applications to have X support. But if you assume X all the time, then you can gaurantee it'll be there when you need it.

If you are worried about interface responsiveness, there are plenty of things that are being done to address that without giving up the X paradigm, such as the X DRI extensions, and X server hardware support (its difficult enough to get NVIDIA and ATI's support for X, do you think they'll want to bother with 2 totally different unix graphic drivers?), and my personal favorite, the preemptable kernel (woohoo, Linux 2.6! (3.0?)).

Re:Don't think so....

[firewrought]

And so far as the "features" of X... the only feature X has that DirectFB doesn't is network independence, which very few users need, and those who do can use VNC or the DirectFB X server.

If anything, I want to see X11 incorporate more network saavy features... not remove them. It would be nice, for instance, to park X11 sessions and applications, much like screen allows you to multiplex terminals. (There are apps like xmove and others, but none of them are reliable enough yet to withstand X server reboots.) I'd also like to see more RDP-ish functionality (Microsoft's RDP protocal lets you carry sound and printer connections over the network as well). And more flexiblity when working with different screen depths and other resources would be nice too.

Getting back to your point... a frequent piece of design advice is to "optimize the common case". Yes, cutting out network independence does help performance for the common case, but consider: for many, network independence is a must-have feature. It provides all sorts of flexibility with different hardware arrangements and usage models. Thin-client protocals like VNC are nice, but they don't cut it for serious, extended use. And the DirectFB X server isn't going to provide a whole lot of network independence if developers are targeting DirectFB.

The true promise of network independence is only now being realized: it opens up new avenues, even for users who have been content with the "single PC, single desktop" model. It would be a shame to lose the network conveniences provided by X now that we have computers fast enough to host it. :-)

Yes, it would be nice to optimize the common case, but cutting network independence is the wrong way to do it: ideally, the client librarys should be able to choose b/t listening on the network and connecting via shared memory (if X doesn't already have an extension for that [Xshm?]). This choice should be done by the library so that all apps written for X11 are network-capable by default. If the programmer knows they are doing something intensive, then they should be able to do something special to insist on a non-networked app, but this should be the exception and not the rule (and I think X11 has extensions for this too [DRI? xv?]).