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

Quartz is not vectorized

[Saven Marek]

One thing should be noted, is, OSX aqua quartz isn't vector based it is still bitmapped, as many people are under the apprehension that it is all vector when it is just good bitmaps.

it is live compositing like postscript on screen but it is not yet vector.

the best mac community on the web

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.

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

[jeif1k]

Note that Gtk+ has been using vectorized themes and GUI elements already (i.e., elements could stored and scaled SVG); it simply rendered them client-side. This adds server-side support.

The situation with OS X appears to be reversed: it inherited vector drawing in the server, but mostly seemed to be using bitmaps for theming.

Re:Quartz is not vectorized

[Anonymous Coward]

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.

Oh, that is so dead-born an idea.. It'll never work on a modern system like Vectrex :)

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

[Qa1]

Quartz handles vectors just fine: it's all PDF underneath which handles vectors just fine.

You meant PostScript, not PDF. Apart from that, you are correct.

Re:Quartz is not vectorized

[The Ego]

it's all PDF underneath which handles vectors just fine

You are correct in stating that Quartz handles vectors just fine. Quartz (split into the Quart 2D layer and the Quartz Compositor) is primarily a vector API. As all good vector APIs (e.g. SVG, Cairo), it can also deal with bitmap graphics, hence the confusion in some minds.

Yet PDF is _not_ underneath. Quartz uses the same graphics model first introduced in Postscript, then re-used in PDF/Java 2D/GDI+/Quartz/(maybe others ?) . Still, no PDF is generated/rendered in a call to NSBezierPath while rendering on screen. PDF can be generated if the graphic context requires it (typically when printing).

See this post, other posts by mpaque (Mike Paquette, one of the main developers of Quartz and previously of Next's graphics) and check the dev documentation from Apple.

The first-poster was quite misleading or is not quite grasping the layering in the OS X graphics subsystem. Quartz can handle vectors perfectly fine, as you noted. Yet the OP was also correct in stating that _Aqua_ is mostly bitmap-based (today). Once GPU acceleration is available for the Quartz layer (with Quartz 2D Extreme, see my other post in this discussion), we are likely to see more UI elements rendered from vector descriptions (at least rendered once per size and cached, I don't see the interest in re-rendering the same bits over and over).

Re:Quartz is not vectorized

[Wesley Felter]

Er, not really. NeXTSTEP/OPENSTEP was based on PostScript, but Apple ripped all that out when they built Quartz. Quartz Compositor is all bitmaps, while Quartz 2D is based on the PS/PDF imaging model, but when you're rendering to the screen it doesn't generate PS code or a PDF file.

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

[tomstdenis]

How did this get +5?

People who don't bundle nvidia/ati drivers [or at least make them possible to add] are just as bad as the "closed source" peeps in the first place.

Isn't it about my choice not yours? ... and this is why I use gentoo and not some freakish zealot "debian totally/free/only" ...

Yeah, it would be cool if nvidia released the specs and source. But no, I don't care about loading a "binary" in Gentoo. All I want is gfx driver that properly supports my card.

And well... so far they've worked perfect in 32 and 64 bit mode [nvidias drivers].

I mean you might as well say "it would be nice if we had open source cpus, ok I'll hold out until one exists.". I mean running debian on an AMD or Intel cpu is just hypocritical if it must be 100% pure free.

Hell for that matter, let's see the northbridge/southbridge specs and the ram!!! oh and let's see the exact inner workings of those hard disks!!! .... ... +5? Punk...

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

[tomstdenis]

No, distro licensing keeps the binaries away.

From the nvidia license...

2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files). .... So go fuck yourself and your zealot distro already. ;-)

Tom

Re:Open Source 3D

[bsharitt]

So go fuck yourself and your zealot distro already. ;-)

Calm down. Breath in. Breath out.

Either that or go back under your bridge.

Re:Open Source 3D

[X0563511]

How about open source BIOS? I was under the impression that those were closed.

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

[tomstdenis]

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

Why? ... modern x86 cpus convert the x86 ISA to a risc ISA. It's therefore a "program". Last I checked Intel doesn't tell people how the cpus work exactly.

So by your logic OSS shouldn't be written for "closed source" cpus like the x86 series.

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.

There is choice. if nvidia stopped making the drivers they would lose their significant linux advantage. I mean I don't buy ATI cards for this VERY reason. Even though they may [or may not] be technologically better their drivers suck so I don't buy them.

Similarly even though cpu designs are not open I CHOOSE amd processors over Intel because they're more efficient.

Not that I disagree with the sentiment though. I think the scene WOULD be better off with opened nvidia drivers. I just don't share the belief that it's crucial.

Tom

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

[binford2k]

So go fuck yourself and your zealot distro already. ;-)

Typical Gentoo user.

(Yes, I know that's hypocritical of me, since I use Gentoo myself, but damn, people. Believe it or not, Gentoo is *NOT* the solution to all of the world's problems!)

Re:Open Source 3D

[imroy]

I've been using the Open Source radeon driver for about a year with my Radeon 9200 Pro. There appeared to be some stability problems at first and I tried to stay away from OpenGL programs to avoid crashing. But it seems to have cleared up since about the middle of last year. I'm not a gamer, so the performance of this 2-year-old card is perfectly fine.

I was never able to get the ATI binary driver to work on my Debian system. That's one of the main reasons I don't like binary drivers: I don't use a "popular" Linux distro. So I either f**k around with Alien and their broken RPM's, or I just use the Open Source driver included in the Debian-supplied package.

Re:Open Source 3D

[bsharitt]

Unfortunatly the 9200 series was the last card supported by the DRI drivers.

Re:Open Source 3D

[Anonymous Coward]

The fact that it is possible to create a complete system which works exactly like an x86 CPU and run your software (Bochs, Plex86, VMWare, VirtualPC etc.) shows that you're a complete fucking looney. Of course anyone who's read Slashdot long enough knows that you're a complete fucking looney already.

Re:Open Source 3D

[PygmySurfer]

Isn't that pretty much how it works now? If you write to X11, the driver interprets it. If you write to OpenGL, it gets interpreted by the driver.

Re:Open Source 3D

[imroy]

Really? That's good. I only got it because my younger brother was upgrading his machine. He's a gamer. I see that the Mac Mini also has a Radeon 9200 in it, so that bodes well for running Linux or one of the BSD's on that little beauty.

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

[Anonymous Coward]

You may be right about what you're saying, but let me remind you that the troll word doesn't refer to any tolkien character, but to the more earthly fishermen.

Re:Open Source 3D

[Anonymous Coward]

Which is why there is OpenGraphics. It's been mentioned here before, a video card that does enough to support Cairo, and is fully documented so that we can have open source drivers and an out-of-the-box working accelerated desktop without any hassle.

Lourens

Re:Open Source 3D

[wertarbyte]

So I either f**k around with Alien and their broken RPM's

No, you don't. Others have done that for you already: http://www.stanchina.net/~flavio/debian/fglrx-inst aller.html

Re:Open Source 3D

[Lussarn]

Yes you are correct, except there are no (or only a few) drivers for OpenGL. The best driver today for Linux, possibly the only really good driver are nvidias and thats only x86 and it's not OSS. OSS is not about vendor/architecture lockin so that driver doesn't count except for some short time pleasure like doom 3.

