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."

Comments

Open Source 3D

[bsharitt]

Now if we had some sort of open source 3D drivers to take advantage of this . Sure we have ATI and Nvidia binary drivers, but the uncertanties in the licensing pretty much keeps them from getting bundled in most distributions.

Oh well, at least it's a start to get some OS X-like eye candy.

Re:Open Source 3D

[Lussarn]

You are missing the point. The point is that a library or program (in the world of oss) should not need to depend on closed source software. If there are only binary 3d drivers the whole desktop becomes tainted by closed source software. Therefore we need good stable (They don't have to be as good as nvidia's offering though) open sorce drivers before OpenGL desktops in Free software can be a reality.

Remeber that while good binary drivers exists for Linux and FreeBSD other OSes are not that lucky, and free software is for everybody.

An new free sofware project should not need to talk to Nvidia and ATI (Who would not give a shit anyway) to get basic functionality going.

I like many others use binary GFX drivers today to drive my desktop but today it isn't needed except for some extra fluff like games.

Re:Open Source 3D

[Lussarn]

The complete x86 ISA is exposed in the documentation. Nvidia or ATI don't provide docs for there hardware, therefore it's close to impossible to write open source software for it. A big difference.

If the complete driver was in the firmware of the hardware and it exposed somekind of API (like x86 is) it would be ok, because then we could use the full hardware just as good with open or closed software.

Re:Open Source 3D

[TheRaven64]

The I2O specification was supposed to provide something like this. Your device driver would be in two parts - and OS-dependent component would ship with the OS, and a generic component would be included in the device firmware. Ideally, you would only need one driver for each device class (e.g. graphics card, sound card etc.) on each OS, because the complicated functionality would be in the firmware. The I2O specification was due in 1998, but the working group disbanded before completing it. I really don't understand why graphics manufacturers don't simply include an OpenGL driver in the firmware and ship a stub driver which translates X/GDI/DirectX calls into OpenGL and passes OpenGL calls through to the underlying firmware (possibly converting ARB_* into NV_* if extensions have been accepted by the ARB since the firmware was released). They could then release the OpenGL drivers as open source. If nVidia and ATi collaborated on the interface specification then they could even use the same drivers (driver initialises, driver checks for supported OpenGL version and extensions, driver loads emulated code paths for everything else), cutting their own driver development costs without having to expose any of the internal workings of their hardware. Of course, the consumer would also benefit, since they could swap graphics cards at will without having to worry about drivers.

I should note that this is exactly how most USB and FireWire devices do work, which is why you rarely need to install drivers for them (except on Windows).

Re:Open Source 3D

[bman08]

bullshit! fuck you and your zealot distro. I've been feeding my family gentoo for six months, fucker. Listen asshole, my car runs, pollution free, on gentoo and my home is heated same. As soon as it finishes compiling my rocket, Gentoo is going to take me to mars so you and your faggot ass free only distro can enjoy this miserable blue rock until the sun explodes douchebag. You'll be dead someday, but gentoo promises to finally fulfill the dream of eternal life, retard. Right now, while I'm typing this, gentoo is turning lead into gold...

shit. etc-update just overwrote all my config files. I'll be back in week or two, asshole. Then you'll be sorry.

Re:Open Source 3D

[Bloater]

> I really don't understand why graphics manufacturers don't simply include an OpenGL driver in the firmware

OpenGL may not be optimal for a hardware interface. You may want more light sources available from OpenGL than the card can do on its own. The interface to the hardware needs to support compositing of several renders to implement many more light sources than the hardware can do.

Furthermore, textures may use a sophisticated compression technique that must be done on the host CPU, the hardware will have to have registers programmed, and they may have a clever video RAM page mapping technique that gives them a large performance or temperature boost. they may not use IEEE floating point numbers in the same format as the host CPU and don't want to give away the format they use, or include extra silicon to decode them.

Lots of very good reasons for a business with interests in money rather than quality of service.

> If nVidia and ATi collaborated on the interface specification then they could even use the same drivers (driver initialises, driver checks for supported OpenGL version and extensions, driver loads emulated code paths for everything else), cutting their own driver development costs without having to expose any of the internal workings of their hardware.

They specifically want to avoid using the same drivers since driver performance is a *major* factor in performance in general, and they want to maintain any advantage they have in whatever areas they have. The first one to open up is the first one to lose the advantage.

The only solution is to design an open 3D video interface that supports the implementation of the very highest performance hardware, and write the drivers for it to the very highest quality. Then the first hardware manufacturer to port their core to the new interface (which could be a lot of work) might be the first to *gain* the advantage. Only then will you see any movement.

And I make no pretense that anything would happen even then.

Re:Open Source 3D

[Rutulian]

I'm surprised nobody has mentioned the Open Graphics Project in this thread. With any luck the card will be released just in time for Cairo to take advantage of it.

Re:Quartz is not vectorized

[Anonymous Coward]

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.

Open Source drivers for 3D

[anti-NAT]

Have a browse around Direct Rendering Open Source Project for details of video cards with open source 3D drivers.

Mono and cairo

[Goalie_Ca]

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

Re:Vector Graphics is a DUPE of the NeXT box...

