Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Graphics Software GNOME X Programming GUI KDE Technology

GTK+ to Use Cairo Vector Engine 247

Posted by CowboyNeal from the pretty-pictures dept.
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."
This discussion has been archived. No new comments can be posted.

GTK+ to Use Cairo Vector Engine More

GTK+ to Use Cairo Vector Engine

Comments Filter:
  • 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 [tribbles.org]

    • Re:Quartz is not vectorized (Score:5, Informative)

      by Anonymous Coward on Saturday February 05, 2005 @03:46AM (#11581149)
      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 (Score:5, Informative)

        by TheRaven64 ( 641858 ) on Saturday February 05, 2005 @05:16AM (#11581369) Journal
        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.
        • 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

          • Re:also exists in X11--just turn it on (Score:5, Insightful)

            by DrWhizBang ( 5333 ) on Saturday February 05, 2005 @11:54AM (#11583129) Homepage Journal
            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.
      • 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.
      • 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 gen

  • Open Source 3D (Score:5, Insightful)

    by bsharitt ( 580506 ) * <bridget@NoSpAM.sharitt.com> on Saturday February 05, 2005 @03:37AM (#11581124) Journal
    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.

    • Open Source drivers for 3D (Score:5, Informative)

      by anti-NAT ( 709310 ) on Saturday February 05, 2005 @03:55AM (#11581171) Homepage

      Have a browse around Direct Rendering Open Source Project [freedesktop.org] for details of video cards with open source 3D drivers.

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

    • 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 "popu

    • Re:Open Source 3D (Score:3, Informative)

      by slashdot.org ( 321932 )
      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 sk

    • Re:Open Source 3D (Score:4, Interesting)

      by Rutulian ( 171771 ) on Saturday February 05, 2005 @11:24AM (#11582880)
      I'm surprised nobody has mentioned the Open Graphics Project [slashdot.org] in this thread. With any luck the card will be released just in time for Cairo to take advantage of it.
    • 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

  • Mono and cairo (Score:5, Informative)

    by Goalie_Ca ( 584234 ) on Saturday February 05, 2005 @04:10AM (#11581205)
    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
    • 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.

  • Why give up bitmaps (Score:2, Insightful)

    by smartsaga ( 804661 )
    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. Whe

    • Re:Why give up bitmaps (Score:3, Funny)

      by Anonymous Coward

      "Bitmaps should be enough for anybody" -- slashdot, 2005
    • 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!) hard

    • Vector are Faster (Score:2, Informative)

      by VeryApt ( 852702 )
      ... 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:Why give up bitmaps (Score:3, Informative)

      by Junta ( 36770 )
      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 rem
    • 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

    • Re:Why give up bitmaps (Score:5, Interesting)

      by Rolman ( 120909 ) on Saturday February 05, 2005 @05:06AM (#11581340)
      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.
    • 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.
    • 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 applica
    • 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.

      Wi

  • a question... (Score:2, Interesting)

    by dermusikman ( 540176 )
    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 [svg.org], 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?

  • Now - finally (Score:3, Insightful)

    by megajini ( 557306 ) on Saturday February 05, 2005 @05:01AM (#11581328)

    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 [freedesktop.org] seem to do the trick very well (they didn't get between the lines -- yet)

    Interesting is, that there are also java-bindings [cairographics.org] that work together with SWT [eclipse.org] 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...

    • means that gnome and KDE join on the same backend.

      No more than that they both use XLib somewhere along the line.
    • 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).
    • 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...

  • Gnome marketing (Score:4, Insightful)

    by Anonymous Coward on Saturday February 05, 2005 @05:10AM (#11581351)
    > "GTK+ is now the first major toolkit to have added
    > support for the Cairo 2D vector graphics library"

    http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/ gn ustep/core/back/Source/cairo/

    6 months later....

  • real news please? (Score:5, Insightful)

    by Anonymous Coward on Saturday February 05, 2005 @05:14AM (#11581359)
    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.

  • Comment removed (Score:4, Interesting)

    by account_deleted ( 4530225 ) on Saturday February 05, 2005 @06:37AM (#11581593)
    Comment removed based on user account deletion

  • FLTK and Cairo (Score:2, Informative)

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

  • All we need now is mesa-standalone, and then XGL (Score:4, Informative)

    by Nailer ( 69468 ) on Saturday February 05, 2005 @07:47AM (#11581824)
    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...
  • The mechanical engineers in the audience collectively ask, "How many horsepower?"

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

    Go Cairo!

  • Scaling? (Score:3, Informative)

    by fossa ( 212602 ) <pat7@g[ ]net ['mx.' in gap]> on Saturday February 05, 2005 @11:28AM (#11582903) Journal

    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? yes (Score:3, Informative)

      by spitzak ( 4019 )
      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 gre

  • OpenGL on linux (Score:3, Informative)

    by Stevyn ( 691306 ) on Saturday February 05, 2005 @02:01PM (#11584080)
    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?

Slashdot Top Deals

"jackpot: you may have an unneccessary change record" -- message from "diff"

Close