On Sun, Nov 15, 2009 at 06:56:26PM +0000, Jakob Bornecrantz wrote:
> Hi I'm sorry for taking this long to respond.
> The basic idea is to create API struct that holds the functions for
> the different APIs and then just switch between those in EGL. There
> are also some changes to the in the way that framebuffers works. I
> have started to change the egl_xlib driver but haven't gotten that
> far.
> I have attached a patch series that adds the API and the work in
> progress conversion of egl_xlib. Please feel free to continue on the
> egl_xlib stuff.
I was busy with the opengl-es branch last week, and don't have the time
to think about it until now. Sorry for the delay.
I like the idea of st_framebuffer, and I am thinking about how EGLImage
can be supported. That is, a texture image or a renderbuffer can be
used to create an EGLImage which is shared with other APIs. And through
extensions such as GL_OES_EGL_image, an EGLImage (created from a
NativePixmap or other APIs' resources) can be used as a texture image or
renderbuffer.
It seems that an EGLImage can be mapped to an st_framebuffer without
flush_front. Then what's lacking is a way for client APIs to look up
the backing st_framebuffer of an EGLImage, as needed by GL_OES_EGL_image
and others. Maybe something like
struct st_co_api
{
struct st_framebuffer *(*lookup_framebuffer)(void *eglimage);
}
and a way to pass it to the client APIs?
--
Regards,
olv
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
