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

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

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

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