[cairo] Question on DirectFB backend

[Lionel Landwerlin]

On Fri, Nov 20, 2009 at 1:45 PM, Chris Wilson <chris at chris-wilson.co.uk>wrote:

> Excerpts from Lionel Landwerlin's message of Fri Nov 20 09:39:11 +0000
> 2009:
> > Hi folks,
> >
> > I'm working with buildroot (http://buildroot.org/) 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.
> >
> > 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.
> >
> > 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.
>
> The commit that added ReleaseSurface is a good example of the style that we
> need to avoid:
>
> commit 08516d97a1b34cbb119d6d842ae31e4cb4e08740
> Author: Claudio Ciccani <klan at directfb.org>
> Date:   Mon Dec 10 18:54:01 2007 +0100
>
> [cairo-directfb] Merging from directfb.org
>
> - 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.
>

Ok, thanks.


>
> 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?
>

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...)



> 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
>

Thx for your response.

--
Lionel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091120/26f094bf/attachment-0001.htm