[cairo] Does Cairo Use Hardware Acceleration?

[Anthony Walter]

My question mirrored here with videos: http://www.codebot.org/cross/?doc=9588

I am working on an open source project that provides a unified and
simplified cross platform 2D vector animation programming interface.
It is powered by different back ends on different platforms. On
Windows it uses Direct2D when available with a fallback to GDI+. On
Linux when Gnome is available it user uses Cairo (I am also
considering a QPainter back end for KDE). On OSX and iOS the my API
implementation uses Quartz 2D.

My question is related to describing the various back ends to other
programmers using my system.

Would I be truthful if I were to describe to users of my API that the
Cairo implementation is hardware accelerated?

That is, does Cairo on a Linux distribution, such as Ubuntu 12.04,
with proprietary Nvidia drivers installed and the correct hardware
installed make much of the GPU (OpenGL) any if at all? And if so,
which portions, functions, percentage of Cairo use the GPU to
accelerate rendering? the more information I can get, the better
documentation I can provide to users of my project, and I'd be very
appreciative of your honest assessment of Cairo's performance using
different hardware.

The answers you give me might help me better describe how Cairo works.
I don't want to start off the release of my open source project by
feeding users of my project bad information. Also, if anyone can feed
me some links or information about how much of graphics hardware the
other API users, I'd appreciate that as well.

Thank you.

[Henry (Yu) Song - SISA]

The short and definite answer to your question is yes - cairo can use GL backend if you use cairo_gl_surface.

Now the long answer

1. depending on your driver quality and how you use gl_surface, you might not see performance boost vs. image-backend, reasons for that varies from driver to driver. The most important is because of GL context switches, unlike mesa-based driver, proprietary drivers usually have very expensive gl context switches (glXMakeCurrent) - thus you are advised to add cairo_gl_device_set_thread_aware (device, FALSE) to avoid unnecessary context switch if-and-only-if your app meets the following conditions

A. Your app is not multi-threading that multiple threads will access a same GL context
B. You generate a GL Context that that only cairo is the only one that uses that GL context - if you mix cairo/gl and raw gl calls, you cannot set thread aware to false.

2. Now once that is done, you need also consider your driver supports MSAA vs non-MSAA (glxinfo -v | grep multiSample to get idea of driver MSAA supports). If your driver does not support MSAA, you are likely using a slow path for rendering in GL, and you might see slow performance vs image-based cairo.

3. If your driver supports MSAA, then you need to add GLX_SAMPLES, n (where n can be 2, 4, 8, 16), GLX_SAMPL_BUFFERS, 1, and GLX_STENCIL_SIZE, 1 to your glx attributes when you initialize GL context.

4. There is now two paths in cairo/gl supprt - one is using span/traps compositor that line-scanning of geometries which is slow. The second path is msaa compositor that takes advantage of MSAA capability of driver. Unfortunately, msaa compositor has not been entriely upstreamed. If you want to get it, please visit http://code.google.com/p/cairogles - we are trying to sync it with cairo-1.12.4 at this moment, so please use release-1.12.4 branch once you checked out. It has a little problem with gles, but I think GL works fine.

5. To use msaa compositor, please set your env CAIRO_GL_COMPOSITOR=msaa - we hope once it is upstreamed, it can be a default compositor.