If there where no open drivers for things like video TIVO may never have happened (or they would have used windows) because they couldn't get a licencing deal with nvidia. Even if they could licence the software they probably would have to go x86 which may not be the best route for all appliances that need good video. The more closed source requirements we put on developers and vendors the harder it is to enter a market using Linux or other OSS as base.

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

[tomstdenis]

Um a K8 can smoke a PM in power/processing any time.

My K8 at 2.2Ghz hits a max of 45C, can you say the same about a PM? Can a PM at full load do as much as a K8?

And my point was even though the working specs of the cpu are largely not disclosed I can still CHOOSE which product I want. I'm not locked into Intel or AMD [hell I could go VIA, PPC, ARM, etc... if I wanted].

Similarly if I really want an open card I could buy an oldschool s3 or something. If I want a cheap, robust card that gives decent performance I'll buy a whopping 100$ 5200FX and "put up with" free drivers that work [very well] on my x86_64.

Tom

Re:Open Source 3D

[tomstdenis]

You missed my point.

Them bitching about closed source nvidia drivers is like me bitching about closed source Pentium cpus.

You say there is choice amongst cpus ... I say there is choice amongst GFX cards...

Almost like WE'RE SAYING THE SAME FUCKING THING!!!!

Tom

Re:Open Source 3D

[Bralkein]

Yeah, it's just a shame ATI and NVIDIA feel such a need to keep their card specs secret from everybody... there are some people working on these things though. One project I have been keeping an eye on for a little while is this one, they seem to be making some progress on R300 drivers (R300 cards are the ones after 9200, I think). Check out their current status:

# 01/31/05

* Tagged a new snapshot "jump_and_click" of r300_driver. Quake3 demo should now be playable, albeit with some artifacts.

Now I don't want to hype this up too much, I guess they probably still have a lot of work to do, but I think a playable Quake 3 is fairly promising... okay, it's taken a little while to get to this stage from the release of the R300, but it still goes to show that it can be done!

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

[TeknoHog]

I've always wondered why we need special drivers, when OpenGL is supposed to be a standard API. Can't we just talk OpenGL to the graphics card?

Re:Open Source 3D

[dinivin]

There's currently a project underway to develop an opensource r300 driver. It's making decent progress considering that ATI refuses to give the specs to the developers (though they have given the specs to Xi Graphics).

Dinivin

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

[defile]

Sure. But the graphics cards cost a whole lot more money.

Re:Open Source 3D

[Anonymous Coward]

OpenGL is a software standard.

OpenGL specifies how a programmer tells the computer "I want to draw a bunch of triangles", or "I want to use this RGB24 texture" but it doesn't specify how that's implemented. It doesn't even specify that you _have_ hardware, there are some fairly quick (not for gaming, but for other purposes) OpenGL software implementations.

This is a GOOD thing because hardware changes really fast. In 1998 there's no way anyone could have sold you a card with programmable rendering pipeline for less than a house, but in 2003 you can buy a desktop PC that has this feature built onto the motherboard. So your new PC comes with drivers that implement the same OpenGL rendering primitives, but now they're using programmable hardware instead of doing most of the maths in software as happened with a 3Dfx Voodoo. If it weren't so much faster you'd never know :)

Re:Open Source 3D

[Anonymous Coward]

It doesn't seem to be close enough to impossible to prevent the likelihood that there will be Free Software drivers for the R3xx and R4xx (ie current ATI high-end cards) in the next six to twelve months.

Read the DRI mailing list for details (look for topics with [r300] at the front)

They have Quake 3 rendering (not correctly, but well enough that it's playable). I don't doubt that initially the drivers will be slower than ATI's, and less complete but that would only worry me if I saw an endless series of such quantum leaps in hardware in front of us (the previously supported R2xx is basically a fixed-function design, the R300+ are programmable only).

The game studios don't seem to have any immediate requests for anything other than "more of the same please", and as we all know, "more of the same" often doesn't even need a new driver, because it's the same hardware with more RAM, a wider bus, and a faster clockspeed. So we _can_ catch up unless there's something spectacular coming down the pipeline in the next year or so.

Re:Open Source 3D

[cbrocious]

Because a _lot_ of the work is done in the driver.

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

[cortana]

$ apt-cache policy nvidia-glx
nvidia-glx:
Installed: 1.0.6629+1-1
Candidate: 1.0.6629+1-1
Version Table:
*** 1.0.6629+1-1 0
600 http://ftp.uk.debian.org sid/non-free Packages
100 /var/lib/dpkg/status

You suck!

Re:Open Source 3D

[Curtman]

Sweeet, I guess I can upgrade my Radeon 7200 now. :)

Re:Open Source 3D

[Curtman]

Link here.

Re:Open Source 3D

[drinkypoo]

While I agree with you in principle I differ on specifics. If the graphics card manufacturers were not supporting open standards then you would be entirely correct. However, both nVidia and ATI provide OpenGL, and as far as I can tell they provide a fairly recent version of it at a very high level of compatibility. I have always valued OpenGL acceleration, even before it was particularly useful on the PC. The first card I could afford with good OpenGL compliance was a FireGL 1000 Pro card (Parhelia 2) which IIRC was a little slower than a 3dfx Voodoo 2, but not much. It was certainly an excellent card for glquake and more than adequate for Lightwave 3D.

The point I'm making here is that all this stuff is OpenGL and none of my video cards have ever cost me more than $160. (That was my latest, a Sapphire Radeon 9700 XT 256MB.) Some of them have pretty sketchy Linux support, and probably all of them would require binary drivers to work on Linux, but they all support OpenGL so the moment a useful card with open source drivers shows up in my hands (which will be shortly after one is available for $100 or less, shipped or locally) I'll be able to get the same results, perhaps at a lower speed, from a card with open source drivers. There's no lock-in involved. Our collective stubborn insistence on OpenGL over the years (thanks, Carmack!) as geeks has born the desired fruit. Everyone should remember this when it comes time to support open or closed APIs, and their patent status.

Re:Open Source 3D

[drinkypoo]

While you almost certainly know a whole lot more about this than I do, I would think that OpenGL with control over pixel shaders will let you do just about anything you really need. I would prefer a completely open solution but I am willing to pay as long as people support OpenGL. I don't see any reason that a modern computer couldn't do every single thing it needs to do either through VESA (for simple purposes like generating consoles) or OpenGL. Since basically every accelerated video card available for a PC today does both VESA and OpenGL, I don't really have a problem... Except where I really feel that the open source community could do a better job writing the drivers. You know who you are, ATI.

Re:Open Source 3D

[Bloater]

> While you almost certainly know a whole lot more about this than I do, I would think that OpenGL with control over pixel shaders will let you do just about anything you really need.

Yes, but not necessarily with good performance. The data may need to be in early. Then you've got all the decisions on how early, how do you decide, is the decision on where it is stored in video RAM made on the board (could be costly), or in the driver. Should probably be in the driver. That means you've got details of the hardware implementation in the driver. Any other way and you've got costly, slow, hot-running hardware. You cannot simply slap a mid-high level graphics API in the hardware and expect to create a domestic product.

OpenGL is only fairly low level when considered as running on a single CPU system (or SMP). As soon as you've got a NUMA system, OpenGL abstracts away a whole lot of communication details and buffering issues.

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

