Yes, that's a possible way to implement this. However, it would artificially introduce the notion of a current context in Gallium. Also, if you mean implementing this as an egl_g3d API, it seems to me you would have to implement the whole st_public_tmp.h for Gallium. This would introduce more artificial notions like framebuffers with front and back attachments, draw and read buffers, texture image binding, and so on.
Instead, the point of accessing a Gallium context is to be able to use *only* pipe_context functions after doing initial setup with EGL (except possibly for presenting the drawn pipe_surface to the user with eglSwapBuffers). So, for instance, setting a framebuffer has to happen via the user calling pipe->set_framebuffer_state, not EGL. EGL only needs to provide a struct pipe_context* (and if pipe_screen had a create_context function like it should, then EGL would only need to provide a pipe_screen*) It also needs to either provide a struct pipe_surface* for the screen or provide an interface to show an user created struct pipe_surface* on the screen.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