Since you mentioned you are using nvidia driver (not nouveau) - I am pretty sure that you should use msaa compositor that can give quite fast performance (I don't have nvidia, but on fglrx it is fast).

Now you also mention that gnome - gnome uses cairo, but I am not sure it uses cairo_image_surface or cairo_gl_surface - I think it is the former, in that case, you won't see acceleration.

Your last question - how much of graphics acceleration other API uses? - I am not sure I understand it. I can be of help if you clarify though.

Hope this helps

________________________________________
From: cairo-bounces+hsong=sisa.samsung.com at cairographics.org [cairo-bounces+hsong=sisa.samsung.com at cairographics.org] on behalf of Anthony Walter [sysrpl at gmail.com]
Sent: Tuesday, October 09, 2012 5:59 PM
To: cairo at cairographics.org
Subject: [cairo] Does Cairo Use Hardware Acceleration?

My question mirrored here with videos: http://www.codebot.org/cross/?doc=9588

I am working on an open source project that provides a unified and
simplified cross platform 2D vector animation programming interface.
It is powered by different back ends on different platforms. On
Windows it uses Direct2D when available with a fallback to GDI+. On
Linux when Gnome is available it user uses Cairo (I am also
considering a QPainter back end for KDE). On OSX and iOS the my API
implementation uses Quartz 2D.

My question is related to describing the various back ends to other
programmers using my system.

Would I be truthful if I were to describe to users of my API that the
Cairo implementation is hardware accelerated?

That is, does Cairo on a Linux distribution, such as Ubuntu 12.04,
with proprietary Nvidia drivers installed and the correct hardware
installed make much of the GPU (OpenGL) any if at all? And if so,
which portions, functions, percentage of Cairo use the GPU to
accelerate rendering? the more information I can get, the better
documentation I can provide to users of my project, and I'd be very
appreciative of your honest assessment of Cairo's performance using
different hardware.

The answers you give me might help me better describe how Cairo works.
I don't want to start off the release of my open source project by
feeding users of my project bad information. Also, if anyone can feed
me some links or information about how much of graphics hardware the
other API users, I'd appreciate that as well.

Thank you.

[Anthony Walter]

Thank you for that useful information. It's interesting that you
mention cairo_gl_surface. I did some google searching on that function
and found little information about it. I've done a bit of OpenGL
development before including creating and managing GL contexts, so
some of what you mentioned is familiar to me.

My source code Cairo import unit doesn't define any OpenGL related
routines. I am going to go ahead an assume I would need to build Cairo
from source with the proper flags to enable an OpenGL render path. Can
you tell me if the Cairo OpenGL render path would work on Windows and
OSX in addition to Linux? Also, when building Cairo is the result and
only dependency I need either libcairo.so or libcairo.a or a static
lib on Linux, and libcairo.dll on Windows?

Also, I am using Pango with the Pango-Cairo bridge functions such as
"pango_cairo_create_layout". Does Pango work equally well with an
OpenGL based Cairo context?

As for my current work, so far I am using a Gtk+ window and creating a
cairo context with the GdkDrawable* passed to the expose event like
so:

cr = gdk_cairo_create(drawable);
//.. cairo draw code here
cairo_destroy(cr);

Or alternately painting to the window using a loop where I invoke code
similar to the following:

GdkRegion* region = gdk_drawable_get_clip_region(drawable);
gdk_window_begin_paint_region(drawable, region);
gdk_region_destroy(region);
cr = gdk_cairo_create(drawable);
//.. cairo draw code here
cairo_destroy(cr);
gdk_window_end_paint(drawable);

I am running Ubuntu 12.04 with compositing effects on and proprietary
drivers installed. My test laptop has an Nvidia 8600M video card in
it, which was a mid range mobile graphics card in 2008. The rendering
seems to vary with scene complexity and some effects or rendering
types seem to slow down the render more than others.

>From what you said, it sounds like possible hardware is not being used
with approach, but maybe it is? Could anyone shed a more definitive
light on the two paths I described above?

Thanks again.

[Henry (Yu) Song - SISA]

Let me answer your questions one-by-one

1. build cairo GL - yes, you need to build from source "./configure --prefix=your_install_directory --enable-gl=yes"

2. cairo GL on windows - there is a binding of wgl and cairo. However, it has not been (to best of my knowledge) paid as much attention as on other platforms. So it is very likely it is not optimized, for example, cairo_gl_device_set_thread_aware() has no effect on wgl. In addition, I believe OpenGL on windows only expose GL 1.0 API, other GL calls must go through getprocaddress(), this makes cairo/gl not compilable at this moment (someone on the mailing mentioned/fixed it, but I did not keep a close eye on it).

3. cairo GL on OSX - there is no native binding to apple's objc-based opengl context. The only way is running cairo under the X that uses glx. You need to use macport to get mesa driver, and other utlilities, such as pixman, fontconfig, freetype, libz, among others. There is, however, a quartz backend for cairo that you can use. However, cairo quartz may not be as fast as GL backend and extend_pad/reflect does not work because quartz does not support them.

4. compiling/linking with cairo - I will use Linux as example - "gcc -o app app.c `pkg-config --libs --cflags cairo gtk+-2.0` should do it

5. pango-cairo - I don't know about it, maybe someone else knows?

6. gtk/gdk with cairo - the provided gtk API for cairo are all software based. However, you can roll your own dice:

/* create a 480x800 window gl surface in cairo */
cairo_surface_t *window_surface = cairo_gl_surface_create_for_window (device,
GDK_WINDOW_XID (gtk_widget_get_window(widget)), 480, 800);
/* once you done drawing, swap buffer */
cairo_gl_surface_swapbuffers (window_surface);

Hope these help

Henry
________________________________________
From: cairo-bounces+henry.song=samsung.com at cairographics.org [cairo-bounces+henry.song=samsung.com at cairographics.org] on behalf of Anthony Walter [sysrpl at gmail.com]
Sent: Tuesday, October 09, 2012 8:43 PM
To: Henry (Yu) Song - SISA
Cc: cairo at cairographics.org
Subject: Re: [cairo] Does Cairo Use Hardware Acceleration?

Thank you for that useful information. It's interesting that you
mention cairo_gl_surface. I did some google searching on that function
and found little information about it. I've done a bit of OpenGL
development before including creating and managing GL contexts, so
some of what you mentioned is familiar to me.

My source code Cairo import unit doesn't define any OpenGL related
routines. I am going to go ahead an assume I would need to build Cairo
from source with the proper flags to enable an OpenGL render path. Can
you tell me if the Cairo OpenGL render path would work on Windows and
OSX in addition to Linux? Also, when building Cairo is the result and
only dependency I need either libcairo.so or libcairo.a or a static
lib on Linux, and libcairo.dll on Windows?

Also, I am using Pango with the Pango-Cairo bridge functions such as
"pango_cairo_create_layout". Does Pango work equally well with an
OpenGL based Cairo context?

As for my current work, so far I am using a Gtk+ window and creating a
cairo context with the GdkDrawable* passed to the expose event like
so:

cr = gdk_cairo_create(drawable);
//.. cairo draw code here
cairo_destroy(cr);

Or alternately painting to the window using a loop where I invoke code
similar to the following:

GdkRegion* region = gdk_drawable_get_clip_region(drawable);
gdk_window_begin_paint_region(drawable, region);
gdk_region_destroy(region);
cr = gdk_cairo_create(drawable);
//.. cairo draw code here
cairo_destroy(cr);
gdk_window_end_paint(drawable);

I am running Ubuntu 12.04 with compositing effects on and proprietary
drivers installed. My test laptop has an Nvidia 8600M video card in
it, which was a mid range mobile graphics card in 2008. The rendering
seems to vary with scene complexity and some effects or rendering
types seem to slow down the render more than others.

>From what you said, it sounds like possible hardware is not being used
with approach, but maybe it is? Could anyone shed a more definitive
light on the two paths I described above?

Thanks again.

[Chris Wilson]

On Tue, 9 Oct 2012 20:59:33 -0400, Anthony Walter <sysrpl at gmail.com> wrote:
> My question mirrored here with videos: http://www.codebot.org/cross/?doc=9588
>
> I am working on an open source project that provides a unified and
> simplified cross platform 2D vector animation programming interface.
> It is powered by different back ends on different platforms. On
> Windows it uses Direct2D when available with a fallback to GDI+. On
> Linux when Gnome is available it user uses Cairo (I am also
> considering a QPainter back end for KDE). On OSX and iOS the my API
> implementation uses Quartz 2D.
>
> My question is related to describing the various back ends to other
> programmers using my system.
>
> Would I be truthful if I were to describe to users of my API that the
> Cairo implementation is hardware accelerated?

Yes. cairo supports a number of backends, which it uses is under your
control.

cairo-image: pure CPU rasterisation
cairo-gl: use OpenGL for GPU compositing and some rasterisation, depends
upon driver quality
cairo-xlib: use XRender to send commands to X which uses the GPU for
compositing and some rasterisation, depends upon driver quality
cairo-quartz: use Quartz to offload some commands to the GPU
cairo-win32: uses image + GDI blitting, one day should have a d2d
backend

On the Linux desktop, both Nvidia and Intel have very good XRender
drivers which are much faster than trying to feed cairo through OpenGL.
fglrx (catalyst) is not good at cairo-gl or cairo-xlib. The open source
EXA drivers (nouveau and radeon) are more or less equally bad at cairo-gl
and cairo-xlib.

Depending on the mix of operations, using a cairo-image and SHM
transport provides a very good baseline for performance.

> That is, does Cairo on a Linux distribution, such as Ubuntu 12.04,
> with proprietary Nvidia drivers installed and the correct hardware
> installed make much of the GPU (OpenGL) any if at all? And if so,
> which portions, functions, percentage of Cairo use the GPU to
> accelerate rendering? the more information I can get, the better
> documentation I can provide to users of my project, and I'd be very
> appreciative of your honest assessment of Cairo's performance using
> different hardware.

cairo uses XRender to talk to X. This means cairo has to convert paths
into trapezoids, which is computationally very expensive. Then Nvidia
uses a trapezoid shader along with shaders to describe the sources to
composite that onto the destination using the GPU. So more or less
everything after converting the path into geometry is accelerated by
Nvidia. Both Nvidia and Intel would like to feed the path to X so that
we can offload the geometry generation as well.

cairo-gl has some more flexibility and can offload more of the geometry
generation (or rather bypass such generation by using alternative
algorithms). cairo-gl also uses shaders to describe all the source
patterns, within the OpenGL limits. It does not yet try to split
operations that exceed those limits (and so will incur sw fallbacks in
those surprisingly regular corner-cases).

> The answers you give me might help me better describe how Cairo works.
> I don't want to start off the release of my open source project by
> feeding users of my project bad information. Also, if anyone can feed
> me some links or information about how much of graphics hardware the
> other API users, I'd appreciate that as well.

QPainter is taking the approach of dropping acceleration on X and using
their own CPU raster engine. (For their sakes, I hope it is much
improved since the last time I looked at it.)

Basically, it already sounds like you have invented your own Cairo, and
would make an invaluable contributor :) Please do have a look at what
Cairo offers and your suggestions are very welcome.
-Chris

