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

[Ivan Vučica]

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" <address@hidden> 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.

On Fri, Apr 26, 2013 at 5:53 PM, Ivan Vučica <address@hidden> wrote:

On 26. 4. 2013., at 09:13, David Chisnall <address@hidden> 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.
>
> 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