[TelJanin]

You don't have to use Gentoo to not use an uptight, pseudo-religious distro.

Re:Open Source 3D

[Anonymous Coward]

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

Eh? I've used a bunch of funny USB storage devices and mice, and never had to install a single new USB driver. The "drivers" one has to install for printers are print drivers, i.e. they implement most of the control logic that isn't part of any USB spec. On linux, what is supported is just typically precompied.

Re:Open Source 3D

[Mornelithe]

How do you know he's a Gentoo user?

SuSE includes the nVidia binary drivers as well, and gives people the option to install them during the install, I believe. Gentoo is not the only distribution that doesn't have moral problems with the nVidia proprietary drivers.

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

[ticktockticktock]

Actually, no version of SuSE, that I know of, has ever included nvidia's binary drivers. It seems as if they do merely because they offer the ability to fetch them and install them for you in their Yast Online Update utility. That utility just grabs the fetchnvidia.sh script, verifies its signature, and then runs it to fetch the nvidia driver and install it for you.

Re:Open Source 3D

[be-fan]

The set of operations offered by OpenGL is very different from the set of operations offered by the hardware. The drivers have to do an enormous amount of work to convert OpenGL operations into commands the hardware understands. Modern OpenGL drivers include an entire compiler for the GL shading language! Look at the size of an OpenGL driver sometime --- they are several megs of code and data.

Re:Open Source 3D

[The Vulture]

If there where no open drivers for things like video TIVO may never have happened (or they would have used windows) because they couldn't get a licencing deal with nvidia. Even if they could licence the software they probably would have to go x86 which may not be the best route for all appliances that need good video.
Uhh, no. Tivo would most certainly have used whatever video chip they wanted, open source drivers or not.

I'm a developer of embedded devices (having worked on over a half-dozen different chips), and have been through this first-hand. The companies that I have worked for would make an agreement to buy X units, enter a licensing agreement, sign an NDA, and then get full datasheets, reference boards, and sometimes even full schematics. The reference boards also usually come with full source code. So, pretty much any company that rebrands ATi or nVidia designs has full source code to the driver (so that they can make necessary changes to accomodate their board design).

It's actually fairly important that source code come with the reference design when you get it, since most embedded designs do not use x86 processors (they're too power hungry and run too hot).

-- Joe

Re:Open Source 3D

[Mornelithe]

