[cairo] Re: [Mesa3d-dev] Points in Cairo Glitz paper

[Keith Packard]

Around 12 o'clock on Apr 22, Jon Smirl wrote:

> It's not about the performance of a specific app, it's about building a whole
> bunch of future desktop software that can't easily have it's drawing
> accelerated.

I guess I don't understand what parts of cairo aren't "easily accelerated".
I thought that Glitz demonstrated that this isn't true on modern hardware,
and that modest changes in the Glitz library, or perhaps the cairo
interface would resolve some performance issues on other hardware as well.

> Do display quality and ease of use real improve enough to justify doing
> things that don't map easily to the hardware? After all, given the life
> span of X we're going to be staring at these decisions for the next ten
> years.

Cairo is designed to provide a "PDF 1.4"-like API.  That particular
rendering architecture has been a stable part of the 2D landscape for years
and doesn't appear to be going anywhere soon.  Someone has to connect this
well known and fundemental 2D abstraction with the graphics system.  2D
graphics is fairly unique in its near-universal acceptance of PDF-1.4 as
the single common drawing abstraction; we can't just ignore that and 
create something on our own.

It's possible that some parts of this standard abstraction will prove a
difficult match with 3D hardware.  To a great extent, that's "too bad". We
can't exactly rewrite the SVG and PDF specifications to match our desires.

What we can do, however, is to build on that API in the future.  We can
provide new or altered functionality for application developers that fits
within the framework and yet provides capabilities better matched for 3D
hardware.  Careful design will still allow for conversion to PostScript,
PDF, SVG or whatever.

We should also continue to ensure that the internal structure of cairo not
accidentally eliminate optimization opportunities.  This is the reason we
departed from our initial goal of a standard back-end API for cairo -- we
kept finding serious problems in our back-end abstraction as we moved to
new rendering systems.  Finally, we just pulled all of the back-ends inside
the cairo library so that we could mutate these (now) internal interfaces
at will.

Any performance problems which can be solved by changing how cairo is
implemented should be considered bugs.  Performance issues rooted in
differences between PDF 1.4 rendering and the underlying graphics system
will have to be accepted as the cost of supporting this standard 2D drawing
model.

And, remember that cairo is just a user-mode library; there's nothing about
it which stands in the way of an alternate 2D API from sprouting alongside
and providing functionality better suited to 3D hardware.  Using cairo as a
gateway to non-GL APIs would ensure equivalent portability.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040422/d8aec287/attachment.pgp