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

[bsharitt]

Who said I was against the binary drivers. Just the licensing keeep them from getting distibuted by most distros.

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

[slashdot.org]

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.

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:Open Source 3D

[Heretik]

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.

Re:Open Source 3D

[Curtman]

Link here.

Re:Open Source 3D

[groomed]

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.

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

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

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

[Anonymous Coward]

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

Re:Why give up bitmaps

[jcupitt65]

You can still use bitmaps if you want. This is more about unifying the rendering API.

At the moment GTK uses gdk (essentially xlib) to paint widgets, and programs which want to display lines, shapes etc in their application window use GtkCanvas (declare a lot of objects for how you want your screen painted, it gets rendered clientside in tiles, then sent to the screen with XPutImage() or somesuch).

Cairo should give gtk a single API for drawing both widgets + application which will be (eventually!) hardware accelerated. It's the future.

Re:Why give up bitmaps

[Junta]

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.

Re:Why give up bitmaps

[doorbot.com]

I know vector based GUI may reduce file sizes but to the cost of performance?

One of the things I always assumed, and this may not have any basis in "computing reality" but it would seem something like an X server that rendered everything with vectors is the perfect solution for remote windows. You no longer have to send bitmaps, just a mathematical description of the screen, then you let the client decide how detailed they want to render the screen... maybe no antialiasing or shadows for a low-end box and full goodies for the high end machines. Since the server isn't rendering or loading bitmaps beforehand, wouldn't this make it faster too, as well as use less bandwidth?

Think of a Gnome session remotely... SVG icons, etc, and vector-based windows... it'd be extremely low bandwidth and processing on the server, wouldn't it?

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.

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.

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.

Jargon explanation

[Anonymous Coward]

Trolltech? No thanks. Not until they shed some light on their dealings with Canopy.

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:

1. GTK+ *
2. Cairo *
3. X *
4. X/GTK *
5. OSX *
6. Quartz *
7. Longhorn *
8. Avalon *
9. PPT *
10. 3D *
11. OpenGL *
12. Glitz *
13. Qt *
14. Trolltech *

I hope it helps. (Your comment has too few characters per line (currently 20.2).)

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.

Vector are Faster

[VeryApt]

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

a question...

[dermusikman]

it looks like a nice feature, which will be good, for both gtk and qt. looking at the Cairo site, it looks to serve a purpose similar to SVG, which used to be the big buzzword.
can anyone tell us, is Cairo in direct competition with SVG applications? i notice cairo advertises "high quality...printing outputs" - is that its focus while SVG deals more with graphic displays and the web?

Re:a question...

[JanneM]

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.

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

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

also exists in X11--just turn it on

[jeif1k]

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.

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.

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.

FLTK and Cairo

[Anonymous Coward]

FLTK 2.0 http://fltk.org/ is able to draw using Cairo too, by defining "USE_CAIRO" variable (--enable-cairo).

Re:Bloat

[j.blechert]

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

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:Quartz is not vectorized

[Ignominious Cow Herd]

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.

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

Scaling?

[fossa]

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.

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:I missed somthing...

[DrWhizBang]

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

OpenGL on linux

[Stevyn]

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?

Re:Scaling? yes

[spitzak]

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.

Re:I missed somthing...

[DrWhizBang]

It already works.

Yes, it does if you can figure out how to build it yourself. When I say future, I mean when this is all released and distributers pick it up so that I can rpm it (or apt, as the case may be.) I have spent the past several days trying to build the freedesktop x server with the opengl goodies, and I haven't had much luck.

It's Pango

[m50d]

Pango is what causes all of the problems with GTK apps being slow. It renders text very nicely - rich text support is all there, i18n support is right in, it can render antialiased bold multibyte kanji as easily as anything else. But the price of that is that it's very slow. I think Qt does some ascii optimisation so you only have the i18n stuff slowing you down if you need it.