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? > 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". > 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? 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. > > 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? -Carl
Attachment:
pgpK8d0Yw4txJ.pgp
Description: PGP signature