LWN.net Logo

Cairo release 1.2.0 now available

From:  Carl Worth <cworth-AT-cworth.org>
To:  cairo-announce-AT-cairographics.org
Subject:  cairo release 1.2.0 now available
Date:  Sat, 01 Jul 2006 04:36:04 +0200
Cc:  gnome-announce-list-AT-gnome.org

A new cairo release 1.2.0 is now available from:

        http://cairographics.org/releases/cairo-1.2.0.tar.gz

    which can be verified with:

        http://cairographics.org/releases/cairo-1.2.0.tar.gz.sha1
        c5da7f89cdd3782102357f99a47f516d11661e92  cairo-1.2.0.tar.gz

        http://cairographics.org/releases/cairo-1.2.0.tar.gz.sha1...
        (signed by Carl Worth)

  Additionally, a git clone of the source tree:

        git clone git://git.cairographics.org/git/cairo

    will include a signed 1.2.0 tag which points to a commit named:
        61404bd5022b913f58ecda8dc9e8922b4fc6f80b

    which can be verified with:
        git verify-tag 1.2.0

    and can be checked out with a command such as:
        git checkout -b build 1.2.0

We are very pleased to announce this release, the first major update
to cairo since the original 1.0 release 10 months ago. Compared to
cairo 1.0, the 1.2 release doubles the number of supported backends,
adding PDF, PostScript, and SVG backends to the previous xlib, win32
and image backends.

As with all of cairo's major releases, cairo 1.2 retains both source
and binary compatibility with the cairo 1.0 series. Programs compiled
for cairo 1.0 should run with cairo 1.2 without requiring any
modification.

I want to personally express my congratulations and admiration to
everyone on the cairo team. This includes authors of code,
contributors on the cairo mailing list, and users who have submitted
bug reports and suggestions. This release has been a huge effort, and
its high quality is due to the contributions of dozens of
people---many more than are mentioned below. So thank you!

I would also like to thank everyone for their patience during this
long and uncertain release process. I imagine some people may have
thought cairo 1.2 would never appear as date after projected date
slipped by. I should express particular thanks to Behdad Esfahbod
without whom the release still wouldn't be done, nor would it be
nearly as good, (many documentation updates, good catches of bad
mistakes that almost got frozen in the release, etc). Thanks Behdad!

-Carl

What is cairo
=============
Cairo is a 2D graphics library with support for multiple output
devices. Currently supported output targets include the X Window
System, win32, and image buffers. Experimental backends include OpenGL
(through glitz), Quartz, XCB, PostScript and PDF file output.

Cairo is designed to produce consistent output on all output media
while taking advantage of display hardware acceleration when available
(for example, through the X Render Extension).

The cairo API provides operations similar to the drawing operators of
PostScript and PDF. Operations in cairo including stroking and filling
cubic Bézier splines, transforming and compositing translucent images,
and antialiased text rendering. All drawing operations can be
transformed by any affine transformation (scale, rotation, shear,
etc.).

Cairo has been designed to let you draw anything you want in a modern
2D graphical user interface.  At the same time, the cairo API has been
designed to be as fun and easy to learn as possible. If you're not
having fun while programming with cairo, then we have failed
somewhere---let us know and we'll try to fix it next time around.

Cairo is free software and is available to be redistributed and/or
modified under the terms of either the GNU Lesser General Public
License (LGPL) version 2.1 or the Mozilla Public License (MPL) version
1.1.

Where to get more information about cairo
=========================================
The primary source of information about cairo is:

	http://cairographics.org/

The latest releases of cairo can be found at:

	http://cairographics.org/releases

Snapshots of in-development versions of cairo:

	http://cairographics.org/snapshots

The programming manual for using cairo:

	http://cairographics.org/manual

Mailing lists for contacting cairo users and developers:

	http://cairographics.org/lists

Answers to some frequently asked questions about cairo:

	http://cairographics.org/FAQ

What's new in cairo 1.2 compared to 1.0
=======================================
New, supported backends (PDF, PostScript, and SVG)
--------------------------------------------------
The major theme of the 1.2 release is new PDF, PostScript and SVG
backends for cairo. Unlike the 1.0 series, in the 1.2 series these
backends are not marked as experimental and are now fully supported,
(that is, they will now have the same API stability guarantees as the
rest of the library).

These new backends form an integral part of the new printing support
that will soon be released as part of GTK+ 2.10.

Earlier, experimental versions of the PDF and PostScript backends used
image fallbacks exclusively, which was obviously unsatisfactory for
many uses. In contrast, the PDF backend in the cairo 1.2.0 release
will emit vectorized output for all operations drawn with the default
OVER operator, even when the drawing includes translucence. The
PostScript backend emits vectorized output as long as there is no
translucency. The SVG backend can handle basically anything with
vector output, (particularly if the user selects SVG 1.2 output).

And as always, with any supported cairo backend, the backends should
work fine with any possible cairo operations, (through image
fallbacks). In 1.2.0, when a fallback is necessary on any page, it
renders the entire page as a fallback. It is expected that future
releases will fallback more gracefully and use images only for the
minimum region necessary.

Text support in these backends has seen a tremendous amount of
work. At a minimum, text will be rendered as paths in any of the
backends, (assuming no other operations force a fallback). And in the
PDF and PostScript backends, both type1 and TrueType fonts will be
directly embedded in the output file. This results in higher-quality
previews and better performance. Note however, that due to a known bug
in the PDF backend, it is not currently possible to use a PDF viewer
to select text in a PDF file generated by cairo. It is anticipated
that this shortcoming will be addressed shortly in a subsequent
release.

New, experimental backends (beos and directfb)
----------------------------------------------
The 1.2.0 release includes two new backends that did not exist in the
1.0 series:

	* beos backend
	* directfb backend

These are experimental still, (as are the existing xcb, glitz, and
quartz backends), meaning we don't yet guarantee they are fully
functional, (not yet passing the entire test suite), nor are we
guaranteeing strong API compatibility into the future.

But please feel free to experiment with these backends and give use
feedback, or help us to improve them.

Group rendering API
-------------------
The long-awaited group-rendering support is now available with the
following function calls:

	cairo_push_group
	cairo_push_group_with_content
	cairo_pop_group
	cairo_pop_group_to_source
	cairo_get_group_target

This API provides a much more convenient mechanism for doing rendering
to an intermediate surface without the need to manually create a
temporary cairo_surface_t and a temporary cairo_t and clean them up
afterwards.

