On Wed, 9 Mar 2005 17:27:25 +0100, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Quoting Mike Emmel: > > Cairo and a backend for directfb are now checked in under the top > > level cairodfb repository. > > Thanks, I had a quick look. > > > Directfb has no wat to get the top level interface from a sub > > interface making it difficult to get the top DirectFBI interface to do > > further work. > > You can call DirectFBCreate() to get the top level interface > which is a singleton, i.e. subsequent calls to DirectFBCreate() > only increase the reference counter. > > When this counter reaches zero, the core will be shut down. > That may be documented but I did not catch it ... If its not then probably should be made clearer.
> > There is no way to create a compatible surface from a existing surface > > this is quite common and I think should be added. > > IDirectFBSurface::GetCapabilities(), GetSize() and GetPixelFormat() > should be sufficient to fill out the DFBSurfaceDescription. > > But IDirectFBSurface::CreateOffscreenSurface() or similar with some > flags for initializing the new surface, e.g. copy from original, > could be convenient ;) Yes its a pain in the but to do it manually. > > > Cairo does not really support acclerated backends like dfb that are > > very similar to there image surface. I think the dfb backend should > > extend/override the image surface. > > I thought they have other backends that accelerate these operations. > > > Also there is currently no easy way to acclerate the image surface > > other operations using directfb ops that may be accelerated or tuned > > for the platform. > > I had the idea of adding a separate rendering API to DirectFB that > comes as an extra module, because it would be much bigger than the > existing one and should fully support vector graphics operations > as required to fully accelerate cairo, libsvg etc. Not sure thats really that possible with subpixel rendering anti-aliasing etc etc you tend to need the full pipeline design its difficult to split things up easily in a generic manner. I think it is better to export primitive useful functions for these types of pipelines now its not clear what the primitive useful functions actually are. > > The implementation should have a new graphics driver API at the lower end. > Coexistence with the existing driver API should be no problem. Even DRI > coexists with the existing API and in this case both APIs are implemented > in the same driver module, so there's a much better way of transition. > Umm I'll look at that I've not looked at the DRI code any pointers as to what I should look at ? > > So I hope that people intrested in Cairo/Directfb can spend some time > > looking at the design failures I see so we can come up with a better > > integration method for Cairo to direct rendering systems such as > > DirectFB. Please feel free to comment since although I see a number > > of issues I'm not yet clear on the "right" way to fix cairo for > > directfb. > > I'll have a closer look. > Thanks prob something similar to the DRI stuff I think basically you really want to "export" the image data to cairo so it can you it internally. then somehow allow the lowlevel accelerated ops to be accessed. There are locking issues etc etc. > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
