Xfree86 4.2.0 Out

According to david_eliasson, Xfree86 v4.2.0 is out, but it'll probably be awhile before all the mirror sites have sycned up with the release, so you may want to just enjoy reading that changelog for a couple days before you bother getting the whole archive.

Comments

Mirrors for Xfree86

[Adrian Voinea]

Here's a nicely formatted list of mirrors for you lazy bastards ;)
Let's make the slashdot effect on xfree86.org a little more bearable :)
ftp://ftp.calderasystems.com/pub/mirrors/xfree86
ftp://carroll.cac.psu.edu/pub/XFree86
ftp://ftp.cs.umn.edu/pub/XFree86
ftp://download.sourceforge.net/pub/mirrors/XFree86
ftp://ftp.freesoftware.com/pub/XFree86
ftp://ftp.infomagic.com/pub/mirrors/XFree86
ftp://mirror.sftw.com/pub/XFree86
ftp://phyppro1.phy.bnl.gov/pub/XFree86
ftp://ftp.rge.com/pub/X/XFree86
ftp://ftp.valinux.com/pub/mirrors/xfree86

Re:Moving away from X

[stripes]

Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency

There are people working on adding a new rendering model that does antialiasing and sub-pixel addressing. "People" being mostly Keith Packard.

enhanced programming environment

There is no reason you can't do that to X, in fact if you compare things like xlib to Gtk--, or Xt to Qt there has been huge progress. Oh, and there is GNUStep too, which is mostly like NeXTStep which is what OS X is based on...

and a new, well defined and examined user interface?

That is the hard part. In part because backwards compatibility works against you.

This would be going the Mac OS X route

I think OS X has a lot going for it, but the biggest thing really is that the apps do mostly work alike, which is rather unlike X11. I know I'm partly at fault since the X11 apps I worked on (xtank and w3juke) are not much alike :-)

Re:Moving away from X

[pthisis]

The problem with X11 is, in part, the separation of client/server; this causes extra latency and a heap of context switches

The context switches aren't a significant overhead. They weren't even a significant overhead in 1986 when Sun first started spreading FUD about this (at the time, Sun was trying to push NeWs over X11). See e.g. Jim Gettys' posts in the "rendering model in X" thread in the Xrender mailing list archives

It's not all sunshine, he's willing to own up to places where X needs improvement (exposure lists are a big one, througput for e.g. texture mapping is another), but it's way better than a lot of people claim. And Xrender and DRI address the vast majority of the problem cases very effectively.

Sumner

README, Release notes, etc.

[Lac]

I found additional documents looking through the website. These are much more interesting to read than the changelog.

The README
The release notes
Installation details
Driver status

Enjoy!

Re:MS Windows vs. X, same hardware

[pthisis]

There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive

If you had read the thread I mentioned in the article you replied to, you'd see the anser to this one:


> > Not to be too non-technical...
> > > > If the protocol overhead is so small, why can't my 1200 mips (600mhzPIII)
> > machine resize windows without widgets streaking? My 486 could do
> > this fine running MS Windows. Is this because many widget toolkits (GTK,
> > QT) use XPutImage? There must be some way to speed things up.

blame your widget set. basically (sorry owen and co on the list) gtk a
(and i presume qt) dont render optimially at all. the do a semi-decent
job.. EXCEPt for opaque resizing, and when redrawing is more than a few
lines and boxes... this is a toolkit issue and imho the current set of
toolkits (motif, qt, gtk etc.) do a god-awful job of this kind of
stuff. right now i have silky smooth "opaque resize" stuff working here
with enlightenment 17 - but i do the rendering completely differently
to gtk/qt - its all a canvas and thus the rendering happens in a
"backing" so updates are smooth. on todays hardware this is the best
way to do it and have almots no artifacts ANd retain speed.

> "Streaking"? Are these opaque resizes? Alot of apps aren't doing
> event compression. They repaint the whole damn window every time they
> get an event. They could have at least checked that there weren't
> more events in the queue and got rid of them instead of handling each
> one in turn.

true. its a very bad thing that there are a LOT of apps that behave like
this... a LOT. some of the most commonly used are guilty of this
(netscape for one....)

the mouse frame rate is low

If you enable Silken Mouse in XFree86 4.0 and later, this should be fixed. Certainly an implementation issue and not an architectural issue (i.e. not a reason to throw out X and start over)

applications all have inconsistent look and feel, keyboard support is lacking...

These aren't X11 problems but GUI problems, GUI standardization is certainly a huge issue. But, gtk-2.0's accessibility enhancements include excellent keyboard support and some steps toward simplifying and unifying look&feel. KDE is moving in that direction as well. Obviously you need to use a single unified UI on your desktop, but having two decent ones available to choose from is not a bad thing (not to say that either is decent yet, but they're both heading there rapidly).

Sumner

Re:Xfree is sufferring from poor PR

[JollyTX]

The XFree86 source tree looks absolutely horrible the first time you try to find out how to compile it.

I looked at the make files for a _long_ time before I though "hell, let's just do make World and see what happens".

X built without a single hickup. Why doesn't the README say "If you're using Linux, just do make World and it'll work" ? ;)