Slashdot Mirror
GTK+ to Use Cairo Vector Engine
Eugenia writes "GTK+ is now the first major toolkit to have added support for the Cairo 2D vector graphics library, which is designed to provide high-quality display and print output. GTK+ project leader Owen Taylor has commented on the X/GTK integration of Cairo. To put it in perspective, Cairo is similar to OSX's Quartz engine and Longhorn's Avalon (PPT analysis). The 3D hardware accelerated image compositing OpenGL part of Cairo will be provided by the Glitz library. Cairo is 'possible' to be part of Qt 4.x at a later date, according to Trolltech's Qt 4 technical preview document."
Quartz handles vectors just fine: it's all PDF underneath which handles vectors just fine. Cocoa provides a number of classes to create and draw vectors images (ie: NSBezierPath).
The Aqua interface elements (brushed metal, gel buttons, title bars, wtc) are bitmaps but that's not a limitation of quartz.
Of course everything you see on the screen is eventually rasterized before being displayed - but that's a requirement for any display thats out puting to a CRT, LCD, etc.
Have a browse around Direct Rendering Open Source Project for details of video cards with open source 3D drivers.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
Who said I was against the binary drivers. Just the licensing keeep them from getting distibuted by most distros.
Actually, mono is currently using cairo a lot. In fact, their new Windows.Forms is switching to a native implementation. System.Drawing uses cairo. This implies gtk# as well. :D
----
Go canucks, habs, and sens!
NeXTSTEP and OPENSTEP didn't use vector graphics for a lot of the most commonly seen graphics. The buttons on windows, the application icons, and the buttons in various programs were all bitmaps.
Some programs exploited Display Postscript more than others, but on the whole, I'd expect to see a lot more vector graphics use in a typical free software OS in the next few years than I saw with NeXTSTEP and OPENSTEP. I was never much of a PS hacker, but I understand that PS can do a lot more than graphics work.
I own a NeXT cube system (currently in my attic, unused) which I used to use regularly from NeXTSTEP 2.1 through NeXTSTEP 3.2.
Digital Citizen
I have a better idea: let's shed some light on the apocryphs used in the story. Seriously, I had hard time to hunt all of those definitions. Here's a handy list of links for anyone who is not up to date with "ppd," "glitz" and other bloody-edge jargon:
- GTK+ *
- Cairo *
- X *
- X/GTK *
- OSX *
- Quartz *
- Longhorn *
- Avalon *
- PPT *
- 3D *
- OpenGL *
- Glitz *
- Qt *
- Trolltech *
I hope it helps. (Your comment has too few characters per line (currently 20.2).)What's your definition of "out"? From the Cairo download page, "Cairo is still under active development. The API is rapidly approaching stability, but is not quite there yet, so there is not yet any official "release" of cairo." So, Cairo is not a 1.0 release, or even a .01 release. Dev snapshots are available, in an unstable form (the API is "approaching" stability). How does this differ from the available technology preview of Avalon (aside from the openness of the source, of course)?
Both are still in pre-release stages. Both are available in a publicly-consumable form even though they've not reached API stability yet. Declaring one or the other the "winner" is still premature.
Oh, yeah, and Avalon will be available on XP and 2k3, not just Longhorn.
... Assuming (even cheap) OpenGL hardware. Like you say, the description is smaller. It is the description you are sending the GPU, be it triangles or pixels. That is where your bottlneck lies. GPUs are designed to process these triangles and and they do it FAST.
The big advantage of vector graphics is not that it reduces size, but that it allows abstraction of pixel-wise screen geometry from GUI design. It allows designers to request a size in inches/centimeters (assuming monitor DPI is known by graphics system, which is generaly the case nowadays), and produce a perfectly scaled image for the screen. You go to 1600x1200 and you don't end up with unreadable dialogs, you end up with really crisp, readable dialogs (allowing user to reduce point size and have it remain readable, so you can still acheive a goal of fitting more stuff on the screen).
As a bonus, editing and particularly the 'print preview' features are then much more easily perfectly representative of what the result will be.
XML is like violence. If it doesn't solve the problem, use more.
A new X.org release comes out every 6 months.
Currently Linux desktops ALREADY HAVE vector based graphics.
The icons are vector for instance. Some simple games like Gnome's solitare version (the command is sol) is vector based. And this has been for a year now or so.
Gnome 2.8 I know has vector based graphics, because I use it everyday. I think that 2.6 had it a bit for applications. Icons and such have been vector based for a long time now.
So 50% of the new stuff that Longhorn promises, we already have. Longhorn isn't due out for another year or two, and it's going to take another year to two to start to get popular (based on history from Win98 and WinME and the time it took for WinXP to get popular over those).
So X.org and Freedesktop.org and the Gnome and KDE people have between 3 and 5 years to surpass Longhorn in Gui-sexy-ness. Then as far as looks go Linux should be pretty freaking capable.
X Windows has other benifits, too, that go far beyond what OS X or Windows will ever be able to do. And if Linux folks are able to extend on those current capabilities we will see new things that nobody would think much about.
Say your at your office. Your working on your word proccessor, but your building gets hit by electrical outage and your computer dies, but other computers are OK.
You haven't saved any of your information or work, but that's ok because your application is still running fine on a central X application server, so you go to a different workstation and open up your word proccessor and it's like nothing never happenned. Everything is just as you left it.
Say your setting up a presentation. You open up your OO.org and start a power-point-like presentation. You have to take off to go use the restroom and so your partner will finish up before the meeting starts. So you drag and drop your current applicaton to his desktop and you close your laptop and run off for a powder.
Stuff like that. That's the future potential power of X Windows network transparency.
You can already acheive it in a limited way with Sun's X terminals, and other software, but X.org hasn't yet gotten to that point. They are working on it now though.
I believe that the point the grandparent was trying to make was that Quartz buffers the rasterised image, not the vector source. This means that when you invoke something like Exposé which resizes a window without redrawing it you are scaling a bitmap, rather than a vector image. This is done for performance reasons (most graphics cards - even quite old ones - can handle scaling a bitmap quickly. Scaling and rendering vector images is more computationally expensive), although the trade-off is a slight loss in quality. I suspect that Apple will ship an updated backend to Quartz (as they did with Quartz Extreme) which buffers the vector data once they believe that enough of their install base has fast enough graphics cards to make it worthwhile.
I am TheRaven on Soylent News
Gtk+ uses SVG as the file/dataformat for vector graphics (think png for vector images). Cairo is a drawing API, used to actually render SVG (and other graphics) onto a surface. So they are complementary, rather than competitive.
Trust the Computer. The Computer is your friend.
gcj and GNU Classpath have been using cairo for well over a year now in order to implement the Java2D API.
People on the OS X side rave about the smooth opaque window moves and exposes under Aqua and try to portray it as if it were some advanced technology in OS X. But you can get the same behavior under X11--turn on "backing store", it's a server option. Lots of other systems had the same functionality, including AmigaOS (notable because it came out around the same time as the original MacOS).
The reason it isn't turned on by default is that that kind of buffering consumes a lot of memory. Furthermore, once you turn it on by default, software authors will not pay attention to redraw logic anymore and applications will become unusable without backing store.
X11 made the decision to leave it off by default, OS X made the decision to turn it on.
FLTK 2.0 http://fltk.org/ is able to draw using Cairo too, by defining "USE_CAIRO" variable (--enable-cairo).
Now if we had some sort of open source 3D drivers to take advantage of this
Tsss, you didn't even _try_ to look, now did you?
It's very simple;
GTK+ can now use Cairo.
Cairo uses Glitz.
Glitz uses Mesa for OpenGL.
Mesa uses DRI to interface with the hardware.
DRI drivers implement hardware acceleration under X, using DRM drivers.
DRM drivers are kernel drivers.
These layers are handled by at least 3 or 4 totally different organizations. Fortunately software engineers are known for their fabulous communication skills.
So, yes, the DRI drivers fully support 3D hardware, and there are quite a few available, with source.
well I didn't measure it but it's -well- under 1s here so I don't know what's the trouble about...and while I'm at it, cairo does -not- slow down your system, if you would have read the article you would know that it does exactly the opposite (given you have an opengl-graphics card which works) gee, why do I do this anyways?..
Mesa-standalone is a GL layer that doesn't run through X.
XGL is an X server where everything displayed on screen is accelerated.
Cairo makes toolkit graphics vector.
Then it's all done, we'll party with hookers and coke while some guy from Sun complains loadly about daniels removing xeyes from the so called 'modular' tree...
this adds server-side support
No, it doesn't. This is still client-side. The X server knows nothing about GTK+ or Cairo.
There are discussions about putting Cairo in X (via RENDER?), but this is not it.
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
So, is this or is this not what I've always been seeking in a GUI: total resolution independance? E.g. right now I can have my monitor at 800x600 and everything is *huge*, and I can have it at 1600x1200 and everything is *tiny*. Sure I can have Gnome/Gtk+ use larger icons and fonts. But not larger everything. Currently in Gtk+, one specifies the spacing between widgets in pixels. Will this change to vector units and allow the ability to smoothy scale everything up so I can use the full 1600x1200 but still have things readable? (And no, using a resolution in between those two extremes is not a solution. They are too few; none is quite right. Or it's an LCD where all but one is garbage.) And what will these vector units be?
Actually, I'm usually running at 1024x768. There's always those few programs that just don't fit on the screen... The ability to scale them down would be fantastic. Ideally I'd have an enormous monitor, but I don't.
If this is the direction this small step is headed in, then I applaud the Gtk+ team and look forward to the future with excitement.
Uh... we do have sufficient specs for the CPU, northbridge, southbridge, and RAM to implement free software drivers.
I don't remember having to download a proprietary kernel module to use my RAM.
Dumbass.
Yes, you missed something. This has very little to do with the size of your icons.
This will allow all gtk application to render everything using cairo, much like gdk was used in the past. This makes high quality vector (and bitmap) operations available in gtk, where they weren't before. And the plan is to later accelerate this through the graphic cards GPU or 3d engine to make all graphics fast and smooth.
And you can have some honkin' big icons if you want...
Schrodinger's cat is either dead or really pissed off...
Link here.
This isn't meant to be a troll or to point the blame on any one entity.
I think the current state of opengl on linux desktops in general can be a pain in the ass. Have an NVIDIA chip in my laptop so I'm pretty much forced to use NVIDIA's drivers if I want 3d acceleration. Now xorg has opengl drivers, but I must use the ones nvidia provides. Sometimes this means switching between interfaces just to get software to compile. To get kde's screen savers, I had to switch to xorg and then back to nvidia' opengl interface. Just to get matlab running, I had to switch to xorg opengl and keep it that way. Now I can't use nvidia's opengl drivers so I can't run any opengl screen savers as long as I plan on using matlab. X crashes if I even try to run glxgears.
So I don't know if it is because of xorg, nvidia, or mathworks, but opengl on my system is becoming a source of lots of problems. That said, will more opengl usage make things better because it will force others to fix the problems, or will I just end up with a system that requires different drivers for different apps and things won't run properly?
Cairo makes it trivial to scale all the drawing done by an application. The big step is that a toolkit such as GTK has to draw *everything* with Cairo. Then only a few small fixes to set the initial size of the windows and to back-transform the location of mouse clicks, you will be able to scale applications.
Yes it is quite possible that the resulting graphics will not be perfect. However at least it will be possible and easy to get to that point. This makes the hurdle of adjusting the graphics to look great much easier.
So the answer is that Cairo is a huge step in the direction you are talking about.
Not really, because OpenGL doesn't define much in the way of a language representation to talk in. It merely defines a model or world view and a set of operations on that model.
Imagine you are in a foreign country where you don't speak the language, and you want to buy an apple from a fruit merchant. Without a common word for "apple" it's going to be hard to get what you want. You can make your desire clear by pointing at the apple, but that's just because then you've reverted to a different kind of language, namely sign language. The problem here is not that you and the merchant don't share the same world view; you both know about fruit and apples. The problem is that you don't share a common representation of that world view.
So for your suggestion to work, OpenGL would first have to define a common language representation. Then the cards would have to include lots of very fast hardware to translate that representation into commands for the graphics hardware (basically it would mean putting the graphics drivers on the cards themselves).
It's certainly possible. It has been done before: this is how PostScript printers work. But it's a trade-off, since it adds considerable cost and reduces the rate of innovation. Maybe in a few years time.