--
Chris Wilson, Intel Open Source Technology Centre

[Anthony Walter]

Chris,

Thank you for the information. Regarding contributing to Cairo as a
team member, I am sorry I don't have much (any) experience working in
a team environment or with an OSS project.

I can do pulls from svn, and I have a git hub account and have managed
to send my own changes and notes using git, but only for my own
projects. I haven't had to deal with working with other people. This
project is my first attempt at that and I am unfamiliar with managing
patches, merges, commits, or branches from others. What I need is a
mentor in that area to help me get started.

What I can offer is some advice on Direct2D. I made the first request
to Microsoft to take on the project and started the Wikipedia article
on it. Part of my API bridges some gaps in Direct2D which Cairo would
need to replicate if it were to have a Direct2D back end, and since my
API is modeled mostly after Cairo, albeit in an OO manner, much of
what I've written could be ported back to a Cairo Direct2D back end
relatively easily.

Specifically copying bitmaps (patterns or surfaces in Cairo) between
contexts. In Direct2D this is a problem since some resources (brushes
and bitmaps) as device dependent. The solution I came up with is to
make sure render targets are compatible and using sharable bitmaps to
copy between render targets. This is essentially what I was asking
about in Cairo when I posted this question a month ago:

http://stackoverflow.com/questions/12104147/how-to-stretch-draw-a-cairo-gdk-pixbuf-pattern-region-with-an-arbitrary-opacity

Anyhow, this is a bit off topic from the original question related to
this thread. If anyone would like to discuss making Direct2D work like
Cairo, I can offer advice because I've already done it once and have
knowledge of its problems/performance tuning. If anyone wants to
message me privately about that sort of thing I've be happy to help.