Reading the notes of yesterday’s teleconference with people like Mike Harris from Red Hat, fontconfig’s Keith Packard and others, it seems that they have decided to actually do fork the XFree86 codebase or at least to create a parallel organization to “demonstrate how a scalable community might work” (they also seem to email eachother in a non-archived mailing list of a sort). They currently looking for a nice, catchy name for the project, but they have registered xwin.org just in case nothing better will come up. Reactions of the teleconference have been recorded at XFree’s public mailing list.
XFree86 Fork Imminent?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why don’t I like this?
Well, I think change is a good thing. Stagnation isn’t. Also, more accessible X development process is what we wanted for some time now, right? Good luck, then.
I think that this is a good idea, the OSS community will definitely benefit from a more suitable X Windows binary, then again, if we see any incompatibilities it could become quite the hell hole to work with.
Just my thoughts, I’m probably wrong. Right?
The cool thing about open source is that there is alot of inbreeding going on. Since the xfree fork will be based on xfree, their codebase will have a lot of similaties and every once in a while bored hackers like to “backport” and “borrow” or “steal” cooll features/ideas/implementations so both projects still evolve at a good pace.
I always thought that inbreeding was bad. I think a better analogy would be that closed source is inbreeding, and open source is widening the gene pool. Seems to make more sense.
What I want to know is details, details and more details. Things are very vague at this point. Does the new project intend to provide a compatible alternative to XFree86 or will it aim to replace it ? Is it going to be Linux-only or are any other platforms going to be supported ? I am a FreeBSD user and having a Linux-only XFree86 fork would be (IMHO) ridiculous.
> Well, I think change is a good thing. Stagnation isn’t.
“Change” would be an interesting choice of name, “Stagnation” of course not.
I suggest “Supernova” as project name.
Regards,
Marc
the problem in the XF86 code base is not the interface to the code, it is the back end cruft. why would they change the interface unless ther is no other way around a certain bottle neck.
Why does he have to be such a prick about this? In Apache, we just vote +1, -1 or +0 and move on, even after an impassioned speech. Anyone who can’t accept the result goes off and forks and everyone wishes each other the best of luck. If David really feels that the group is illegitimate and that no changes are needed, just say so and ignore the group. If he feels lingering resentment but recognizes the value of engagement, delegate someone else from the BoD or Core Team with more neutral emotions. Staying engaged while displaying open hostility isn’t productive for anyone’s agenda.
Organizations rarely reform themselves, especially if significant change is needed.
You can blah, blah all you want.
The bottom line is X needs a kick in the ass.
Imagine Arpi (from MPlayer team — or used to be) joining
this XFree fork…. we could get to see some real evolution
in X..
good xfree86 sucks! time for a change!!! may be you can change
drivers now with out geting trapped in google is you freind hell! i am verry happy with this !!! hey mabe 3d on the desktop now! betterx would be a good name.
>>The bottom line is X needs a kick in the ass.<<
Absolutely it does. While X does see some significant changes, they frequently seem to be a LONG time in coming – like decent AA fonts for instance. A little competition in a stagnant organization is only a good thing.
This is really bad news. The *nix community needs to *combine* and not diversify. You may say “divide and conquer”, but when you divide your army into a billion batallions of half a soldier then it’s time to unite again, and not divide.
Surely, good changes and innovations might come from this, but in the end it’s going to be bad for those people that would like to see a non MS operating system on all pc’s.
IMHO you are whong. Combined and unified efforts
only work on organizations where people get paid to work.
In a community-oriented project, competition is a great
way to encourage people to work more and better.
Will this forX perhaps feature fully composited UI capabilities al’a OSX? Because either way you look at it that is the way of the future, older X can still be used for server type work on older cards, but with the GPU evolving in a such rapid rate I think it would be fairly stupid to not start take advantage of it in other things then OpenGL screensavers (for us non-gamers).
Since the fork guy is the randr guy (as I understand it) I don’t think the composited idea should be too big a of a leap.
Either way, I support the fork, Linux have eaten everything on the server market and I think a fork is necessary to start chewing on the desktop market.
I love XFree, but what they hay, for the sh** out of it!
Forks are natural in evolutionary development, like animals. Only the better (strongest) will survive.
I think that they will not be stupid to break X compatibility. A fork within Samba project occured to try less conservative advances. I think that the same will be made with XFree86 code.
Personally, I think xfree is a great name, but there would be legal troubles with that. 😉
Forks can be good. Think of a fork like a branch, certain developers go off and develope new and exciting things removed from the main trunc, and then maybe later the two remerge (except you never know which will be the “trunk” and which the “branch”).
Still, this isn’t an issue for armchair critics. There will be a lot of inertia going agaist them, but if they put out something exciting it might get used. Actually, there are enough linux distros that *someone* is bound to use them.
A fork will make things exciting (but ask me if I want something like gcc to fork and my oppinion would be much different).
Any word whether they intend to use Sun’s font system?
EGCS was a fork of gcc – eventually it became the main gcc branch (along with the group that forked)..
On the other hand emacs fork (if xemacs was a fork of emacs) had a different route – where both co-exist now..
Will be interesting to see which path the X stuff ends up in..
…but we think that they are because of all those *nix wars.
Anyway, we all should remember that this is Open Source, folks.
The Linux kernel is forked as hell – and it’s advancing quickly because of that.
The BSD forks led to three high-quality OS – Free, Net and OpenBSD.
The GCC fork led to the forkers (EGCS) actually taking over GCC.
Samba, MPlayer etc, all those apps were forked to people explore new possibilities.
Why XFree can’t be forked? Why an XFree fork would be a bad thing? I personally believe that will happen with XFree what happened with GCC: the forkers will take over the development.
Finally, a better graphical engine for Linux! As for the name, how about XFork86?
// Bad example of forking
if (fork()) {
. //XFee86 project
. improve_x();
} else {
. //xwin.org
. improve_x();
}
//produces two different improvements to XFree86
//Good example of forking
if (fork()) {
. //XFee86 project
. improve_x();
} else {
. //xwin.org
. add_functionality_to_X();
}
//Lets XFree86 improve and xwin added functionality like randr
While I hear all the time that XFree86 has problems, where can I read something that actually explains what some of them are.. Or perhaps someone can elaborate here who knows..
Is the fact that the mouse “feels” less responsive in linux as compared to windows one of these issues?
Is the fact that the mouse “feels” less responsive in linux as compared to windows one of these issues?
change ur mouse setting to match your windows mouse setting.
Don’t trust most of what you hear about X. Unless someone gives you some benchmarks to back up what they say, it’s probably a knee-jerk reaction. If you want to find out where the real problems are, read some of the XFree mailing lists (particularly the threads written in regard to the recent fork) or the KDE or GNOME mailing lists.
To take your war analogy and run with it, it’s more like the current crop of commanders are just ho-humming about, not really sure they want to go fight today. As for “divide and conquer,” it’s more like cloning the enemy but halving your own side’s numbers. OTOH, if the new half is much more motivated to make changes happen, this can be a net win.
the situation is not comparable to the distribution diversification, which splits somewhat the linux community with lots of package formats and annoying differences.
It’s more like the linux kernel forks, as it was pointed out in a previous news thread on the subject. This fork will help making new experimental features to be tested and then incorporated in the xfree tree.
Embrace for impact? 🙂
It’s getting to work bazaar-style. Fork and develop, unfork and consolidate changes.
I say good luck for both branches.
Why are graphics drivers not integrated into the kernel in the same way sound, network card, ide, chipset drivers etc are?
There is support for some graphics cards with fbdev in the kernel but it’s a small subset compared to xfree.
All graphics card drivers should be part of the mainstream kernel, rather than a seperate project. It would mean developers could use an xfree, directfb, blueos api, yet still all benefit from the xfree driver work without having to use Xfree86.
RE: Getoutofhere
“// Bad example of forking ….”
There should have been a fork bomb in the bad example
why dont you modify it and post the source code
The whole point of X is to be operating system independent.
Do you really want to piss the BSD people by including it in the kernel?
Why are graphics drivers not integrated into the kernel in the same way sound, network card, ide, chipset drivers etc are?
There is support for some graphics cards with fbdev in the kernel but it’s a small subset compared to xfree.
All graphics card drivers should be part of the mainstream kernel, rather than a seperate project. It would mean developers could use an xfree, directfb, blueos api, yet still all benefit from the xfree driver work without having to use Xfree86.
It’s what I always wonder why they do that.. I don’t understand why it’s seperate from OS’s kernel projects. Perhaps, portable better that way?
I just hope that this doesn’t discourage companies like NVIDIA from releasing drivers.
/me crosses fingers and hope that a rewrite would happen as result of the fork…
Personally, I think XFRee86’s code is too bloated. And if it isn’t community issues that is keeping users away, it is Xfree86’s codebase itself. Comparing XFree86 with other commercial stuff like Metro doesn’t really gives me a good impression of XFree86.
Why are graphics drivers not integrated into the kernel in the same way sound, network card, ide, chipset drivers etc are?
XFree86 outdates Linux’s framebuffer. As a result, it is darn smarter writing drivers for XFree86 than for the kernel. Besides, NVidia provides drivers that work both in the kernel and XFRee86.
The only way to change this fact is to make XFree86 Linux-only. And considering the market for non-Linux operating systems, especially Mac OS X, I would find such a change in direction utterly stupid.
evolution isn’t needed (dinosaurs will never be sentient 🙂 what we need in this case is revolution (DirectFB being the comet 🙂
(and yes, it’s possible to port DirectFB to other OS’s like bsd’s or osx)
If the fork of XFree86 were to explore more efficient possibilities, then it would have to break compatibility.
This would be incredibly bad for the Linux community, as new drivers would have to be written / the old drivers would have to be ported, as would GUIs such as KDE and GNOME?
I would be the first person to use this fork.
Go XWIN!
we are going to get a backwards compatible X wrapper and a new optimized X server architecture, </me goes out to watch thunder over louisville, ends up watching crank yankers, extended play, red planet> and all the distros will probably switch to it. at least this is the way i hope it turns out. and how damn long is this gonna take?
This is definitely the right moment to make the move. Breaking away isn’t bad if things are for the better, though. Past is past, the future is there to take, why not grab it?
There are so many things to consider, like providing a framework for GPUs which will kick that perf meter higher.
>> Why are graphics drivers not integrated into the kernel in the same way sound, network card, ide, chipset drivers etc are?
It’s arguable if they’re really integrated, since they are optionally compiled and can even been made as loadable modules.
Some people go to the point of considering the kernel all code minus the drivers. This even happens (albeit to a very limited extent) with Windows, as they install appropriate drivers from the original CD.
Though I tend to opt for this view, many experts (which definitely is NOT my case) are comfortable with the monolithic, non-modular kernel idea. Go figure! 😐
>> There is support for some graphics cards with fbdev in the kernel but it’s a small subset compared to xfree.
It is “convenient” to put things which are common (like VESA support) into kernel. If you have a quirky video board, you’ll need a driver.
>> All graphics card drivers should be part of the mainstream kernel, rather than a seperate project. It would mean developers could use an xfree, directfb, blueos api, yet still all benefit from the xfree driver work without having to use Xfree86.
I guess I simply didn’t understand that last phrase. Anyway, one of the utmost “holy graals” of doing quality software is making it lean (sometimes lean is impractical, as it’s not cheap).
If you’re using an OS in a device with no display (like a cluster node, for instance), there’s not much point in having a graphics interface… IMHO.
Well if you have read the comments on the board seems this fork will specifically be with l,inux in mind they class bsd as a good server os but dont see it likely for it to be on the desktop as a main os.
As for compatibility if they intend to do what they intend to do. then i doubt the xfree86 will be compatible. Which is a good thing really cos xfree86 needs a rehaul network shit should NOT be removed one of the dumb arse BOD’s who know develops on windows and has nothing to do with linux was going on about that it should be made more like windows. Funny thing about it is that windows longhorn and after series are planning to provide what x already provides. So that arguement is null and void in the network sides it should be rehauled and enhanced so that over a 512/256 internet line u can forward applications etc much better. Lets not forget internet acess speeds are increasing so providing the x networking is a very clear advantage. But it should moved away from lan specific to internet specific. Which would be absolutely awesome.
As to the outcome of the fork go ahead with it good stuff im glad its being done. X isnt bad dont get me wrong it did what it was designed to do very well. But on modern hardware it just doesnt take full advantage of all thats available and its a shame that the BOD’s are so set in their ways. I still dont get what that windows guy is a BOD ok u were part of development once u were a founding member good stuff. But do you really need to be their ?
Last thing as i said good luck to them. The good of this project will be known by when the core is up when work actually starts and the politics is pushed to one side.
They have definately started on the right foot keeping it completely open to all. Hopefully actual work on the coding starts and they take comments and criticisms level headed hopefully too many people dont stand up and go nay nay to everything they test, cos that would be a real bad thing at the end of the day we should all be supporting them (all those that use linux on desktop) and giving them encouragement. What will be interesting to see is if the xfree86 start trying to block their path i hope not.
Other thing to note though is if the project does start and the code is gnu/gpled it probably wont be merged back into main code cos the xfree86 licence is like bsd. But i actually would like it to be gnu/gpled reason being is if they do make some amazing leaps. That companies like microsoft cant just thief microsoft would be no where without all of the bsd code is thiefed over last few years. and the fact that that bsd cant even say the name properly on air showed so much disrespect, cos windows would be
no where without it.
This is my 2 pence worth. Ive been following the thread on xfree86 etc. I really hope good comes out of this.
Damn reread my post and some of it dont make sense. Sorry 5:30 am here ignore spelling grammatical errors. The end it should be :
and the fact that bill gates cant even say the name properly (bsd)
XFree86 has forked according to sashdot (So wheither it has really forked is of course still up for question).
http://developers.slashdot.org/developers/03/04/13/0253224.shtml?ti…
What is holding it back are the complainers in the X consortium who don’t want new ideas because it throws a spear into their inferior X-Servers. Just look at Xsun, can anyone say, “boy, that really sucks”? Xft doesn’t work, fontconfig doesn’t work.
Over all the other X-Servers need to be undated and kicked into action, it is the so-called “established” X-Servers holding up development NOT XFree86.
Now we have some prune in SUN who wants to throw the baby out with the bath water and use a completely new fontconfiguration/manipulations/stimulation tool to replace Xft.
Sun is just pissed off because their X server is so old and crusty and their directory structure is so screwed, just look at /usr/lib, bloody links every bloody where, from here to openwindows to somewhere else to somewhere else and what reason do I get, “oh developers can’t find the libraries”? these are dimwitts who can’t even use the -I and LD_LIBRARY_PATH? my god, I was using basics like that when I was 12 years old.
Well, congradulations, you’ve just made the kernel panic in the *NIX world a common thing! wow, what an innovation, grabbing Windows worst possible feature and embracing it! I wish was as talented as you, being completely ignorant of the bloody obvious that you have mastered in such a short period of time.
To be a little less harsh than Matt here, I’d like to point some things out.
1) Most drivers don’t need to be in the kernel. The DRI model is almost ideal for today’s hardware/OSs. There is a itsy-bitsy part that runs in the kernel that just bangs some registers and provides an ioctl (kernel API) interface to that functionality. Then there is a userspace graphics driver that does the actual drawing, and invokes the kernel driver only when it has a batch of commands to send it, or has to respond to an interrupt.
2) The graphics driver is huge. The OGL NVIDIA driver is several times larger than the average kernel image. Shoving that into the kernel is just asking for instability.
Matthew Baulch: Supporting XF86-A and XF86-B could be hell
Actually, what is hell is the amount of different distributions requiring different binary distributions. One thing I suspect is that a little after the fork, the fork would overtake XFree86. Maybe less than a year. I’m putting my money in a year. If it all goes well (meaning no splits in the new community).
Mainly because much of the developers that actually brought new features to X may be going to the XWin side of things.
what we need in this case is revolution (DirectFB being the comet 🙂
I quite doubt DirectFB can be ported over to BSD and Mac OS X. What could be done is something like DirectFB built for FreeBSD (which IIRC has a framebuffer) and Mac OS X.
What I much prefer is that XFree86 being based on GGI… oh did I let the zealot part of me come through?
Chongo: If the fork of XFree86 were to explore more efficient possibilities, then it would have to break compatibility.
Actually no. It can add new features and all, and still run old applications – except that the old apps can’t use the new features without adapting.
Matthew Gardiner: Xft doesn’t work, fontconfig doesn’t work.
Hmmm… didn’t they have their own thing, not XFT, that is compatible with XFT? Yeap, they “threw the baby out of the bath water”, but from where I’m standing, what Sun has a superior design… I don’t know about implementation as they don’t have anything to show for.
But overall I agree than Xsun sucks hardcore. They badly need to rewrite it, or license something better from their competitors (like Metro) or fork XFRee86.
Actually, the hardware support issue should be minimal. XFree has had a stable driver API since 4.0, and Keith has commited to maintaining driver binary and protocol compatibility. XAA and DRI were totally new for 4.0 so they probably wouldn’t gain much from changing them around anyway. What I’m more worried about is if XWin has extensions XFree86 doesn’t, about DE’s supporting them. Also, GGI isn’t that exciting anymore. XAA is much improved over the older X driver API, and in conjunction with the DRI, seems to be serving X just fine. Now, presuming the reason you want GGI is the wide platform support, what would really be an interesting (and probably easier) project would be to break out XAA so it didn’t depend on X. It’d be a insanely hairy though. I’ve looked at the X codebase, and it’s not pretty down there. The directory structure alone is enough to scare away any would-be hacker. It doesn’t help that a complex XAA driver (nvidia) interfaces to about 400 XAA/MI/xf86 methods.
The more I read about this on various places the less of a “revolution” I get the sense this fork will be.
It will still not take any advantage whatsoever of my GPU, extensions will continue to do the work of rewrites and because all the portability needs one kind of starts to wonder, why fork in the first place?
The idea of heavier experimenting in the fork is good to later be merged into XFree is OK, but that idea shouldn’t even need a fork at all and it shouldn’t have taken all this fuss to come up with that idea.
Think Linux will be put back a couple of years extra when Longhorn comes out leaving Linux the only OS without a fully composited GUI engine, and the last thing Linux needs on the desktop front is to get nudged back in time.
The reason this is not “revolutionary” is because there is no need to. KeithP (who has 15 years of experience with the internals of X!) has decided that there is nothing wrong with X that can’t be fixed through extensions or at the server end. The main reason for this fork is not technical, but organizational. He feels that XFree86.org is slowing development, and he wants to create an open environment where development will be faster. Now, if you have some critical idea that you can prove can’t be implemented without breaking compatibility (preferably with some sample code or a prototype) then by all means feel free to send mister Packard an e-mail and a tarball of the code…
Moving on, there are two elements to Quartz and Longhorn:
1) Inter-window compositing. This is a relatively useless one. It only makes sense for some window transparency and shadows.
2) A high-level graphics API with intra-window compositing. This is the cool one. This allows for rich, resolution independent graphics. In Longhorn, this API will be hardware accelerated, while on OS X, it is (at least for now) software rendered (yes, even with QE).
Now, X already has a lot of progress on (2). EVAS (the main canvas for Enlightenment 17) is already OpenGL accelerated, and very powerful. What it is still missing is a vector graphics API. This is taken care of by the Xr/Xc extensions (which Keith is working on as we speak). Longhorn won’t be coming out until at least 2005. I would be very surprised, given the amount of development that has already happened, if the XFree guys don’t beat Microsoft to the punch here.
How about actually informing yourself on XFree86 instead of making such stupid statements.
You’re going on about how great a hypthetical operating system is, yet, you don’t even know the first bloody thing about DirectX! Here is a hint sunshine, unless your video card is DirectX 10 (assuming that is what Longhorn is going to use), you will notice no bloody difference, and another clue, you WON”T get this so-called “eXPerience” unless the application has been explicitly written to take advantage of those features.
XFree86 4.3 has OpenGL, SDL, DRI and numerous other extensions that off load a good amount of processing to the GPU. How about actually read about XFree86 before making such stupid illinformed comments which are based on nothing but clueless rants from Windows “supporters” who know jack-squat about the issues that GDI has fundamentally and hence the reason why it was rammed into kernel space along with the video drivers and any other bloody thing Microsoft feels to “speed up”.
@Matt : Don’t kick the stupid, educate them. I sense in you much anger…
I’m probably as far from a Windows supporter you can get… I’m just a fan of the concept of Quartz, it’s super slow but then again so is XFree (for me, it’s probably slower for us idiots).
Sorry about the flame before. I am just having a really bad day, I mean, REALLY BAD DAY and things get compounded when I see people make statements on things because the only other thing they know, in this case, there is a comparision between X and something else. Sure, X has its quirks, just like GDI and QE, however, just look at the results of each and personally X is the best of the worst. GDI being the worst, QE not too bad, however, I could never understand why they dumped Postscript Display in favour Quartz and X, in comparision to GDI and Quartz feels faster and more stable. Yes, I have given MacOS X a whirl and to be completely honest, it is like a slug. This isn’t the processor fault. A PowerPC with Linux runs like a dream unfortunately when MacOS X is shoved on top the whole thing comes to a crawl for no apparent reason.
I am, right now, running FreeBSD 4.8 + XFree86-4.3 + KDE 3.1.1a, all compiled using GCC 3.2.2 (except the kernel etc). Everything is fast, stable and reliable. As for fonts, I am using no Truetype fonts. Everything on my desktop is 100% Type1 and the results are stunning with Freetype 2.1.4. Fontconfig and Xft are providing what is required.
As for the X-Fork, I suggest you check out the fontconfig site. Fontconfig 2.2 is just around the corner, how long will it take to get into XFree86-4.3? at the rate things are going, one would have to wait another year to see it. What should happen is this feature to be merged into 4.3.1 and releases should be occuring at a rate of 4.3.x every 2-3months which covers bug fixes and feature updates such as OpenGL 1.2 to 1.3 or Fontconfig 2.0 to 2.2.
>> feature updates such as OpenGL 1.2 to 1.3
I hope that was a typo..
Yeap, was a typo, confusion between the Mesa version and OpenGL version.
From http://www.mesa3d.org
[Quote]November 13, 2002
Mesa 5.0 has been released. This is a stable release which implements the OpenGL 1.4 specification.[/Quote]
-is it possible to get the same performance for fullscreen gaming on Xfree?
-is it possible get good 3D performance on XFree?
-Is Xfree better than DirectX etc. ?
than its a nice idea to fork Xfree i guess.
> -is it possible get good 3D performance on XFree?
Depends on the driver. The architecture is not broken, just some drivers are less-than-optimal.
> -Is Xfree better than DirectX etc. ?
X is a windowing system. DirectX is a library for hardware accelerated graphics/sound. You can’t compare the two, they are completely different things.
Compare X to the Windows GDI.
Compare DirectX to SDL+OpenGL.
Q: is it possible to get the same performance for fullscreen gaming on Xfree?
Q: is it possible get good 3D performance on XFree?
A: Yes, provided the GPU pipeline utilization is at 100%. See http://www.graphicshardware.org/previous/www_2001/presentations/Hot…
in comparision to GDI and Quartz feels faster and more stable
Well, i don’t know if quartz “is faster and more stable” than gdi, but i can tell you that the xp gdi is more stable than xfree86 any day, i’ve never crashed the gdi once in xp, x crashes as much more common for me, the “faster” part is also arguable.
From what I can tell, this fork will probably be a good thing. The current leadership of XFree86 just doesn’t seem to be “getting it done”. Versions supporting up-to-date hardware are slow coming out even when the necessary code has been made available. The leadership continually points out that they have other jobs and do this in their spare time. While this is a partially valid excuse, this is mainly a problem because they retain such tight control over their project. There seem to be many interested parties ready to assist in XFree86 development that are being turned away. Also, the dismissal of Keith Packard seemed rife with egos and agendas beyond providing a good product. I hope that this fork is more responsive to the needs of Linux and that XFree86 and this fork coexist well without introducing incompatibilities.
1) If you mean OpenGL performance, then yes, it is possible to the same fullscreen (or windowed) performance in X as in Windows. However, this is heavily driver-dependent. The ATI drivers in Linux, for example, are very poorly optimized and run much slower than the Windows drivers. The NVIDIA drivers, OTOH, are much more well optimized, and run every bit as fast as the Windows ones. There are occasional differences in performance (X is faster in some things, XP in others), given different workloads, but it’s very close. Windowed performance is also excellent, to the point where even pro-3D houses (notably ILM) have moved to X on Linux for their workstations.
2) DirectDraw (the 2D graphics part of DirectX) and X are two different things. DirectDraw is a high-performance, low-level API. X is a medium-performance high level API. Most applications do not use DirectDraw for drawing, rather they use the GDI. Further, DrawDraw pretty much only accelerates blits. All other drawing (lines, polygons, circles, etc) are done via software. X has something similar to DirectDraw, called DGA, but it’s use is discouraged. As for performance, it all depends what you’re doing. In my experience, blitting via X is almost as fast as blitting via DirectDraw, and a lot faster than blitting via GDI. The primitive (line/curve) drawing performance in GDI was also pretty slow the last time I benchmarked it (around NT 4) to the point where even my software rasterizer could outperform it.
Yep, directdraw pretty much only blits, probably because it was meant as a gaming api, but that really is no excuse for them not have some form of hw accelerated primitives in there.
The GDI is slower blitting, except for transparent blitting wich is a lot faster than X.
I think hw accelerated primitives came with gdi+, and you can probably use the gdi+ functions to write to a directdraw surface, but i’m not really sure :-
There’s an ms document about the gdi+ here: http://www.microsoft.com/hwdev/archive/video/GDInext.asp
…but certainly not bug-free. Since DirectDraw / GDI is used for a very large amount of Windows 2D drawing functions (and for XP’s skinnable theme support), a lot of this data is stored in buffers; unfortunately these buffers aren’t always cleared completely. Now this hasn’t caused any disastrous problems that I’ve heard about, but playing Giants: Citizen Kabuto one lovely autumn day I fell out of my chair laughing at the sight of Kabuto striding into my base textured entirely with the big green start menu button. Not necessarily on topic, I know, but I figured it was worth sharing.
I am interested in what you used for your video card. I am running a Matrox G550 using stock XFree86 drivers and it is rock solid. If you are experiencing crashes I suggest two things, check the drivers and secondly run a memtest. Everytime I get a person complaining about X instability I find that after running a memory test they eat hunble pie and accept that their memory has bad memory segments.
Not sure if anyone is interested, but Mike Harris keeps a diary at Advogato, though it hasn’t been updated since Jan 14th. Get more at http://www.advogato.org/person/mharris/ .
It’s a prolink geforce 4200ti 128mb, drivers from nvidia, no overclocking, system is a duron 1300mhz with an msi kt133 mainboard.
When it crashed, some apps would first stopped being repainted (just the usual grey window) and after a while the entire screen would display only a weird “bar code like pattern” in the entire screen.