Well, okay, I suppose I was a bit mistaken (I've never used SuSE myself, only heard this from other people), but the concept is the same. You can fetch and install the proprietary driver from their default update environment. This is no different from how Gentoo does things. The driver isn't strictly necessary, so there's no reason to install it by default for everyone.

The fact remains that it is possible for a distribution to make the closed-source drivers available easily. The fact that Debian (?) or whoever doesn't provide those packages by default (without adding extra repositories?) is a reflection of Debian's strict ethical policy, not on whether or not the drivers can be provided.

And it's entirely possible that a SuSE user could claim that Debian is a "zealot distro" for refusing to distribute a program that they are quite within their rights to redistribute. Instead, the original poster decided to interpret his parent as a Gentoo user claiming that Gentoo is the solution to every problem, which I think is quite a stretch, considering that the post doesn't mention Gentoo, or anything besides licensing for that matter. But it's all right; he's a self-loathing Gentoo user, so he's allowed to perpetuate the stereotype that Gentoo users are all ranting idiots who slander other distributions for no reason other than their own ignorance.

Hurray..

[Anonymous Coward]

The race begins.. do we see distro's with this first or Longhorn??

Inquiring minds want to know.

Re:Hurray..

[Anonymous Coward]

Not much of a race - this is real, and Lockhorn is still vaporware.

Re:Hurray..

[AndroidCat]

Cairo or Longhorn, same thing. (I wish people would (a) stop overloading "code names", (b) telling everyone what their new thingy is called now until they figure out the real name.)

Re:Hurray..

[Anonymous Coward]

Err... that's not the cairo being talked about, though that's pretty damn funny!

Re:Hurray..

[AndroidCat]

Yup. As I said, I wish people would stop overloading names. Firebird the DB or the browser? Pick some random two word name like Big Puppy and stick to it. (I have a program for that, and that's what it just generated. Hmm, it could have rolled Fire Bird so a little checking for previous use is still required.)

Off to work on my Disciple Cheese project...

Re:Hurray..

[Anonymous Coward]

(I wish people would (a) stop overloading "code names", (b) telling everyone what their new thingy is called now until they figure out the real name.)

Welcome to the wonderful world of Marketing.

Re:Hurray..

[Anonymous Coward]

My word you're retarded.

The MSDN have had access to preliminary builds of Longhorn for ages now.

Conversely, just try and build Cairo and the required libs from the link in the article. Besides the fact that there haven't been any proper releases yet (like Longhorn), the current snapshots won't build. Quoth the website:

"CAUTION: The cairo API is not yet stable, so any users of these
snapshots should be prepared for incompatible changes between
snapshots, (even with only an increment of the minor version number).

We don't make gratuitous changes, but we're still learning so the API
will change."

If anything, the opposite of what you said is closer to the truth.

Cairo? Windows NT 4.0 Beta?

[TWX]

hmmm.. I thought the joke was

Windows 95 = Apple 1994

rather than anything having to do with Microsoft's beta releases of Windows NT 4.0 back in 1995/1996...

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

[ABeowulfCluster]

It's 1992 all over again.

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: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:Vector Graphics is a DUPE of the NeXT box...

[MemoryDragon]

No wonder, NeXTStep had to run on 68000 based machines doing everything as vector graphics would have dragged the performance down to a slideshow. I recently saw the Steve Jobs demo of the next cube, and I was amazed how much performance they could get out of that configuration (which back then was years ahead of everything PC wise, but compared to nowadays a better Amiga)

Cairo vs Longhorn's Avalon

[PxM]

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.

--
Free iPod? Try a free Mac Mini
Wired article as proof

Re:Cairo vs Longhorn's Avalon

[Anonymous Coward]

There has been Linux 3D GUIs for many years, remember Cairo's precursor Berlin?

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.

Re:Cairo vs Longhorn's Avalon

[Anonymous Coward]

Remember anyone who ran it? Since they only had 2 applications, it doesn't really matter.

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

[Anonymous Coward]

Actually, to be pedantic, it's at release 0.3! Just because they refer to them as "development snapshots" doesn't mean they're not releases:

Here's the source link, too:
http://cairographics.org/snapshots/cairo-0.3 .0.tar .gz

Re:Cairo vs Longhorn's Avalon

[Anonymous Coward]

Actually, it's more like 0.3x ;-) Next time you try to post intelligently, try reading the source first!

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

Re:Cairo vs Longhorn's Avalon

[oliverthered]

Cool, I'm just working on directx under wine now, It would be nice to get Avalon working on Linux.

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.

Re:Open Source drivers for 3D

[Anonymous Coward]

support for opengl under linux is half-assed at best. that's why I'm moving all my shit to OSX

Re:Open Source drivers for 3D

[sp0rk173]

From the Site:

nVidia
Status

nVidia provides their own closed source, binary drivers and therefore nVidia cards are not supported by DRI.
Unless of course you run FreeBSD on AMD64...like me...then you're SOL. Bullshit.

Correction

[Anonymous Coward]

Windows 95 = Apple 1984

Re:Correction

[TWX]

"Windows 95 = Apple 1984"

yeah, I've had too much to drink tonight. I actually enjoyed watching the Schwarzenegger/Belushi movie Red Heat...

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:Mono and cairo

[jeif1k]

Gtk# is a binding of Gtk+ to C#; it uses whatever drawing mechanism the underlying Gtk+ implementation uses, which may well be different from Windows.Forms. However, with this announcement, it looks like everything is going to be using Cairo consistently, which is nice.

Re:Mono and cairo

[Anonymous Coward]

GTK# is not rendered at all by System.Drawing !
GTK# is only a C# binding on top of the classical gtk libs, so gtk# application are rendered like any pure-gtk app.

Re:Mono and cairo

[Anonymous Coward]

Yeah, Managed.Windows.Forms is implemented on top of System.Drawing though, which in turn relies on Cairo (with or without the Glitz OpenGL backend).

Bloat

[Anonymous Coward]

More Bloat stuffed into GTK+ and GNOME. Makes things depend on even more technology and makes stuff become slower and bloddier. What are we up too ? Competition to Microsoft or 'getting a usable Desktop' ? I doubt the majority of people ever give rats arse for Cairo or not, they don't even know what the hell it does. All they want is a fast cool Desktop and a fast applications and execution speed. Opening GNOME Terminal these days takes 10 seconds and more because of the overkill junk tied to all of it.

Re:Bloat

[Anonymous Coward]

If your computer takes 10 seconds to open a GNOME terminal it's obviously to slow for gnome. Just use xterm and use fluxbox as windowmanager.

GNOME are for todays computers, just like Windows XP or OS X.

Re:Bloat

[Anonymous Coward]

So you say an XP2600 with 512 mb RAM is not actual enough ?

Re:Bloat

[Anonymous Coward]

hdparm -d1 /dev/hda

Re:Bloat

[Anonymous Coward]

RTFM of the 2.6.x Kernel series, DMA is activated by default. But that's not the problem DMA IS activated. So stop pulling out garbage like my system is too slow or too less ram or other crap like crappy harddisk. A lot of people complain about GTK+ being slow ass system and GNOME loadingtimes suck balls.

Re:Bloat

[anagama]

It's been a while, I could use a whole article devoted to generating a KDE v Gnome flamewar. It's the weekend - entertain me!

Re:Bloat

[Anonymous Coward]

I could use a whole article devoted to generating a KDE v Gnome flamewar.

Well, okay then: the

But somehow, I don't think just one article quite captures the subtleties of the debate?

Re:Bloat

[Anonymous Coward]

Sorry, Gnome vs KDE ended in a tie (for last place), so there's not much to say.

Well, at least you guys have Motif to kick around!

Re:Bloat

[sp0rk173]

Opening GNOME Terminal these days takes 10 seconds

4 seconds here. Using the X-one-thousand counting method, where X is an integer greater than 0. Perhaps it's time for you to (a) upgrade or (b) use xterm? I mean...open source is about choice, right? Choose to use a less resource-intensive terminal for your out of date hardware. HELL, i'm using FreeBSD and it's fucking DEAD man!

Re:Bloat

[sp0rk173]

True. but you could still do something fucking lame like attaching a ata66 drive as a slave to an ata100 drive, in which case you would be running the ata100 drive EXTREMELY SLOW. Just becuase it's activated by default doens't mean you're not so dense as to have your hardware set up incorrectly. Of course, you're probably a troll. In which case I am one as well. In which case, We Have Both Been Trolled. We Should Have A Nice Day.

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

Re:Bloat

[J. T. MacLeod]

Isn't 4 seconds a bit ridiculous, too?

Both GNOME and KDE tick me off in this regard.

Re:Bloat

[JanneM]

I think he measured 4 seconds for the first terminal to be started during a session (when it still needs to load a bunch of stuff from disk).

When I start a new terminal instance on a 1.1Ghz Centrino machine, it pops up in less than half a second. And if I force a new terminal application to start (which you would normally never have a reason to do), it is still less than two seconds.

Re:Bloat

[Heretik]

Nowadays Xterm can use anti-aliased fonts (see the -fa option) so using it instead of gnome-terminal is a much nicer option than it was a little while ago.

I switched to Xterm for this reason, it starts instantaneously, and terminal I/O is way faster than gnome-terminal (and uses much less CPU).

Re:Bloat

[MemoryDragon]

The bloat is not worse than xlib .... since you can bypass with Cairo xlib and go the OpenGL route optionally and get a huge speed increase. Cairo will also be in the long term one of the X11 core libs, so the bloat is just in your mind not in Cairo...

Re:Bloat

[mini me]

A lot of people complain about GTK+ being slow ass system

GTK+ using it's native themes is very slow on my system. But using the GTK+ Qt theme (renders GTK+ apps using Qt themes) I see a significant speed increase. So there is definitely a bottleneck in there somewhere, but it's not necessarily the GTK+ library.

Re:Bloat

[GreyWolf3000]

What would be nice is a Gnome, HIG-compliant wrapper around xterm.

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

[Anonymous Coward]

1. the bitmap size disadvantage gets worse in an O(N^2) fashion (i.e. when your display resolution doubles all your bitmaps now take 4 times the space)

2. if you want to support a reasonable range of resolutions (obviously a requirement) then you end up having to have multiple bitmaps (wasting even MORE space) If you want to do it well (like OS X) you also need a way of interpolating between them smoothly (at which point you're probably SLOWER than the pure vector approach)

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

[Anonymous Coward]

Not give up bitmaps...

Vector is good because you use it to create scalable graphics. For instance in Linux and OS X you can take your icons and scale them to be very big and they don't get all pixlated or ugly (or at least UGLIER).

Right now Windows XP sucks for very high resolution graphics. As does most of Linux's Gnome/KDE stuff.

If you want nice sharp graphics you give it high resolution. If you want reasonably sized icons you have to make it have a reasonably low resolution.

If you want lots of deskspace you make it have a very high resolution, but then everything becomes very small.

It's all a trade off.

With vector based you can have everything exactly how you want it irregardless of the resolution. A 19 inch monitor with a 1024x768 resolution can have exactly the same sized text and borders and icons and desktop space as a 19 inch monitor with 2028x1536 resolution. It's just that the high resolution would end up being much sharper image.

Also since this would be taking advantage of your 3d stuff in your video card it is (and cairo prototypes have been benchmarked) MANY times faster then using the 2d portion of your card to render bitmaps.

Currently a experiment, proof of concept backend for Cairo is called Glitz.

Normal applications should be able to benifit from this sort of thing without being rewriten or modified or anything. This is due to the multilayered abstraction that is inherent in Unix-like OSes and X Windows.

You update the GTK or QT library, replace Xrender with a 3d version similar to Glitz and BAM! OpenGL graphics.

All the work is done by the GTK/Cairo/X.org people.

X.ORG ROCKS! They are dragging X Windows kicking and screaming into the 2000's.

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

[lachlan76]

Vector graphics scale perfectly. If I take a screenshot of the corner of my screen and scale it up, it will look perfect. With bitmaps, it will get pixellated as it is scaled larger.

Re:Why give up bitmaps

[Anonymous Coward]

Yeah, but they don't scale down perfectly. Try making a vector that looks good at 256x256 that also looks good at 16x16 when on your Start Menu clone.

Re:Why give up bitmaps

[jeif1k]

Smaller file sizes mean faster loading.

In any case, that's not the reason for going to vectorized graphics; vectorized graphics makes development and theming easier and allow new kinds of interaction. This isn't Apple's idea; Tcl/Tk and Gtk+, for example, use a stored vector canvas extensively. Apple is rather late to the party, sticking with bitmaps for a long time.

The time is about right to switch to vectorized graphics now: it is less efficient, it is harder to implement, but it will simplify application programming.

Re:Why give up bitmaps

[Anonymous Coward]

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.

???

Apple haven't released anything like this yet. I didn't even realise they'd announced it.

Re:Why give up bitmaps

[Anonymous Coward]

Vector graphics scale perfectly. If I take a screenshot of the corner of my screen and scale it up, it will look perfect.

A popular myth. In fact, vector graphics have a "native resolution" just like bitmap graphics. Scale them up too much, and they start to look sparse and poorly detailed; scale them down too much, and they look cluttered, thin lines stop rendering well, etc.

Re:Why give up bitmaps

[j.blechert]

obviously it will still take some time for this all to be implemented properly and with a real difference for the user. considering that right now on ebay in germany an athlon xp 2000+ with mainboard, etc. coasts around 250 the hardware that's neccessary for all this should be able to get around 50 (for those who then still don't have it, which is quite unlikely) so I don't understand what the fuzz about super computer etc. is

Re:Why give up bitmaps

[Anonymous Coward]

WTF???

Apple has been doing this for 5 years, opengl accelerated for 3 years.

Re:Why give up bitmaps

[lachlan76]

What I mean is a curve stays as a curve, a line stays as a line. There are no jagged edges when I scale it up. I don't see a series of squares.

Re:Why give up bitmaps

[Anonymous Coward]

REGARDLESS

there is no such word as irregardless.

Why make up a word that's MORE work than the correct one?

Re:Why give up bitmaps

[Anonymous Coward]

Actually, you have it backwards. The X Window System works pretty much like that already.

Server - the machine with the monitor, keyboard, and mouse.

Client - the machine running the program.

The client program "draws" a picture by sending the commands to the server (assuming its not a photograph, but instead is a widget or some such thing) to draw lines, fill areas, etc. The server, since it is the one with the monitor and graphics card, handles turning those commands into bitmaps to put on the screen.

Yours is a common mistake to make. Possibly because of the internet with your machine is the client and the server is the one with the file.

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:Why give up bitmaps

[The Ego]

Apple haven't released anything like this yet. I didn't even realise they'd announced it.

Sure they have, although you had to pay attention to spot it (Graphics & Media state of the union).

I don't have a time marker in the stream, but Quartz 2D Extreme is demonstrated. It is the OpenGL/GPU-accelerated implementation of the Quartz 2D vector library.

The other reply to your post was also somewhat correct in stating that Apple is already using the GPU to accelerate Quartz. However it is only the compositing layer that is accelerated (Quarz Extreme, note the absence of '2D' in the name), at least until Tiger/10.4 ships. There are excellent presentations of Quartz Extreme available on the net (from Apple folks).

Re:Why give up bitmaps

[Anonymous Coward]

> In fact, vector graphics have a "native
> resolution"

Nonsense.

However, cairo *does* have a "native" resolution: It pre-renders the szene into a sequence of trapezoids and sends this picture to the X server. It doesn't send the scene graph.

Re:Why give up bitmaps

[spitzak]

Actually scaling a bitmap to non-square pixels looks no worse than scaling to square pixels. Most (all?) scaling algorithims do the horizontal and vertical directions totally independently.

However I agree with you in general.

Re:Why give up bitmaps

[captaineo]

Good filtering is another issue. Currently lots of applications try to do scaling themselves and make stupid mistakes like using point sampling or a box filter.

An ideal scalable graphics system would support both raster and vector primitives, where the raster primitives would be scaled to the appropriate resolution automatically with guaranteed high-quality filtering (like bicubic or better).

Re:Why give up bitmaps

[wild_berry]

Surely a line with a fixed width and items of pixel-counted size will look bad when scaled, because that's not true vector imagery. Real vector-based imagery should have everything as porportions irrespective of the number of pixels involved which ensures it will scale well.

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

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.

Re:Vector are Faster

[Anonymous Coward]

An arbitrary polygon doesn't need to be a triangle, or even convex. It can require tesselation that costs time, A vector figure need not even be a polygon, any arbitrary line drawing is more expensive for drivers optimized for Quake rather than AutoCAD. And when these figures have textures, these textures need to be mapped and I suppose that you would want them to be vector-based rather than raster operations.

And if all of this is for a static image it will be slower than a bitmap for anything that isn't very simple. Video cards can blit quite quickly. If however it's not static, but rather consists of a series of animations that can be expressed as transformations of the original vector data then it can be quicker in a larger domain of cases. Otherwise precomputed images will be faster, and that is why all of these vector renderers will cache results.

Wow!! Now THIS is what we can call PROGRESS!

[ZuperDee]

Holy Toledo!!! I was seriously thinking about jumping ship to Longhorn or MacOSX before I read about this. This development looks like it could seriously narrow the technological gap between the proprietary MacOSX/Longhorn world and the open source community. Well done GTK+ people!!!!

But now here's a realistic goal question: Can the open source community really deliver, and do an official, working release of this before Longhorn comes out?!? Now THAT would be AWESOME, cause it might even put the F/OSS community AHEAD of the curve and at the forefront of innovation!!!

I guess it just had to be said:
Now wouldn't Microsoft just hate it if this was released before Longhorn?!?

Then again: I urge caution--supposing Microsoft has already patented such things in Longhorn? The F/OSS community could be in serious trouble...

No shit, sherlock

[Anonymous Coward]

The bottom line is that Trolltech has some ties with the Canopy group. Unless you've been living under a rock for the past two years, here's tne executive summary: Canopy is also a major stakeholder in the SCO group, and funds Darly-girl's litigious bastard frivolous attack against FOSS in a last ditch attempt to make a few bucks off the corpse of a dying company.

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

Wake up and smell the coffee fer cryin' out loud.

-STM

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

[Too Much Noise]

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

More like a complicated way of saying "we have no idea whether there's any merit to it or not, but even if it were, we think they took the wrong approach" He says we do not support these actions from SCO twice. How much clearer could he be considering it's an ongoing case?

Now, if a certain Darl had been the speaker here, 100 negations would have been worthless. But unless there's evidence to the contrary, I would consider this to be in good faith. He did say their business relies on Linux being successful, btw.

Re:No shit, sherlock

[ahillen]

Yes, I completely agree. In case it wasn't clear, I was just refering to the poster before me, who claimed:"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.'", which is complete BS as can be seen by this interview.

There is nothing they can do about this investment, and with ~5% it's also nothing to worry about. Apart from that, they don't agree with Canopy/SCO. That's all I need to know.

MOD PARENT UP

[Anonymous Coward]

Please

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

[Anonymous Coward]

Nope.

your thinking of it in Windows terms. In Linux you have many layers of programming and abstraction.

Cairo gives X Windows the ability to render vector graphics natively. SVG is a file format for vector graphics.

Cairo isn't some big Avalon-do-dad. It's using existing technology and merging it all together to make new stuff. It's the nice stuff about Linux and open source.

It's just another componate. Not a monolythic new way of doing graphics. Hell you don't even have to rewrite applications to take advantage of it. It's all done thru the GTK or QT (future) library.

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.

Re:a question...

[matlhDam]

Cairo's also one of the available rendering backends for Mozilla's SVG project. I was playing with it at work during the week and the results are already quite impressive, even with Mozilla's (or, in this case, Firefox's) still-limited-but-improving SVG support.

Re:a question...

[Directrix1]

I've been playing with SVG in linux for the last couple of weeks. And I came across a couple of fun relevant projects:
Gnome: supports scalable SVG icons, fun!!!
Inkscape: is an open source SVG editor that has recently added Text-on-a-Path to its feature list
librsvg: lib for adding SVG support to apps. Also, has a command line SVG rasterizer (although inkscape can do that also)

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:Now - finally

[lachlan76]

means that gnome and KDE join on the same backend.

No more than that they both use XLib somewhere along the line.

Re:Now - finally

[slavemowgli]

KDE and gnome already do have the same backend, namely, X. That may sound trivial, but I'm not sure what the fundamental difference would be with the adoption of a common vector-based backend (outside of the fact that it *would* be vector-based, of course).

Re:Now - finally

[MemoryDragon]

Actually Cairo is from the X people to my knowledge... It probably will end up being one of the core libs of X.org in the long term...

Re:Wow!! Now THIS is what we can call PROGRESS!

[Anonymous Coward]

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

[im_thatoneguy]

... what was wrong with bitmaps? If your icons are large enough that you need vector icons... they're way way too damn big.

Re:I missed somthing...

[Anonymous Coward]

What is wrong with vector graphics?

You need vector graphics to take advantage of high resolution monitors, but yet have the ability to be a nice size on smaller displays.

With bitmapped you would have to have many different versions of the same icon to fit all the different sizes, resolutions, and color depths.

Re:I missed somthing...

[Anonymous Coward]

One huge problem with vectors is that icons/symbols don't look very good when scaled down to 'list view' or whatever. That's why OSes have traditionally used hand-tweaked bitmaps for small icons.

Of course, there could be a hack-fix where bitmaps replace vectors below a certain size (just as is done with fonts).

Re:I missed somthing...

[Maljin Jolt]

... what was wrong with bitmaps? If your icons are large enough that you need vector icons... they're way way too damn big.

For me, just the opposite. App icons on docking panel of my linux pda are 8x8 and 6x7 pixels. With sub-pixel rendering from vector definition, they are just looking much better than filtered down 32x32 raster.

Re:I missed somthing...

[hattig]

App icons on docking panel of my linux pda are 8x8 and 6x7 pixels. With sub-pixel rendering from vector definition, they are just looking much better than filtered down 32x32 raster.

So, create 8x8 and 6x7 bitmaps from the vector definition, and save memory on a 32x32 bitmap! a 32-bit 8x8 image is 256 bytes in size.

Re:I missed somthing...

[Maljin Jolt]

So, create 8x8 and 6x7 bitmaps from the vector definition, and save memory on a 32x32 bitmap! a 32-bit 8x8 image is 256 bytes in size.

Hardly. 8x8 and 6x7 are docking icons. In the list icon view of a directory, they are 24x24, and 32x32 big-at-center-of-screen while starting up something. Some of these vector icons are even animated.

So, I still prefer to have vector icons in precious pda flash, rendering them in sub-pixel quality to raster icon cache ram on the fly as they are needed in whatever size is required by current view.

Re:I missed somthing...

[hattig]

Ah, that's fair enough then, if they're animated and you'd also have to create large versions of the bitmaps too.

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

Re:I missed somthing...

[LPetrazickis]

Take that back, young man. My icons are not too damn big! Wash your mouth out with soap!

You disgust me.

(Actually, I've switched to ones a quarter of the size since then. Also, I got myself a nice Debian laptop, but it's not as customized as the XP box.^-^)

Re:I missed somthing...

[Anonymous Coward]

And the plan is to later accelerate this through the graphic cards GPU or 3d engine to make all graphics fast and smooth.

Actually, that's not the future plan.

It already works. (Cairo already uses the glitz library to provide acceleration through OpenGL. It's extremely fast, even on dated hardware.)

Drawing can be done through Xlib, GDI+, quartz, etc. as well.

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.

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]

Read carefully asshole

> "GTK+ is now the first major toolkit to have added.

So who gives a slight fuck for GNUStep ?

Re:Gnome marketing

[Anonymous Coward]

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

Re:Gnome marketing

[Anonymous Coward]

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

FUD FUD FUD !!!!
http://wiki.gnustep.org/index.php/All%20GNUstep%20 Applications

And sorry but calling GTK a major toolkit is a little bit strech.

GTK have more than 1% of the toolkit market ( I mean not on Linux, but on all systems ) ?

Re:Gnome marketing

[Anonymous Coward]

And sorry but calling GTK a major toolkit is a little bit strech.

GTK have more than 1% of the toolkit market ( I mean not on Linux, but on all systems ) ?

Sir, you need a pill. It's common knowledge that in open source software, the major toolkits are gtk and qt (and perhaps tk and motif). And gtk is the first one to get a cairo backend.

Now you can go back to trying to distort reality cause you can't accept it.

Re:Gnome marketing

[babyblink]

Sorry to disappoint you, but comparing with how GNUstep blend itself along with Cairo, I wouldn't call GTK+'s way an "integration" either. And before you mod this down, please check out the code and you'll understand what I meant.

Really?

[Anonymous Coward]

Are you serious? Sorry, when I first read "Canopy" I didn't connect it to SCO. Is it true that Trolltech has some ties to SCO? Could anyone confirm it please? If so, wouldn't it make more sense to boycott them instead of giving them free publicity?

Re:Really?

[Anonymous Coward]

Define "ties". Wayback when SCO was Caldera, they got 5% of Trolltech. They were actually good guys, once, remember? However, before you get your underwear all twisted up in outrage, 65% of Trolltech is owned by its own employees. So, it doesn't matter one whit that SCO owns 5%.

Trolltech vehemently disagrees with what SCO is doing. However, Trolltech can't force SCO to sell them back that 5%.

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:real news please?

[Anonymous Coward]

Eugenia, even the original article on your website only states _dependancy_, not support.

Re:real news please?

[Bloater]

Specifically, he committed an API to get a cairo drawable for a window or something (not looked at the details). So its just to let GTK using app devels use cairo calls from their apps for advanced drawing on canvas's and such. So far GTK doesn't actually use cairo. Though apparently GTK head will start using cairo for fonts shortly. Hopefully a theme engine will appear for using cairo for widgets (imagine SVG widgets rendered with a librsvg for cairo :) shaped buttons and stuff !

Perhaps we're on the wrong track

[wtd]

I don't think Cairo necessarily means things will suddenly start to look better, but they don't necessarily have to. GTK+ apps already look pretty good with a decent theme. It's sufficient if apps continue to look the way they do, and see a performance boost. In fact, I think I'd rather see than than fancier graphics and no speed improvements.

Re:Wow!! Now THIS is what we can call PROGRESS!

[wereHamster]

Then again: I urge caution--supposing Microsoft has already patented such things in Longhorn? The F/OSS community could be in serious trouble...

Not in europe... we're never gonna have software patents.

Must get eyes tested & get out more

[Linker3000]

A quick scan of the headline and I was wondering why they'd use a Casio engine - OS + calculator-style graph graphics in perfect harmony!?

Re:Bloat yup

[Anonymous Coward]

agreed. layer upon layer of nonsense.

Get rid of X,Qt,GTK, and the silly ass bloatware DEs that sit on top of that and start again with a proper GUI for Linux and I reckon it will vastly increase it's market share.

wow.... more dependancies.

[xmorg]

Great. More dependancies, so they can break, and then i cant upgrade... hurray.

Cairo

[Anonymous Coward]

The finished backends for Cairo (the X-backend in particular) are not very fast. Even scenes with a quite small number of solid paths take a noticeable while to render.

I like the Cairo-API, though. It is coherent and consistent, a rare trait in Linux-graphics APIs.

GDI equivalent?

[njyoder]

So is cairo or more specifically cairo+GTK going to be like the *nix GDI equivalent?

Re:Wow!! Now THIS is what we can call PROGRESS!

[Anonymous Coward]

Windows has supported vector graphics forever (WMF format). Check the clipart from Word 6. How exciting.

Of course that's not what the article is talking about, so you are a dumbass.

Cairo and gcj

[Anonymous Coward]

gcj and GNU Classpath have been using cairo for well over a year now in order to implement the Java2D API.

Re:Cairo? Windows NT 4.0 Beta?

[Anonymous Coward]

OS X 2002 == Windows NT 1994

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

[Anonymous Coward]

It is off because (so I read) it was not supported good by much hardware.

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.

Re:Wow!! Now THIS is what we can call PROGRESS!

[lisaparratt]

Seeing as Apple have already been doing it for years, you neither need to worry about patents, or getting near the forefront of innovation.

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.

Re:Mathematics

[Anonymous Coward]

I get the feeling that any "embedded consumer products" with a need for hi res graphics will have an FPU available.

Re:Mathematics

[Anonymous Coward]

Can the Cairo folks actually guarantee to get repeatable results with floating point processing? Without strict IEEE compliance, the exact pixel output could change in each minor version of the system, as code changes lead to different compiler optimizations... As everyone here should know, x86 processors are particularly unpredictable about the exact floating point results. (You don't get strictly IEEE compliant results unless you take an extra performance hit by storing every intermediate result to memory.)

Unless they take special measures in their floating point code, I can't see how they can guarantee that say, a line that just touches an ellipse with one build of the Cairo library, will do the same in the next build.

Re:Mathematics

[MenTaLguY]

Unless you enable -ffast-math, gcc will generate IEEE-compliant code by default.

Re:Mathematics

[Anonymous Coward]

That property of Cairo/XRender is overrated. As Glitz proves, what people really want is speed. Glitz does provide the most important guarantees, such as that adjacent polygons won't overlap. This turns out to be all most people really need. Also, with antialiasing turned on, exact predictable output becomes much less important.

Re:Mathematics

[lisaparratt]

As some one who works in the digital television set top box industry, I can tell you that you feel incorrectly.

Re:Mathematics

[eloki]

I back lisaparratt's comment. Eyecandy is appreciated on almost any embedded device with output on a display. That doesn't mean that FPUs will be available on the hardware. We're working with such a device right now.

Re:Wow!! Now THIS is what we can call PROGRESS!

[Anonymous Coward]

Apple have been doing nothing for years that both Linux and Windows have not also been doing. They just market it better, so Apple fanboys end up thinking they're getting something amazingly innovative. (I can't get over the marketing blurb for the iPod Shuffle, which tried to make out that random playlists were an AMAZING NEW INNOVATION!!!)

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:FLTK and Cairo

[Anonymous Coward]

And FLTK 1.1 has limited SVG support via Cairo.

Re:Cairo? Windows NT 4.0 Beta?

[Anonymous Coward]

Cairo was NT5

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

Mod parent up FUNNY!

[Anonymous Coward]

I just nearly spewed my morning coffee on my screen. The desktop right next to it is doing an "emerge system" right now.

Gentoo rules, but this is pretty good!

Re:I for one...

[Anonymous Coward]

...welcome our redundant Simpsons quotes.

Useless

[Anonymous Coward]

This thread is useless without pics!!

Cairo Vector Engine, eh?

[xXunderdogXx]

The mechanical engineers in the audience collectively ask, "How many horsepower?"

Convergence

[Qwavel]

The idea of GTK+, KDE, and Windows all supporting the same API is enough to make a cross-platform developer giddy.

Go Cairo!

Combine GTK and QT?

[Anonymous Coward]

Instead of developing on two fronts, why not take the resources and combine QT and GTK to make Gnome and KDE GUIs compatible?

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:A little knowledge is a dangerous thing

[Matthias Wiesmann]

I must agree. Even if a postscript program eventually terminates, it can take ages to render. So a very short file can be very expensive to display.

People who thing this is a purely intellectual issue should try to open this small postscript file. While the file itself is less than 1600 bytes, it should keep your processor busy for a little time (don't worry it terminates).

For those who have a very fast processor, they can simply edit the file (it is a text file) and change the value 14 at line 9 by a larger number. It will take more time but the picture will be nicer.

By the way, this file not only demonstrate that you cannot determine the length of calculation before hand, but also that the resulting image is not fixed, you will get a slightly different image each time you run it.

Re:All we need now is mesa-standalone, and then XG

[Anonymous Coward]

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

I'll bring the popcorn and wine.

FVWM already exists for those who want it

[Ars-Fartsica]

I don't understand these posts. If you want a zero-bloat environment, it is trivial for you to build one with any linux distribution. First, if you really want to avoid bloat, try lynx running on the console...this will enable you to do what you have always fantasized about - having top display an ongoing idle meter over 98% in another shell.

Now assuming you like graphics and different size fonts, fvwm, twm, or fluxbox etc are debugged, stable and widely available. Install one of them and go about your business.

Re:FVWM already exists for those who want it

[drooling-dog]

Good point.

The parent post isn't asking for solutions, though; it's about generating FUD regarding Linux not being "ready for the desktop"(!). The 10s he quotes makes my old 366 MHz laptop look like a supercomputer. Maybe I'll hold onto it for a while longer...

Re:FVWM already exists for those who want it

[Anonymous Coward]

fluxbox is not stable.

TWM is quite simply not fit for human consumption.

It's interesting that not one developer, NOT ONE has put together a fast GUI that can:

1) Show icons the desktop

2) open a window (not a 10 ton file manager) when you double click on a directory icon

