Slashdot Mirror
Xr Renamed to Cairo
Charles Goodwin writes "Xr, the vector graphics extension for XFree86 that Keith Packard, Carl Worth, and a few others have been hard at work on, has been renamed and is now officially called Cairo. Keith and Carl recently gave a detailed presentation on Cairo (then known as Xr) which should be a useful read for those wishing to understand it a little better. There is already a useful Gtk+ rendering backend that uses Cairo, as well as an SVG test suite. This, along with Gnome2's subtle adoption of SVG and the inception of Xouvert (which now has goals for both the short term and long term, and an initial plan which includes coexisting with XFree86), spells a bright future for the eye candy of an X desktop."
I have always thought vectors were the way to go. The mac implementation is really good (I used mac os X for the first time yesterday). Although having a nicer looking desktop (as long as its optimized) is a good thing. Of course, at first, you wouldnt expect it to go very fast but it should get faster and stable in good time.
Can your karma go above being Excellent?
Actually, it was Windows XP which was code-named Cairo. X and P refer to Greek Letters Chi and Rho. Possibly Xr changed to Cairo using the same logic. Just a guess, though.
getSexySig();
Cairo is not for you! someone like you should use the old version of Xfree86 because you dont like cutting edge, you dont like polish, you dont need eye candy.
But please do not hold the rest of us back because you dont want progress.There's the commandline and original Xfree86 for people like you, we also need to attract desktop users, and this requires eyecandy.
They will not switch from Windows if Windows is better.
If you use Linux, please help development of Autopac
One of the parts in the article mentions a user-specified error tolerance to control quality vs performance. I'd be curious to see how this performs in the real world.
There's already a gnome theme by the name of scalable gorilla that uses vector graphics. It runs a little slow on slow CPUs, but it looks fantastic and it's easily configurable. With a bitmap icon, I have to recreate the graphics file, with the Scalable Gorilla theme, I change text in a XML file. Another thing to keep in mind is the size of the hi-res bitmaps that would be required to compete with the computer synthesized perfection of vector graphics.
Isn't this a disk space vs CPU tradeoff? I have to store a bitmap where I have to compute a vector? I'm all for using my untapped CPU cycles instead of disk storage.
Does anybody know if sub-pixel anti-aliasing is planned for this -- or any other vector drawing APIs? Smooth anti-aliased lines look nice, but they look bad in comparison when they're next to sub-pixel anti-aliased text on an LCD screen.
BZZT! It WAS Windows NT 4.0. Here's a FOLDOC entry on NT4:
Windows NT 4
A version of Microsoft's Windows NT operating system, originally code named "Cairo". It was supposed to ship in the first half of 1995. Details are scarce, but it is intended to provide an object-oriented version of Windows.
(1996-07-09)
"right future for the eye candy of an X desktop"
;)
This is essentially untrue. Accepting vector graphics as the default in computers may alter our perception of what is eye candy completely. As far as I'm concerned the Fresco/Berlin project was the right way already several years ago. Today, the hardware has caught up and there is nothing to be lost in user space with vector graphics everywhere.
In fact, we have no idea what kind of possibilities may open up here. If we're unlucky, yes, it might be a can of worms...
I like the sound of Xr/Cairo, seems pretty cool. But how long is it going to take for this to turn in to something I can actually use? I guess the eventual goal is to have GTK and QT running on top of Cairo (maybe with extensions to do explicitly vector things?), but this strikes me as something that's not going to happen fast. Maybe I'm just being impatient.
Stuffed on the finest of herring no doubt!
Great news on the arrival of rasterized graphics output for Xfree86. That should allow for some superb gaming, visual modeling, and graphic apps for Linux.
XrStroke is sure to be a popular command...
maybe that explains the contented look... randy penguin!
If you are lost with these references, you might enjoy "Why a penguin?" and "linux" together as a google search.
~8^]
The lack of vector graphics was on of the major arguments citing why X11 doesn't work very well over low-bandwidth links.
Is having X over low bandwidth eye candy?
Mod me down and I will become more powerful than you can possibly imagine!
Actually the protocol wouldn't have to be changed much at all. I've investigated this - the alpha value can be passed in the word-alignment byte. If you load up transluxent and throw real alpha values into your XImage, then it will be real alpha. It's just that regular XFree86 ignores the word alignment byte, and transluxent just passes it on to OpenGL so it actually works fine. Unfortunately transluxent isn't very stable.
I think the whole friggin GUI should be vectors. The Icons should be vectors, and these vectors should be manipulated in realtime via the video card/hardware.
Forget software rendering, we need hardware rendered GUI, using SVG for the interface and icons.
We also need to somehow maybe via OpenGL or some technique, to get the special effects of the video card applied to the GUI.
Then someone can write KDE4 or whatever, and the eyecandy/special effects should be plugins, a person should be able to code an effect via a scripting or programming language, someone should be able to download say, the motion blur or sparkle plugin, and then I click it and suddenly my menus motion blur or sparkle with fairy dust when I move them.
You could break the effects up into groups.
Scaling effects
Trails for cursor
Trails for menu
Icon effects/animations
etc, and when this is done, then people can write themes easily etc and we can innovate.
The key should be a system that allows a newbie who isnt a coding genius to actually manipulate a video card either via scripting, or some high level interface.
What I want is complete revamping of the X protocol with backward compatibility maintained (permanently), such that new apps can take advantage of new server-side widgets without breaking compatibility. Wouldn't it be sweet if GTK+ apps could run as well over a 256kb/s line as XAW apps do?
I dont care so much about backward compatibility and I dont think most desktop users do. Servers sure as hell wont be running this. But if back compatbility is so important that can be handled to.
QT3 has translucent menu items and such. I haven't checked to see if they cheat by reading from the screen, or if they have implimented an alpha layer.
Fake translucency is not what people want, we want alpha channeling. This will only happen when the whole interface changes from pixel based to SVG based and then an OpenGL backend to access the video cards.
I think Evas has the right idea here, now its just time to have X catch up to it.
If you use Linux, please help development of Autopac
Whatever happened to descriptive naming? Who would instinctively associate "Cairo" with "vector graphics for XFree86"? Why not name it something sensible, like "XVector" (if that's not already taken)?
In all seriousness, I think that poor name choices hurt the adoption of free software. Think about "Photoshop" vs. "The GIMP," or "Internet Explorer" vs. "Mozilla." Rather than something simple, descriptive, and catchy, we usually opt for indecipherable codenames, stupid recursive acronyms, or lame in-jokes that few people but the developers themselves will get.
Poor naming limits the spread of the software meme to those who are already in the know, especially when the names are designed to enforce an only-the-anointed-get-it, us-vs-them mentality.
Cheers,
IT
Power corrupts. PowerPoint corrupts absolutely.
Over the next few years, desktop graphical environments will move increasingly towards vector graphics and away from bitmaps. The Mac is already there. Windows and Linux are both in the development stage (Longhorn and Cairo respectively) and it will be interesting to see who gets there first. Desktops will finally scale properly to different sized monitors and there will be no excuse for apps that do not scale properly.
Once every operating system supports vectors natively, SVG will become a no-brainer. Why would we use vectors for everything on the desktop and then dumb it down to bitmaps for transmission over comparitively thin network pipes to devices of arbitrary size and shape? It would make no sense whatsoever. So SVG will replace a huge number of the GIFs and PNGs on the Web, to say nothing of Flash files.
A wonderful side effect of this will be that people will finally be able to have richly rendered text on the Web without resorting to binary formats like GIF and Flash. Imagine being able to cut and paste text even when it is embedded in highly stylized corporate graphics (as is becoming more and more common!).
There are really so many follow-on effects that we could have a long thread discussing them. Congratulations to the Cairo and X teams for taking a few more steps down the path!
Why is backward compatibility so important to engineers who create Xfree86 when they only use Linux to create Xfree86?
What is this supposed to mean? Are you under the impression that XFree86 only runs on Linux? If so, here's a quote for those of you who live in the "Linux is the only thing there is" box:
That's directly from the XFree86 home page. Apperently, the engineers who create XFree86 do care about compatibility.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
But...who knows. Maybe this Cairo won't be a wasted excursion in the desert...
Of course, once we have backing store it is a small step to provide (unaccelerated) translucent windows.
;-)
The *really* important thing to do after that is to provide an extension to use the backing store of each window as a pixmap, and as a OpenGL texture.
This will allow a window manager to do nice tricks.
* On a window move, unmap the window, get its backing store as a GL texture, and do all the flippy rolly effects that have got everybody salivating over longhorn and OSX.
* Expose like effects. See if those patents (or the will to sue) hold up
It could also allow desktop pagers to get an accurate picture of whats on the screen, and maybe provide a slightly improved performance for remote desktops like NX and x0rfb. Not as good as a drawing command redirect, as I said here.
For some really nice currently available eyecandy, see 3ddesktop . This should make clear that its not neccessary to shove too much into the server to get nice things done.
For anyone who has not used an SGI machine before, windows often have one or two widgets (if two then one would be oriented on the horizontal axis, the other on the vertical) which resemble long, thin, ridged wheels. When you click and drage so as to rotate the wheel showing in a file manager window the file icons will all resize automatically in realtime and smoothly, since it is all drawn in vectors. To me this would make a graphic desktop in linux a lot more useable.
That, and the way you can use a mouse and three buttons in OpenInventor windows to navigate/manipulate in three dimensions are a couple of the best things about SGI user interfaces to my mind.
A picture of an IRIX desktop with an icon resizing wheel is here