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

[Anonymous Coward]

this is why I use gentoo and not some freakish zealot "debian totally/free/only"

You are aware that Debian provides non-free software, right ? is it the fact that they are put in a separate place than free software that bothers you ? What about my choice to not use them ? It's quite nice to have an easy way to know if a given package is free or not.

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.

Re:Open Source 3D

[FauxPasIII]

> nvidia implements a standard driver [which X can talk to and works in OpenGL].
> They follow standards. The fact that the source is closed shouldn't bother people.

Speaking only for myself, the main difference is that the nVidia driver has to be linked with the kernel.
This may seem like an unbelievably eggheaded reason to dislike it, but I'll try to explain. When nvidia's
giant binary blob is linked with my kernel, all bets are off as to debugging any problems that might arise. If
the driver crashes, it takes the kernel down with it. The nvidia module lives in the same place as my hard drive and
filesystem drivers, so it could presumably cause data loss. All manner of undesirable consequences.

I work a lot with wireless cards; here's another example. Atheros has generously assisted with the creation
of a very high-quality mostly-open driver for their cards in Linux. I say mostly because of a sizable
binary HAL that is linked in, to prevent free reprogramming of the radio (FCC regs, blah blah).

On the other hand, you have the Intersil prism 54g. It has a fully open-source driver, also high-quality
and functional. They comply with non-reprogrammability requirements by having a binary-only firmware
that is loaded at module init time. Now, there's still closed, untouchable code in there... but it runs on the card's chipset,
not on my CPU where my kernel and other things live. And, since the driver is fully open, it's included with
the mainstream kernel, so much more convenient and more likely to work with any of the weird kernels I cobble together.
And a bug in that card's firmware is much less likely to cause my whole system to come crashing down, although
it's certainly possible.

(All bitching aside, much thanks to nVidia, ATI, Atheros, Intersil, and all the other hardware companies out there
who throw Linux a bone every now and then.)

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

[ABeowulfCluster]

It's 1992 all over again.

Why give up bitmaps

[smartsaga]

when all the wanto-lick eye candy comes in bitmaps for OS X?

I know vector based GUI may reduce file sizes but to the cost of performance? I mean bitmap = load and display, vector = load and process then display not to mention that windows can be resized, be transparent, transform (maybe) and all of this needs CPU power. This is not counting that if it is done right then we all want a piece of it.

The tendency nowadays is to make files smaller and smaller which requires more and more processing power. When will we stick to something that has good speed and then just make it look good? Of course generally speaking. It's like always buying the latest processor chip, the biggest hard drive and the super thin and large monitor. There is always a faster one, bigger one, smaller... Whe do we stop to make something good out of what we have and then move to the next step??

No I didn't RTFA
No I will not fix your super computer
No I don't care about drivers being bundled with linux or not
Your bitmap are belong to us... got it?

Man I can't sleep!!!!
Have a good one. Have a good one.

Re:Why give up bitmaps

[grumbel]

The reason to go for vector graphics is not to get more/less speed or disc usage for graphics, but graphics that are independend of the displays resolution. Today if you switch from a 17" LCD with 1024x768 to a 17" LCD with 1600x1200 you will get tiny fonts, tiny GUI elements and a whole lot of nasty side-effects. Todays GUIs provide a bit of help to get the fontsize up again, but thats mostly it, icons often stay tiny, stuff like some themed music players often even get unusable on to large resolutions.

With a fully vectorized GUI if you make the same switch you would have exactly no sideeffects from a higher resolution, it simply would look sharper, no disortion, shrinking, etc. of GUI elements or fonts. The OS would take the DPI of the monitor and just adopt the rendering to it.

The issue gets even more dramatic if you have a 1600:1200 display with a ration of 16:9 or the like (aka non-quadratic pixels). With todays pixel based interfaces it simply would look awfully streched, with vector based GUI on the other side it would simply work, no streching since the GUI can adopt automatically to whatever you throw at it.

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

Re:Gnome marketing

[Anonymous Coward]

Calling GNUStep a "major toolkit" is a bit of a stretch considering that it only runs like 12 applicaitons.

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:No shit, sherlock

[ahillen]

Canopy is also a major stakeholder in the SCO group
[...]
Do a little research and you'll find that Trolltech is going to answer any questions you may have regarding their connection to the Canopy Group, their board of directors, and the connections between same with a bland "no comment."


Well, Trolltech is not really secretive about their investors. Do a little research and you'll find this site. Out of the 9 parties and groups listed there, Canopy is number 7 and SCO number 9, with a combined share of about 5%. Now if you want to call that major... To me it would seem that Trolltech is majorly owned by it's employes.

With a little more research you even might find for axample this interview with the Trolltech President, where he talks about the Canopy investment:
-----
PF: Somebody mentioned that the Canopy Group & SCO owns some parts of Trolltech.

ME: Sorry, we don't have any influence on them.

PF: Do they have any influence on you?

ME: Not really. They have a 5.7% stake in Trolltech. Historically Canopy became an investor because we cooperated with Caldera. As you might know we made and delivered the graphic install, which was the first graphical install for Linux, for Caldera Linux. The Canopy Group as the main investor in Caldera was so impressed by the work we had done that they wanted to invest in Trolltech, to make sure that Trolltech could become a solid company that could continue to deliver software to the Linux community. It's pretty ironic to see what has happened historically after that of course. But they don't have any influence on Trolltech. Trolltech is employee-owned, 65% of the shares are owned by the employees and we control the business so they have a small stake in us and that is it.

PF: You haven't talk about this complicated with SCO on Linux

EE: The patent issue or the corporate issue?

PF: The thing that SCO is asking and preparing to sue everybody about some code they pretend they own in Linux.

EE: I can tell you that we do not support these actions from SCO. Trolltech in many ways is dependent on the success of Linux. We think Linux is a Good Thing. We support Linux in many ways. On the other hand everybody has the right to bring his case to court. In this case it is very strange that they have not pinpointed exactly where in the code there is a problem and we feel that if they really had a problem with this, they could have acted very differently in presenting this to the community. So again we do not support these actions.
------------------

Seems to be a quite complicated way to say 'no comment'.

Re:Cairo vs Longhorn's Avalon

[Anonymous Coward]

For fuck's sake get your fucking pyramid scheme spam out of your fucking post. That belongs in your sig, so those of us who are not interested in your spam can turn it off and not have to read your spam.

Re:Cairo vs Longhorn's Avalon

[sirReal.83.]

Oh, yeah, and Avalon will be available on XP and 2k3, not just Longhorn.

So will Cairo. Remember that GTK+ is cross-platform. =D

A little knowledge is a dangerous thing

[Anonymous Coward]

The apparent intellectual conundrum of the halting problem has absolutely nothing to do with the application of pdf and postscript to the domains you describe. Hey, maybe they should try a reduction algorithm to reduce the image sizes???

Re:A little knowledge is a dangerous thing

[pohl]

I respectfully disagree. A high-performance rendering library depends heavily on being able to reason out the computational cost of operations. If these operations are open-ended expressions in the PS language, that cost cannot be known by the engine. If the operations are just the low-level primitives provided by the PS/PDF imaging model, then the cost can be known. This has everything to do with eliminating the unknown imposed by the use of the PS language.

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.