Hi Timothy, Thanks for your detailed explanation! I have a few questions though..
1. This could be obvious but still, while a thread obtains the hardware Lock and uses OpenGL APIs on a surface (with EGLContext), is it possible that DirectFB APIs can be used to render on the same surface concurrently? Does the "Lock" function (b)lock the surface access from other threads? 2. If the surface/layer is double buffered, then to make the drawings rendered by OpenGL APIs visible we need to call IDirectFBSurface::Flip? This technically means that a module that does the OpenGL rendering has to return the control to the one handling DirectFB APIs to make the drawings visible - is that the case really? Your answers are much appreciated! Sourath On Tue, Jun 1, 2010 at 5:05 AM, Strelchun, Timothy < [email protected]> wrote: > Hi Sourath, > > The IDirectFBGL interface enables the OpenGL API (or OpenGL ES API > depending upon your DirectFB driver set) to be used for rendering 2D/3D > scenes to a DirectFB surface (generally video-memory based) with a > compatible pixel format. I am not sure about other platforms, but on the > Intel(R) CE Media Processors with their IDirectFBGL OpenGL ES 1.1 > implementation, the DirectFB surface can be associated with a display layer > that is single/double/triple buffered, or off-screen that is single/double > buffered. As you've noticed, it can be obtained by calling the desired > destination surface's IDirectFBSurface::GetGL function. > > Taking the OpenGL ES 1.1 API as an example, each IDirectFBGL interface > instance maintains its own EGLContext (and EGLSurfaces if not maintained > elsewhere) that is made current on the calling thread when the Lock function > is called. The client thread can then directly call OpenGL ES functions (or > call them using their pointers obtained by using the GetProcAddress > function, without a compile-time link). Afterwards, the client thread calls > Unlock to make the EGLContext not current on the thread (as well as perform > an implicit glFinish if necessary to complete the rendering requested). The > associated IDirectFBSurface interface can then be used to perform any > desired additional rendering on the surface, followed by a Flip if the > surface is double/triple buffered (instead of eglSwapBuffers) to switch the > front buffer and potentially make it visible if it is a display layer > surface. > > I believe that the Mesa OpenGL library and associated IDirectFBGL interface > plug-in includes a sample (perhaps df_gears?). > > Cheers, > Timothy > > -- > > Timothy Strelchun > CE Software Engineering > Digital Home Group > Intel Corporation > > The views expressed above are my own and not those of Intel > > >-----Original Message----- > >Date: Mon, 31 May 2010 01:43:12 +0530 > >From: Sourath Roy <[email protected]> > >Subject: [directfb-users] IDirectFBGL - what are the use cases? > >To: [email protected] > >Message-ID: > > <[email protected]> > >Content-Type: text/plain; charset="iso-8859-1" > > > >Hi, > >Does anyone know where more documentation on IDirectFBGL can > >be found? I read the reference manual > >here<http://212.227.87.76/docs/DirectFB_Reference_1_2/IDirectFB > >GL.html>and > >there is not much of an information over there on this topic. > >I am interested to know when this interface is useful, is it > >when DirectFB uses the same graphics "layer" as OpenGL on a platform? > >I can also see another GL function in IDirectFBSurface, GetGL. > >So a location where I can find more information on DirectFB > >and OpenGL in general will be helpful. > > > >Thanks in advance! > >Sourath > _______________________________________________ > directfb-users mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users >
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