Backend-specific pkg-config files
---------------------------------
In addition to the original cairo.pc file, cairo will also now install
a pkg-config files for each configured backend, (for example
cairo-pdf.pc, cairo-svg.pc, cairo-xlib.pc, cairo-win32.pc, etc.) this
also includes optional font backends (such as cairo-ft.pc) and the
optional png functionality (cairo-png.pc).

These new pkg-config files should be very convenient for allowing
cairo-using code to easily check for the existing of optional
functionality in cairo without having to write complex rules to grub
through cairo header files or the compiled library looking for
symbols.

Help for drawing disconnected circles
-------------------------------------
A new path-construction function was added which clears the current
point in preparation for a new sub path. This makes it much easier to
use cairo_arc to draw a circular arc that is not connected to the
current path:

	cairo_new_sub_path

Degenerate paths for easier "dots"
----------------------------------
Degenerate paths are now consistently handled in a manner similar to
the PDF specification. This means that round caps can now be used to
easily draw circles (move_to, close_path, stroke), or dotted lines,
(set_dash with a 0 length for on segments).

The following function been added to complement
cairo_surface_set_device_offset:

	cairo_surface_set_fallback_resolution
	cairo_surface_get_content
	cairo_debug_reset_static_data
	cairo_surface_get_device_offset

Type querying functions
-----------------------
There are new get_type functions for querying sub-types of object:

	cairo_surface_get_type
	cairo_pattern_get_type
	cairo_font_face_get_type
	cairo_scaled_font_get_type

Scaled font query/convenience functions
---------------------------------------
More convenience in working with cairo_scaled_font_t with new getter
functions:

	cairo_scaled_font_get_font_face
	cairo_scaled_font_get_font_matrix
	cairo_scaled_font_get_ctm
	cairo_scaled_font_get_font_options

As well as a convenience function for setting a scaled font into a
cairo context:

	cairo_set_scaled_font

and a function to allow text extents to be queried directly from a
scaled font, (without requiring a cairo_surface_t or a cairo_t):

	cairo_scaled_font_text_extents

These new scaled font functions were motivated by the needs of the
pango library.

image backend
-------------
It is now possible to obtain access to the image data of any image
surface with the following new functions:

	cairo_image_surface_get_data
	cairo_image_surface_get_format
	cairo_image_surface_get_stride

xlib backend
------------
Fix potentially big performance bug by making xlib's create_similar
try harder to create a pixmap of a depth matching that of the screen.

Add the following functions to allow the user to extract all the
details of the underlying Xlib drawable from an xlib surface:

	cairo_xlib_surface_get_display
	cairo_xlib_surface_get_drawable
	cairo_xlib_surface_get_screen
	cairo_xlib_surface_get_visual
	cairo_xlib_surface_get_width
	cairo_xlib_surface_get_height
	cairo_xlib_surface_get_depth

win32 backend
-------------
Performance improvements by preferring GDI over pixman rendering when possible.
Fixes for text rendering.

Add a new function to create a font_face for an HFONT:

	cairo_win32_font_face_create_for_hfont

PostScript backend
------------------
We anticipate that with cairo 1.2, toolkits will begin to use cairo
for printing on systems that use PostScript as the spool format. To
support this use case, we have added 4 new function calls that are
specific to the PostScript backend:

	cairo_ps_surface_set_size
        cairo_ps_surface_dsc_comment
        cairo_ps_surface_dsc_begin_setup
        cairo_ps_surface_dsc_begin_page_setup

These functions allow variation of the page size/orientation from one
page to the next in the PostScript output. They also allow the toolkit
to provide per-document and per-page printer control options in a
device-independent way, (for example, by using PPD options and
emitting them as DSC comments into the PostScript output). This should
allow toolkits to provide very fine-grained control of many options
available in printers, (media size, media type, tray selection, etc.).

PDF backend
-----------
The PDF backend also provides capability for per-page size changes,
with the following API:

	cairo_pdf_surface_set_size

There has been a lot of interest in adding additional PDF-specific API
for inserting various kinds of meta-data or other structure into the
PDF output. We have avoided this in 1.2.0 since we don't yet know
exactly what the interface should look like. If you have interest or
knowledge in this area, please share your ideas with us.

SVG backend
-----------
Unlike some earlier, experimental versions of the SVG backend, the SVG
backend in cairo 1.2.0 does not have any dependency on the libxml2
library.

The SVG backend provides flexibility with regard to what version of
SVG it targets. It will target SVG 1.1 by default, which will require
image fallbacks for some of the "fancier" cairo compositing
operators. Or with the following new function calls:

	cairo_svg_surface_restrict_to_version
	cairo_svg_get_versions
	cairo_svg_version_to_string

it can be made to target SVG 1.2 in which there is native support for
these compositing operators.

Optimizations and bug fixes
---------------------------
Shortly after the 1.0 maintenance series branched off the mainline
there was a major rework of the cairo font internals. This should
provide some good performance benefits, but it's also another area
people should look at closely for potential regressions, (thanks to
Federico Mena-Quintero for already pointing out a problem with bitmap
fonts containing a very large number of glyphs).

There has not yet been any widespread, systematic optimization of
cairo, but various performance improvements have been made, (and some
of them are fairly significant). So if some things seem faster than
1.0 then things are good. If there are any performance regressions
compared to 1.0 then there is a real problem and we would like to hear
about that.

Now that 1.2.0 is done, the major focus of the cairo project over the
next few months will be on performance and optimization. We are very
interested in benchmarks demonstrating cairo call sequences that are
of interest to users. Please send your benchmarks to the cairo mailing
list for inclusion in an upcoming automated performance regression
testing environment. Ideally benchmarks should run for a (fairly
short), fixed amount of time, terminate, and print a single number.

There has been a huge number of bug fixes---too many to mention in
detail. Again, things should be better, and never worse compared to
1.0. Please let us know if your testing shows otherwise.

What's new in cairo 1.2.0 compared to 1.1.10
============================================
There has been one API addition since the cairo 1.1.10 snapshot:

	cairo_xlib_surface_get_width
	cairo_xlib_surface_get_height

There's also a new feature without any API change:

	Dots can now be drawn by using CAIRO_LINE_CAP_ROUND with
	degenerate sub-paths, (cairo_move_to() followed by either
	cairo_close_path() or a cairo_line_to() to the same location).

