Unfortunately, the purpose is to provide accelerated DirectFB to end users, so we have no control of the userland application and its associated API's, otherwise we would just be able to provide the 2D api that the copro already provides. Using DFB provides a standardised API to the user over multiple hardware platforms - this is a becoming more and more vital to reduce time to market.
This is starting to look like quite a big job, but any further ideas are more than welcome...!! James 2008/9/23 Clemens Kirchgatterer <[EMAIL PROTECTED]>: > On Tue, 2008-09-23 at 10:16 +0100, James Hughes wrote: > >> If I were to use Voodoo to provide a client/server system on to the >> coprocessor, then I would need to build DirectFB server on the copro, >> which is non-linux based (Nucleus I think). I imagine this may be >> quite a difficult process, but has anyone done this or something >> similar? If so how long did it take? Would I need to implement some >> sort of Linux framebuffer abstraction for the nucleus system, plus OS >> abstractions for things like pthreads which I see is extensively used. > > i wouldn't go the way to wrap all DFB APIs but instead implement a > higher level GUI on the coproc and do a narrow (client server) API > between host and coproc. this works of course only if you have a custum > application and will not work with unmodified DFB apps. if i weouldn't > have my own implementation already i would look at the Evas Canvas. > > good luck! > > clemens > > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
