Guillaume Maillard’s article for OSNews regarding XFree86’s speed the other day has started a long-ish and interesting discussion on the XFree86 mailing list about how they can speed up things. Many developers from the XFree86 core team, Xig, Red Hat, Compaq and others have joined the discussion.
Discussion on XFree86’s Mailing List Regarding Speed
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Finally someone is addressing the problem, instead of saying “X is not slow, it’s the window managers” or “Yeah, but we can run XClock on a machine across the country!”
I know there are several other alternatives to X out there, but they are either missing features or incompatible with X now. And X is the de-facto standard for GUI apps on (Li/U)NIX machines, so (Li/U)NIX stuck with it, whether or not it’s good or bad, slow or fast.
I’m wondering how much of a speed increase can be realized, using X’s current architecture (DRI notwithstanding).
Now all X needs is some decent truetype rendering (and don’t say Xft, it’s good but doesn’t compare to Apple, MS, or BeOS’s font rendering). For some reason, Verdana never renders correctly, it’s always missing pixels here or there.
The Apple and Ms font rendering is great, true. But the BeOS 5 font rendering is terrible. The native BeOS fonts look pretty good, because they were created to look decent in that terrible font engine that BeOS 5 uses. Have you ever tried to install Arial, Verdana and the rest of the Web Fonts? Then, you will truly appreciate Freetype…
To me Redhat rendered fonts as well if not better than cleartype or whatever it is called on XP.
Not true. I have Arial installed as system font (and Courier New as fixed system font) and it looks great. I heard that it’s not good on LCDs but i have CRT. And Windows XP “smoothed” looks like blurred s*it compared to BeOS’ one. On BeOS only VERY VERY small strings could be rendered more sharply.
>Not true. I have Arial installed as system font
Oh yes it is true. The BeOS font engine does not render the TTF fonts *correctly*. Get the same font side by side on png shots from osx and winxp and even X11 and then compare it to the BeOS one. Night and day.
In fact, this was one of the reasons why Be had completely used a newer font engine for the version of BeOS that was never released: BeOS6/Dano. That version of BeOS includes a new, improved, font engine. The BeOS 5 one, sucks big time.
>>”To me Redhat rendered fonts as well if not better than cleartype or whatever it is called on XP.”
I agree. For the first time I can honestly say my Linux font rendering is superior to what I could get with XP. Before I installed Red Hat 8.0 the last time I put the factory XP image on this machine just to make sure it wasn’t subjective. After all, I’d been using Linux so long I thought maybe I’d just gotten used to crappy font rendering. But it turned out I actually prefer Red Hat’s rendering (on my laptop, on the desktop machine it hardly matters).
But this isn’t just “Red Hat” rendering. Red Hat (as usual) just happens to have done it first. The new GNOME and KDE releases will both natively support Xft2 and FontConfig, as far as I know. It looks like the days of poorly-rendered fonts in Linux are over. One more hurdle cleared!
Speed is another important hurdle. The kernel developers are addressing this (finally!) with the latency and preemption stuff in the development kernel. These patches are slowly making it into current distros (Gentoo’s had them for a while now).
You know what I think would be really great? ALL of the big desktop-related projects should finish up their next major release and then freeze all feature enhancements. Period.
KDE should release 3.1, then spend a few months doing NOTHING but speed enhancements. Ditto for GNOME (it’s fast now, but not fast as it _could_ be). The OpenOffice team should do the same. There has to be something they can do to make OO.o’s startup time more reasonable, even if it’s just to get the QuickStart applet working right. The same goes for Mozilla.
Stop ADDING to the codebase for a while and concentrate on streamlining what’s there already. That’s the “dirty work” I guess, that isn’t something most people want to do. Spending all day agonizing over a few lines of code in a loop to get a 2% speed increase probably isn’t all that exciting. But enough of those types of increases really make a difference.
I know nothing like this could possibly happen, but wouldn’t it be nice?
i can’t see it sucks in anything. i didn’t try to compare shots, but even if it doesn’t render “correctly” it doesn’t suck at all IMHO. it’s very readable. i tried dano some time ago and it looked good too (unless pumping up smoothing – than it lookad as blurry as on windoze).
Finally I hear someone saying it. I kept reading all those wonderful comments on how great fonts look on BeOS and could never understand why the hell people say it. To my eye the TTFs on BeOS always looked mediocre at best. Of course, God forbid someone should say that BeOS is less than perfect in any respect. The unfortunate soul who should dare to do so shall be instantly burned alive in the flames of BeOS fanatics.
yeah.. funny.. haha… if You don’t like it write it as Eugenia did. Why start stupid word fight again?
>it doesn’t suck at all IMHO. it’s very readable
Yes, it is very readable. But the point is to have fonts render as they suppose to, otherwise there is no point installing new fonts, especially web fonts that are used for surfing. For example, the Arial font on BeOS does not look like an Arial. It looks like something else. It is still readable, clean and usable and all, but it is not render the lines correctly. It is impossible to identify it as an “arial”.
>> I know nothing like this could possibly happen, but wouldn’t it be nice?
One word…..yes!
I found pretty sad that the first and only direct comment on Guillaume Maillard’s article in XFree ML is:
| I think the author is right that interesting things can be
| done in the area of performance and X. As far as
| particular problems that he identifies and solutions he
| proposes… well, they certainly wouldn’t be where I was
| looking.
I’m a programmer too, and I think this is an harsh reply to a perfectly reasonable list of questions. If GM’s solutions are so bad can you explain why to the rest of us?
How did XFree speed issues turn into BeOS font rendering issues?…this is OS news not BEOS news
anyway…even on Red Hat 7.3 i find font rendering to be more than adequate…i will admit that i am not a font afficionado, but to me, font-wise Red Hat 7.3 looks as good to me as Mac OS X and Windows XP
speed however definitely needs improving…i’m glad people are finally starting to accept this as a problem instead of running away and shouting “Linux rulez i am l337 h4x0r…you are win-bloze lamer”
It is amazing how close Linux is to the desktop…I can’t wait to see what’ll happen in the next three years
-bytes256
This is my opinion and as long as it doesn’t insult anyone I’ll express it however I see fit. What would be the point for me to “write it as Eugenia did”, she already wrote it.
I constantly tell people that X is slow, but everyone of those 7337 linux users to go use windows and shut up because X is faster. I guess they are in denial.
I was writing about Your sarcastic comment towards BeOS fans. And yes it could be takes as insulting because of that.
I tried Red Hat 8 beta (NULL) and it’s font smoothing (when it was used – not all apps use it) was quite good. Better than what i’ve seen on linux before.
Well, not only was that a patently offensive, mean spirited attack at a large group of people, 99% of which would never call themselves “7337”, but it took me three readings just to understand your grammer.
Thank you, you’ve made your point. Now, please let people who want to actually discuss an issue do it, without you.
Reading the list I found this too:
http://www.std.org/msm/common/WhyX.pdf
Also, whoever didn’t try Guillaume’s X test back when the article went live, give it a try:
http://blueos.free.fr/Static.tar.gz
While reading the thread, there was talk of “fixtensions”, which I thought was a cute term. The idea is to make extensions (think render) which can be used to get around actual bad design in X. That’s pretty clever.
But, it seems to me as somebody who codes every day, but has never touched XLib, that this would probably be a mess — as the toolkits would probably have to explicitly use these extensions to benefit from them. So, the poor people at trolltech and those writing gtk would have to write two X frameworks, one for vanilla X and one for XFree when it has those extensions present. That’s not a good solution.
Dont you just absolutely love it when a company listens to constomers (and actually does something about it) other than give us lip service 5 months down the road.
I know nothing has been done yet or may never be, but the fact is they hear us and have started reacting. This shows the people are in charge of alot of things over there, its not just one fat cat saying “no, I can make money fine without it”
I just typed ” constomers ” so either I have to copywrite that word or aknowledge im an idiot that started to say consumers and typed out customers..
hey eugeina where is that damn preview button! hehe
>I constantly tell people that X is slow, but everyone of >those 7337 linux users to go use windows and shut up because >X is faster. I guess they are in denial.
Ok, if know any linux users who refer to themselves as “7337 linux users” slap them silly.
Maybe I am too old school but I got into Linux because it was the Unix-like alternative with the most native apps for the x86 platform. So, for me and other people who prefer the *Nix way, it makes sense. This is back in the day when I used Postillon for mail, wmfinder for file management, Netscape for browsing and Windowmaker as a window manager — no desktop stuff.
Actually this whole “Windows beater” “Just works” linux stuff is silly. It is getting better but I do not want the world to move over to Linux.
Linux was created for geeks by geeks and no matter how much you slick it up it will still be too geek for most users.
Yes, X is too slow and serious improvements need to be made. Accelerated X used to be touted as much better but I have no idea if it is even still available.
Has anyone done a comparison of GTK+ 2.0.6 with directFB and X11? XDirectFB supports X apps too, with window moving+overlaps done with hardware rather than by requesting the app to redraw.
I don’t have a compatible graphics card to run it, but I think a comparison with X would settle this issue very quickly.
I’m really curious as to wether direct fb is a viable system yet.
As far as I can tell from the website, yes, it works. (I don’t have a supported card either) but, do you lose drag and drop? Do you lose the clipboard?
It’s one thing to have a modular underpinning for gtk/qt which can use a different display susbsystem, but frankly, without the extras, it wouldn’t really be usable.
>>>>
You know what I think would be really great? ALL of the big desktop-related projects should finish up their next major release and then freeze all feature enhancements. Period.
>>>
I get your point, but naaah, that’s not a good idea in my opinion. On the desktop, adding new features vis-a-vi improving existing ones is the only way linux is going to catch-up and eventually overtake Microsoft (technology wise, the market share is a different thing altogether).
Yes, better speed would be nice like you say, but you would have noticed that huge improvements have been made on the speed end as well. Redhat 8 is about as fast as XP, on modern machines anyway. Same for the major apps, like mozilla. The only app that really sucks is evolution (when you are using many IMAPed boxes anyway, I don’t know about using a single pop account). Evolution is slow and erratic, and I find using the mozilla mail is even better.
Glad to see this was covered. Requiring an application to redraw a portion of the window whenever it is obscured or moved off screen is silly, reduces performance, leads to botched rendering/compositing, and leads to completely corrupted application windows when an application goes unresponsive. This has been my primary concern with X and Win32’s architecture for some time now… improper use of shared memory.
I think every man and his dog knows that this is the fundamental reason why *NIX desktops will never take over. XWindows has this way of making your brand new P4 act like a P2.
<quote>
I found pretty sad that the first and only direct comment on Guillaume Maillard’s article in XFree ML is:
| I think the author is right that interesting things can be
| done in the area of performance and X. As far as
| particular problems that he identifies and solutions he
| proposes… well, they certainly wouldn’t be where I was
| looking.
I’m a programmer too, and I think this is an harsh reply to a perfectly reasonable list of questions. If GM’s solutions are so bad can you explain why to the rest of us?
</quote>
That certainly wasn’t what I’d call a harsh reply. It would be interesting to hear *why* he doesn’t think Guillaume is looking in the right place, though.
I have only had limited experience with BeOS’s fonts, mainly because I could never get my network card working in it, and so it was pretty useless for me. The original fonts I thought looked pretty good, but I never looked at them under a magnifying glass.
However, any discussion of X should include fonts due to X’s architecture–> the whole idea of just being a graphics server and not have any native widgets, or anything else. I haven’t tried Xft2 yet (just tried out some stuff about 6 months ago), but even if it is better, wouldn’t you have to compile existing apps to take advantage of the improved font rendering? Or does Xft2 have hooks for KDE/GTK/etc apps that don’t require recompilation? I for one do not want to have to recompile applications to get the fonts to look decent.
My complaint is this… whenever I set up Xft to AA fonts in a certain range, it would screw up fonts that it didn’t AA. Maybe this has been resolved by now, but I like how certain fonts sizes are AA and certain aren’t. All AA fonts make the screen hard to read and give me eyestrain.
Even Be Inc. engineers said (read, pls, BeOS Bible carefully!) that font rendring is (softly said) not the best possible engine:).
For me (inspite i’m real BeOS fan) – it s*cks totally.
I can explain it to you on BeShare with screenshots and some theory, but don’t be blind…
And IMHO, Dano rendering isn’t so better, though, didn’t try it with new type of BitStream fonts (ffs)
From that posts we’ve seen, very few people read the thread. A great deal of the thread was devoted to how X, in fact, really wasn’t that slow, and that stupid apps were to blame for a lot of things. In particular, apps tend to draw everything in a local pixmap then blit the results to the screen (which doesn’t take advantage of hardware acceleration) and they handle expose events very poorly, particularly with respect to windows with child windows. Also, apps tend not to compress events in time. For example, if does something with the mouse wherin every mouse message (sent hundreds of times per second) causes an update to the window contents, apps will redraw for every messege sent, instead of compressing several move events into one update. One important suggestion was that app developers should seriously take a look at the details of the protocol and do things in the best-case way, not the worst-case way.
The X related stuff was comparatively minor. Someone mentioned that he and Keith Packard had been discussing an extension to clean up certain problems with the protocol, but from the looks of it, these were minor cleanups, not major overhauls. Also, there was proposed an extension to allow the window manager to manipulate windows in groups to allow more efficient updates.
That said, the theme of the thread was handling updates efficiently. As was pointed out in the thread, updating efficiently requires some quite sophisticated logic on the part of the application. Thus, a major help would be some sort of UI layout library that would abstract this sophisticated update code into a common codebase.
PS> To Bascule, expose events *are* a good idea. Buffering the contents of all windows (ala OS X) was mentioned in the thread, but met with significant criticism due to its inordinate use of memory. As we move to vector GUIs (ala OS X) buffering giant bitmaps becomes an even more stupid idea, because it’s easier and faster to store the vector form and just re-render it when needed.
Having trouble understanding the thread? It’s really simple.
The XFree team isn’t working on speed. They’re working on crack!
<ahem>
do you realise that this means OS News now commands a great
deal of power. sparking a discussion based on a crituique
writen for here is the big time…were talking O’Reily Factor
type power 🙂
| particular problems that he identifies and solutions he
| proposes… well, they certainly wouldn’t be where I was
| looking.
>>I’m a programmer too, and I think this is an harsh reply to a >>perfectly reasonable list of questions. If GM’s solutions are >>so bad can you explain why to the rest of us?
>That certainly wasn’t what I’d call a harsh reply. It would be >interesting to hear *why* he doesn’t think Guillaume is >looking in the right place, though.
Maybe it’s not harsh, but he dismiss such an articole with a I_know_things_you_never_imagine attitude. And all the replies are about minor X adjustments and how bad WM and toolkit are written.
I’m thinking that the real advantage having an integrated graphical engine is that you cannot blame others if things go wrong.
<quote>
Maybe it’s not harsh, but he dismiss such an articole with a I_know_things_you_never_imagine attitude. And all the replies are about minor X adjustments and how bad WM and toolkit are written.
I’m thinking that the real advantage having an integrated graphical engine is that you cannot blame others if things go wrong.
</quote>
After re-reading Guillaume’s article, I think I understand this attitude. Guillaume is basically saying rewrite the X server, forget about backwards compatibility, put the window manager in the server…until you don’t have X anymore. That’s okay, maybe it would be worthwhile to do something like that, but for someone who is devoted to XFree86, it’s not a good idea because it breaks standards. X has been around a long time, and if you’re going to distribute an implementation of X, you might as well make it compatible with the standards, or call it something else.
I stopped using the Mandrake-included X server. There’s a much better one available, that’s been available for quite a while now. It only supports writing to the framebuffer, but that’s not a problem even for games with the new available accelerated framebuffer drivers (and I can’t play games on my i810 anyhow). It doesn’t need any configuration files; the mouse is assumed to be at /dev/mouse, and everything else is autodetected from fbdev.
The program I use is called KDrive, aka Tiny-X. It’s part of the XFree86 project. It’s fast. Mind you, I still think that Fresco/Berlin is a better idea in the long run, but unless you’ve tried KDrive, stop complaining about X’s speed – and start complaining that RedHat et al won’t include Tiny-X as default.
Regarding the fonts in Redhat 8.0, most applications that have been written for Gnome 2.0 have taken the advice of the GNOME development crew, and that is, to keep well away from GDK and other moving targets and instead use Pango + GTK2 + XFT2, to ensure that when the next “big release” rolls around the corner, which will most likely be next year, they will be in a position to either simply recompile or modify their code slightly, voila, compatibility.
By also taking this advice, it allows the GNOME developers to be a little on the radical side and break compatibility with previous releases without the fear of 100s of apps needing to be re-written from scratch.
Please reread Owen’s text… IMHO, he’s just stating Guillaume found things in places of which he, Owen, would never think. This is even a compliment to Guillaume, as Owen is indirectly say Guillaume was very smart to think about such things. In my view, it’s not harsh at all!
I’ve used Accelerate X from Xig. It is atleast 2x faster than XFree86.
As for those who complain saying “X11 is badly designed”, bullrot. Pick up a book and actually read instead of sitting on a fench throwing stones at an issue you know nothing about. What ever problems there are they can be easily fixed via extensions and so-forth.
If you don’t like X11 and Linux then stick with Windows, see if I or the other 3million Linux users care. At the end of the day, YOU came to Linux not the other way around. No one has forced you to think, use or install Linux. You made the choice, now handle it.
As for me, I’ve been using Linux for 7 blooming years, from the early days of slackware to SuSE and Redhat. Prior to that, I had an Amiga 500 and prior to that I own a BBC Micro with 32K of memory and a 5 1/4 drive. I’ve seen Linux improve in all areas. Distributions becoming more professional, applications easier to use, number of programmers considerably increased, desktops become more lively vs. the basic desktop of CDE.
Funny how EVERYONE of these people who complain about Linux don’t even have a CLUE about programming or software design. The way certain people act in this forum would be like me telling a mechanic how they should do their job. Sure, I know the basics and how to change the oil, however, I certainly do not go out of my way to tell him/her what do to. I let him give me the advice and if I find it strange, I’ll ask a friend who may have knowledge about cars and tell him what the mechanic told me.
And your reply sounding like a person who has never used a *nix desktop. Having use SGI’s, SUN and HP-UX, I can clearly say, you not know what the heck you are talking about. Sure, admitingly SUN’s X11 is semi-alright. HOWEVER, SGI’s implementation is stable, fast and reliable.
If you’ve got a axe to grind with X11, use some facts, not psuedo BS made up to ammuse your simpleton cravings for attention.
You know, X really has made some giant steps lately. Currently, I’m running kernel 2.5.44 with XFree 4.2.1, trying out GNOME 2.1.2 just for giggles. To configure X, I typed in X -configure, and that was *it*. No user intervention, nothing, just one command and it generated a working XF86Config. I compiled my kernel with support for USB, so I could use my mouse. After I had started X, I realized my mouse wasn’t plugged-in (it’s a laptop) so I plugged it in. Usually, you then have to restart, but not this time. I plugged it in, and the cursor started moving around. Even stuff like changing the speed of an external mouse (which doesn’t work in XP without downloading Logitech’s drivers) worked just fine.
I went to go install some fonts, so I copied the fonts over to /usr/share/fonts, and magically, they appeared in the GNOME font selection menu (thanks to FontConfig!) With the CVS-FreeType, fonts even look wonderful! Over the last year, the X devs (especially Keith Packard and crew) have been improving X at a breakneck pace. We’ve got Render (compositing + vector graphics), Xft (anti-aliased fonts), FontConfig (duh!), and XRandR. At this rate, XFree 5.0 is going to be one hell of a release!
While Accelerated X has a reputation for speed, there are some issues. First, AX was a whole lot faster than XFree in the 3.x days. XFree has nearly caught up these days. Second, drivers matter a whole lot. Toms Hardware did some testing awhile ago, and found that the NVIDIA drivers on a GeForce were several times faster (in 2D) than the Matrox drivers. Since Matrox hardware has excellent 2D performance (and NVIDIA isn’t reputed for particularly great 2D performance) the difference lies with the drivers. For ATI chipsets and whatnot, the AX drivers are clearly superior. For NVIDIA chipsets, XFree86 is just fine.
can someone give me an example of how X specifically is slow?
I run Unreal Tournament, Maya 3d, I drag a window around the screen and fling it around, I click on menus – they pop right up.
X does not seem slow to me.
on the other hand=
when I launch Mozilla on Redhat 7.3….on an athlon xp1800 w/7200rpm drive…there is a noticeable delay compared to windows (that i’ve grown accustomed to), for it to launch.
the last observation imo is not X’s fault.
if i were to guess…it would be the kernel, but i really don’t know. i do know, that once the app is launched, i can maximize, minimize, drag, navigate menus quite speedily.
So it’s my belief that a lot of wankers are confusing the issue.
I do think that the GUI responds to operating systems and programs more quickly in Windows, compared to X.
I’ve always assumed (maybe incorrectly) that this was due the fact that Microsoft runs the GUI at the executive layer in windows (NT 3.5 did not).
The consequence: IN WINDOWS THE GUI CAN BRING DOWN THE ENTIRE SYSTEM.
In the rare instant that the GUI got away from me in Linux, I simply changed to a different console. At the worst I would ssh in and kill off X resources. The machine is not locked up…I don’t even have to reboot.
I can’t remember the last time I’ve had to hard reset any of my linux boxes.
This has been a blessing, and X being a little bit behind MS gui is totally acceptable. But SLOW? Hell I’m getting 100 plus frames a second in games, and I’m spinning geometry around in real time within Maya. I don’t think there is anything SLOW about X.
If someone can make improvements, or optimize it. I welcome that.
Someone says X is slow….I want a specific example.
Moog: X is slow
I wish I could kick you in the face right now.
Moog, you’re comparing 2 very different things..
3D rendering is done using a different path than the ‘normal’ drawing of windows and widgets..
Jack, i actually laughed at that.
I know i probably frustrated you. And I obviously am not up to the level of understanding that you are. Oh well…thanks for the enlightenment. I’m glad I could provoke you…it was unintentional, rest assured.
Richard,
I mentioned several 3d related apps. But I also mentioned Mozilla, generic menus, and plain old windows. Those menus and windows could be gftp, pan, gaim, galeon…you name it. My intention was to include drawing of 2d screen elements in that passing comment.
so you are basically saying widgets, windows, menus, and other misc 2d elements are drawn/handled slow in X?
Has anyone any empirical data, differentiating/identifying where all the slowness is coming from? It’s all X’s fault right? There is no latency coming from the kernel, or KDE/Gnome, or from a specific library right?
I’m just asking.
If you want to kick me in the face…well.
I find that amusing. 😉
I just felt like being a troll, and threw that comment in because http://www.realultimatepower.net/ uses phrases like that alot.
I completely agree with your comments on X though, X can play 3d games just fine (abiet a few frames slower than windows, but that could be due to the actual drivers, not X). I would imagine the slowness caused by X would be how it renders what is visible and what is not. This could also be further aggrivated by the graphics toolkit used to make the programs. Although X was designed around networks, and so a tiny hit in performance is almost not avoidable.
So, in summary, I agree, X is probably not the devil in this case
i’m stupid for not catching that reference.
😉
>Yes, X is too slow and serious improvements need to be made. >Accelerated X used to be touted as much better but I have no >idea if it is even still available.
http://www.xig.com – yes its still availible and *yes* its as fast as advertised. You’ll notice a perk up across the board and on many kinds of tasks (scrolling a document with lots of text, for example) you’ll see a huge difference. Its not free but its very worthwhile.
Regards to XIG costing money. if you are downloading Redhat Linux 8 for free, is it really that bad to pay a bit of money for a commercial quality X server with drivers written based on the specs given to them by the manufacturer?
I’m a bit surprised to see a link to the article about XFree performance in the mailing list of XFree86. Isn’t other developers using X?
Because XFree86 coders know exactly how it could be improved and assume that RENDER, backing store are not SOLUTIONS, things could evolve. But I’m not sure that the “read the spec” and “pray for someone to improve toolkit” is a best attitude.
When will they start to ask themself things like:
“why don’t people read the spec?”
“why are toolkit so slow?”
I have some answer to these question, but because I have clearly no time to work on XFree86 development, I can wait and continue to use XFree86 as I want.
Regards,
Guillaume
Sorry but I read books how X is designed, I used to program with XLib and I say “X is badly designed”.
Extentions can hide most of the problems, but something instead of hiding problems, having a fresh restart helps.
Rayiner Hashem reports that the thread (that I hadn’t the time to read yet), mostly says that applications and windows manager should be improved to 1) better handle events, 2) avoid drawing pixmaps and sending pixmaps,etc
For me, 1) X should have been better designed to avoid sending all those events in the first place (unless the applications asks for all those events of course), 2) and as for applications drawing themselves their pixmaps instead of asking the X server to do it, maybe it is caused by applications being not sure if an extention is there or not they have to code as if extentions weren’t present, so they do it anyway.
[]
>If you don’t like X11 and Linux then stick with Windows,
[]
That’s a childish argument, Linux is doomed to use X11?
I don’t think so! Blue Eyed OS plan to use Linux kernel and eventually to ditch X11 (if DirectFB is available).
This make sense to me: use the best part available.
And about complaining, sorry I’m a programmer for 7 year, and frankly your arguments are not very well grounded either.
Well, why don’t YOU WRITE A **** SOLUTION, if you are a so-called “programmer of 7 years experience”? I don’t see you going out, rewriting a whole NEW API + rewriting 1000s X11 dependent applications + porting 100s of display drivers to thing “new thing”(tm) you have instore.
As for your pathetic remarks regarding DirectFB, my god, someone, please smack this young lass around the head with a wooden spoon. There have been papers upon papers upon papers WHY it is a stupid idea. Ranging from its lack of network transparency to its terrible latency issues.
As for X11, there is nothing wrong with it. It was designed from day one to be platform independent and network native. Simple as that. It has lived up to its original design goals. If you have something to moan about, it is the implementation of the standard, not the standard itself.
Heck, why don’t I just rip into GDI/GDI+ and its pathetically stupid idea of ramming into ring 0 just so the “eye candy” addicts of the world can get the warm fuzzies when using NT.
I would say the majority of users will never ever use the network functions of X. And yes, xlib is horribly written, and no, I personally do not have time to rewrite it. By the same token, just because I do not have time to rewrite code does not make that code any better, nor should we sugar coat it matthew.
Is it because X is Network native that it is slow? Is it because of bad drivers? Is it all these toolkits that insists on being skinnable? What is it?
Fact remains, every other GUI I’ve ever used have been more responsive then X (Win311, BeOS, Win95 and up, MacOS 9, MacOSX), not complaining, it works “good enough” for me but as everyone else I wouldn’t mind it being just a tad more responsive, especially since I use it daily for a range of office work.
I would love for Linux to get one unified GUI and skipping all the changable interface stuff that I see as completely useless, I used BeOS for a couple of years and it had static UI, no one complained, some (like me) even thought it was far superiour the rest.
> Well, why don’t YOU WRITE A **** SOLUTION, if you are a
> so-called “programmer of 7 years experience”?
No need to shout, you’re being rude.
It is easy to see the problems in the design of X, it is very hard to code a replacement.
As for DirectFB, I do not know it very well, I just repeated what Blue Eyed OS developers intend to do eventually (right now they are using X but they hope to get rid of X later).
I do prefer the design of Berlin instead of X, but I think that they’ve made a mistake by using Corba instead of something lighter: they ported Berlin on an Ipaq: it used the full 24 MB of the Ipaq whereas small X implementation can use much less.
But Berlin is still in development so they should be able to lower their memory usage eventually.
It’s not a problem with networking.
An application running on the same machine as the X server doens’t use the network to communicate with the server.
It’s not a problem with networking.
An application running on the same machine as the X server doens’t use the network to communicate with the server.
No, but exposures are still handled over sockets, be them Unix domain or not. Exposures shouldn’t be handled by applications, but by the server. If you read the thread you’ll see a great deal on this, namely that clients handling exposures is an antequated practice from the days when systems didn’t have nearly the resources they do now.
The main problem with X is that it’s increasingly becoming the case that the burden of making applications work well in X is being shifted off the shoulders of the X developers and placed squarely upon the toolkit developers. However, in the classic manner of the Bazaar, the toolkit developers aren’t working with the XFree developers, or really looking at some serious performance bottlenecks in the rendering pipeline resulting from the way in which the toolkits are implemented. (I’m mainly talking about GTK here…)
The only way I can see this situation improved is increased collaboration between the XFree developers and the toolkit developers, but all I’ve really seen so far is a great deal of finger pointing and blaming the other camp.
It rather reminds me of Linus versus the glibc developers… thank god for FreeBSD where the kernel developers also write the system libraries
Obviously you don’t know the mind set of UNIX developers of UNIX users.
UNIX User: I want MY computer to look and act exactly the way I want it to act.
UNIX Programmer: Hmm, I like that language, but I don’t like that widget set. Thats alright, I’ll use foosmit instead of foosmot.
BeOS/Windows/MacOS: I want to told how to use my computer, what colours I can use, what applications I can load, what widget sets I can use.
As for you comments regarding speed. I am runnning Redhat GNU/Linux 8 with a Matrox G550 and 768MB RAM, and I have NONE of the so-called issues you are having. The only people who do fit into two categoris:
1) GeForce users
2) Idiots who have 810 chipsets with integrated video