And at least the following bugs have been fixed:

 6759  fontconfig option AntiAlias doesn't work in cairo 1.1.2
 6955  Some characters aren't displayed when using xlib (cache u...
 7268  positive device_offset values don't work as source
 * PDF emit_glyph function needs to support bitmapped glyphs
 * PS emit_glyph function needs to support bitmapped glyphs
 * SVG emit_glyph function needs to support bitmapped glyphs
 * PDF: minefield page one is falling back unnecessarily
 * PS/PDF: Fix broken placement for vertical glyphs
 * PS: Fix to not draw BUTT-capped zero-length dash segments
 * Do device offset before float->fixed conversion
   http://bugzilla.gnome.org/show_bug.cgi?id=332266
 * PS: Fix source surfaces with transformations
 * PS: Fix to not draw BUTT-capped degnerate sub-paths
 * PS: Don't walk off end of array when printing "~>"
 * Fix some memory leaks in the test suite rig
 * SVG: Fix memory leak when using cairo_mask
 * Fix EXTEND_REFLECT and EXTEND_PAD to not crash (though these are
   still not yet fully implemented for surface patterns).

Detailed list of changes since 1.1.10
=====================================
Behdad Esfahbod:
      Note that create_similar clears surface.
      Accept CAIRO_TEST_TARGET being empty or containing a list of backends to test.
      Add test device-offset-positive.
      Correct comment about expected result in device-offset-positive test.
      Reference images for new test...
      Update .gitignore
      Add create-for-stream.* to .gitignore.
      Replace noinst_ with check_, such that nothing is built with default make
      Make configure generate cairo-features.h. Generate AC_DEFINE and AM_CONDITIONALS
      Minor refinements, mostly to configure.in.
      Removed excess mkdir.
      Pass --cache-file=config.cache and --disable-static to configure from
      Rewrite configure caching.
      Fix circular dependency in cairo.pc and cairo-xlib.pc.
      More configure foo fixes for .pc files.
      Remove config.cache in make distclean.
      Report Xlib Xrender status.
      Update list of ignored header files.
      Ignore *.bak
      Use $RELEASE_OR_SNAPSHOT to determine upload directory.
      Make docs not build by "make all", but by "make doc", "make dist", and "make
      Remove cairo_public from source files.
      Prefix "cairo_*_test_*" symbols with underscore.
      Fix support for non-pkg-config cflags and libs (needed for supporting
      Add "Since: 1.2" to docs for most new API functions.
      Mark enum additions as "Since 1.2" too.
      Require gtk-doc 1.6, and make it ignore cairo_public and cairo_private
      Update lots of docs.
      Hook some more symbols into docs.
      Remove CAIRO_SVG_VERSION_LAST from public header file.
      Minor doc syntax fixes.
      Use $no_x in configure.in.
      Fix an oops.
      Detect and report crashes in tests.
      Make CAIRO_EXTEND_REFLECT and CAIRO_EXTEND_PAD not crash on surface patterns,

Carl Worth:
      Increment CAIRO_VERSION to 1.1.11 after making the 1.1.10 snapshot
      PDF: Don't fallback due to CAIRO_ANTIALIAS_NONE
      PS PDF: Drop unused hex_digit functions, (now that output stream supports %02x)
      test/fallback-resolution: Remove extra call to cairo_show_page
      output-stream: Support %X in addition to %x
      Add new CAIRO_BITSWAP8 macro for swapping the bits within a byte.
      ft-font: Use compile-time test (WORDS_BIGENDIAN) rather than run-time function to test
endian-ness.
      SVG: Fix to not crash on bitmapped glyphs
      New bitmap-font test with bundled 6x13 font.
      PS: Add support for emitting bitmapped glyphs into type3 fonts.
      PDF: Push glyph stream creation down from emit glyph to outline/bitmap variants
      PDF: Fix display of bitmapped glyphs (bitmap-font test now passes)
      ROADMAP: Update with 1.1.10 notes as well as new blockers and fixes
      Add 'private' cairo_scaled_font_test_set_max_glyphs_cached_per_font for testing
      Add test/glyph-cache-pressure to demonstrate xlib failure (bug 6955)
      Bug 6955: Fix by adding freeze/thaw around scaled_font glyph cache in
_cairo_xlib_surface_show_glyphs
      xlib: Prefer BAIL over FAIL when the cleanup code is also used in succesful cases.
      ROADMAP: Note that bug 6955 is fixed.
      Remove comment which had been incorrectly copied
      ROADMAP: Note that SVG bitmap glyphs now work. Move some bugs to a punt list.
      Fix bug 7268: Fix coordinate space for _cairo_surface_get_extents
      ROADMAP: Note that bug 6617 might already be fixed.
      ROADMAP: Note that cairo_xlib_surface_get_width/height exist now.
      xlib: Fix failure path to do cache thawing cleanup.
      ft-text-antialias-none: Update reference images and igore list.
      ROADMAP: Note that bug 6759 is now fixed.
      Prefer using configure-generated variable for finding stdint.h or similar.
      Add documentation for how degenerate segments and sub-paths are treated.
      Prefer sub_path over subpath in identifiers.
      Prefer sub-path over subpath in documentation.
      Prefer TRUE and FALSE over 1 and 0 for assigning cairo_bool_t values
      Merge branch 'degenerate-path' into cairo
      ROADMAP: Note that degenerate path stuff has been pushed out now.
      Update reference images for ft-text-vertical-layout
      Ignore degenerate-path
      Squelch some bogus compiler warnings about possibly uninitialized values.
      PS: Fix for dash-zero-length
      Add several more stress tests to test/dash-zero-length
      Mark test/leaky-dash as an expected failure.
      Update PDF and PS reference images for test/text-pattern.
      Move device_transform of path to before floating->fixed conversion.
      Add PDF-specific reference image for composite-integer-translate-over
      Add PDF-specific reference image for paint-source-alpha
      Update PDF-specific reference image for scale-source-surface-paint
      ps: Fix transformation of source surfaces.
      ps: Fix degenerate-path test failure.
      Add ps-specific reference image for test/degenerate-path
      Add new libz/libpng suppressions.
      ps: Fix to not walk off the end of the data array.
      Add another suppression due to mysterious occurences in libc
      Add valgrind suppressions for still-reachable memory from XGetDefault and
XrmGetStringDatabase
      Add valgrind suppressions for pthread initialization still reachable/possibly lost memory
      Fix a memory leak by removing accidentally duplicated code.
      Fix some leaks in the test suite itself.
      Add yet another XrmGetStringDatabase valgrind suppression.
      SVG: Fix leak in _cairo_svg_surface_mask
      Even _more_ valgrind suppresions for Xrm (XrmGetFileDatabase this time)
      Don't remove INSTALL during maintainer-clean
      Add many references images (and a font) missing from EXTRA_DIST
      Add src/cairo-features.h and test/*.ps to CLEANFILES
      Update version to 1.2.0 and add notes to NEWS file.

Emmanuel Pacaud:
      SVG: dumb implementation of bitmap glyphs.
      SVG: fix bit order for bitmap font data and use a group with matrix

Ian Osgood:
      Update the XCB backend for screen sensitivity.

Jeff Muizelaar:
      Add new test case degenerate-path to show current 'bug'
      Initial support for degenerate-path stroking
      PS: Workaround to avoid splitting final ~> terminating sequence.

Jinghua Luo:
      Add missing prototype for _cairo_lzw_compress.
      Add ft-text-antilaias-none test case demonstrating bug #6759.
      freetype: Respect configurations in font pattern.
      freetype: cleanup _cairo_ft_scaled_glyph_init.
      freetype: Fix warnings in _decompose_glyph_outline.
      freetype: Clear target mode correctly in _cairo_ft_options_merge.
      freetype: Compare all elements in ft_options but not use memcmp.
      freetype: Don't ignore antialias in some cases.
      Turn hinting off to get consistent results for ft-text-antialias-none test case.
      Turn hinting off to get consistent results for ft-text-vertical-layout test case.

Jonathon Jongsma:
      Fix a minor documentation typo in cairo_pop_group_to_source

Keith Packard:
      Skip TrueType font output for PS/PDF until it handles vertical layout.

Kristian Høgsberg:
      Implement 0-padding and field width for _cairo_output_stream_printf().
      Add 'x' case to printf switch so we actually implement %02x.

Michael Emmel:
      Added major updates fixes and enhancements by

Robert O'Callahan:
      Surface size getters for xlib

Torsten Schoenfeld:
      Fix build after recent pixman.h change.

_______________________________________________
gnome-announce-list mailing list
gnome-announce-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-announce-list



(Log in to post comments)

Cairo release 1.2.0 now available

Posted Jul 3, 2006 23:11 UTC (Mon) by dcoutts (guest, #5387) [Link]

I am a fan of cairo. Nice output, lots of backends, easy to use API.

Well then, time for me to go update the Haskell cairo bindings (and the Gtk+ bindings to Gtk+ 2.10 for that matter).

The Cairo operating system

Posted Jul 4, 2006 6:39 UTC (Tue) by jimmybgood (guest, #26142) [Link]

An efficient and sensible vector graphics library would certainly be useful. What I don't understand is why we have to have all the backends. I don't need or have any desire for directfb and libmpeg3. I mean what's it going to do? Kill X, open a directfb session, draw a Bezier spline and then open up an X session again to antialias some text? Are we all going to have to have svga and ggi so we can use gtk+ programs? And what about the ultimate challenge, vector-based libaa? At least that's something I'd like to see.

I can smell a committee behind all this. Why not take a modular or plugin approach? Users wouldn't be obligated to load their computers down with unwanted or untrusted backends to use programs that didn't need them. Developers would be free to implement the libwoodburning3 backend if that's what they want to do.

Darn, now I've caught the Cairo operating system virus. I just opened the pricewatch.com web page to look for serial port lasers and parallel port lumber feeds. Those horrible pixelated raster wood burnings just plain suck.

The Cairo operating system

Posted Jul 4, 2006 8:47 UTC (Tue) by pharm (guest, #22305) [Link]

For starters, the Gtk Debian installer is using directfb as a backend. And there's nothing that restricts antialised text to X displays either.

Regardless, I really don't understand your objections. I guess there's the memory usage argument, but that can easily be solved by having cairo only dlopen() those libraries if they're actually used. If a backend isn't used by the application, it's associated libraries will never be touched. (I don't know whether cairo does this or not)

And all the backends have users: libmpeg3 lets you use mpeg2 decoders as a backend, for, eg, remote TV displays. directfb is used a lot in embedded devices. You want Quartz for Macs, XCB is the new Xlib replacement for X11, PS and PDF for printing (and SVG too I guess), win32 for MS, OpenGL for future-proofing against a forthcoming all-OpenGL based desktop.

And of course, nothing's stopping you compiling a 'minimal' cairo without any of these backends. Disk space is pretty cheap on modern machines though...

The Cairo operating system

Posted Jul 4, 2006 9:09 UTC (Tue) by nix (subscriber, #2304) [Link]

It *has* taken a modular / plugin approach. You're not obligated to install all the backends, and you can render to multiple 'surfaces' without disconnecting from the others.

The Cairo operating system

Posted Jul 4, 2006 17:40 UTC (Tue) by jimmybgood (guest, #26142) [Link]

The fact that cairo can render to another surface is not a comfort. That's one of my concerns. I don't want my computer busy drawing someplace that I can't see and can't control while I'm trying to work on something else.

Yes, I know I can compile programs with subsets of features, in fact I take great pleasure in doing just that. I just counted 25 features that I have turned off in my version of Seamonkey. I learned quite a while ago how to add c preprocessor commands and hack configure scripts to trim useless crap out of software.

To avoid semantic arguments, what I mean by a modular approach is like the Linux kernel. You can load the modules you want or just delete them if you don't trust them. By plug-in approach, I mean like Abiword. You have a configuration menu where you can explicitly enable or disable plug-ins. With Cairo, when it's built with libwoodburning3 support, as the Debian package maintainers will insist on doing, if you turn off your wood burning appliance, gtk+ apps will fail to load with the message, "cairo: /dev/laser0, no such device" hidden in your logs somewhere.

For most folks, though, if someone wants to install any gtk+ app in, for example, Debian, they indeed are going to be obligated to have directfb on their system. The package maintainers could add directfb support to the udeb for the installer and build the regular package without it. But package maintainers as a rule take the "kitchen sink" approach to packaging and developers should be aware of this tendency. A good example is enchant, which was originally conceived so that if an app needed a spell checker it could link to enchant and enchant would find an available spell checking backend. If there were multiple backends available, the user could choose which one he preferred for any particular purpose. The Debian maintainer, though, perverted this into requiring every backend, preventing the user from choosing which one he wanted and hiding which one was actually used.

Just because the marginal cost of hard disk storage is 50 cents per gigabyte doesn't mean a user who needs two more gigabytes can spend a dollar to solve his problem. For most people it means they have to buy a new computer for $500 with Windows XP preinstalled. The complexity, size and resource demands of software creates a significant barrier to the adoption of free/libre software by literally billions of people.

Stability and security are two concerns that affect every computer user. Every library and piece of software that is run on a computer has a chance of developing vulnerabilities, can crash or run in infinite loops. Software isn't perfect. Should glitz be packaged the same way as the other backends, a 3d driver bug could lock up my gpu and make my computer nearly useless. And if glitz isn't packaged that way, then why not package the other backends the way glitz is?

The Cairo operating system

Posted Jul 4, 2006 18:11 UTC (Tue) by dcoutts (guest, #5387) [Link]

Perhaps you should use Gentoo. It does allow you to specify which cairo backends are compiled in (and control a whole lot else besides).

The Cairo operating system

Posted Jul 4, 2006 20:49 UTC (Tue) by evgeny (guest, #774) [Link]

This might be an acceptable solution for an end-user. But for a developer, the situation is hopeless. I can't use Cairo for my non-X application, because it will always be linked to libX11 and what not.

The Cairo operating system

Posted Jul 5, 2006 15:50 UTC (Wed) by dcoutts (guest, #5387) [Link]

Huh? It's ok for an end user but not a developer?

USE="-X" emerge cairo

then it doesn't link to libX11.

Note that even if you USE="X", that doesn't mean that you can't use it on a server. It's not uncommon to have libX11 but no X server on a server machine. With modern modular X that's easy to do since X apps only depend on the X client libs and not on any X server.

The Cairo operating system

Posted Jul 5, 2006 16:02 UTC (Wed) by evgeny (guest, #774) [Link]

> USE="-X" emerge cairo

Do you suggest I should care only about Gentoo users or what?!

> It's not uncommon to have libX11 but no X server on a server machine.

Yep. Targetting at clueless sysadmins isn't my idea, either.

> With modern modular X that's easy to do since X apps only depend on the X client libs and not on any X server.

Dude, this has been the case since the first days of X11 (or even X10).

The Cairo operating system

Posted Jul 4, 2006 18:18 UTC (Tue) by jonabbey (subscriber, #2736) [Link]

The fact that cairo can render to another surface is not a comfort. That's one of my concerns. I don't want my computer busy drawing someplace that I can't see and can't control while I'm trying to work on something else.

Are you seriously worried that Cairo having an ability to render to multiple kinds of graphic devices means that your computer will sneak off behind your back and scribble on things.. just because?

The Cairo operating system

Posted Jul 4, 2006 19:58 UTC (Tue) by tetromino (subscriber, #33846) [Link]

Calm down.

First of all, Debian's cairo links to:
* libXrender (you alredy use that, otherwise your fonts will look ugly)
* libX11 (if you aren't using X11, well, why do you need Cairo?)
* libpng (you already use that, almost all modern GUI applications require it)
* libfontconfig (you are already using it if you have truetype fonts)
* libz (you are already using it since virtually all applications require it)
* standard C library
* expat (you already have it because GNOME requires it)
* glitz.

So, how can a program destabilize your system by turning on Glitz? Well, it has to explicitly tell Cairo to open a Glitz surface. Cairo won't render anything to Glitz unless the programmer who of your application tells it to render to Glitz. In other words, your beef is with the application writer who (oh horror!) is using your 3D hardware without your consent. Except that is a totally invalid point since
1. there are many, many other ways for an application to access 3D hardware (e.g. /usr/lib/libGL.so) and stab you in the back with a TEXTURED TRIANGLE OF DOOM;
and 2. if your GPU is so unstable, you could just disable glx in xorg.conf, or switch to a driver physically incapable of 3D (like nv and vesa).

And "I don't want my computer busy drawing someplace that I can't see and can't control while I'm trying to work on something else." -- what? Are you telling me that you don't have any daemons or background tasks running on your machine? Perhaps you use a single-processing system like MSDOS?

To summarize, I fail to see a single coherent point in your argument.

The Cairo operating system

Posted Jul 4, 2006 20:57 UTC (Tue) by evgeny (guest, #774) [Link]

> * libXrender (you alredy use that, otherwise your fonts will look ugly)

Nope. I was going to use Cairo to build nice-looking charts for my mamba-nyamba CGI script. No X stuff on the web server. Shall I continue?

PS. I'm not the poster you replied to, but very much share his attitude. It's a shame to not use dlopen() and friends today.

The Cairo operating system

Posted Jul 5, 2006 9:44 UTC (Wed) by nix (subscriber, #2304) [Link]

dlopen()ed shared libraries
- can't be prelinked
- don't benefit from ld.so.cache
- have to be explicitly located by the application
- don't necessarily have consistent error messages if they can't be found
(e.g. if mesa can't find the DRI libraries because you need to hack a
#define deep in the source to get it to look in the right place with
modular X, there's no message; it falls back to unusuably slow software
rendering...)
- have... interesting effects if you dlopen() a library that is already
named in a DT_NEEDED
and much else.

They're useful, but they're definitely not a panacea, and in general I prefer DT_NEEDED for stuff that isn't strictly optional or totally plugin (by 'totally plugin' I mean something like KParts, where even the name of the library to load is unknown until runtime).

The Cairo operating system

Posted Jul 5, 2006 10:42 UTC (Wed) by evgeny (guest, #774) [Link]

> - can't be prelinked

Well, yes, this is the purpose.

> - don't benefit from ld.so.cache
> - have to be explicitly located by the application

Why? From the dlopen man page, dlopen("libm.so", RTLD_LAZY); works fine without specifying explicit path.

But actually I didn't mean a mere replacement of the compile time linking with dlopen(), but rather a plugin approach - which is usually (but not always) done using dlopen() on a plugin which in turn is linked to all necessary for this specific plugin .so libs.

The Cairo operating system

Posted Jul 5, 2006 13:51 UTC (Wed) by farnz (guest, #17727) [Link]

> - can't be prelinked Well, yes, this is the purpose.
Why exactly do you want to prevent prelink(8) from working? All it does is move the cost of doing relocations to the time at which prelink is run, not runtime. By using dlopen(3), you prevent prelink from determining the relocations itself, and force the dynamic linker to recalculate the relocation values every time the library is used. For a long running process, this is no big deal (it's a once per process run cost). For desktop processes, where the user is sitting waiting for the application, any delay in startup is noticeable.

The Cairo operating system

Posted Jul 5, 2006 14:13 UTC (Wed) by evgeny (guest, #774) [Link]

> Why exactly do you want to prevent prelink(8) from working?

I want the cairo library (and hence my app) to not be prelinked against anything which is strictly necessary for the 2D rendering core itself.

> By using dlopen(3), you prevent prelink from determining the relocations itself, and force the dynamic linker to recalculate the relocation values every time the library is used.

The time needed for the dynamic linker to recalculate the relocation of a plugin (typically containing only a couple of functions) is negligible comparing to the rest of initialization of any GUI app. The rest (actual libraries doing the hard work) can be prelink'ed to the plugin object.

The Cairo operating system

Posted Jul 5, 2006 14:16 UTC (Wed) by evgeny (guest, #774) [Link]

Oops. s/which is strictly/which is NOT strictly/

The Cairo operating system

Posted Jul 5, 2006 14:43 UTC (Wed) by farnz (guest, #17727) [Link]

Your application should only be prelinked against the backends if they're installed, as your application should only be linked against the 2D rendering engine (cairo), and not against the backends. The 2D rendering engine is linked against the installed backends; when prelink does the work needed to guarantee that the runtime linker does not need to do any relocations, it'll pick up the backends.

Why does it bother you that I've done the caculations to determine how to do the relocations in advance? If you never use the DirectFB or X11 backends, that data is simply ignored, as the backend is never called, so the relocation never takes place, and the backend library is never loaded into memory.

If you're complaining because your choice of distribution doesn't provide you with some mechanism to only have the backends you need installed, bitch at your distribution, not the authors, who provide you with compile-time switches to disable the backends you don't want.

For some classes of applications, notably C++ applications, the relocation time is significant. Plus, you're ignoring the effects of hot caches; when an executable is fully prelinked, all the code pages, including the GOT and PLT, are never dirtied, so they are shared with all other executables using that library; when you've not got much RAM, not having to keep a private copy of these pages helps. This is especially true on a desktop, where the chances are high that another application is using the library, and thus has pulled the pages you'll need into memory already.

In short, you seem to be advocating that cairo drops a perfectly reasonable compile-time method for controlling which backends are installed, and goes to a runtime mechanism with some disadvantages for desktop applications, just because your distro doesn't provide a decent selection of packages without the backends you don't need. I'd like you to justify that position, or correct my misunderstanding of what you're after.

The Cairo operating system

Posted Jul 5, 2006 15:28 UTC (Wed) by evgeny (guest, #774) [Link]

> If you're complaining because your choice of distribution doesn't provide you with some mechanism to only have the backends you need installed, bitch at your distribution, not the authors, who provide you with compile-time switches to disable the backends you don't want.

I'm complaining NOT as an end-user, but as a developer. My application does NOT need X/FB/...; it's a server-level utility. As such, when I consider the use of Cairo for 2D-rendering, I ask myself: what's the chance that potential users of my app will have Cairo installed on their servers? Right now, the answer is "hardly if at all", since for most mainstream binary distros, Cairo will require X/gtk/what not, probably entire Gnome libs, so who in a sane mind would install all this cruft on e.g. a web server?! Thus, the stone-age inflexibility of Cairo precludes me from using it.

> For some classes of applications, notably C++ applications, the relocation time is significant.

Cairo is not C++, and so isn't my app.

> you seem to be advocating that cairo drops a perfectly reasonable compile-time method for controlling which backends are installed,

Huh? You call it a perfectly reasonable method? Then why don't you advocate for returning to pre-1.0 linux version when drivers were built monolithically in the kernel? or just try persuading Firefox or Gimp users and developers that compile-time selection of extensions/plugins is very reasonable, if not perfect? I bet you'd be laughed at.

> and goes to a runtime mechanism with some disadvantages for desktop applications

Do you have hard figures proving this claim? I'd expect we're talking about some milliseconds or even less, that's all.

The Cairo operating system

Posted Jul 5, 2006 16:03 UTC (Wed) by farnz (guest, #17727) [Link]

So, by the same token, I assume you avoid all libraries, in case a distribution is fool enough to build versions that depend on libraries your users won't install? If Cairo provides enough benefits to you, write to it; at the moment, you're saying that you might want to use Cairo in a situation the Cairo developers aren't designing for, but are scared to because if distributions don't provide a server-suited Cairo build, and if Cairo turns out to be the best way for you to do something, you don't think anyone (Cairo developers or distribution builders) will flex to accomodate you.

You seem to advocate changing everything at runtime or startup time; why can't I choose a different VM at startup time? Why can't Firefox drop the XUL handler, if I only need a HTML renderer without a UI? Why can't GIMP run without GTK+, if I'm only using it from the command line? If I'm not planning to use text, why does GIMP pull in FreeType and Pango?

My point is that the mechanism works for the currently intended uses of Cairo, and provides a small, but measurable benefit for them in terms of memory usage as well as time in their choice of application. It also makes their code considerably simpler to write in the first place (and yes, I've written code in both styles - dlopen is slightly harder to get right, and harder to debug if you get it wrong). You are asking them to drop that gain, in order to get into a class of applications that they're not targetting.

If using Cairo makes your application simpler, use it. If the result is that Cairo needs better backend selection (so that your users don't have to install any X11 libraries), that will happen. In the meantime, you're asking them to drop a small gain from doing things the way they've done them, for a potential future benefit.

The Cairo operating system

Posted Jul 5, 2006 16:58 UTC (Wed) by jimmybgood (guest, #26142) [Link]

> You seem to advocate changing everything at runtime or startup time; why can't I choose a different VM at startup time? Why can't Firefox drop the XUL handler, if I only need a HTML renderer without a UI? Why can't GIMP run without GTK+, if I'm only using it from the command line? If I'm not planning to use text, why does GIMP pull in FreeType and Pango?

Those possibilities are very appealing. It probably would sacrifice some performance for people who have powerful computers and want all the features anyway. But it would make it much easier for less-advantaged people the world around to install reduced feature set software on legacy computers.

Cairo is not like a new RSS aggregator that we can just delete from our computer, if we feel uncomortable with it. Gtk2 is central to the desktop. I think it's reasonable to ask the developers to consider the needs of all users, not just the power users and to anticipate the potential misuses and abuses of package managers and application writers.

On the other hand, it's still possible to have a desktop without the bloated, insecure monstrosities that QT and now GTK2 have become.

I see several comments that say to the effect, X and OpenGl do something so it's OK that Cairo does it. Let me repeat, it's easy to keep OpenGL on a tight leash and turn it off completely. As for X, it's a very old application that was written in a different era. If experienced developers were to rewrite it from scratch, if they wanted to they could make it much more controllable, stable and secure.

The Cairo operating system

Posted Jul 5, 2006 20:26 UTC (Wed) by evgeny (guest, #774) [Link]

> So, by the same token, I assume you avoid all libraries, in case a distribution is fool enough to build versions that depend on libraries your users won't install?

I avoid all libraries that invariably chain with themselves absolutely different (and optional to their core functionality) API layers.

> You seem to advocate changing everything at runtime or startup time;

I advocate for maximal flexibility (as far as it hasn't noticeable negative side effects - and in this case, it doesn't).

> why can't I choose a different VM at startup time? Why can't Firefox drop the XUL handler, if I only need a HTML renderer without a UI? Why can't GIMP run without GTK+, if I'm only using it from the command line? If I'm not planning to use text, why does GIMP pull in FreeType and Pango?

1. Not sure what you meant (i.e., in which context) by VM, but the rest would be really great. Why don't you think so?
2. In fact, in the above, "would be" should be replaced by "is". I suggest you do e.g. "ldd /usr/lib/libgimp.so" and verify that the base Gimp functionality is available in a clean (no gtk/X/...) way. This is a sign of a well-thought design.

> My point is that the mechanism works for the currently intended uses of Cairo,

No, it doesn't. The fact is you _can_ build Cairo without the X stuff and other cholesterol additions, so such a use (alongside with others) _was_ intended. Yet, when considering Cairo as a mainstream 2D rendering API (which is obviously what Cairo devs think of it as), it becomes clear that with the current monolithic design this will never be realized except in DIY distros like Gentoo.

> and provides a small, but measurable benefit for them in terms of memory usage as well as time in their choice of application.

Who cares about extra half a millisecond or a few bytes?! And are you serious the choice (i.e., monolithic vs. plugin design) was ever discussed and decided upon based on the performance considerations?

> It also makes their code considerably simpler to write in the first place

OK, now this boils down to the truth. That's the whole reason - it simply has NOT been designed/thought of/coded YET. Adding another mumbo-jumbo backend is cooler than doing the backend separation in a proper way, that's all.

Now, please notice that I'm NOT criticizing the priority list of the Cairo devs. Most of us (myself including) is coding FOSS stuff for fun. Let mumbo-jumbo be first. But please, don't call a bad design by any other name. Perhaps this will help releasing Cairo-2.0 with all the backends as optional plugins.

The Cairo operating system

Posted Jul 5, 2006 21:44 UTC (Wed) by farnz (guest, #17727) [Link]

I'm still not clear what you're after; Cairo has the needed separation between backends and core library internally. They just haven't spent the hours needed to write dlopen() boilerplate code, and their own runtime linking of backends derived from this, especially since the backend interface isn't stabilised, and thus this boilerplate code would need plenty of changes.

You're still arguing that because your distribution of choice combines a lack of flexibility in providing alternative versions of a package with maintainers unwilling to do the extra (manual) work involved in providing those alternatives, all library developers should do the extra (manual) work in working round this deficiency.

Plus, as you've said yourself, who cares about a few bytes? If you never use anything other than the SVG backend for Cairo, the other backends and their associated libraries won't be used in memory at all, and disk is even cheaper than RAM (which you're happy to burn). Indeed, if the dynamic linker is bright enough (and I've never checked this), you could delete the X11 and OpenGL backends, and not even notice that you're missing compile-time dependencies.

If it's security that worries you, I'd just like to point out that you're advocating that the Cairo developers stop making use of the dynamic linker's symbol resolution, and write their own version; there's no guarantee that this code won't be buggy. In addition, bugs in a manually coded subset of a dynamic linker are likely to lead to arbitrary code execution, not to output faults.

Here's a constructive suggestion for you; if the dynamic linker isn't bright enough to cope with missing libraries (despite the fact that they're not used), why don't you motivate someone to fix this? The result should be that your server code (which presumably never touches the DirectFB backend) can link to a version of Cairo that was compiled with all the backends, and never notice that someone didn't install the DirectFB backend. Then, your distribution of choice can compile Cairo with everything turned on, but ship it in a split set of packages with different backends.

The Cairo operating system

Posted Jul 5, 2006 22:35 UTC (Wed) by evgeny (guest, #774) [Link]

> I'm still not clear what you're after; Cairo has the needed separation between backends and core library internally. They just haven't spent the hours needed to write dlopen() boilerplate code

Exactly, that's my point.

> especially since the backend interface isn't stabilised, and thus this boilerplate code would need plenty of changes.

I don't believe it. If the internal API changes, they still need doing practically the same amount of work, be it a direct linking or glued by dlopen. As far as the core and the backends are maintained by the same team, at least - which is the case now.

> You're still arguing that because your distribution of choice combines a lack of flexibility

NO! why don't you read carefully what I've said earlier? _My_ distribution of choice (Gentoo) is flexible enough to accomodate my needs, not to mention I'm pretty much content with compiling from the source tarballs. But this doesn't matter. What I care about are _users_ of my software, which is NOT specific to Gentoo, so if a sysadmin doing e.g. "apt-get install myapp" on a server will see about entire Gnome lib pack selected (due to the deps) plus the kitchen sink, he will (and rightfully so) say "No". That's what I'm afraid of. I don't agree to cut the number of potential users of my app tenfold because of the dumb Cairo architecture.

> Plus, as you've said yourself, who cares about a few bytes?

Now you're comparing apples to the oranges...

> Here's a constructive suggestion for you; if the dynamic linker isn't bright enough to cope with missing libraries (despite the fact that they're not used), why don't you motivate someone to fix this?

Huh? May I have a contr-suggestion for you: write about this idea to LKML or the glibc maillist, or better both. And don't forget letting me know - I want to enjoy the show ;-)

The Cairo operating system

Posted Jul 7, 2006 0:26 UTC (Fri) by nix (subscriber, #2304) [Link]

It's not half a millisecond. It's hundreds of Kb per running instance and 10--20 seconds of extra startup time for applications with large numbers of symbols.

Prelinking *matters*.

(FWIW, Jakub Jelinek and Ulrich Drepper recently designed a new ELF symbol hash table format that should reduce the relocation time of non-prelinked apps by 40% or so: but that's a glibc-2.5 thing and requires apps to be relinked to benefit anyway. Plus it can't reduce the memory hit.)

The Cairo operating system

Posted Jul 7, 2006 10:40 UTC (Fri) by evgeny (guest, #774) [Link]

Oh come on, why on Earth are you continuing to talk about some thought-out-of-the-thin-air situations? Let's focus on Cairo - I'm not suggesting to convert a C++ bloatware to a thousand of plugins! Each Cairo backend (total number < 10) should have a single dlopen'd init entry! Add another one per plugin for maximal flexibility (i.e., the versioning check), but that's all.

The Cairo operating system

Posted Jul 8, 2006 22:54 UTC (Sat) by nix (subscriber, #2304) [Link]

Cairo is *in use* by large C++ applications.

I repeat: prelinking matters.

The Cairo operating system

Posted Jul 9, 2006 17:33 UTC (Sun) by evgeny (guest, #774) [Link]

I repeat: one or two dlopen's per backend in Cairo will be unnoticeable in your favorite C++ bloatware app.

The Cairo operating system

Posted Jul 6, 2006 20:27 UTC (Thu) by oak (guest, #2786) [Link]

You forgot one additional problem with dlopen() which is debugging
things for libraries which have been dlclose()d.

Trying to determine with Valgrind in a large application doing lots
of dlopen()s and dlclose()s from which dlopened library a memory
leak is coming is "interesting". Only way to debug in that situation
is to change the code not to do dlclose() which then can have some
other problems when the libraries are dlopen()d another time...

And yes, the performance and memory usage difference between
prelinked libraries and dlopen()ed libraries is very noticable
if you have a lot of them and especially if they use C++.
For large C++ program/library not being able to do prelinking
can easily waste megabytes of memory per process (if there are
tens of thousands of symbols that need resolving).

The Cairo operating system

Posted Jul 7, 2006 0:30 UTC (Fri) by nix (subscriber, #2304) [Link]

dlclose() also interacts... interestingly with VM randomization.

I found a bug in Subversion (with --enable-dso) a while back which reduces to dlopen(), store a pointer to a function in the shared object in a data structure, dlclose(); later dlopen() again, call through the function pointer, *boom*; there's no guarantee that the dlopen() is at the same address this time, and with VM randomization it's pretty much guaranteed to be different.

Oops.

I think this would likely also kill C++ RTTI through repeatedly-dlopen()ed shared libraries, since that relies on pointer comparisons. The lesson in all this is to avoid dlclose().

The Cairo operating system

Posted Jul 7, 2006 8:28 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> The lesson in all this is to avoid dlclose().

... er ... or at least to invalidate any dlsym()s you have cached when
you dlclose(), as any *sane* developer would, and look them up afresh
if/when you re-dlopen() the library.

The Cairo operating system

Posted Jul 7, 2006 10:15 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, yes, but it can be hard to keep track of such things if you're keeping pointers to some entities which are dlsym()ed from different places and others which are not, in the same data structure.

The Cairo operating system

Posted Jul 7, 2006 10:46 UTC (Fri) by evgeny (guest, #774) [Link]

Why the hell do you need to unregister a backend (except for atexit time)? I know of no plugin-enabled app (Gimp/Firefox/...) that allow for run-time plugin unloading. Even in the kernel support for rmmod is a non-default option.

The Cairo operating system

Posted Jul 7, 2006 19:38 UTC (Fri) by oak (guest, #2786) [Link]

If you need to change the backend. For example when you migrate your
application window from local display (with OpenGL support) to a remote
display. Gtk has already some support for display migration.

For something like in-process panel applets dlclose() & dlopen()
make sense. User might very well want to change the panel applets
at run-time...

The Cairo operating system

Posted Jul 7, 2006 20:01 UTC (Fri) by evgeny (guest, #774) [Link]

Fine, but this still doesn't explain why you insist on closing the first _backend_? What you describe is switching from an _instance_ of a device to an instance of another device. Say, the X11 device, once registered, could allow you to have several Drawables (Pixmap/Window) in the same app - e.g., one for the main window, another one for File/Open... preview, etc, which doesn't mean the X11 device plugin should be registered/unregistered each time. Just as the dynamic loader does symbol resolving only once, similarly, all available/enabled backend plugins need to be initiated only once.

The Cairo operating system

Posted Jul 7, 2006 20:24 UTC (Fri) by oak (guest, #2786) [Link]

> Fine, but this still doesn't explain why you insist on closing
> the first _backend_?

I did not say any such thing. :-)
I was merely commenting on the pros&cons of dlopen() and dlclose().
Whether some piece of code actually uses them, is up to the code...


> Say, the X11 device, once registered, could allow you to have several
> Drawables (Pixmap/Window) in the same app - e.g., one for the main
> window, another one for File/Open...

Note that those are different windows. (X) display migration means
moving all of applications (open) windows from one (e.g. local) X server
to another X server. For example you take a PDA with you to a meeting
and you want to show something you've scribbled with it briefly on the
projector before continuing using the same program. Or you have in your
desktop machine multiple graphics cards each running a separate X server
and you want to migrate some of your apps from one X server to another
*without closing* the apps.

The Cairo operating system

Posted Jul 4, 2006 21:18 UTC (Tue) by jimmybgood (guest, #26142) [Link]

Well, it turns out the Debian maintainers were more sensible than I gave them credit for and did compile cairo2-directfb as a separate package. The dependency on libdirectfb came from libcairo2-dev not libcairo2 itself. So libdirectfb0 is just useless cruft not the dangerous cruft it would be, were it to be actually linked to. And I tried directfb recently. It did such a number on my video card that I had to turn my machine off and unplug it from the wall to get the card to reset.

This could change at any time, though, and I bet within a year Debian will start requiring directfb for anyone who wants gtk+. They recently did this with SDL, prompting me to build my own packages without directfb support.

I don't object to any of cairo's possibilities. I'm concerned about the ability to make an informed choice. Right now I can choose to run GL screensavers or I can easily choose to turn them off if I'm working on something important and might walk away from the computer for more than 5 minutes. I can choose which daemons and cron jobs I want to run and which I don't. But, I don't see any mechanism in cairo that allows me to select which backends I wish to use and which I'd rather not.

Do I really have to have a reason that's approved by someone who starts their post by giving me an order?

BTW, is there a milestone for implementation of the libwoodburning3 backend or is that just a rumor started by some troll to poke fun at the Cairo project?

The Cairo operating system

Posted Jul 5, 2006 9:38 UTC (Wed) by nix (subscriber, #2304) [Link]

The fact that cairo can render to another surface is not a comfort. That's one of my concerns. I don't want my computer busy drawing someplace that I can't see and can't control while I'm trying to work on something else.
I hope you've stopped using X then, and especially OpenGL, because rendering to off-screen surfaces is explicitly a feature of that.

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds