Slashdot Mirror
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."
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
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.
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?
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?
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.
- Otaku no naka no otaku, otaking da!!!
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?
I am TheRaven on Soylent News
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.
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.
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.
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.
Schrodinger's cat is either dead or really pissed off...
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.
I am trolling