3) show a desktop background

4) Draw a menu of basic file commands on the top of the screen.

Interesting not one so called lightweight gui/de can do that. And actually therein lies a lot of Linux's problems. Until the Opensource community can attact good coders with basic common sense who understand the fundementals of what peope take for granted in desktop computing then Linux is on a path to nowhere. In the meantime trying to foist prehistoric nonsense like twm onto people is not even funny.

Re:FVWM already exists for those who want it

[Anonymous Coward]

Hey, I use ROX with openbox3. It does pretty much what you are requesting *shrug*

Re:FVWM already exists for those who want it

[Anonymous Coward]

Yeah that is exactly my point

Gentoo Rocks, but this Parody Rocks even more

[FreeUser]

This has to be one of the funniest parodies I've read in a very long time, and I say that as an avid fan of Gentoo who uses it at work and at home.

Absolutely hilarious!

PS - Gentoo is recompiling my genome as I ... oh damn ... addfjjjjj

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

[Anonymous Coward]

centimeters

Re:Wow!! Now THIS is what we can call PROGRESS!

[Anonymous Coward]

Are you kidding me? Anyone who's actually used OS X knows how far behind Linux and Windows are. That gap won't be bridged for a long time if ever.

Re:Cairo? Windows NT 4.0 Beta?