[jbn-o]

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.

Re:Why give up bitmaps

[Anonymous Coward]

"Bitmaps should be enough for anybody" -- slashdot, 2005

Re:Cairo vs Longhorn's Avalon

[Osty]

Hmm...since Cairo is out and Avalon isn't, the Penguin now has a step up on Redmond in terms of graphics. Granted, Avalon includes some other spiffy 3d eye candy, but this is a first where the Linux GUI beats out the Windows one.

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.

Now - finally

[megajini]

This is a big step forward. Something I've waited for a long time. If it is possible to unite all those vector-graphics efforts in cairo more time can be spent on "stuff that matters".

Well, I always hoped X11 would do this step but they seem to enjoy doing politics instead of standards... On the other hand this approach has some unique advantages:

• Platform independence: runs on win32 and linux, awaiting os x...
• Can work without X11...especially interesting in not-so-full-powered-configurations (directly via OpenGL)
• Independent... People at freedesktop seem to do the trick very well (they didn't get between the lines -- yet)

Interesting is, that there are also java-bindings that work together with SWT which is an interesting step (mono is already on board -- see previous comments)

So hopefully the time of ugly graphics in platform-independent OpenSource-Software is finally over... (just watch OpenOffice -- uaaahh)

Well, a last wish: If Qt guys come aboard, this means KDE is in which on the other hand means that gnome and KDE join on the same backend... just dreaming...

Re:Why give up bitmaps

[Rolman]

A vector engine is not always a size-to-performance tradeoff.

1) Smaller sizes also give a performance boost on all types of data transfer, including expensive memory bandwidth
2) The rasterized vectors can still be cached, this reduces overhead during redrawing operations (something already being done with bitmaps)
3) Vectors give you resolution-independent displays that have better visual quality at negligible performance differences between resolutions (this is debatable, but I'm talking about full hardware-acceleration)
4) Cairo, Quartz and Avalon are ultimately designed for GPU acceleration, so ideally there won't be a performance hit on the CPU

Yes, you may still need a somewhat powerful PC to have full-access to all the benefits of these vector-based engines, but on less powerful equipment you can do something you can't do with bitmaps, and that's having a smoother and more graceful visual degradation using the same source material.

And, by the way, we'll still be using bitmaps for a long time, so you don't need to worry about GTK/X developers deprecating bitmap rendering and everything becoming vectors overnight, chances are that most users will need to have some form of programmable GPU before that happens. I guess that's why Avalon is getting delay after delay, and Apple can get away with it so much earlier because it has better control on its out-of-the-box hardware capabilities.

Gnome marketing

[Anonymous Coward]

> "GTK+ is now the first major toolkit to have added
> support for the Cairo 2D vector graphics library"

http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/ gn ustep/core/back/Source/cairo/

6 months later....

real news please?

[Anonymous Coward]

did someone actually read the _20 lines_ post made by Owen Taylor? He just commited gtk dependancy on cairo in the cvs repository, but that's all. Nothing's working on Cairo yet, not even font support.
I'm really not a fan of Windows, but they've been showing Avalon demos for a while now, so could you please at least wait for the Gtk team to reach a similar level before comparing their work to Microsoft's one, or Apple's(!)?
Now, if we are to speak about the possibilities offered by such technologies, I'd like to know your opinion on the topic guys.

Re:Quartz is not vectorized

[TheRaven64]

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.

Re:Vector Graphics is a DUPE of the NeXT box...

[TheRaven64]

I was never much of a PS hacker, but I understand that PS can do a lot more than graphics work.

PostScript is a Turing-Complete language. This actually makes it a bad choice for interactive graphics (i.e. not printing), because it is impossible to determine how long a piece of PS code will take to run in advance (or even if it will ever terminate - see the halting problem). Display PDF, used in Quartz, eliminates this problem, since PDF is a non-Turing-Complete subset of PS.

I own a NeXT cube system (currently in my attic, unused)

I don't suppose you're interested in selling it are you?

Mathematics

[lisaparratt]

I looked at Cairo because it purported to be fixed point, which would have made it ideal for many embedded consumer products (which rarely have FPUs), and enabled them to have pretty OS X style graphics.

I was most disappointed when I found out it was only the API that was fixed point, and most of the internals used floating point.

All we need now is mesa-standalone, and then XGL

[Nailer]

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

Re:also exists in X11--just turn it on

[DrWhizBang]

But you can get the same behavior under X11--turn on "backing store",

Except it's not quite that easy. Many applications do not use the backing store, mostly because the way the old backing store system works in X is not useful. Just as a test, turn on backingstore and drag one firefox window over another - you will see trails of the top window in the bottom one, no matter how fast your hardware is. This is because X is continually telling the lower window to redraw itself because the upper window has exposed a different portion of it.

The real solution to this problem is the Damage and Composite extensions. Damage allows the server to be more intelligent about what needs to be redrawn, listening for changes from clients. Composite allows a compositing manager to run which can keep all the windows contents available and redraw changed windows (via damage). The compositing manager is then using a backing store properly to make opaque move smooth.

A backing store is no good if you don't/can't use it for anything.