Re: GDK-DirectFB Patches

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

On Dec 5, 2007 1:17 PM, Carl Worth <cworth cworth org> wrote:
> On Wed, 5 Dec 2007 12:15:38 -0800, "Mike Emmel" wrote:
> > 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.
>
> So that sounds like justification for adding more surface formats to
> cairo. Do you have a short list of "interesting" formats?
>
DirectFB has a loooong list of supported formats :)
Probably some of the YUV are the most interesting ones in this context.
I'd rather not see Cairo polluted with a zillion formats just we might
want to handle
format mismatches better. I actually like the idea of Cairo working
with a small number
of formats and the conversion issue solved elsewhere.

DirectFB is pretty much the exact opposite of cairo rich set of
surface formats and small
number of drawing primitives and at the moment at least maybe not enough.

> > 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.
>
> For performance, that's definitely the case. If you can't accelerate
> everything, it's often much better to not accelerate anything.
>
> And in that case, can't the application just use a cairo image surface
> directly (ignoring for the moment the fact that not all surface
> formats are supported)? That's generally the cairo way of saying
> "please use software rendering only".
>

This becomes a issue with toolkits like GTK that hide the cairo creation.
The best approach depends on how you want to use cairo and the best
approach for DirectFB may not be the best for X11 etc.

In general to get the best configuration you tend to need to know the
capabilities
and the use case. Unfortunately this seems to require some input on
the part of the
user.  Its not so much a issue for Cairo/DirectFB users that are
working directly with both
api's they can make the decision. It more a issue for wrapping
toolkits that try and hide
this.




> > 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.
>
> Above we were talking about performance, right? And here you are
> talking about incorrect results, right? What's the cause of this? Is
> it that cairo-directfb is just broken?
>
I've not tested the latest sets of accelerated functions. Some where
turned off earlier
because they where just broken. But I'm talking about both performance
and incorrect interleaved results.

If cairo is using a temp buffer thats only created if needed and
flushed when requested and your also
say using a directfb call say fill rectangle.  The you need to flush
before the fill rect.

No problem just use the flush apis right ?
But this means that code written for X11 works just fine while
DirectFB is "broken".
The real answer is that the cairo api is being used incorrectly
because it just works right under Gtk/X11.
I'm guessing that you might run into the same situation under X11 in
cases that your using the image fallback.

I'm not convinced that I can always provide the fastest correct
solution given the api's and the way the various
backends work.

The right answer my be something as simple is letting the application
provide the fallback buffer.
Then it can decide how it want to handle software fallbacks.





> For interleaving cairo and non-cairo rendering, cairo provides the
> cairo_surface_flush and cairo_surface_mark_dirty APIs. Does
> cairo-directfb implement those and does your application use them.
>
In this case the issue is GTK/Pango which does not use these api's.
I may well be out of date on this its been a while since I looked.
Also the application developer using cairo inside GTK may need to make
use of these api's.
So we may need some more documentation on cairo/GTK.




> > > 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.
>
> I still don't understand the issue. Can you explain more please?
>
Sorry  we would need a suite of DirectFB specific tests and
potentially some gtk ones
to ensure this was working correctly. Its outside the scope of pure cairo.
Its not a cairo problem its a DirectFB/ GTK/DirectFB issue.


> -Carl
>