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
