<div class="gmail_quote">On Fri, Nov 20, 2009 at 1:45 PM, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote: <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's message of Fri Nov 20 09:39:11 +0000 2009: <div class="im">> Hi folks, > > I'm working with buildroot (<a href="http://buildroot.org/" target="_blank">http://buildroot.org/</a>) to generate rootfs for > embedded systems. > I'm trying to upgrade the current cairo package in buildroot to the 1.8.8 > version. The current package uses cairo-1.6.4 + one patch. > </div><div class="im">> I reapplied manually the patch and found that most of it has already been > applied in the 1.8.8 version, some other part has been rewritten and there > is only one part which bother me. > </div><div class="im">> Does someone know why theses ReleaseSource calls has been added ? > I guess this has something to do with the fact that cairo owns a lock on the > surfaces that requires frequent EngineSync calls when blitting (which slows > down the hardware acceleration), but I'm not really sure. </div>The commit that added ReleaseSurface is a good example of the style that we need to avoid: commit 08516d97a1b34cbb119d6d842ae31e4cb4e08740 Author: Claudio Ciccani <<a href="mailto:klan@directfb.org">klan@directfb.org</a>> Date: Mon Dec 10 18:54:01 2007 +0100 [cairo-directfb] Merging from <a href="http://directfb.org" target="_blank">directfb.org</a> - Improved performance in case of surface conversion: allocate a shadow buffer that can only grow - Fixed support for small surfaces (less than 8x8) - Optimize the blending function according to the surface format - Added _directfb_categorize_operation(): selects the blitting function according to the transform matrix - Avoid inverting the matrix when doing a simple StretchBlit() - Use TextureTriangles() instead of StretchBlit() when scale factors are negative - Added support for ARGB32 fonts (converted to A8 internally) - Removed unused functions (flush() and mark_dirty_rectangle()) - Code cosmetics So we have no idea why ReleaseSurface is required. </blockquote><div> Ok, thanks. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Lionel, can you give a quick pitch on why I should not simply delete the directfb backend? From my reading of the code, it will only attempt to accelerate the simplest of blits and blends [though, that includes solid glyphs]. Everything else will trigger fallbacks. So is there any justification for Cairo to continue to have a DirectFB backend? </blockquote><div> I'm probably not the better person to answer this question. But I can try : DirectFB is still mainly used in environments with a reduced amount of memory. I can speak about set top boxes, where the amount memory needed to decode a full hd video lets a lot less RAM for graphic components. Of courses with Intel CE31xx chips you can rely on the PowerVR's OpenGL/OpenVG implementations to accelerate cairo operations. But some of the biggest chips makers only integrate 2D blitter in their chips and implementing a DirectFB driver remains simpler than an OpenVG one. Blits/blends, it's at least, it's better than nothing... For more, since directfb 1.2, there is a SetMatrix method on the Surface object, currently unused in the cairo backend. (But I know most of the drivers doesn't implement it...) </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'm radically changing the internal interfaces, that will reduce the directfb backend to being basically a wrapper around the image surface, and I'm not sure if that is worth the effort. (The effort principally be in writing better glyph support.) -ickle -- Chris Wilson, Intel Open Source Technology Centre </blockquote></div> Thx for your response. -- Lionel