[MemoryDragon]

Actually Cairo was back then vaporware, Bill Gates constantly under the impression of NeXTStep which back then was just released for x86 was talking about an OO based Windows which never saw the light of day. Typical Bill Gates, hold on dont buy that stuff we are working on something similar talk. That is one of the constant tactics Billy boy uses, to keep a competition away from the Windows territory.

Calm down boy

[Anonymous Coward]

You need to take some valium or something.

There ARE OS drivers for lots of cards!

[MarcQuadra]

I say this weekly on Slashdot, but there ARE open-source 3D drivers in xorg. I've got a RADEON 7500 and a 9200 which are both fully-accelerated for 3D in xorg and xfree.

If you're gonna use Linux, PLEASE buy hardware that works with it from the start. I wouldn't go out and buy a video card that I can't get accelerated 3D on out-of-the-box. Every time you buy a piece of hardware without open specs and interfaces you support the closed philosophy.

It's always been the case that the open-source drivers for 3D cards come out a while (sometimes a LONG while) after the cards are out, it takes a while for the developers to figure out the interfaces and get things working.

Re:Bloat yup

[Anonymous Coward]

Believe it or not you're not the first person to have suggested that. The problem with your idea is that it can never happen under the open-source development model.

Say, for example, that Jesus appears to you in a dream and gives you the ultimate design for a GUI. Then, by another stroke of incredible luck, you actually rally 100 developers to set to work on your idea.

