Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
X GUI Graphics Software

Xr Renamed to Cairo 216

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."
This discussion has been archived. No new comments can be posted.

Xr Renamed to Cairo

Comments Filter:
  • That's all good and well, so when are we getting alpha-blending in X? It's really annoying having "almost" transparent terminals that copy my background.
    • by Rooktoven ( 263454 ) on Saturday August 30, 2003 @01:53PM (#6833849) Homepage
      In some ways almost transparent is easier on the eyes. I know when I have 4 or 5 mac terminals open the overlay can be confusing-- not to mention if (assuming a dark background) a light colored application ends up behind a terminal.

      I know it's nice for the "see what is possible" factor, but pseudo-transparency has it's place. I might even opt for it at times if I had the choice.
      • by Equuleus42 ( 723 ) on Saturday August 30, 2003 @03:00PM (#6834219) Homepage
        I can't remember where I read this quote, but it went something like, "In the publishing industry, tons are spent and much effort is made to ensure that the paper is thick enough so that the reader can't see the words underneath the current page... In the computer industry, it seems that the effort spent is for the opposite effect." :^)
    • Well, Cairo supports translucency. Maybe you'll get your alpha-blending from Cairo?
    • KDE3? (Score:5, Informative)

      by SHEENmaster ( 581283 ) <travis@uUUUtk.edu minus threevowels> on Saturday August 30, 2003 @01:54PM (#6833863) Homepage Journal
      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.

      The big issue with an alpha layer is that someone has to have the authority to impliment such a change in the X11 protocol, it can't be done as an extension. Anyone who uses the fucked up protocol won't be able to display their app on a different X server. This breaks compatibility with thin clients.

      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?
      • Yes, they cheat.
      • Re:KDE3? (Score:5, Informative)

        by IamTheRealMike ( 537420 ) on Saturday August 30, 2003 @02:13PM (#6833968)
        They do cheat, yes. There is no need to break backwards compatability, in fact the protocol already has what's needed, it's mostly a matter of XFree engineering and getting it effecient enough to not kill performance. If you want GTK apps to run sweet over a modem even, look into NX compression. Again, no need to break X.
      • Re:KDE3? (Score:3, Interesting)

        by andrewl6097 ( 633663 ) *
        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.
      • by HanzoSan ( 251665 ) on Saturday August 30, 2003 @02:37PM (#6834095) Homepage Journal


        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.
        • I agree completely. Screw the current practice of using X as a glorified framebuffer, I want my vector based GUI!

          Years ago, I had a vector based GUI. Now, however, that old NeXTSTEP box is just too old and obsolete. It was nice, though, having the whole GUI use PostScript. Now, I don't really care if you want to use PostScript, SVG, or whatever. It would be nice if both were supported somehow, but this should be in some layer of abstraction. Make the basic protocol elegant and extensible---you'll be living

        • Nice ideas. The only problem is X. From what I've seen, they're more worried about stability and backwards compatibility than new features. That's why I'm looking forward to xouvert. People can stick with standard XF86 for older systems, servers and terminal clients, while desktop users can have their eye candy. Compatability might eventually become an issue, but hey, it's open source. Somebody will find a way to fix it.
        • This is exactly what needs to happen. In a few years, Microsoft is going to release a hardware accelerated desktop with full transparency and graphic effects. It would be nice if Linux would beat it to the punch within the next year.
        • but my workstation might. I'd need to still be able to tunnel X from my server to display GUI apps locally.
        • Wow, that sounds great! When can we expect to see your 0.1 alpha release?
  • great (Score:4, Funny)

    by SHEENmaster ( 581283 ) <travis@uUUUtk.edu minus threevowels> on Saturday August 30, 2003 @01:50PM (#6833833) Homepage Journal
    but when do we get an ASCII renderer for it?
  • by Anonymous Coward on Saturday August 30, 2003 @01:52PM (#6833842)
    This is the code name for Windows NT. This is a blantant and illegal DMCA violation, and a dilution and sullying of Windows NT's good name. They will be served.
  • by justsomebody ( 525308 ) on Saturday August 30, 2003 @01:56PM (#6833872) Journal
    According to publications they are going to contact as many organisations and support as many standards as possible. That's something that XFree never did.

    They even plan to contact Freedesktop.org.
    • They even plan to contact Freedesktop.org

      Bagh, Freedesktop.org came to existence because the XFree team was unwilling to develop any new standards in the first place.
      Now, roughly the same people who participate in the Freedesktop efforts are taking over the flag of free X server development as well. For me, it's definitely a turn to the better.


  • Why are we posting this when this happened like a month ago?

    Anyway where can I donate money to Cairo development?I mean I dont have A PHD in software engineering and cannot help with the actual development, so how about accepting donations people?
  • Not eye candy!!! (Score:5, Interesting)

    by G3ckoG33k ( 647276 ) on Saturday August 30, 2003 @02:22PM (#6834002)
    "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... ;)
    • Re:Not eye candy!!! (Score:5, Informative)

      by penguin7of9 ( 697383 ) on Saturday August 30, 2003 @04:11PM (#6834603)
      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.

      X11 doesn't support "vector graphics" any more or less than it used to. What has changed is that X11 now has an imaging model similar to PostScript (subpixel addressing, antialiasing, etc.) in addition to its older bitblit model (pixel-accurate, using boolean operations for drawing).

      (Subpixel addressing also allows you to do zoomable or "resolution independent" graphics, while the bitblit model is resolution dependent. However, the term "resolution independent" is somewhat of a misnomer--even if your imaging model supports arbitrary zooming, you can't just zoom user interfaces up and down and expect them to be usable.)

      When people talk about "vector graphics" in the context of window systems, that usually means the use of display lists: you give the server a list of "objects" to display (lines, triangles, rectangles, etc.), and the server takes care of displaying them when needed. But they might mean something else as well.

      Display lists in X11 are still handled the way it has always been handled: by client-side libraries. Eventually, there may be a server-side extension for handling display lists and perhaps even the ability to transfer display lists and structured graphics in the form of SVG data. That would give you Quartz-like redrawing and rescaling, although while that looks nice it has few real advantages.

      Now, what about Berlin vs. X11? First of all, one big thing in Berlin is the incorporation of GUI components into the server. That is an anathema to X11 designers. Also, while resolution-independent graphics is nice (the same thing X11 now supports with Cairo), it is a poor choice as the only graphics model: well-designed application for low-resolution and/or low-depth screens (e.g., a 160x160 Palm) must be able to draw with pixel-accurate drawing operations and precisely predictable results on every bit on the screen.

      I don't think Berlin "got it right". Berlin concentrated on the obvious, convenient, clean, high-level stuff. Berlin would give you slick-looking OS X-like desktops if it ever caught on, but the Berlin designers have neglected the other imaging models that are really important to real window systems, and they have put way too much policy into the server.

      Fortunately, the way X11 is evolving, we won't have to make a choice: you can have all the slick antialiased, structured graphics you like, and yet still have pixel-accurate drawing in a bounded memory X11 implementation. The only difference will be that X11 still won't enforce policy on the server side, and that's a good thing as far as I am concerned. But the market will decide that issue.

      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... ;)

      There is no "can of worms". We have had window systems with antialiased drawing, structured graphics, and all that at least since the 1980s; maybe you remember NeXT and NeWS. The feature is nice, but it doesn't radically change what people do with GUIs.
      • Perhaps a tad pedantic, but X11 is the protocol and hasn't evolved. XFree is, what I think, you are referring to.

        Replace all the X11 references with XFree86 and the parent was a very informative post!
        • Perhaps a tad pedantic, but X11 is the protocol and hasn't evolved. XFree is, what I think, you are referring to.

          I view the Render extension as part of the X11 protocol family now, and Cairo as a portable client-library for it. So, in that sense, I do view this as a part of X11 now, not just some XFree86-specific hack. I believe some commercial vendors of X11 server implementations have already been tracking Render. I would hope that HP, Sun, and IBM will start supporting Render quickly.
      • The feature is nice, but it doesn't radically change what people do with GUIs.

        Then why does everyone else have it but Linux?
        • Neither Windows nor MacOS got support for anything close to the PostScript imaging model until fairly recently, and very few applications take advantage of it.

          And did the Windows or MacOS GUIs get significant functional changes as a result? Not really: it's still the same old menus, the same old dialog boxes, the same old title bars, etc. They just look a little prettier, and transparency and fading give people some slight additional visual cues. Nice, but not exactly a revolution.
      • Cool to see someone who doesn't have misconceptions about fresco. However, can you elaborate a bit on why you think putting as much policy as possible in the server is a bad thing?

        - it offers possibilities to take advantage of and adapt to the available hardware. (server knows if the screen is only a 4" PDA screen, or a 30" 3D display - the application shouldn't have to know these things)
        - it should be the user (where the server is) who decides on policy, not the application
        - it's bandwith friendly if you'
        • it offers possibilities to take advantage of and adapt to the available hardware. (server knows if the screen is only a 4" PDA screen, or a 30" 3D display - the application shouldn't have to know these things)

          But the application has to know--scaling applications down to a PDA screen requires some hard choices to be made in terms of what is displayed. Merely scaling down the display won't help, and the server simply doesn't know enough about the application to do it automatically

          - it's bandwith friendly
  • by Vexalith ( 684137 ) on Saturday August 30, 2003 @02:26PM (#6834020)
    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.
  • by TheRaven64 ( 641858 ) on Saturday August 30, 2003 @02:36PM (#6834089) Journal
    From the short term goals:

    Provide an option to force backingstore on all windows.
    This is the one I've been waiting for for a while. When RAM was $500 for 64K it made sense not to buffer windows, but now it is insane not to, forcing redraws which drain CPU and networt bandwidth (on remote displays).
    • by listen ( 20464 )
      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
  • ... for one of the w9x window's versions.

    Bad, bad :-)
  • by IntelliTubbie ( 29947 ) on Saturday August 30, 2003 @03:29PM (#6834392)
    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
    • Oh wait, we should call everything by its function then: Ford and Porsche must then be called eg. "NormalCar" and "FastCar". Is that what you intended?
    • Who would instinctively associate "Cairo" with "vector graphics for XFree86"? Why not name it something sensible, like "XVector" (if that's not already taken)?

      Well, exactly -- it's a cross-platform library not necessarily tied to X at all. That's why the name was changed *away* from "Xr".
    • X r -> Chi Rho -> Cairo

      Names are all about first impressions, anyway.

    • Jaguar, XP, Outlook, KaZaA, QuickTime, Quartz, DirectX, etc., there are a million proprietary apps or technologies with nondescriptive names. Besides, no end user should ever have to hear about Cairo, they should just see good-looking graphics.
    • by nathanh ( 1214 ) on Saturday August 30, 2003 @06:37PM (#6835281) Homepage
      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.

      Oh? So Excel just says "spreadsheet" to you? How about Quark Express? Or Oracle? Or Solaris? These names are only "obvious" because you have heard them before. There is nothing descriptive about them.

      • There's nothing descriptive about the name Oracle for database software? Do you know what the world oracle means?
        • So? The "ouvert" in "Xouvert" means "open" in French. So it roughly translate to "Open X". But that didn't stop all the ignorant Slashdotters who don't know French from complaining about the name either.
        • There's nothing descriptive about the name Oracle for database software? Do you know what the world oracle means?

          Yes, I know my Greek history just fine, as does everybody else who did 8th grade high school. How's things, Josh? Haven't seen you in ages.

    • Holy freaking crap! Did you just hold up "Internet Explorer" as an example of a GOOD product name? GASP!
    • maybe we should name it rename Xfree86 to windows, since X puts 'windows' on the screen. And when you hear window, don't you just automaticly think 'a rectangle on a computer monitor' rather than, say, a peice of transparent glass in a wall?

      Generic names like word, office, windows... so unimaginative...
  • by smallpaul ( 65919 ) <paul @ p r e s c o d . net> on Saturday August 30, 2003 @03:34PM (#6834409)

    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!

  • X r == "Cairo" (Score:5, Informative)

    by musselm ( 209468 ) on Saturday August 30, 2003 @04:32PM (#6834737)
    Pronounce the Greek letters.

    X == Chi

    r == Rho

    Okay
  • "We're on the road to Cairo" he was right but his timing was just a little off.
  • by mattr ( 78516 ) <mattr&telebody,com> on Sunday August 31, 2003 @02:32AM (#6836804) Homepage Journal
    That awesome icon resizing wheel widget you get in SGI desktops. I've wanted one for years and years, didn't get one with BeOS, and now finally I'm gonna get one!! Hooray!!

    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 [nekochan.net]

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...