[cairo] DirectFB

[Mike Steinert]

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:

https://github.com/msteinert/cairo/commits/directfb

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.

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