[cairo] problem regarding cairo-gl

[Eric Anholt]

On Thu, 2009-05-07 at 13:09 +0530, Yogesh Gole wrote:
> 
> 
> 
>         
>         > Hi,
>         >
>         > I am using cairo-gl from
>         > http://cgit.freedesktop.org/~anholt/cairo/tree/?h=gl,
>         >
>         > and i tried to run cairo-perf, but while calling
>         glGenFramebuffersEXT
>         > (all gl extensions functions),
>         >
>         > It gives following error message and continues
>         >
>         > Mesa 7.0.3-rc2 implementation error: User called no-op
>         dispatch
>         > function (an unsupported extension function?)
>         > Please report at bugzilla.freedesktop.org
>         
>         
>         Sorry about that!  It's one of the things I noted before that
>         needs to
>         be fixed before it sees serious use -- the cairo-gl backend
>         currently
>         doesn't check for OpenGL extensions it uses.  My plan is to
>         use GLEW, a
>         nice[1] library that hides the pain of OpenGL extension
>         handling.

Turns out I'd already done this and forgotten to push it.  It's in my
tree now.

>         So, you need EXT_framebuffer_object and
>         ARB_texture_non_power_of_two to
>         use cairo-gl currently.  If you're using the Intel graphics
>         driver,
>         you'll get EXT_framebuffer_object once you update your kernel,
>         2D
>         driver, and Mesa to something recent (I'd recommend 2.6.29.2,
>         2.7.0, and
>         7.4 respectively), and it'll be coming to Radeon with the KMS
>         development by Dave Airlie and Jerome Glisse.
>         
>         The ARB_texture_non_power_of_two requirement could be relaxed
>         with some
>         minor work, and would let cairo-gl work on pre-915 hardware.
>         
>         [1] OK, GLEW is almost nice, except that it lacks a pkgconfig
>         file.  So
>         it's ugly to build against, but the C API you get in the end
>         is what you
>         always wished using OpenGL was like.  And I'll forgive just
>         about
>         anything to get that.
>         
>         --
>         Eric Anholt
>         eric at anholt.net                         eric.anholt at intel.com
>         
>         
> 
> 
> Thanks for replying,
> Now, it is working properly,
> 
> i ran cairo-perf and found that cairo-gl is slower than
> cairo-xrender/xlib or cairo-glitz backend.

cairo-perf is mostly a collection of microbenchmarks.  They can be
useful for tuning small pieces of code you're working on, but I'm
generally more interested in performance on macrobenchmarks.
Unfortunately, we're pretty bad about these for desktop X usage.

But I know there's plenty that needs to be fixed in cairo-gl without
needing more data yet.  It's still somewhere between the "make it work"
and "make it work correctly" stage of development, and only after that
is "make it work fast" really a priority.  Thus why I haven't pushed at
all for getting it into cairo yet.

For those interested in performance, there are a few major things to be
done:
- Use fragment shaders to generate gradient content directly in
compositing rather than generating it to a temporary buffer in software
first.
- Use the span renderer to avoid generating trapezoids to a temporary
buffer.
- Implement span renderer usage for strokes as well as fills (cairo
core)
- Research how to generate *antialiased* stroke/fills directly from
incoming path data rather than tessellating to traps or spans.  The
Microsoft page I saw was showing demos of what they'd done, but didn't
have the math explaining it.
- Hook up cairo-trace for cairo-gl so we can capture traces from things
we actually care about (firefox, swfdec, inkscape, etc.) and profile
them.  Or do some cairo-traces with xlib and tweak them for use as
cairogl testcases.

If these, I've got #2 partially done -- I'm generating spans into a
temporary using hardware acceleration (VBOs full of GL_LINES).  It's
slightly slower than sw rasterization with texture upload.  The next
step for that is to skip the temporary and just use that geometry, which
is where the payoff should be.  Check out gl-span-renderer for the code.

> but i read from following link that cairo-gl backend is faster than
> cairo-xrender.

It is for me on cairogears, which does a collection of non-axis-aligned
strokes and fills, which is probably a pretty favorable test for direct
rendering since it's testing the weakest part of xrender.  My excuse is
that when I go look at profiles of cairo apps when they're sucking my
CPU's will to live, it's in these sorts of trapezoid rasterization
paths :)

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20090510/cfd7b58e/attachment.pgp