<br><br><div class="gmail_quote">On Fri, Nov 20, 2009 at 1:45 PM, Chris Wilson <span dir="ltr">&lt;<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Excerpts from Lionel Landwerlin&#39;s message of Fri Nov 20 09:39:11 +0000 2009:<br>
<div class="im">&gt; Hi folks,<br>
&gt;<br>
&gt; I&#39;m working with buildroot (<a href="http://buildroot.org/" target="_blank">http://buildroot.org/</a>) to generate rootfs for<br>
&gt; embedded systems.<br>
&gt; I&#39;m trying to upgrade the current cairo package in buildroot to the  1.8.8<br>
&gt; version. The current package uses cairo-1.6.4 + one patch.<br>
&gt;<br>
</div><div class="im">&gt; I reapplied manually the patch and found that most of it has already been<br>
&gt; applied in the 1.8.8 version, some other part has been rewritten and there<br>
&gt; is only one part which bother me.<br>
&gt;<br>
</div><div class="im">&gt; Does someone know why theses ReleaseSource calls has been added ?<br>
&gt; I guess this has something to do with the fact that cairo owns a lock on the<br>
&gt; surfaces that requires frequent EngineSync calls when blitting (which slows<br>
&gt; down the hardware acceleration), but I&#39;m not really sure.<br>
<br>
</div>The commit that added ReleaseSurface is a good example of the style that we<br>
need to avoid:<br>
<br>
commit 08516d97a1b34cbb119d6d842ae31e4cb4e08740<br>
Author: Claudio Ciccani &lt;<a href="mailto:klan@directfb.org">klan@directfb.org</a>&gt;<br>
Date:   Mon Dec 10 18:54:01 2007 +0100<br>
<br>
[cairo-directfb] Merging from <a href="http://directfb.org" target="_blank">directfb.org</a><br>
<br>
- Improved performance in case of surface conversion: allocate a shadow buffer that can only grow<br>
- Fixed support for small surfaces (less than 8x8)<br>
- Optimize the blending function according to the surface format<br>
- Added _directfb_categorize_operation(): selects the blitting function according to the transform matrix<br>
- Avoid inverting the matrix when doing a simple StretchBlit()<br>
- Use TextureTriangles() instead of StretchBlit() when scale factors are negative<br>
- Added support for ARGB32 fonts (converted to A8 internally)<br>
- Removed unused functions (flush() and mark_dirty_rectangle())<br>
- Code cosmetics<br>
<br>
So we have no idea why ReleaseSurface is required.<br></blockquote><div><br>Ok, thanks.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
Lionel, can you give a quick pitch on why I should not simply delete<br>
the directfb backend? From my reading of the code, it will only<br>
attempt to accelerate the simplest of blits and blends [though, that<br>
includes solid glyphs]. Everything else will trigger fallbacks. So is<br>
there any justification for Cairo to continue to have a DirectFB backend?<br></blockquote><div><br>I&#39;m probably not the better person to answer this question. But I can try :<br><br>DirectFB is still mainly used in environments with a reduced amount of memory.<br>
I can speak about set top boxes, where the amount memory needed to decode a<br>full hd video lets a lot less RAM for graphic components. Of courses with Intel<br>CE31xx chips you can rely on the PowerVR&#39;s OpenGL/OpenVG implementations to<br>
accelerate cairo operations. But some of the biggest chips makers only integrate<br>2D blitter in their chips and implementing a DirectFB driver remains simpler than<br>an OpenVG one.<br><br>Blits/blends, it&#39;s at least, it&#39;s better than nothing... For more, since directfb 1.2, there is a<br>
SetMatrix method on the Surface object, currently unused in the cairo backend.<br>(But I know most of the drivers doesn&#39;t implement it...)<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

At the moment I&#39;m radically changing the internal interfaces, that will<br>
reduce the directfb backend to being basically a wrapper around the<br>
image surface, and I&#39;m not sure if that is worth the effort. (The effort<br>
principally be in writing better glyph support.)<br>
-ickle<br>
<font color="#888888">--<br>
Chris Wilson, Intel Open Source Technology Centre<br>
</font></blockquote></div><br>Thx for your response.<br><br>--<br>Lionel<br>