On http://www.mandrakelinux.com it is real. Just that I think its 2.6 test 11 and everything is pretty much beta, it’s a snapshot of cooker from a few days ago…
I (quickly) checked the xfree86 main site, and I couldn’t find any log on changes between 4.3 and 4.4 ? Does anyone know where to find anything useful related to this ?
From perusing it, (PERUSING, not reading intently,) it seems that the biggest differences are hardware, and OS support (duh!), AND a cool new autoconfig system that autogenerates a XF86Config-4 file (forgive me, I haven’t had to tweak the file in a while, and forget its exact name.) It works without this file, and generates an automatically configured one in /var/log/XFree86.0.log. If you make your own XF86Config-4 file, it overrides /var/log/XFree86.0.log. This is only supported in Linux, and FreeBSD though.
There is preliminary support for GNU/KFreeBSD, and GNU/KNetBSD. (!!)
It appears that some of the changes from Apple to make XF86 integrate better w/ the OS have been accepted into the main Darwin branch, specifically performance enhancements, compatibility w/ Apple’s WM, and dynamic loading of the correct graphics backend at runtime.
Does anyone think XFree86’s unwillingness to modernize will render it unimportant? Freedesktop has made quite a bit of progress in a short time, and while they are not nearly ready for a stable release, their first release will surely be more impressive than XFree86’s future implementation. Comments?
Yep, that’s the wrong usage of peruse (that I just found out myself):
Usage Note: Peruse has long meant “to read thoroughly” and is often used loosely when one could use the word read instead. Sometimes people use it to mean “to glance over, skim,” as in I only had a moment to peruse the manual quickly, but this usage is widely considered an error. Sixty-six percent of the Usage Panel finds it unacceptable.
– American Heritage Dictionary.
As for Xfree being irrelevant, it may become that *if* (and that’s a big if) Xouvert, etc. do get stable, and don’t break the X protocol, they may supplant Xfree. <cynic-mode> It’s going to make a mess I suspect, as they’ll worry more about eye-candy (transperancy) instead of being API and binary compatible with each other</cynic-mode>. It also highlights one problem open source (or more, correctly, human nature): if someone doesn’t like the way a project is being run, they run off and start their own, making huge duplications of work. Not that I’m taking sides in this case, I don’t know anything of the politics of the X variants.
XFree86 (the name “XFree” is entirely incorrect) is one of the few open source projects that values stability and consistency. With everything else racing ahead, throwing in new and untested code and making backwardly-incompatible releases, it’s good to see the XFree86 team focus on solid, sane and progressive releases rather than any-old-new-goodies stuff.
Sure, they’re not the fastest release group in the world, and have some troubles to sort out, but they’re very careful.
I heard some days ago that the XFree project leader (David Dawes) just kicked another developer (Egbert Eich) from the XFree86 core team (because of collaborating with freedesktop.org/expressing sympathy for them). And that this would leave only two active developers besides David left.
Well, there’s an experimental XFree86 4.3 in the experimental (duh) repository : you just have to add an “experimental” source in your sources.list and you’re in business.
I’ve been running it for a while, and it runs very smoothly.
” if someone doesn’t like the way a project is being run, they run off and start their own, making huge duplications of work. ”
That would only be the case if:
1-Started completely from scratch.
2-Ran parallel development paths, tic for tac.
The way I understand it. They’re going were XFree86 either isn’t going, or not going fast enough. That’s new ground and reusing most of the preexisting code base.
As long as there are at most 7 implementations of the X protocol, I’ll be happy. Little or no progress is what happens when you have one desktop environment, one web browser, one toolkit, one email client, and whatever you “Unity-zealots” call it.
The way I understand it. They’re going were XFree86 either isn’t going, or not going fast enough. That’s new ground and reusing most of the preexisting code base.
You took the words right out of my mouth. I don’t understand why people are bashing Xserver and Xouvert. The changes can easily be merged back into XFree (which I believe is the intent of Xouvert, to be a development branch). If Xserver becomes the X of choice then who cares? It’s the same protocol. It won’t take much to rework the drivers if need be and if the companies refuse then it will die off anyway or it will be used by some while others stick with standard XFree. It’s not going to break programs. X is a protocol and both Xserver and Xouvert are using the X protocol.
Little or no progress is what happens when you have one desktop environment, one web browser, one toolkit, one email client, and whatever you “Unity-zealots” call it.
False. Regardless of how many groups there are, people will write what is (they believe to be) needed. If XFree86 and Xouvert both died, we would still be seeing as much progress from fd.o’s X server (though perhaps the faster because XFree86 and Xouvert woludn’t be being updated, so it’d be more important). Competetion only helps progress inasmuchas the different competitors think different things are the more important, & so they include them; cross-pollination subsequently happens (this is why free software constantly lags behind commercial software. While they include different innovations in different areas, people focus on the areas where XF86, Linux &c. is not at least as advanced as the commercial offerings).
The reason Debian’s so slow to use new versions of XFree86 is that they have to make sure it works on all 11 Debian-supported architectures.
The reason because 4.3 isn’t in unstable yet is because 4.3 doesn’t run well on all 11 Debian supported platforms. I believe 1 platform is having problems with Xfree86 4.3, so it’s not in unstable but in experimental.
I was just looking at freedesktop.org … I noticed a xorg xerver implementation anyone know what that’s all about? It seems to be a copy of XFree86… Is XFree86 trying to steal steal some of Freedesktop’s xserver and xouvert thunder?
XFree86 (the name “XFree” is entirely incorrect) is one of the few open source projects that values stability and consistency.
The last I checked, neither Xouvert or FreeDesktop’s X Server has reached 1.0. How could you tell that both the other two competitors don’t value stability and consistency? And what do you mean by consistency? XFree86 3.x didn’t seem all that consistent with XFree86 4.x.
It is trully amazing what a difference freedesktop.org’s Xserver and Xouvert have already made. Over the years(8 now) I was always waiting for the latest Xfree versions. I would “peruse” their web site looking for improvements and changes. When their latest release came out I was thrilled with a sense of excitement. Now with XFree 4.4 around the corner my feeling is like “so what”. Now I am sure that this new version will have a couple of new features and a couple of newly or better supported hardware drivers. I already am aware of the autoconfiguration stuff being integrated, and I am glad it is, FINALLY, happening.
But XFree has shot itself in the foot. XFree has utterly failed to bring in new X developers, has kicked most of the motivated contributors out, and consistently ignores the user base. And I say this as someone who uses XFree exclusively, on all of my machines, and on the machines which I administer.
Xouvert is just now getting up to speed. With Arch, an advanced changeset management system, Xouvert is now opening up X development to a broad range of new developers. It is now easier than ever to get involved and start contributing. Xouvert is not a fork. It is 100% compatible with the existing XFree base. It simply provides a testing ground for the implementation of things which David Dawes et al have refused to implement, refusing primarily based on personal disputes. That which is contributed to XFree *might* find its way back upstream in the official XFree tree, and this is the crux of the entire problem. As is stands one can de-install XFree and install Xouvert’s tree and everything remains the same with the exception of bug fixes and assundry patches.
Xserver, at freedesktop.org, is a fascinating new technology. Reusing XFree code and maintaing protocol compatibility with existing XFree implementations it intrododuces new functionality and new API’s(libXdamages, libXfixes, LibXcomposite etc.) for future development. And Xserver does this now being in a pre-alpha state. Unfortunately Xserver will not work with the existing XFree hardware drivers, which greatly limits its potential impact.
It remains unlikely that ATI and NVIDIA will endorse Xserver unless the major distros start bundling it alongside XFree once it reaches maturity. Then the long process begins of re-integrating support for the tremendous number of supported video cards which XFree currently supports-Xserver is, as of now, primarily a frame buffer X server.
Cairo, Xr/Xc, is also steadily comming along. This technology does have a good chance of becoming part of the standard XFree install. In fact GNOME 2.6 is supposed to support it, and the work has already begun. Cairo may eventuall offer us a PDF-like display with a OpenGL backend, although the OpenGl stuff is still quite a way aways.I would bet money that Rasterman(of Enlightenment fame) is already working on this-probably a lot of the stuff that was going to go into E17 will find its way into X-which is what should happen!. Cairo works now, and one can already get Cairo GTK+ themes.
Hopefully Xouvert will provide the possibility of integrating Cairo and Xserver into a ‘XFree’ implementation, regardless of XFree.org’s b.s. politics. It is trully a shame that many of those in the heirarchy of XFree don’t even use XWindows anymore-but even worse- they tell those who do what they can and cannot do, kicking those people out who don’t “get with the program” as defined by them. XFree is not irrelevant, yet. Ostensibly XFree initiated some changes to open up their development and provide better community feed back- but I honestly don’t believe they can change-at least as long as those who are currently at the top are still there.
Perhaps the single best and biggest improvement in XWindows, in the last years, is the addition of TTF font support- but of course the integratioon of this development did not come from XFree, it came from freedesktop.org. So I no longer look to XFree for any kind of innovation. And if XFree remains as it has been it will become irrelevant, due to the talented developers having gone elsewhere……
I mentioned the new API’s in Xserver- however these may simply be Xextentions and I am not really sure what the relation between the two is. My ignorance here is painful. I do know that Cairo (Xr/Xc) provides new API’s-
“Xc
A low-level compositing API for X. Xc provides the same API as the RENDER extension, and in fact uses the RENDER extension when available. If RENDER is not available, Xc will emulate RENDER via client-side compositing, (this feature is still in development).
Xr
A high-level rendering API for X. Xr provides a stateful drawing API similar to the graphics operators of PostScript and PDF 1.4. Xr provides anti-aliased stroking/filling of spline paths. Xr depends on Xc.”
from xwin.org
and
“Cairo is a vector graphics library with cross-device output support. Currently supported output targets include the X Window System, in-memory image buffers, and PostScript. An OpenGL backend is in progress, and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
Cairo provides a stateful user-level API with capabilities similar to the PDF 1.4 imaging model. Cairo provides operations including stroking and filling Bezier cubic splines, transforming and compositing translucent images, and antialiased text rendering.
Cairo was once named Xr, (or Xr/Xc), so if you came looking for that software, you’ve found it.”
at cairographics.org
” * X Fixes Extension is a draft specification for changes in how the device independent parts of the X server works.
* X Damage Extension is a draft specification for an extension to allow applications to track modified areas within a window or pixmap.
* X Composite Extension is a draft specification for an extension that moves sub-trees of the window hierarchy to off-screen memory, permitting access to and manipulation of those bits, including constructing the parent window contents programmatically rather than automatically.”
I was under the impression that Xfixes and Xdamages helped with window redrawing in multi-windowed displays where windows are resized and moved. BUT I WAS WRONG.
“Another notion of ‘damage’ are drawable regions
which are in need of redisplay to repair the effects of window manipulation or other data loss.This extension doesn’t deal with this second notion at call; suggestions on a better term which isn’t easily conflated with existing
what a shame, although it *was* obvious- Xserver is much slower at redrawing resized and moved windows than XFree…..However this should help drastically cut back on the number of roundtrips between the X server and X client-which should help the overall speed of both local and remote X displays….And I wish this “other” notion of damages would be addressed-perhaps a new hybrid level could be created where the WM has *direct* ties into the memory buffer of the video hardware- enabling a kind of “damage manager” independent of the particular WM-[God I wish I understood this stuff more thoruoughly-pure conjecture-but if such were possible we could avoid the ultra-heavy double buffering, as witnessed by GTK+, and this would have an overlap with Render/Cairo…..]
The following links are helpful to understand Xserver’s new extensions:
Further it should be noted Cairo is based on work in Render, and Render is already partially implemented in Nvidia drivers. If the Xcomposite could be tied into Render-it may be possible to use all of these technologies with the an XFree implementation which already has hardware support……But of course I am just conjecturing……
Take it literally; 1:1 use; like pay ‘per view’, you could peruse the -covers- of all the magazines on the racks or just read the paper straight through to peruse it, but “reading carefully” is way beyond perusal.
If you peruse _Science_ or _Nature_ or _PRL D_ you proabably didn’t take too long, but then you haven’t amended your notes, there’s nothing in the margin, and you’re not going to cite from reading a number -once.-
One document, one read; that’s peruse. Grokking would be to comprehend it and then probably ‘vanish’ the thing using your mind. Gleaning or first-examination might be a good term for just squinting at the page for the real deal. We probably need a series of other terms for things we think ought to be there without even looking for them!
For me, those things would be current directions (“we intend to make an X11 with a free API and proprietary hardware capability plugins so that Motif apps look like a top 1997 playstation game, minimum.”,) sidelong views (and comparisons) of build tree (“depends on UHCI usbtty1 and no other libraries”) and architecture (“provides client console loop to portend usability, while an X11 client lures KDE in and overwhelms it as a prelude to twisting its will and bending its ways.”) Usually I get a pretty rough idea of what changed symbols exist, who has been making doable requests, and who finally hit build last time.
I’m probably just not using an XML-ISO9k aware browser…..
hurra!
I found this on http://www.justlinux.com
http://justlinux.com/forum/showthread.php?threadid=118844
Apparently theres a “Mandrake 10.0 pre-release” that has:
2.6.0 kernel
XFree 4.4
KDE 3.2
GCC 3.3.2
I wonder if its a fake?
It just seems to be a Mandrake ISO made out of the latest Cooker.
On http://www.mandrakelinux.com it is real. Just that I think its 2.6 test 11 and everything is pretty much beta, it’s a snapshot of cooker from a few days ago…
No, it’s just a snapshot from Mandrake Cooker. Nothing to get excited about. If you want all of these features right now, you might as well try it.
” If you want all of these features right now, you might as well try it.
”
nah im more of a slackware fanboy.
I (quickly) checked the xfree86 main site, and I couldn’t find any log on changes between 4.3 and 4.4 ? Does anyone know where to find anything useful related to this ?
ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.3.99.902/RELNOTES
From perusing it, (PERUSING, not reading intently,) it seems that the biggest differences are hardware, and OS support (duh!), AND a cool new autoconfig system that autogenerates a XF86Config-4 file (forgive me, I haven’t had to tweak the file in a while, and forget its exact name.) It works without this file, and generates an automatically configured one in /var/log/XFree86.0.log. If you make your own XF86Config-4 file, it overrides /var/log/XFree86.0.log. This is only supported in Linux, and FreeBSD though.
There is preliminary support for GNU/KFreeBSD, and GNU/KNetBSD. (!!)
It appears that some of the changes from Apple to make XF86 integrate better w/ the OS have been accepted into the main Darwin branch, specifically performance enhancements, compatibility w/ Apple’s WM, and dynamic loading of the correct graphics backend at runtime.
Does anyone think XFree86’s unwillingness to modernize will render it unimportant? Freedesktop has made quite a bit of progress in a short time, and while they are not nearly ready for a stable release, their first release will surely be more impressive than XFree86’s future implementation. Comments?
It’s tried, tested, and it works. Not exactly something that can be said of the forks and new projects just yet.
Slow and steady wins the race,maybe? XFree86 might be irrelevant if something faster/more feature rich/stable comes along.
will xfree4.4 support hardware transparancy?
Maybe if we all sent our opinions to them the XFee86
team they would not seen so “irrelevent”.
IMHO, XFree86 has been somethink I setup once and leave.
It is there in the backgound hidden from me by kde/gnome.
Hardware 2d/3d support should be at the top of the list
then the shiny, multi-colourd, animated mouse curser.
Linux/Unix/*BSD > Free memory = unused wasted memory.
Have you ever played 3D game in XFree86 (eg NWN). It’s
as fast as DirectX, the initial loading may be longer
because everything is not preloaded. linux 2.6 has brought
us better IO speed and as a result XFree86 will be fine.
I don’t see how you can peruse and not read intently. That’s some trick you’ve mastered. Or maybe that word doesn’t mean what you think it means.
Yep, that’s the wrong usage of peruse (that I just found out myself):
Usage Note: Peruse has long meant “to read thoroughly” and is often used loosely when one could use the word read instead. Sometimes people use it to mean “to glance over, skim,” as in I only had a moment to peruse the manual quickly, but this usage is widely considered an error. Sixty-six percent of the Usage Panel finds it unacceptable.
– American Heritage Dictionary.
As for Xfree being irrelevant, it may become that *if* (and that’s a big if) Xouvert, etc. do get stable, and don’t break the X protocol, they may supplant Xfree. <cynic-mode> It’s going to make a mess I suspect, as they’ll worry more about eye-candy (transperancy) instead of being API and binary compatible with each other</cynic-mode>. It also highlights one problem open source (or more, correctly, human nature): if someone doesn’t like the way a project is being run, they run off and start their own, making huge duplications of work. Not that I’m taking sides in this case, I don’t know anything of the politics of the X variants.
XFree86 (the name “XFree” is entirely incorrect) is one of the few open source projects that values stability and consistency. With everything else racing ahead, throwing in new and untested code and making backwardly-incompatible releases, it’s good to see the XFree86 team focus on solid, sane and progressive releases rather than any-old-new-goodies stuff.
Sure, they’re not the fastest release group in the world, and have some troubles to sort out, but they’re very careful.
Other projects would do well to learn from them.
As long as were making picky language comments . . .
Any one else notice they misspelled “authenticate” in the release notes?
What are the odds Debian will have 4.3 packaged in at least sid before 4.4 is released?
I wish Debian would support the latest X on most of its architectures than a stale release on all of them.
I don’t know why it’s a RC2, using the neomagic driver, X just won’t start. Seems to me some drivers are still of beta quality.
I heard some days ago that the XFree project leader (David Dawes) just kicked another developer (Egbert Eich) from the XFree86 core team (because of collaborating with freedesktop.org/expressing sympathy for them). And that this would leave only two active developers besides David left.
I heard that the savage code was released for use by whom ever and there was work on that.
he’s gonna end up as a one man team that way..
Well, there’s an experimental XFree86 4.3 in the experimental (duh) repository : you just have to add an “experimental” source in your sources.list and you’re in business.
I’ve been running it for a while, and it runs very smoothly.
The reason Debian’s so slow to use new versions of XFree86 is that they have to make sure it works on all 11 Debian-supported architectures.
” if someone doesn’t like the way a project is being run, they run off and start their own, making huge duplications of work. ”
That would only be the case if:
1-Started completely from scratch.
2-Ran parallel development paths, tic for tac.
The way I understand it. They’re going were XFree86 either isn’t going, or not going fast enough. That’s new ground and reusing most of the preexisting code base.
As long as there are at most 7 implementations of the X protocol, I’ll be happy. Little or no progress is what happens when you have one desktop environment, one web browser, one toolkit, one email client, and whatever you “Unity-zealots” call it.
That would only be the case if:
1-Started completely from scratch.
2-Ran parallel development paths, tic for tac.
The way I understand it. They’re going were XFree86 either isn’t going, or not going fast enough. That’s new ground and reusing most of the preexisting code base.
You took the words right out of my mouth. I don’t understand why people are bashing Xserver and Xouvert. The changes can easily be merged back into XFree (which I believe is the intent of Xouvert, to be a development branch). If Xserver becomes the X of choice then who cares? It’s the same protocol. It won’t take much to rework the drivers if need be and if the companies refuse then it will die off anyway or it will be used by some while others stick with standard XFree. It’s not going to break programs. X is a protocol and both Xserver and Xouvert are using the X protocol.
Little or no progress is what happens when you have one desktop environment, one web browser, one toolkit, one email client, and whatever you “Unity-zealots” call it.
False. Regardless of how many groups there are, people will write what is (they believe to be) needed. If XFree86 and Xouvert both died, we would still be seeing as much progress from fd.o’s X server (though perhaps the faster because XFree86 and Xouvert woludn’t be being updated, so it’d be more important). Competetion only helps progress inasmuchas the different competitors think different things are the more important, & so they include them; cross-pollination subsequently happens (this is why free software constantly lags behind commercial software. While they include different innovations in different areas, people focus on the areas where XF86, Linux &c. is not at least as advanced as the commercial offerings).
The reason Debian’s so slow to use new versions of XFree86 is that they have to make sure it works on all 11 Debian-supported architectures.
The reason because 4.3 isn’t in unstable yet is because 4.3 doesn’t run well on all 11 Debian supported platforms. I believe 1 platform is having problems with Xfree86 4.3, so it’s not in unstable but in experimental.
Have you ever played 3D game in XFree86 (eg NWN). It’s
as fast as DirectX, the initial loading may be longer
because everything is not preloaded.
Well, if DirectX has everything preloaded there wouldn’t be anything left to load, would it?
“Have you ever played 3D game in XFree86 (eg NWN). It’s
as fast as DirectX, the initial loading may be longer
because everything is not preloaded.”
Not always. I have UT and Quake3 running on my Slackware 9.1 system and they both start up much quicker than its windows counterpart.
NOTE: Im using the LOKI game installers.
I was just looking at freedesktop.org … I noticed a xorg xerver implementation anyone know what that’s all about? It seems to be a copy of XFree86… Is XFree86 trying to steal steal some of Freedesktop’s xserver and xouvert thunder?
XFree86 (the name “XFree” is entirely incorrect) is one of the few open source projects that values stability and consistency.
The last I checked, neither Xouvert or FreeDesktop’s X Server has reached 1.0. How could you tell that both the other two competitors don’t value stability and consistency? And what do you mean by consistency? XFree86 3.x didn’t seem all that consistent with XFree86 4.x.
Not always. I have UT and Quake3 running on my Slackware 9.1 system and they both start up much quicker than its windows counterpart.
True. But the I should of been more clear.
Baldur gate 2 (using wine)
Abes oddicy (Using Wine)
ceasar 3 (Using wine)
NWN (Using wine)
NWN (native) Very quick. Wished it did it in the first
place.
Q3 native fast loading time
Q3 slower
The initial loading is slower with wine. The native
ports do load fast. I should of noticed frst. Wine
is becoming good it i have just setup one config file
and just clicke on the windows app when needed.
It is trully amazing what a difference freedesktop.org’s Xserver and Xouvert have already made. Over the years(8 now) I was always waiting for the latest Xfree versions. I would “peruse” their web site looking for improvements and changes. When their latest release came out I was thrilled with a sense of excitement. Now with XFree 4.4 around the corner my feeling is like “so what”. Now I am sure that this new version will have a couple of new features and a couple of newly or better supported hardware drivers. I already am aware of the autoconfiguration stuff being integrated, and I am glad it is, FINALLY, happening.
But XFree has shot itself in the foot. XFree has utterly failed to bring in new X developers, has kicked most of the motivated contributors out, and consistently ignores the user base. And I say this as someone who uses XFree exclusively, on all of my machines, and on the machines which I administer.
Xouvert is just now getting up to speed. With Arch, an advanced changeset management system, Xouvert is now opening up X development to a broad range of new developers. It is now easier than ever to get involved and start contributing. Xouvert is not a fork. It is 100% compatible with the existing XFree base. It simply provides a testing ground for the implementation of things which David Dawes et al have refused to implement, refusing primarily based on personal disputes. That which is contributed to XFree *might* find its way back upstream in the official XFree tree, and this is the crux of the entire problem. As is stands one can de-install XFree and install Xouvert’s tree and everything remains the same with the exception of bug fixes and assundry patches.
Xserver, at freedesktop.org, is a fascinating new technology. Reusing XFree code and maintaing protocol compatibility with existing XFree implementations it intrododuces new functionality and new API’s(libXdamages, libXfixes, LibXcomposite etc.) for future development. And Xserver does this now being in a pre-alpha state. Unfortunately Xserver will not work with the existing XFree hardware drivers, which greatly limits its potential impact.
It remains unlikely that ATI and NVIDIA will endorse Xserver unless the major distros start bundling it alongside XFree once it reaches maturity. Then the long process begins of re-integrating support for the tremendous number of supported video cards which XFree currently supports-Xserver is, as of now, primarily a frame buffer X server.
Cairo, Xr/Xc, is also steadily comming along. This technology does have a good chance of becoming part of the standard XFree install. In fact GNOME 2.6 is supposed to support it, and the work has already begun. Cairo may eventuall offer us a PDF-like display with a OpenGL backend, although the OpenGl stuff is still quite a way aways.I would bet money that Rasterman(of Enlightenment fame) is already working on this-probably a lot of the stuff that was going to go into E17 will find its way into X-which is what should happen!. Cairo works now, and one can already get Cairo GTK+ themes.
Hopefully Xouvert will provide the possibility of integrating Cairo and Xserver into a ‘XFree’ implementation, regardless of XFree.org’s b.s. politics. It is trully a shame that many of those in the heirarchy of XFree don’t even use XWindows anymore-but even worse- they tell those who do what they can and cannot do, kicking those people out who don’t “get with the program” as defined by them. XFree is not irrelevant, yet. Ostensibly XFree initiated some changes to open up their development and provide better community feed back- but I honestly don’t believe they can change-at least as long as those who are currently at the top are still there.
Perhaps the single best and biggest improvement in XWindows, in the last years, is the addition of TTF font support- but of course the integratioon of this development did not come from XFree, it came from freedesktop.org. So I no longer look to XFree for any kind of innovation. And if XFree remains as it has been it will become irrelevant, due to the talented developers having gone elsewhere……
I mentioned the new API’s in Xserver- however these may simply be Xextentions and I am not really sure what the relation between the two is. My ignorance here is painful. I do know that Cairo (Xr/Xc) provides new API’s-
“Xc
A low-level compositing API for X. Xc provides the same API as the RENDER extension, and in fact uses the RENDER extension when available. If RENDER is not available, Xc will emulate RENDER via client-side compositing, (this feature is still in development).
Xr
A high-level rendering API for X. Xr provides a stateful drawing API similar to the graphics operators of PostScript and PDF 1.4. Xr provides anti-aliased stroking/filling of spline paths. Xr depends on Xc.”
from xwin.org
and
“Cairo is a vector graphics library with cross-device output support. Currently supported output targets include the X Window System, in-memory image buffers, and PostScript. An OpenGL backend is in progress, and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
Cairo provides a stateful user-level API with capabilities similar to the PDF 1.4 imaging model. Cairo provides operations including stroking and filling Bezier cubic splines, transforming and compositing translucent images, and antialiased text rendering.
Cairo was once named Xr, (or Xr/Xc), so if you came looking for that software, you’ve found it.”
at cairographics.org
” * X Fixes Extension is a draft specification for changes in how the device independent parts of the X server works.
* X Damage Extension is a draft specification for an extension to allow applications to track modified areas within a window or pixmap.
* X Composite Extension is a draft specification for an extension that moves sub-trees of the window hierarchy to off-screen memory, permitting access to and manipulation of those bits, including constructing the parent window contents programmatically rather than automatically.”
at http://www.freedesktop.org/Standards/Home
I was under the impression that Xfixes and Xdamages helped with window redrawing in multi-windowed displays where windows are resized and moved. BUT I WAS WRONG.
“Another notion of ‘damage’ are drawable regions
which are in need of redisplay to repair the effects of window manipulation or other data loss.This extension doesn’t deal with this second notion at call; suggestions on a better term which isn’t easily conflated with existing
notions are eagerly solicited.”
from :
http://freedesktop.org/cgi-bin/viewcvs.cgi/DamageExt/protocol?rev=H…
what a shame, although it *was* obvious- Xserver is much slower at redrawing resized and moved windows than XFree…..However this should help drastically cut back on the number of roundtrips between the X server and X client-which should help the overall speed of both local and remote X displays….And I wish this “other” notion of damages would be addressed-perhaps a new hybrid level could be created where the WM has *direct* ties into the memory buffer of the video hardware- enabling a kind of “damage manager” independent of the particular WM-[God I wish I understood this stuff more thoruoughly-pure conjecture-but if such were possible we could avoid the ultra-heavy double buffering, as witnessed by GTK+, and this would have an overlap with Render/Cairo…..]
The following links are helpful to understand Xserver’s new extensions:
http://freedesktop.org/cgi-bin/viewcvs.cgi/FixesExt/protocol?rev=HE…
http://x2.cs.pdx.edu/cgi-bin/viewcvs.cgi/CompositeExt/protocol?rev=…
Further it should be noted Cairo is based on work in Render, and Render is already partially implemented in Nvidia drivers. If the Xcomposite could be tied into Render-it may be possible to use all of these technologies with the an XFree implementation which already has hardware support……But of course I am just conjecturing……
where is the post about it ?
I can find nothing. I can imagine he has been kicked !
I don’t think that there is a public post. I heard Keith Packard telling it in IRC.
That’s a shame.
That’S the reason he wanted to fork, isn’t it?
Oops, I just can’t remember a name across a page…
Take it literally; 1:1 use; like pay ‘per view’, you could peruse the -covers- of all the magazines on the racks or just read the paper straight through to peruse it, but “reading carefully” is way beyond perusal.
If you peruse _Science_ or _Nature_ or _PRL D_ you proabably didn’t take too long, but then you haven’t amended your notes, there’s nothing in the margin, and you’re not going to cite from reading a number -once.-
One document, one read; that’s peruse. Grokking would be to comprehend it and then probably ‘vanish’ the thing using your mind. Gleaning or first-examination might be a good term for just squinting at the page for the real deal. We probably need a series of other terms for things we think ought to be there without even looking for them!
For me, those things would be current directions (“we intend to make an X11 with a free API and proprietary hardware capability plugins so that Motif apps look like a top 1997 playstation game, minimum.”,) sidelong views (and comparisons) of build tree (“depends on UHCI usbtty1 and no other libraries”) and architecture (“provides client console loop to portend usability, while an X11 client lures KDE in and overwhelms it as a prelude to twisting its will and bending its ways.”) Usually I get a pretty rough idea of what changed symbols exist, who has been making doable requests, and who finally hit build last time.
I’m probably just not using an XML-ISO9k aware browser…..