The new X Server developed under the sponsorship of freedesktop.org is aiming at replacing XFree86. Some code will be re-used but the core will be rewritten by Keith Packard and others. The new X server features full support for transparency, and has window-level image compositing among other things. Check out the screenshots (one more added, now there are four shots).
Screenshots from freedesktop.org’s New X Server
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
hhuuurrraaayyy!
Come on Debian, make this apt-getable
Those are some very clear very sharp shots. Way cool!
Yesh. Font-quality has nothing to do with the X server. X uses client-side fonts these days, courtesy of Xft. But this looks like a very interesting development. May the best X server win!
So much for X sucks/is obsolete/etc! Anyway, I’ve got two questions:
1) What does this do to memory usage?
2) Does this mean that they can get rid of double-buffering in GTK+ and Qt?
where would we be without freedesktop.org? they brought real start-up notification to linux
Is why the hell everybody is so infatuated with translucent windows.
You may think drop shadows like that are just useless eyecandy, but I have a number of users around here that don’t seem to see/get the overlapping window concept. They learned computers with DOS or always keep everything maximized. Depth seperation of windows like in those screenshots (and on MacOS X, and someday on Longhorn I’m sure) goes a long way to visually reinforce the metaphor.
And it looks neat
I think transparent windows are a bad idea. What use is it? It’s probably impossible to support windows with different visuals and have this feature.
>I think transparent windows are a bad idea.
You are losing the point people. Nobody is saying using transparent windows, EVEN OSX took out their transparent unfocused windows!! The point is that there are applications and usages for full transparency support that WHEN an application needs it, it WILL be there! It is a feature to be used by some apps that NEED it, that doesn’t mean that Gnome and KDE will have transparent windows all the time!
I don’t know about you, but I do care about using up hundreds of cycles just to move my mouse cursor around. How efficient is this new X server vs. XFree?
That’s great news.
Is this only for the workstation desktop (localhost) or can you use this version of X to remote X into another box running this version of X? Basically, I’m asking – will this project support remote X?
Thanks in advance
First, the issue of drivers. The Xserver is based on the excellent, although narrowly focused, kdrive. IIRC, you get VESA or framebuffer, but nothing more (no 3D, etc…)
Second, all these people asking “Why translucency?” Even if you do not personally want transparent windows (and I agree), COMPOSITING, the technique making this all possible, is extremely useful to the developer. It means easier creation of better looking applications. Done well, it allows flicker free, and accelerated graphics, easily. Transparency also opens a range of new effects available to communicate information to the user. We think it to be useless, because right now, we don’t have that information available to us.
No, I wouldn’t plan on using transparency on every window, but compositing has many other uses.
I didn’t submit any comments about the font quality. That was added by eugenia. Maybe this new Xserver draws fonts differently?
My wife said cute…
Dunno about those fonts. Sure, they look good, but no different to the ones I’m looking at right now on my KDE desktop under boring old XFree86 4.3 with the latest fontconfig + Xft. But anyway, the rest of the ideas look good.
I wonder how long this will take to become releasable, and whether we’ll have a drawn-out KDE vs Gnome type battle with alternative “next gen” X servers? That might not be the ideal outcome….
As I can see this xserver is on very premature stage. The guys on freedesktop are improving the configurability of the X server with new extensions, libraries, etc.
As I can saw this is a very alpha version right now. They are simplifing a lot of the X server, so in near future versions it is posible to find improvements in speed and new options but I think that drivers will be a problem for a while.
Which is the rather antequated client-side expose handling model. Rayiner Hashem will most likely disagree that this method is inherently superior, but it’s certainly my belief that this is the way all modern windowing systems should go. Windows uses this model, but for transparent windows only. OS X uses shared memory raster buffers between client and server and consequently all expose events are handled server side.
I hope to see these changes committed back into the main XFree86 tree, and I also hope that toolkits will begin to give compile-time flags to disable needless client-side double buffering which was a hack to increase performance of the client side expose handling model.
Still… this will not work on hardware that supports different visuals, i.e. RGBA and CI windows.
And why wasn’t OpenGL/GLX used instead of inventing XRender?
I think it would be great to have an interview with Keith Packard and Jim Gettys about where they see the fd.o Xserver and Xlibs project going. More specifically what the new kdrive driver infrastructure is all about and how they plan on dealing Nvidia and ATI to port their drivers to this new Xserver quickly and without a lot of fuss. I image it could go smoothly if redhat, debian, suse, etc.. all get behind this.
I realize that for 99% of the world, having transparent windows is just useless eyecandy, but some some people (Like me) it’s VERY useful.
For instance, I could be working on code or something in an editor window, and below that window could be a browser open to some website with a FAQ or something that I need to read as I’m coding. Having a setup like this would be very useful, since I can have both apps fullscreen and not have to switch between them.
This actually came up yesterday as I wished X would get transparent window support. Perhaps I’m psychic and am influencing the freedesktop developers? Hehe.
has it any relation with Xouvert? I think it’s a good concept of X server.
http://www.xouvert.org/
I don’t see how doublebuffering helps to avoid redrawing on expose; X11 has backing store for this however…
The transparency doesn’t do much for me. I can imagine cases where I would use it, but have never been able to wrap my brain around multiple layers of text.
The drop shadows and fonts are very appealing. The general crispness to the whole thing is good, although that could probably be done with some concerted configuring of kde or gnome.
What is really going to sell me on this is the ease of configurability though. There is no reason why it should be as hard as it is to get decent looking fonts and direct rendering working.
A response to the first person who says “Its just editing a text file”. Then why is this text file posted on most every distro’s forum with a comment to the effect of “Tell me what is wrong with my XFConfig?”
Are 3d/gaming abilities planned? Will graphic drivers be easy to port? Will it work with things like opengl etc. Will performance be kept at least at current levels, or perhaps improved? How about offloading some 2d tasks to the GFX card like OSX does and Longhorn will? They are certainly doing a good job so far though, and maybe we will beat OSX one day in terms of pretty GFX, or at least keep far ahead of windows.
Currently I think that freedesktop.org is the best hope for the future of Desktop Linux.
What about changing x server setting without needing to restart X, and lose the open applications. Like resolution/depth changing in windows.
I wonder what other window managers could do with this X server? Gnome and KDE are nice but I like Fluxbox. It would be nice to see some screnshots of other window managers.
Anonymous (IP: —.lr-s.tudelft.nl)
I don’t see how doublebuffering helps to avoid redrawing on expose; X11 has backing store for this however…
This is far different from backing store… it’s a completely new intelligent compositing model.
Helas (IP: —.onlink.net)
What about changing x server setting without needing to restart X, and lose the open applications. Like resolution/depth changing in windows.
This was addressed by the X Resize and Rotate extension:
http://www.xfree86.org/current/Xrandr.3.html
>This was addressed by the X Resize and Rotate extension:
Which was also got developed by Keith Packard… That tells you something.
But will the GUI delay decrease?
I would think an extra layer like this will increase all but window moves… Window resizing and redrawing will quite possibly be delayed moreso. All those people saying “See X11 is not crap” really do not know why compositing X11 windows from offscreen maps is *not* going to help (just eye candy – and with CPU/Delay expense).
Very very cool and good. Everybody have lot of questions (so do I), but let Freedesktop finish their word/k first before we bombard them with questions/critisms/this and that. Help them to improve.
1) Unless they’re using a different font renderer, the XServer shouldn’t have any impact on font quality. The fonts in the screenshot certainly don’t look better than other Freetype rendered text I’ve seen.
2) Buffering should help expose events because it means that apps don’t need to redraw their windows unless the contents change. So when the window is exposed (say another window moves across it), the X server can simply do a bit-blit from the buffer, rather than asking the app to redraw. Again, I don’t see this as a bottleneck, but if it makes Bascule happy, then I’m not going to complain
3) This is still a regular X server. It supports the X protocol fully. Indeed, the new transparent windowing stuff is done using two new X extensions. So remoting should still work.
I’m curious about that myself. Keith Packard seems to have started so many projects that it is difficult, as a casual observer, to determine where they overlap. His actions have been impressive, especially in the last year, both as an engineer and as an organizer. He seems to have the skills (check out the Xcredits on his resume) and the temperment to give the graphical underpinnings of OSSnix a much needed shot in the arm.
Limited to 2D is still very limited. Is there any possibility that is will ever be able to use 3rd party 3D drivers, such as from Nvidia or ATI?
Q
Reading over Keith Packard’s resume, I must say I don’t like the layout, but the amount of experience he has with X is disgusting. He is certaintly qualified to lead any display server movement on the Linux desktop (or whatever desktops X will run on, for that matter) as both a technical lead and an organizer of others.
On a side note, people need to think less about compositing as making useless translucent menus, and more as providing window drawing capabilities that we’ve been missing for so long. Consequently, we have no app features that use them. One example usage that springs to my mind is the very useful translucent nonrectangular-shaped “tooltip/popup” that appears when you get an email or meeting request, or whatever in MS Outlook. I found this very useful when developing this summer (which had to be on a windows platform), because you could code or continue doing whatever you were doing while the email notification would popup in the lower right-hand corner, which would fade after a few seconds (unless you deemed it important enough to click on it). Very useful.
Keithp’s demos are technical demos; they do not showcase practical usages of the rendering capabilities. Talk to application developers and then determine if you think the technology is “useful,” which it isn’t only if we feel we need to keep the display server in the stone age.
X already does non-rectangular windows (XShape) and GTK+ and Qt already do tooltips (QToolTip for Qt). In KDE, several apps (Noatun, Apollo, Kopete, etc) use them in exactly that manner to notify the user of events.
to make linux future-(desktop?)-ready, today’s xserver should be able to draw the screen in a vector-format.
1) the 2d-graphics should be based on opengl.
2) the transfer from a remote host would be faster because not so much data must be transfered.
what we need is speeeeeeeeeeeeed!
A response to the first person who says “Its just editing a text file”. Then why is this text file posted on most every distro’s forum with a comment to the effect of “Tell me what is wrong with my XFConfig?”
I was going to say its already preconfigured for you in MOST distros. But you probably didn’t wanna hear that.
Is Keith (my new official best mate) going to be working on speed improvements too then? I don’t know if there is a road map for the development of freedesktop X, but i hope it includes speed aswell as new features like these if it does exist.
All in all, fantastic news, we are getting there!
WARNING: I don’t really know what I’m talking about, but I’ve been trying to learn more 🙂
Keith Packard’s work with Xrender and Cairo provide a great deal of vector functionality, though maybe not at the high level you are expecting. As I understand it, both of these extensions could make use of OpenGL, it just isn’t practical at this stage to do so.
As far as speed goes, other extensions he has been working on such as XDamage aim to streamline the conversations neccessary for redraws, which should speed up rendering while providing new functionality at the same time.
Havoc Pennington was pondering these extensions and thinks they introduce stateful, MVC-ishness to X. See his blog here: http://log.ometer.com/2003-11.html#3
This is exciting stuff.
Limited to 2D is still very limited. Is there any possibility that is will ever be able to use 3rd party 3D drivers, such as from Nvidia or ATI?
Aye! As I understand it, this compositing manager is actually an application, so you could easily replace it with one which does the compositing hardware accelerated.
X already does non-rectangular windows
But they look sucky because they aren’t anti-aliased against the background.
This will be possible now (finally smooth rounded corners in Metacity, yay!).
I’d like to second the request for an interview about this, that would be very cool.
I (third?) that request; if OSnews did an interview with keithP that would generate a lot of discussion about the future, here and probably on slashdot.
Limited to 2D is still very limited. Is there any possibility that is will ever be able to use 3rd party 3D drivers, such as from Nvidia or ATI?
XFree86 doesn’t properly handle 3D now anyways, so this isn’t a major loss. I still can’t launch a 3D application while I am in Xinerama mode. I need to restart X, and go into traditional single monitor mode.
here is the font scoop: the font rendering in the screenshot is nothing new, i have the exact same rendering. the issue is in the freetype bytecode interpreter. this interpreter is off by default in mandrake and redhat, but on by default in suse, and gentoo, and i think debian also (havent used debian in a while). the interpreter makes fonts look ‘thinner’ but it helps a lot at low resolutions and on LCDs for subpixel hinting. on CRT’s and/or high resolution, the bytecode interpreter off isnt a big deal, but its a matter of personal preference. its a compile time option of freetype, and it is patented in some regions by Adobe.
I thought Apple held that patent ? I remeber reading that Apple controlled that patent and licenses it out to folks with cash like Microsoft, etc..
I mean long will it take for it to become stable and for drivers to be ported over ? Especially drivers for ATI and Nvidia ?
Um, XFree86 handles 3D very well. Its got full support for OpenGL, hardware accelerated on many cards (Matrox, SiS, NVIDIA, ATI, 3dfx). The best XFree86 drivers (NVIDIAs) are 100% as fast as their Windows drivers (sometimes even faster — some people report better results in WineX than native Windows). They also support every single OpenGL extension that the Windows drivers do.
In fact, the XFree86 NVIDIA drivers are so good, that a number of major movie companies such as Dreamworks (Shrek, Sinbad), Weta (Lord of the Rings), and ILM (Star Wars Episode II, Episode III) have transitioned to Linux for both their render farm and most of their artist desktops. See this article http://millimeter.com/ar/video_linux_hollywood/ for more.
Unless the NVIDIA drivers are ported to this new X server, it simply will not be usable by all the companies that use Linux/XFree on their 3D workstations.
I don’t think any drivers would need to be ported over because it is based on xfree and little has changed in this new version.
@Siti : Actually, the new X server is based on kdrive, KeithP’s own X server. They’ll reuse code, but the core is brand-new.
@Jason Lotito : Some stuff I forget.
1) Both the ATI and NVIDIA drivers support GL in dual-head mode. In NVIDIA’s driver, you have to use TwinView support, in ATI’s, you use their equivilent.
2) Here is a list of movie studios using primarily Linux. Its from the article I linked to. Since a lot of pro graphics apps use OpenGL (even non-3D ones like Apple’s Shake) the availablity of quality OpenGL drivers is critical for Linux.
Digital Domain
Disney
Double Negative
DreamWorks
Flash Film Works
Hammerhead
Industrial Light & Magic
Rhythm & Hues
Sony Pictures Imageworks
Tippett Studio
Weta Digital
Because it looks good enough to eat. I can’t wait. Looks awesome.
“Limited to 2D is still very limited. Is there any possibility that is will ever be able to use 3rd party 3D drivers, such as from Nvidia or ATI?”
XFree86 doesn’t properly handle 3D now anyways, so this isn’t a major loss. I still can’t launch a 3D application while I am in Xinerama mode. I need to restart X, and go into traditional single monitor mode.
3D acceleration is done via drivers + mesa. What you are talking about has nothing to do with the X server and everything to do with the fact that OpenGL does not support multi-screen display. DirectX does, OpenGL doesn’t. IIRC, that is a feature being added to the next specificiation.
here is the font scoop: the font rendering in the screenshot is nothing new, i have the exact same rendering. the issue is in the freetype bytecode interpreter. this interpreter is off by default in mandrake and redhat, but on by default in suse, and gentoo, and i think debian also (havent used debian in a while). the interpreter makes fonts look ‘thinner’ but it helps a lot at low resolutions and on LCDs for subpixel hinting. on CRT’s and/or high resolution, the bytecode interpreter off isnt a big deal, but its a matter of personal preference. its a compile time option of freetype, and it is patented in some regions by Adobe.
There is a bit of a patent criss-cross, however, there are two hytecode interpreters, there is font hinting which is the patented version and there is another one which is being developed by Freetype. The eventual aim is to get this one up to the standard to font hinting so that one will no longer need to rely on the patented switch.
Um, that’s not true. OpenGL supports multihead just fine. All OpenGL cares about are GL contexts. In most systems, GL contexts are windows, and if the window system supports windows on different desktops, so does OpenGL. The real limitation is that most current hardware doesn’t support 3D acceleration to multiple frame buffers. Thus, the GUI system has to use something like TwinView, which implements multiple monitor support by using one double-sized framebuffer. NVIDIA uses this in their DirectX/Windows drivers as well.
Interestingly, this hack will likely be a speed-killer for GTK apps, SDL and any tool-kit, application or environment that buffers its graphics display internally before feeding it through to X11. The introduction of buffering at the window manager level for these effects will only ‘double-up’ the buffering that is already taking place at application level. Thus many existing applications will end up being *triple-buffered*, which would waste most of your memory, plus the dog-slow speed of triple-buffering and X11’s existing throughput issues would make it a huge disappointment.
The only way that this could work is if X11 standardised on this buffering issue and made things easier for developers in this area. Then all the existing apps that use their own buffering need to be adjusted to take advantage of it. Even then, you’ll still need a 1Ghz+ processor because X11’s added overhead still causes a lot of grief when drawing buffered graphics (you could use the XDGA extension, but it only works for full screen games and not the X desktop, so that’s out).
Only OS X and Athene (which already works on X11) have got it right so far – something like this really needs to be done correctly from scratch, not just hacked on to an antiquated display system. The screenshots look fantastic, but I’ll guarantee you that it runs like a dog.
i don’t like
1. still using the x11 code.
2. why they have to name it “n.e.w x s.e.r.v.e.r.”???
3. still not integrated with anything.
—
Well, I am a windows user.
First, please read the paper. You don’t seem to have a good understanding of how these new extensions work: http://freedesktop.org/Software/TranslucentWindows
Interestingly, this hack will likely be a speed-killer… and X11’s existing throughput issues would make it a huge disappointment.
>>>>>>>>>>>
1) Toolkits do not double buffer the way you think they do. The back-buffer is only allocated temporarily while the widget is being redrawn. Thus, the memory usage is very small — only the size of one widget at any given point.
2) Its just an extra blit. Blits are really, really, fast these days. With 6.4GB/sec of memory bandwidth on top in my lowly GeForce4 MX, blit-speed is not a bottleneck.
3) X11 doesn’t have throughput issues. Its throughput is really fast, as several benchmarks have shown. X11 apps have latency issues in places, and these extensions alleviate a lot of those.
Even then, you’ll still need a 1Ghz+ processor because X11’s added overhead still causes a lot of grief when drawing buffered graphics
>>>>>>>>>>
X11 was designed for 20MHz processors. You can do double-buffered graphics on X11 by rendering directly to a pixmap and blitting using ShmPutImage. That’s pretty much what you have to do with DirectX as well. What overhead are you talking about? Have you ever even done graphics programming?
(you could use the XDGA extension, but it only works for full screen games and not the X desktop, so that’s out).
>>>>>>>>>
Didn’t you get the memo? Direct graphics access is passe. DGA is depricated, and nobody seems eager to replace it.
Only OS X and Athene (which already works on X11) have got it right so far – something like this really needs to be done correctly from scratch, not just hacked on to an antiquated display system.
>>>>>>>>>
With the current model, apps will just have to be updated. Simply don’t bother double-buffering, and you’re done. If you start from scratch, you’ll have to rewrite your apps!
Rayiner Hashem: Yeah, I know Linux can do all that movie stuff, but doesn’t mean anything to me. Fine, great. However, right now XFree86 doesn’t do OpenGL while in Xinerama mode.
As far as the TwinView stuff goes, that’s all fine and dandy. I have two seperate video cards, one is a Voodoo, and one is a Savage. Now, in Windows, I can play 3D games in dual head mode, last time I checked. I assume these are for single cards that support 2 monitors, which does me no good, as there are times I use 3 monitors, with three different video cards. They all work fine in linux, just not with 3D support.
Do you have two video cards? I’m asking because I use the Xinerama extension with Twinview (two monitors plugged into the same NVIDIA card) and I can start 3D apps no problem – whether they are windowed or full-screen. But I’ve heard of people having problems when they have two separate video cards, one of each monitor.
People complain too much about things being eye candy, but this is more than that. Having windows cast shadows nicely and so on actually helps the computing experience. It actually reinforces the stack metapor nicely. You can tell which Window is where in the ‘stack’ of windows by just looking. Although transparency will probably used for eye candy, it can have good uses.
Its nice to have these capabilities in X anyway. Getting a bit behind the times. Tis will enable projects lke GNOME and KDE to concentrate on stuff besides hacks to get things to look good. Now, for those OpenGL extensions so this can be all done in 3D on the graphics card
Actually, the reasons the fonts look so good isn’t necessarily because of the bytecode interpreter, but rather of the dramatic hinting improvements integrated into freetype, some of which were provided by David Chester.
I don’t have the bytecode interpreter turned on, and still I get great-looking fonts:
http://archie.homelinux.net:8080/screenshot2.html
I’ve tried turning it on, and frankly the (anti-aliased) fonts look better with only the freetype hinting. Non-anti-aliased fonts do look better with the bytecode interpreter on, however.
He might actually have just recompiled freetype to allow the patented hinting algorithm. It really does improve font rendering that much, especially at small font sizes.
Yeah, I know Linux can do all that movie stuff, but doesn’t mean anything to me.
>>>>>>>>>>>>
Nobody really cares if it means anything to you. You said, “XFree86 doesn’t properly handle 3D now anyways, so this isn’t a major loss.” That’s complete bullshit. How the hell do you make the leap from “it won’t handle my special case of OpenGL with Xinerama with two different video cards” to “XFree86 doesn’t properly handle 3D now anyways?” Losing accelerated 3D on X would be a big loss, whether or not Xinerama + OpenGL works on your computer!
Okay, we posted almost at the same time…So they are different cards. Yeah, I’ve heard of this, and other problems with dual-head (my friend can’t get anti-aliased text if he uses both monitors on a dual-headed system).
Sorry, can’t help you there.
Exactly what linux needs to take the desktop market XFree86 is good for remte sessions but this is sweet
I find the with Freetype’s code enabled, rather than the patented algorithm is much nicer.
Fonts are rounder, and more smooth. Some people don’t like this though.
will help managing many windows on the desktop. (i.e. great visual que)
combined with my penchant for focus-follows-mouse…it could be love
I was curious and looked a bit closer at the fonts and those on my system (unmodified Fedora, Bitstream Vera fonts):
http://liebesgedichte.net/Temp/fonts-comparison.png
As you can see, he is using subpixel smoothing (the colored pixels), which only really makes sense on LCD displays. Apart from that, I see only minor differences, which certainly are nice though. Particulary his “s”, “c” and the small “a” look slightly better. Could just as well be a modified version of the font. Or would this be the effect of font hinting?
that would make sense as he is using a LAPTOP, which you know, have LCDs.
Sorry for the condescending tone in my last post. I thought it was on the link.
it says here about the laptop http://freedesktop.org/Software/TranslucentWindows
once again, sorry.
Woah. I’m looking forward to the performance between this and imlib. If it’s good and Eterm and Enlightenment (probably E17 or something) i’d be one happy fellow. Cause imlib is getting on my nerves
does anyone know how?
Over the last years, X11 has fallen way behind the functionality of Windows which through Windows Terminal Server can re-connect to running sessions from any place and is blazingly fast on a ADSL line. VNC is not the answer, it may be the question. No is the answer. LBX doesn’t help with the reconnection and roaming, xmove can at best be nadled by (let’s call them) trained professionals. This goes for LBX as well.
The more eye-candy I see in X, the more I realize that the open source world is loosing the desktop, not getting it.
/jarek
I wonder if they have any concrete plans to compete with Longhorn.
Longhorn is going to have vector graphics only, dropping
bitmaps completely (except for palmtops editions I presume).
Every graphic element (which means every widget, window
frame, icon, text)
1. will be vector defined.
2. will be rendered use the 3d capabilities of the cards
(via Direct3d).
3. will support translucency.
4. will use z-buffering (don’t ask me what for… futhermore
translucency and z-buffers don’t mix well AFAIK).
5. will be dimensioned relative to the screen size, not to
pixels, so as to be invariant of the screen resolution.
Useful or not:
1. these features will become a must in order to compete
with Longhorn. I can already hear Windows fans “linux
has still bitmapped graphics” adding to the already
known complains.
2. web browsers will HAVE to supply those features
(translucency and vector graphics) in order to be XAML
compliant.
The KDE developers said it is not up to them, and that little is possible unless the X server supports those features.
They have enough time… I just hope they are not overlooking that; If they don’t, GNU/linux risks to stay behind forever (technologically speaking).
the difference in font rendering is due to the fact that he is using a different version of freetype2 (file name is libfreetype6.so).
Ohh, storing window data in off-screen storage and using a compositing engine to render them down into a single framebuffer, thus allowing you to do all sorts of hoopy Alpha & Transparency effects?
I’m sure I’ve seen that someplace before!
It would be a shame if it is not, as it would be a bit of a duplication of efforts.
However, the progress made by X Server really shows what KeithP and his peers are about: hacking up good software without paying attention to the political garble that goes on above them.
During this redesign/reimplementation, it is quite possible to take a lot of X’s functionality out of the core, (and the ‘necessary’ bits around it) and move it into a ‘legacy emulation’ module (something like that.)
This could allow the architecture to be made leaner, meaner and better equipped to be adapted to the future demands of GUI environments.
X in its entirety may not be obsolete, but it carries an awful lot of genuinely obsolete baggage and well-intended features that can be done better with current know how.
Examples are abound, so I’ll just let you look for them.
John.
“Windows Terminal Server can re-connect to running sessions from any place and is blazingly fast on a ADSL line. VNC is not the answer, it may be the question.”
VNC is also fast on a ADSL line. 16 kB/sec worked fine with 2 connections
i remember even using WTS and VNC on a dialup.
Oh, and the Nokia Communicator 9120 does NOT have WTS (you guess why, cause it’s closed source!@#$) while VNC exists for this GSM.
Ah, and there’s ”rdesktop” too.
First: longhorn is waporware until 2006.
I say this because years ago microsoft told us that NT 3.5 will have a powerful object oriented filesystem (and I have yet to see it); windows 95 will have 3d graphics (direct3d came 3 years later).
Even Steve Jobs told us that osX is full 3d accelerated but we now see that only windows compositing is accelerated.
Second: it is better for open source to have DIFFERENT PRIORITIES.
The first thing to do is: modularize modularize modularize.
If we have 2d and 3d/opengl drivers that can be used WITHOUT loading an entire xserver we can do all what we like: several versions of xservers (one that does compositing with xrender, one that does it with opengl), alternative windows servers (fresco, display postscript), unsing directly gnome and kde on etc. etc.
Without modularization is difficult to have progress and we will have surely less features than longhorn and osX
the server is faster with the composite manager enabled; and that in vesa mode. window moving and the mouse feels much better. i think this thing will rock with accelerated drivers.
@ Bascule
> Which is the rather antequated client-side expose handling
> model. Rayiner Hashem will most likely disagree that this
> method is inherently superior, but it’s certainly my belief
> that this is the way all modern windowing systems should go.
> Windows uses this model, but for transparent windows only.
> OS X uses shared memory raster buffers between client and
> server and consequently all expose events are handled server
> side.
The problem with backing stores (because this is what we’re talking about, in essence) is: how are memory allocations handled?
More specifically:
1) where’s the window’s raster buffer allocated? Gfx memory? Main memory?
2) How much memory is allocated? a) As much as its dimensions really requires, or b) as much as its maximum dimensions require?
2.a) In case of (a), what happens when the window is enlarged and no memory is available?
2.b) In case of (b), how much memory is that going to be? Would it be even possible to do it the (b) way at all?
Vnc might not be slow, but it sure FEELS slower.
I use rdesktop all the time to connect to windows computers, and rdesktop is brilliant:=) And it also feels much much faster than any vnc ive ever tried.
What is lacking is a “reversed” rdesktop, a small lean and fast program for connecting to X boxes from windows without the hassle of installing an xserver.
I compiled the whole thing as described in the installation manual to /opt/fdo and the Xvesa server starts (but in some low-color mode … !?). But every attempt to run the xcompmgr results in a segmentation fault (Xvesa doesn’t crash, but xcompmgr just doesn’t run.
After adding some printfs to the code, I found that the second call to XRenderCreatePicture in main() makes the segfault.
I’m running Fedora Core Test3 on a P4/2400MHz with a Radeon 9500.
Longhorn is going to have vector graphics only, dropping bitmaps completely (except for palmtops editions I presume).
Please cite your source(s) for that. What you are claiming is inconceivable. Too much of the user interface relies on bitmaps and too many applications rely on bitmaps for Microsoft to write an OS that doesn’t understand them.
How are users going to display desktop wallpapers? How are they going to view digital pictures? While a skilled artists with a vector program (Illustrator , Corel Draw, etc…) can make very engaging work, it’ll never be the same as a high-quality digital picture.
How are they going to use Photoshop, Paintshop Pro, GIMP, etc…? While most of those programs can use vectors as drawing aids, the output is always a bitmap.
How are users going to edit video? Video files are compressed deltas of frames of bitmaps, not vectors.
How will legacy applications, ones that don’t have vector icons or are written to your hypothetical vector based widget set, work in Longhorn? I’m sorry, but even if your mytical vector only Longhorn is real it will have to support bitmaps for backwards compatibility, if nothing else.
Bitmaps are not going away in Longhorn. They can’t.
Very impressive indeed! I can’t wait for better X servers come out. I also can’t wait for the current XFree86 to just die.
>> Bitmaps are not going away in Longhorn. They can’t.
Of course they won’t go away.
What that previous poster meant is that Longhorn will use vector graphics for rendering the elements of the user interface.
So Longhorn is dropping bitmaps for the UI, but not for the whole OS.
See the MSDN TV episode about XAML how things work..
Hmm, I wonder about building this and running it on my Solaris notebook…..
-Jason
definitely agree!!
You notice that the screenshots are all done with the GNOME desktop, what about people who use KDE…I think we’d like to see screenshots that show how it looks on KDE as well; hell even a few Window Managers to!!!
/dev/null
He might have meant “going away in the UI”, but he said, “Longhorn is going to have vector graphics only.”
To your point of just the UI having vector graphics. Again, that is a misnomer. The Longhorn UI can’t go to vector graphics 100% without completely breaking all existing applications that rely on the bitmap UI toolsets. While Apple might’ve been able to demand a break in compatibility with OSX, Microsoft has too much inertia with the current apps to demand that everyone buy new programs immediately when they buy Longhorn. Longhorn will have to support bitmaps in the UI in some way shape or form.
I’ve seen the videos on XAML. It’s nice, it’s slick. It also won’t be the only way we interact with our Windows boxes for probably a decade or so. People are still using DOS and Win16 apps a full 8+ years after Win95 came out. People are hesitant to change, especially if what they have works for them. Given that, people will still be using apps that require MFC, QT, wxWindows, et. al. for a long long time after Longhorn ships.
“Vnc might not be slow, but it sure FEELS slower.”
Which server have you been running? Have you actually configurated the thing? What kind of hardware?
It isn’t what i’d define as slow on a Nokia Communicator 9210 (sorry mixed numbers earlier).
RDP server has already been discussed. Check out this post
http://mail.rdesktop.org/archive/2002/msg00615.html
> He might have meant “going away in the UI”, but he said,
> “Longhorn is going to have vector graphics only.”
Sometimes you don’t say something because in your mind it is obvious, but it actually isn’t.
> To your point of just the UI having vector graphics. Again,
> that is a misnomer. The Longhorn UI can’t go to vector
> graphics 100% without completely breaking all existing
> applications that rely on the bitmap UI toolsets.
True, but the old apps you are talking about (mostly Win32 and MFC) will be emulated, they won’t run in native mode.
The apps that use Windows.Forms will be transparently upgraded to use vector widgets.
I’d like to see Keith write a book in the spirit of the newly released “Linux Kernel Development” by Robert Love.
The books explains the internals of the Linux kernel very well. It focuses on theory but gives specific examples where applicable and even small code snippets to help reinforce the explanations.
Keith should seriously think about writing a similar book but on the subject of X’s internals…
I’m only part way through Love’s book but already I’m excited about learning how to hack the kernel and what exactly it’s doing inside… I can imagine I’d have the same reaction to one on the new X server’s internals as well…
I feel it would be an excellent way to bring more developers to this effort (even if only casual ones)…
Yes, same here. Aaaargh I want to try it out.
Just a question.
If I understand this correctly, all windows (top level windows) are stored in an offscreen buffer. Even the desktop.
Right?
Doesn’t this mean that the server needs a lot of memory?
Imagine a desktop and 3 maximized windows when using a resolution of 1280×1024:
3 x 1280 x 1024 x 4 = 15MB.
I was on the #freedesktop IRC channel last night and got to talk to keith about the new server a bit. He said he has had trouble with kwin so far and didn’t find it a necessary thing to work on at such an early stage. It will of course be compatible though. Just be patient.
I guess that it will eat memory, but I like the concept. I’ve got mempry on my computer and it’s cheap to buy more!
To those saying that VNC is slower than Terminal Server: it depends a lot on the OS at the remote end. VNC server on Unix is faster than VNC server on Windows. On Unix, the VNC server behaves like an X server as far as the applications are concerned, so it knows exactly when to update and what parts of the screen to update. On Windows, there is no easy way for it to find out what to update, so it uses some heuristics and takes screen shots (I assume Terminal Server, being developed by MS, is able to place hooks deeper in graphical subsystem, somewhere in the GDI I would think).