Now, if the story ended there and we all lived happily ever after, we'd have the ultimate GUI in very little time at all. But, people being people, during the development process you're going to have at least one smartarse who objects to the way something has to work, or some bit of politics, or whatever. Anyway, he ultimately decides to fork the project, and take half your developers with him.

After a while, the the same thing happens to him. After another while, then the same thing happens to you again. Now you've got 4 teams of 25 people all working on seperate forks.

Things continue on for a while and then you've got 100 seperate projects each with only a single developer working on them, which means nothing gets done whatsoever, and all the projects grind to a halt, with nothing to show from any of them.

This is where closed-source, commercial ventures such as Microsoft will always kick the ass of the OSS community. Instead of 100 people pulling in completely different directions achieving nothing, you've got 100 people pulling in a single direction, working together to build a design. Even if the design isn't perfect, at the end of the day you've achieved more than the 100 nobodies who're still thinking of a name for their fork.

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:Bloat yup

[Anonymous Coward]

Yes some some good points you bring up, but I don't think it wouldn't take a hundered programmers. I reckon 1 with reasonable design skils or 2 maybe. Now if it forked and went in 20 different directions afterwards well that's a shame I guess.

For thoses people who still wanted to run X instead and all the other stuff they could.

I suspect the other big problem is a lot of applications rely on X and those other libraries so it would actually mean new applications.

