[cairo] DirectFB

Mike Steinert mike.steinert at gmail.com
Thu Apr 25 10:58:17 PDT 2013

On Thu, Apr 25, 2013 at 1:57 AM, Chris Wilson <chris at chris-wilson.co.uk>wrote:

> On Wed, Apr 24, 2013 at 04:07:12PM -0600, Mike Steinert wrote:
> >    I'm currently working on improving the DirectFB backend.
> >    Is anybody else working on the DirectFB backend? I would prefer not to
> >    duplicate work!
> >    Would these changes be welcomed as a patch? If so, is it better to
> submit
> >    a few smaller patches or submit everything once it's complete?
> >    I currently have the surface acquisition code working with the
> software
> >    renderer. I'm starting to look into the new(ish) compositor interface.
> >    Initially I was looking at cairo-xlib-core-compositor.c for hints but
> now
> >    I'm wondering if cairo-xlib-render-compositor.c (or perhaps something
> >    else) would be a better starting point. Any hints here would be
> greatly
> >    appreciated.
> For the directfb backend, what you want to start with is management of
> a shadow surface (which may just be a locked surface, it depends on
> where those pixels are in memory - i.e. if they are uncached, then using
> those directly would be disastrous for performance) and a damage
> tracking interface. So basically just a fallback compositor.

I'm currently using an approach you've suggested here, i.e. a locked
DirectFB surface. I have a git tree if you're willing to take a look at my
progress so far:


I believe the caching details will be left up to the backend that DirectFB
is using using. I'm targeting a Broadcom 7420 where DirectFB is provided as
a high-level interface to their 2D hardware. The implementation is on top
of Broadcom's graphics drivers which handles the caching/flushing/etc.
Perhaps other backends are uncached, e.g. fbdev?

Damage tracking is a good idea. If I understand you correctly, the surfaces
would track damage and provide an interface so a minimal area could be
computed prior to flipping the display buffer.

cairo-xlib-render-compositor.c would only be an interesting comparison
> if directfb gained a useful set of acceleration primitives. If it has,
> then you would probably want to write a compositor to first try and use
> the acceleration and then fallback to the damage tracked surface.

For the 2D hardware I'm interested in DirectFB has acceleration for blits
and fills. I've been able to accelerate solid fills so far basing my work
off of cairo-xlib-core-compositor.c. I'll continue down this path unless
somebody has a better idea.

Thanks for your insight and suggestions, they're greatly appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20130425/1821402e/attachment.html>

More information about the cairo mailing list