We're basing our system on FreeBSD and there seems to be a DirectFB port, however I don't know how complete it is. For our purpose, as long as it runs on BSD, it's OK.
Johannes Lundberg BRILLIANTSERVICE CO., LTD. <http://www.brilliantservice.co.jp> On Fri, Apr 26, 2013 at 6:46 PM, Ivan Vučica <[email protected]> wrote: > I think David refers to the need to cache as much drawables into > OpenGL/OpenGL ES textures as possible and then composite them on screen > using OpenGL/OpenGL ES. Putting pixels and updating them using 2D drawing > commands ("put a rectangle here", "copy this rectangle into this > rectangle") stops paying off at some point. For example, if you have a lot > of alpha blending, or UI that animates without changing its own content, it > probably makes little sense to do compositing in software. > > I'm not too familiar with DirectFB; does it expose a way to create an > OpenGL context? > > Regards, > > Ivan Vučica > via phone > > On 26. 4. 2013., at 11:32, "Lundberg, Johannes" < > [email protected]> wrote: > > Do you mean that if rendering is offloaded to the CPU the performance > gained from moving from X to DirectFB is not that big? > > For our head mount display all events will be generated from things like > gestures and voice control so we don't really need X for input events. > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. <http://www.brilliantservice.co.jp> > > > On Fri, Apr 26, 2013 at 5:53 PM, Ivan Vučica <[email protected]> wrote: > >> On 26. 4. 2013., at 09:13, David Chisnall <[email protected]> wrote: >> >> > On 26 Apr 2013, at 07:41, "Lundberg, Johannes" < >> [email protected]> wrote: >> > >> >> While we're discussing lower level graphics API I would like to ask >> one more thing. >> >> >> >> What would it take to run GNUstep on DirectFB instead of X? Is this >> possible at this time? >> > >> > Someone did create a DirectFB back end, but it was never pushed >> upstream. I'm not sure it's such an interesting target anymore, because >> with GLES hardware becoming ubiquitous it's more important to be able to >> offload rendering to the GPU (for power efficiency, and also to do >> compositing of complex UIs at a reasonable speed). >> > >> > Note that there are three parts to a back end: >> > >> > - The rendering part, which is responsible for managing graphics >> contexts and putting pixels on the screen (or not - it would be nice to >> have a stub back end for headless applications that wanted to use AppKit >> things for PDF rendering and so on) >> > >> > - The input handling part, which is responsible for mapping host system >> input events to NSEvents for the correct target. >> > >> > - The host environment integration, which includes things like exposing >> the same fonts as other applications and ensuring that copy-and-paste / >> drag-and-drop work with non-GNUstep applications. >> > >> > These are not entirely separated in the back end. It would be nice for >> Ivan's GSoC project to disentangle them a bit more so that each nominal >> back end is formed by cleanly composing classes for each of these things. >> For example, DirectFB will want to supply its own event handling, but will >> reuse the font management via FreeType and will reuse the drawing from >> Cairo / Opal, but will provide its own graphics context setup code. >> > >> > David >> > >> > -- Sent from my Cray X1 >> > >> >> I'll take a look and try to integrate some of that into the proposal. :-) >> >> Regards, >> >> Ivan Vučica >> via phone >> > >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