Perhaps from what you say OSS is not the way forward for such a radical change, and it would benefit from a different approach.

Backwards

[spitzak]

The API is floating point. One implementation of Cairo uses XRender as the backend, and that is fixed-point (8 bits after the decimal point).

Some internals of Cairo is in this same fixed-point format due to the expectation when it was being written that XRender would be the main back-end, however I think this is being rewritten to float due to Glitz becoming much more popular and requiring float as well.

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.

It's the resolution.

[Anonymous Coward]

Vector graphics are all about resolution independence. Why have a monitor set at 1024x768, if it can display at 1900x1600? You're losing SO much quality, just because your software is hard-coded to a certain DPI. This should never have happened on a serious desktop system, never mind that it's STILL happening.

That's what you use Gentoo for?

[thegnu]

I tried compiling myself a 10-inch vibrating penis, and it didn't work. Maybe I was misusing portage.

Anyway, I switched to Arch. A wide variety of pre-compiled penises are available. I highly recommend it.

Re:That's what you use Gentoo for?

[agraupe]

My system came with a penis installed by default... I feel sorry for you if you don't already have one.

Hmmm: "xxx_self_intersect"

[boomgopher]

xxx_self_intersect

That sounds sort of, you know, obscene.

Cool Cairo!

[Anonymous Coward]

Now I will have dogcows and little buildings all over my linux!

But really... I wish they would adopt some time in actually making an OSX port so we can compile native apps without using X11. Seriously, what the heck happened to gtk-aqua or whatever that project was called? Is it too much to ask for a cross platform toolkit other than Qt (for compiling existing apps without heavy modification anyway)?

X-Windows: The Cutting Edge of Obsolescence

[Veshtaj]

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.

That means that X-Windows will match what Display Postsript did in 1994. Of course, Unix weenies will rave about network transparent display as if that makes up for all of X-Windows' brain damage.

Two Words, you say?

[Grendel Drago]

Yeah.. Puppy Helmet! Popcorn Eyeglasses! Peanut-Butter Monkey!!

--grendel drago

Re:Bloat yup

[sp0rk173]

You're assuming that there are only 100 developer through the live of all projects that are interested enough to work on it, and no new developers will join the separate projects as time goes on...and that none of the projects will share code. Those are pretty loose assumptions.

O, young guy! ;-)

[PaulBu]

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.

I guess you were not around when top-of-the-line CG was represented as "display lists", basically list of vectors for DAC to convert to voltages steering CRT e-beam across the screen. THAT was true vector graphics! Of course it was so much better suited for engineering blueprints rather than porn collections, so it was quickly replaced by modern bitmapped displays. I think that bitmapped displays became pupular only in late 70s-early 80s, while "vector" dispplays have been around since 60s...

Paul B.

PARENT IS PURE BULLSHIT, READ HERE

[Anonymous Coward]

Fuck you. This is pure bullshit.

The Halting Problem means you can't determine wether /any/ program will eventually terminate. But this prediction is very easy to do for a lot of computations, which could very well be the case here.

You suck.

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.

Re:Wow!! Now THIS is what we can call PROGRESS!

[lisaparratt]

What, you mean other than a vectorised rendering backend which is exactly the topic of discussion?

Re:Bloat yup

[mikael]

Get rid of X,Qt,GTK, and the silly ass bloatware DEs that sit on top of that and start again with a proper GUI for Linux and I reckon it will vastly increase it's market share.

You could try, but you would probably end up with exactly what you had before.

At the very least, users would want a windowed system that could support multiply displays across networks. They would also want multiple font styles and the ability to read the mouse, keyboard and other input devices. This of course, would have to support accelerated 2D graphics (X-windows) GUI, along with support for accelerated 3D graphics to run games (GLX)

Application developers would want an easy way to develop applications using design tools (Qt), and users would want to have their preferred desktop environment (bloatware DEs) to run their web applications.