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 <ivuc...@gmail.com> wrote: > On 26. 4. 2013., at 09:13, David Chisnall <thera...@sucs.org> wrote: > > > On 26 Apr 2013, at 07:41, "Lundberg, Johannes" < > johan...@brilliantservice.co.jp> 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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
