Re: GDK-DirectFB Patches

["Mike Emmel" <mike emmel gmail com>]

On Dec 5, 2007 10:40 AM, Carl Worth <cworth cworth org> wrote:
> On Wed, 5 Dec 2007 10:22:08 -0800, "Mike Emmel" wrote:
> > Hi Carl Claudio one of the main directfb developers has a lot of cairo
> > patches setting on the directfb git server.
> > One can you give him check-in rights for Cairo.
>
> Here's the process to ask for that (ignore the "CVS" in the title, of
> course):
>
>         http://freedesktop.org/wiki/AccountRequests
>
> I'd feel fine for Claudio to directly push anything that touches only
> cairo-directfb-surface.c. Patches that touch other files in cairo
> should be sent to the cairo mailing list first. Especially API
> additions must be discussed on the list first, (even
> cairo-directfb-specific API additions).
>
> > And next we need to make sure that we are not breaking gdk.  One
> > approach may mean to pass in a features arg
> > when initializing Cairo.  It could be a simple bool accel or no
> > acceleration.
>
> I'm not interested in anything like that at all. If it's not correct,
> then it's not acceleration---it's just broken.
>

Well not quite. One of the problems is that DirectFB directly supports
a lot of surface formats
not supported by Cairo but it does not have the complex drawing api.
When you dealing with incompatible surface formats and software fallbacks it
tends to be better to just use the fallbacks instead of trying to
interleave accelerated direct calls
and redirected software fallbacks.  I've not come up with a general
way to interleave a Cairo context
with directfb calls. So depending on how you do things you can get
unexpected results.
The only perfect answer is for DirectFB/Cairo to never use software fallbacks.



> > For the secondary ports its not easy to do comprehensive testing so I
> > think its useful.
>
> What's the difficulty of testing cairo-directfb within cairo's test
> suite?
>

See above so far its the mixed use case that can trip things up.

> -Carl
>