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.
>
>
> 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
