gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC Mentors Announce] Google Summer of Code 2013


From: Fred Kiefer
Subject: Re: [GSoC Mentors Announce] Google Summer of Code 2013
Date: Sun, 28 Apr 2013 23:08:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

On 26.04.2013 09:13, David Chisnall wrote:
On 26 Apr 2013, at 07:41, "Lundberg, Johannes"
<address@hidden> 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.

We already have a few of the suggested splits in GNUstep back. When Adam rewrote the overall backend structure more than ten years ago we added a split between the class handling the drawing (a subclass of NSGraphicsContext) and the class handling events, resources and environment interaction (a subclass of GSDisplayServer). Font enumeration gets handled by subclasses of GSFontEnumerator and the copy-and-paste code is even in a separate tool. For D&D we currently only have minimal support, the code needs to be moved into to normal event handling to actually work.

In your DirectFB example the FreeType (or rather FontConfig?) support could be directly reused from the cairo backend code and the event and window handling are the bits that need to be written. I would think that they belong into the same class, as that class will need to know about which window an event should be send to and stuff like that, but you could argue here.

There are a lot of things that need a better structure in gui and back, for example font descriptors to make the integration of Opal as a backend easier. But support for a DirectFB backend should be fairly simple even for the current structure.

Fred





reply via email to

[Prev in Thread] Current Thread [Next in Thread]