<div dir="ltr">On Thu, Apr 25, 2013 at 1:57 AM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Wed, Apr 24, 2013 at 04:07:12PM -0600, Mike Steinert wrote:<br>

>    I'm currently working on improving the DirectFB backend.<br>
>    Is anybody else working on the DirectFB backend? I would prefer not to<br>
>    duplicate work!<br>
>    Would these changes be welcomed as a patch? If so, is it better to submit<br>
>    a few smaller patches or submit everything once it's complete?<br>
>    I currently have the surface acquisition code working with the software<br>
>    renderer. I'm starting to look into the new(ish) compositor interface.<br>
>    Initially I was looking at cairo-xlib-core-compositor.c for hints but now<br>
>    I'm wondering if cairo-xlib-render-compositor.c (or perhaps something<br>
>    else) would be a better starting point. Any hints here would be greatly<br>
>    appreciated.<br>
<br>
</div></div>For the directfb backend, what you want to start with is management of<br>
a shadow surface (which may just be a locked surface, it depends on<br>
where those pixels are in memory - i.e. if they are uncached, then using<br>
those directly would be disastrous for performance) and a damage<br>
tracking interface. So basically just a fallback compositor.<br></blockquote><div><br></div><div style>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:</div>
<div style><br></div><div style><a href="https://github.com/msteinert/cairo/commits/directfb">https://github.com/msteinert/cairo/commits/directfb</a><br></div><div style><br></div><div style>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?</div>
<div><br></div><div style>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
cairo-xlib-render-compositor.c would only be an interesting comparison<br>
if directfb gained a useful set of acceleration primitives. If it has,<br>
then you would probably want to write a compositor to first try and use<br>
the acceleration and then fallback to the damage tracked surface.<span class=""><font color="#888888"><br>
</font></span></blockquote></div><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Thanks for your insight and suggestions, they're greatly appreciated.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
-- </div><div class="gmail_extra" style>Mike</div></div>